From Olaf.Bonness@telekom.de Fri Apr 1 00:33: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 D5DD23A691A for ; Fri, 1 Apr 2011 00:33:08 -0700 (PDT) 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.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 D+M-McpilSpO for ; Fri, 1 Apr 2011 00:33:07 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 89F333A6A87 for ; Fri, 1 Apr 2011 00:33:06 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 01 Apr 2011 09:34:44 +0200 Received: from S4DE9JSAACX.ost.t-com.de ([10.125.177.232]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 09:34:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 09:34:42 +0200 Message-ID: <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Happy Eyeballs - Exit strategies? Thread-Index: AcvwOKIU3PxUKp/sRVqjQu5EAATqXwABK6nw References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> From: To: X-OriginalArrivalTime: 01 Apr 2011 07:34:44.0017 (UTC) FILETIME=[44ECDA10:01CBF03F] Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 07:33:08 -0000 Thx Scott, for this clarification. Unfortunately I havn't found a = recommendation for the default P value in the I-D. Would it make sense = to also think about a general method how this default P value can be = adjusted over time refelecting the increase of unbroken IPv6 = connectivity?=20 I don't think that the standard user can/will do this adjustement and = fine triggering. Kind regards Olaf=20 > -----Urspr=FCngliche Nachricht----- > Von: Scott Brim [mailto:scott.brim@gmail.com]=20 > Gesendet: Freitag, 1. April 2011 08:47 > An: Bonne=DF, Olaf > Cc: hagen@jauu.net; v6ops@ietf.org > Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? >=20 > Happy eyeballs is eminently configurable. For IPv4/v6, you could > initialize the P value so that it never tries IPv4 unless there are > extreme delays in getting an IPv6 connection. You could also > parameterize P adjustment behavior. >=20 > Scott >=20 > On Thu, Mar 31, 2011 at 19:47, wrote: > > Hi Hagen, > > > > as I tried to explain: If the HE approach remains in the=20 > network without a dedicated exit strategy than all the=20 > clients outthere will go on trying to connect via IPv4 (see=20 > "flashing the destination P value every 10 min") also in the=20 > case when there is already a better IPv6 connectivity is available. > > > > According to Gerds proposal this will end when there is no=20 > A record for the destination is available anymore or the=20 > client is IPv6-only. Gerd is of course right but the problem=20 > with this approach is, that it simply relies on the=20 > assumption that all the people are accordingly updating there=20 > DNS records. > > > > Besides that, one of the IETF standardization basics is to=20 > also think about exit strategies for mechanisms and protocols=20 > they standardize. > > I hope that I could make my position a bit more clear. > > > > Regards > > =A0 =A0 =A0 =A0Olaf > > > > PS: IMHO, HE is a very useful and needed mechanism (that=20 > may perhaps have some room for improvement), and thats why I=20 > definitely don't share your classification of this mechanism. > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Hagen Paul Pfeifer [mailto:hagen@jauu.net] > >> Gesendet: Donnerstag, 31. M=E4rz 2011 19:26 > >> An: Bonne=DF, Olaf > >> Cc: gert@space.net; v6ops@ietf.org > >> Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? > >> > >> * Olaf.Bonness@telekom.de | 2011-03-31 11:32:36 [+0200]: > >> > >> >Hmm I've made the experience that DNS records are very often > >> not at such an > >> >actualized status as they should be. > >> > >> >Besides that this (sit back and wait) seems not be an an > >> acceptable exit > >> >strategy from a provider point of view. (The same applies > >> also to the "wait > >> >until the last IPv4 user died" approach.) > >> > >> What are these drawbacks that makes Happy Eyeball approach > >> somewhat stinking? > >> Why is Gert's reply not adequate from a provider point of view? > >> > >> Hagen > >> > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 From roberta.maglione@telecomitalia.it Fri Apr 1 00:55: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 B98DE28C0F3 for ; Fri, 1 Apr 2011 00:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=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 2vwzxfOpgjnW for ; Fri, 1 Apr 2011 00:55:02 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id C19C528C104 for ; Fri, 1 Apr 2011 00:55:01 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Apr 2011 09:56:39 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 1 Apr 2011 09:56:39 +0200 From: Maglione Roberta To: "'v6ops@ietf.org'" Date: Fri, 1 Apr 2011 09:56:33 +0200 Thread-Topic: comments on stateless mechanism presentation Thread-Index: AcvwQlvUx+bGZIDSTSOZkJBL8lnYrg== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB294EF8A@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] comments on stateless mechanism presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 07:55:02 -0000 Hello, I would like to try to clarify the comment I made yesterday on slide 6. The third bullet of this slide says: "ISPs may adopt flexible address rules, no extra requirements on address fo= rmat and address allocation" My understanding of this is that the purpose of this slide is to compare th= e impacts of the different transition mechanisms have on the address alloca= tion scheme that the ISP has to use. dIVI uses a specific format to build the IPv6 address, made by concatenatin= g an IPv6 prefix with an IPv4 + a port, thus it introduces some constrains = on the addresses scheme to be used in the network While DS-Lite does not have any specific requirement on the IPv6 prefix del= egated to the customers. The table in slide 6 in the first column for DS-LIte says: "Address of the tunnel end to be passed" This sentence refers to the address of the AFTR that needs to be provisione= d on the B4 in order to allow the B4 to setup the IPv4 over IPv6 tunnel. This is a provisioning issue (and BTY it solved by DHCPv6 option specified = in draft-ietf-softwire-ds-lite-tunnel-option, now in RFC queue). This point is NOT related to the address allocation scheme to be used by th= e ISP, thus I don't think it should appear in this table. If you want to compare the provisioning aspects of the different techniques= I would suggest adding a separate slide for them. Going to your slide 11: Flexible addressing In my opinion DS-Lite has some advantages compared to dIVI on Flexible addr= essing point because, as I said before, DS-Lite does not requires a specifi= c format for the IPv6 prefix. Thanks, Regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Ted.Lemon@nominum.com Fri Apr 1 01: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 E97463A63CB for ; Fri, 1 Apr 2011 01:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 jimPeZipF4zo for ; Fri, 1 Apr 2011 01:41:08 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 0F6AE3A63D2 for ; Fri, 1 Apr 2011 01:41:07 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTZWQB2KSsMiMgRYkYJmwZC3JapVrFnor@postini.com; Fri, 01 Apr 2011 01:42:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3D55DF80D9 for ; Fri, 1 Apr 2011 01:42:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A2CA8190064; Fri, 1 Apr 2011 01:42:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [130.129.17.119] (130.129.17.119) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.255.0; Fri, 1 Apr 2011 01:42:46 -0700 References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> In-Reply-To: <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> MIME-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: <5A90C8B8-96A3-4B73-9EA7-A359B2ABD3A5@nominum.com> X-Mailer: iPhone Mail (8B117) From: Ted Lemon Date: Fri, 1 Apr 2011 10:42:05 +0200 To: "" X-Originating-IP: [130.129.17.119] Cc: "" , "" Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 08:41:09 -0000 On Apr 1, 2011, at 9:34 AM, wrote: > I havn't found a recommendation for the default P value in the I-D. Would i= t make sense to also think about a general method how this default P value c= an be adjusted over time refelecting the increase of unbroken IPv6 connectiv= ity? My first reaction to this was to propose sending p in a DHCP or RA option, b= ut then I realized that in the end case, p will not matter because the HE im= plementation will have no IPv4 configuration, and therefore will not be send= ing any IPv4 packets regardless of p.=20= From Olaf.Bonness@telekom.de Fri Apr 1 02: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 1A5423A679F for ; Fri, 1 Apr 2011 02:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVusNNBBUa+1 for ; Fri, 1 Apr 2011 02:16:52 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 3D8C43A6774 for ; Fri, 1 Apr 2011 02:16:52 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 01 Apr 2011 11:15:59 +0200 Received: from S4DE9JSAACX.ost.t-com.de ([10.125.177.232]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 11:15:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 11:15:57 +0200 Message-ID: <8A34913DF3402341B6E0AF5FD0E8BBA708B75F5E@S4DE9JSAACX.ost.t-com.de> In-Reply-To: <5A90C8B8-96A3-4B73-9EA7-A359B2ABD3A5@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Happy Eyeballs - Exit strategies? Thread-Index: AcvwSMqRpCuLfKQxRwSc+Q1MBspm0AAAw7MA References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> <5A90C8B8-96A3-4B73-9EA7-A359B2ABD3A5@nominum.com> From: To: X-OriginalArrivalTime: 01 Apr 2011 09:15:58.0419 (UTC) FILETIME=[698D0A30:01CBF04D] Cc: v6ops@ietf.org, scott.brim@gmail.com Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 09:16:53 -0000 Hi Ted, hmmm I'm not sure if I got you right. What do you understand under "end case when the HE implementation will = have no IPv4 configuration"?=20 IMHO the "interesting" phase is the long time interval when the IPv6 = Internet connectivity is comparable to (or better than) the IPv4 one, = but an IPv4 addressing of services is still heavilly used and IPv4 is = far from beeing switched off. For this time range a DHCPv6 or RA option for proposing an useful P = value to the users could perhaps help. Regards Olaf > -----Urspr=FCngliche Nachricht----- > Von: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Gesendet: Freitag, 1. April 2011 10:42 > An: Bonne=DF, Olaf > Cc: ; > Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? >=20 > On Apr 1, 2011, at 9:34 AM, wrote: >=20 > > I havn't found a recommendation for the default P value in=20 > the I-D. Would it make sense to also think about a general=20 > method how this default P value can be adjusted over time=20 > refelecting the increase of unbroken IPv6 connectivity? >=20 > My first reaction to this was to propose sending p in a DHCP=20 > or RA option, but then I realized that in the end case, p=20 > will not matter because the HE implementation will have no=20 > IPv4 configuration, and therefore will not be sending any=20 > IPv4 packets regardless of p.=20 >=20 From ggm+ietf@apnic.net Fri Apr 1 06:32: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 ABA183A686A for ; Fri, 1 Apr 2011 06:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 IzSGzm4t-SZO for ; Fri, 1 Apr 2011 06:32:19 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4CD143A687A for ; Fri, 1 Apr 2011 06:28:58 -0700 (PDT) Received: from dhcp-54ae.meeting.ietf.org (dhcp-54ae.meeting.ietf.org [130.129.84.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C9879B6731; Fri, 1 Apr 2011 23:30:35 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Fri, 1 Apr 2011 15:30:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <813A104C-AE82-48F5-ADB5-760005C50AC7@ecs.soton.ac.uk> <4D9433B3.9040206@kit.edu> <9D6FD1CD-660C-462F-9512-53A01AD3D8D3@ecs.soton.ac.uk> <67253A6C-9AC1-4AC6-949C-A6D76505A316@apnic.net> <427CCB3F-7A1B-4790-9C92-7DBBB715FD0E@apnic.net> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] RAmond Download URL X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 13:32:20 -0000 I re-ran my checks over one days worth of reverse-DNS. You are right, the non-FF:FE encoding now overwhelmingly predominates. the top ten: VMWARE 17 DELL 21 SYNOLOGY 25 USC-INFORMAT 40 INTEL 44 ASUSTEK 48 XEROX 49 1523 APPLE 3530 nonOUI 19311 I pulled the IEEE registry today, so the high suggests some = people are being creative inside 2002: probably privacy mode. Noting that, the largest single vendor of IPv6 active equipment which is = demonstrably NOT a gateway box..=20 -G= From fred@cisco.com Fri Apr 1 07:07:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5285E3A6856 for ; Fri, 1 Apr 2011 07:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.531 X-Spam-Level: X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbWcNNn4Lj2T for ; Fri, 1 Apr 2011 07:07:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 28EC93A6835 for ; Fri, 1 Apr 2011 07:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=12871; q=dns/txt; s=iport; t=1301666935; x=1302876535; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=5fJy+vk6LUdKq+A/BDBB+p1I7eClDcK81n8oyIIVRcQ=; b=JkLsPo9j7n6QS2hhaGaLkXVYba12Tggp6+TifsQhq6bfLKJO/LAzAkKu HDdifSqa/gx94Kfuq5R3aiLuD79IVYuTtUubu2QU3j7tXc+bZUbbxAbTY drMDMH2cFTkc9DcvD7a2fuVjToak3Cy35z7znX20SVPJ+GIdEjdZ3ynZx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAADjblU2Q/khNgWdsb2JhbACYGo09FAEBCwsmJYh5nG6cPoVrBI0bg1k X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="81840965" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2011 14:08:53 +0000 Received: from dhcp-4213.meeting.ietf.org (dhcp-10-55-92-242.cisco.com [10.55.92.242]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p31E8qmd005283 for ; Fri, 1 Apr 2011 14:08:53 GMT Received: from [127.0.0.1] by dhcp-4213.meeting.ietf.org (PGP Universal service); Fri, 01 Apr 2011 16:08:53 +0200 X-PGP-Universal: processed; by dhcp-4213.meeting.ietf.org on Fri, 01 Apr 2011 16:08:53 +0200 From: Fred Baker Date: Fri, 1 Apr 2011 16:08:42 +0200 References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> To: IPv6 Ops WG Message-Id: <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 01 Apr 2011 14:07:16 -0000 As promised Thursday... This is some ruminations I had regarding CPE routers and shared with the = design team.=20 Begin forwarded message: > From: Fred Baker > Date: March 28, 2011 4:36:28 AM GMT+02:00 > To: > Cc: cpe-router@external.cisco.com > Subject: Re: [v6ops] I-D = Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > On Mar 27, 2011, at 11:22 PM, Frank Bulk wrote: >=20 >> Thanks for the diagram. Because we're talking about multi-homing, >> multi-routers, and stacked routers, it may be helpful to create an >> exhaustive set of diagrams that cover each scenario so we can be on = the same >> page when talking about this bis draft and also work through our = ideas in >> each of the scenarios. >>=20 >> It may end up that the scope of this draft is reduced to just a few >> scenarios, even though we may *want* to tackle them all. =20 >>=20 >> Frank >=20 >=20 > Copying the design team; I don't want them to take this as direction, = but it might be appropriate input to their thoughts. >=20 > My personal opinion: the use case for a residential or SOHO network is = very simple. A common one - the one in my children's homes - is "I have = a router and it connects me to the Internet", as James Woodyat has = spoken about. This was the only case discussed in = draft-ietf-v6ops-cpe-router: >=20 > 1) Simple Residential Network >=20 > `. ISP ,' > `--+--' > | > +-----+-----+ > |Residential| > |CPE Router | > +-----+-----+ > | > `----------+---------- > Wired and Wireless LAN >=20 > A variation on that is Cisco's recommendation for its telecommuter = population (which is perhaps 1/3 of the company, at least part-time): we = use an 8xx series router, split the four "inside" ports between two or = more subnets, one of which is for the telecommuter's home office, and = provide a wireless access for use by the telecommuter. In my case, I = don't use the wireless capability, as wired is more reliable and I = pretty much sit at a desk; I instead have a 24 port 10/100/1000 switch = wired to the various rooms in my home, including two 802.11g access = points that effectively extend that LAN throughout the house. The latter = are, however, a technical detail; if I chose to, I imagine I could build = that all into a higher end router. >=20 > 2) Multi-LAN Residential Network >=20 > `. ISP ,' > `--+--' > | > +-------+-------+ > | Residential | > | CPE Router | > +-+-----+-----+-+ > | | | > ` --+-- --+-- --+-- > Wired and Wireless LANs >=20 > There are two obvious implementations of a multi-LAN residential = network: one could implement separate subnets and route between them, = and one could implement an ND Proxy and bridge between them. I suspect = both implementations have their cases, and should be treated as the = "routed" and "ND-proxy" subcases of the form. >=20 > For internal structure, I think the case I mentioned should be = present, if only because it represents the most general case: >=20 > 3) Multi-router subnetted network >=20 > This again has two sub-cases; it could be literally a tree, as I have = drawn it, or could include some amount of complexity such as = interconnecting some of the non-backbone subnets. I might call those = "tree" and "redundant" networks. >=20 > \ ISP / > `--+--' > | > +--+---+ > | CPE | > |Router| > +---+--+ > | Home backbone LAN > -----+----------+-+--------+----------+--- > | | | | > +---+--+ +---+--+ +---+--+ +---+--+ > |His | |Her | |A/V | |HAN | > |Office| |Office| |LAN | |Router| > |Router| |Router| |Router| +--+---+ > +---+--+ +---+--+ +---+--+ | > | | | | > -------+--- -----+--- -----+--- ----+---- >=20 > There are two more bits of complexity that should not be omitted: = multihoming, and redundant paths. These are each, I think, special cases = of the first three, such as >=20 > 4) Multihomed network >=20 > The most common version of a multihomed network, I suspect, is a = network in a home where multiple people have offices, virtual or = physical, and whose companies have similar information security policies = to Cisco's; James Polk could give you some insight there, as Motorola = required his wife to maintain similar separation between work and home. = The amusing thing was that he could hear her on the phone. As in case 2, = each had a router that provided them access to both a "secured" subnet = for their office and an "unsecured" subnet for the home; they connected = the "unsecured" subnets on the home LAN. Jari Arkko's home is another = example, although to my knowledge his wife doesn't work outside the home = - he simply chooses to have multiple upstreams. So the key = differentiation in this case is that it has multiple upstreams. >=20 > \ /\ / > \ ISP / \ ISP / > `--+--' `--+--' > | | > +--+---+ +--+---+ > | CPE | | CPE | > |Router| |Router| > +---+--+ +---+--+ > | | Home backbone LAN > -----+-+--------+-+--------+----------+--- > | | | | > Various variations on cases 1, 2, and 3 >=20 > So, for my money, six cases and subcases: > 1) Simple residential network > 2a) Routed Multi-LAN Residential Network > 2b) ND-Proxy Multi-LAN Residential Network > 3a) Tree Multi-router subnetted network > 3b) Redundant Multi-router subnetted network > 4) Multihomed Network >=20 > The most general case, of course, is a multihomed redundant = multi-router subnetted network. This begins to look like an SMB network, = and might want to be called out explicitly: >=20 > 4b) Multihomed Redundant Multi-router subnetted network >=20 > \ /\ / > \ ISP / \ ISP / > `--+--' `--+--' > | | > +--+---+ +--+---+ > | CPE | | CPE | > |Router| |Router| > +---+--+ +---+--+ > | | Home backbone LAN > -----+-+--------+-+--------+----------+--- > | | | | | > +---+--+ +---+--+ +---+--+ | +---+--+ > |His | |Her | |A/V +-+ |HAN | > |Office| |Office| |LAN | +-+Router| > |Router| |Router| |Router| | +--+---+ > +---+--+ +---+--+ +---+--+ | | > | | | | > -------+--- -----+--- -----+--- ----+---- >=20 > As far as the cases we want to cover or not cover; IMHO, if our = solution to the tougher problems, such as the subnet delegation model, = doesn't work in 4b, we're not really done. That said, for most = residential/SOHO purposes, we're talking about (1), (2a), (2b), and = (3a). >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Fred Baker >> Sent: Thursday, March 17, 2011 5:03 PM >> To: Templin, Fred L >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] I-D = Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >>=20 >> On Mar 17, 2011, at 2:29 PM, Templin, Fred L wrote: >>=20 >>> Hi Fred, >>>=20 >>> What I mean to say is that when a host on the LAN >>> side of CE 'A' sends packets to a host on the LAN >>> side of CE 'B', 'A' has to figure out what to do >>> with them since it all it has in its routing table >>> is a default route. >>=20 >> In any context where routing comes up, there is more than one LAN in = the >> local area, and the question is how to get a datagram from one to the = other. >> Consider this simplistic case: >>=20 >> ISP >> | >> +--+---+ >> | CPE | >> |Router| >> +--+---+ >> ------+-------+----------------+----- >> +--+--+ +---+--+ >> |Alice| |Router| >> +-----+ +--+---+ >> ----+----+-------- >> +-+-+ >> |Bob| >> +---+ >>=20 >> Alice wants to send a datagram to Bob, and because she got her RA = from the >> CPE, considers the CPE her default gateway. So sends the datagram to = Bob's >> address at the IP layer, and to the CPE's address at the link layer. >>=20 >> If you are expecting the CPE to respond with a redirect to the other = router >> in the picture, the CPE has to know that the other router is a router = and >> has a LAN behind it, and specifically the LAN that Bob's subnet is = on. More >> generally, in a home that has them all, one could readily imagine >>=20 >> ISP >> | >> +--+---+ >> | CPE | >> |Router| >> +---+--+ Home backbone LAN >> -----+----------+-+--------+----------+--- >> +---+--+ +---+--+ +---+--+ +---+--+ >> |His | |Her | |A/V | |HAN | >> |Office| |Office| |LAN | |Router| >> |Router| |Router| |Router| +--+---+ >> +---+--+ +---+--+ +---+--+ | >> -------+--- -----+--- -----+--- ----+---- >>=20 >> If "Alice" is in "Her Office" and "Bob" is in "His Office", how does = Alice's >> router know where the default route should point to? What is its = "default >> gateway"? >>=20 >> I understand your point that if you have a trivially simple network, = with >> one router and everything attached to it, it knows what you're doing. >> Predicating everything on that simplistic picture is, in my = experience, >> naive. >>=20 >>> So, 'A' bounces the initial packets off its default >>> router 'C' which forwards them to 'B' but also >>> returns redirection messages to 'A'. >>>=20 >>> 'C' can know about 'B' if it has full topology >>> information, but it is possible that 'C' also has >>> only partial topology information and has to default >>> route the initial packets through some higher level >>> gateway 'D'. 'D' can then forward the packets on >>> towards 'B', and can return redirection messages >>> to 'C', then 'C' can proxy the redirection messages >>> back to 'A'. >>>=20 >>> So, there can be a hierarchy of proxying gateways >>> in the operator's network, where each higher layer >>> in the hierarchy has more topology information than >>> the layer below it. I'm not quite asking for the same >>> thing as a full-up ND_Proxy, however, since all I'm >>> asking for is proxying of redirection messages. >>>=20 >>> Was this informational or obfuscational? >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com=20 >>>=20 >>>> -----Original Message----- >>>> From: Fred Baker [mailto:fred@cisco.com]=20 >>>> Sent: Thursday, March 17, 2011 2:10 PM >>>> To: Templin, Fred L >>>> Cc: Hemant Singh (shemant); Cameron Byrne; IPv6 Ops WG >>>> Subject: Re: [v6ops] I-D=20 >>>> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>>>=20 >>>> Really? How does the router emitting the ICMP Redirect learn=20 >>>> where routes should be directed to? How does it compare them? >>>>=20 >>>> On Mar 17, 2011, at 1:55 PM, Templin, Fred L wrote: >>>>=20 >>>>>=20 >>>>> Regarding scaling, there is another way to do dynamic >>>>> routing when traditional proactive routing protocols >>>>> like OSPFv3 and RIPng cannot be used. For example, if >>>>> the CEs and BRs can be represented as neighbors on a >>>>> virtual NBMA link, then ICMP redirection can be used. >>>>>=20 >>>>> This would be classified as an on-demand (instead of >>>>> proactive) dynamic routing protocol, and so does not >>>>> need to hold non-essential routes in the RIB. >>>>>=20 >>>>> I have specified a way to do this for ISATAP in the >>>>> latest VET spec (draft-templin-intarea-vet) but the >>>>> same method can be applied to other mainfestations >>>>> of virtual NBMA links as well. >>>>>=20 >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Fri Apr 1 11: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 93ED13A6911 for ; Fri, 1 Apr 2011 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 QeVXWlA1HUga for ; Fri, 1 Apr 2011 11:12:23 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 1FB9D3A690D for ; Fri, 1 Apr 2011 11:12:23 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p31IDuSK015059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2011 11:13:57 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p31IDuQn014190; Fri, 1 Apr 2011 11:13:56 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p31IDug1014177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 1 Apr 2011 11:13:56 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 1 Apr 2011 11:13:56 -0700 From: "Templin, Fred L" To: Fred Baker , IPv6 Ops WG Date: Fri, 1 Apr 2011 11:13:54 -0700 Thread-Topic: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvwdl2oP0eEK4FVQmSvUfdV9tmWrQAIevSQ Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> In-Reply-To: <14D633B3-6087-4303-8A84-0D84D11CCFA4@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 Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 01 Apr 2011 18:12:24 -0000 Hi Fred, Not sure if you were looking for feedback on this, but all of these SOHO-network-behind-the-CPE scenarios you outlined have one thing in common - they can all be supported by ISATAP. Is it too early to introduce that into the discussion? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Fred Baker > Sent: Friday, April 01, 2011 7:09 AM > To: IPv6 Ops WG > Subject: [v6ops] Fwd: I-D=20 > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > As promised Thursday... >=20 > This is some ruminations I had regarding CPE routers and=20 > shared with the design team.=20 >=20 > Begin forwarded message: >=20 > > From: Fred Baker > > Date: March 28, 2011 4:36:28 AM GMT+02:00 > > To: > > Cc: cpe-router@external.cisco.com > > Subject: Re: [v6ops] I-D=20 > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > On Mar 27, 2011, at 11:22 PM, Frank Bulk wrote: > >=20 > >> Thanks for the diagram. Because we're talking about multi-homing, > >> multi-routers, and stacked routers, it may be helpful to create an > >> exhaustive set of diagrams that cover each scenario so we=20 > can be on the same > >> page when talking about this bis draft and also work=20 > through our ideas in > >> each of the scenarios. > >>=20 > >> It may end up that the scope of this draft is reduced to just a few > >> scenarios, even though we may *want* to tackle them all. =20 > >>=20 > >> Frank > >=20 > >=20 > > Copying the design team; I don't want them to take this as=20 > direction, but it might be appropriate input to their thoughts. > >=20 > > My personal opinion: the use case for a residential or SOHO=20 > network is very simple. A common one - the one in my=20 > children's homes - is "I have a router and it connects me to=20 > the Internet", as James Woodyat has spoken about. This was=20 > the only case discussed in draft-ietf-v6ops-cpe-router: > >=20 > > 1) Simple Residential Network > >=20 > > `. ISP ,' > > `--+--' > > | > > +-----+-----+ > > |Residential| > > |CPE Router | > > +-----+-----+ > > | > > `----------+---------- > > Wired and Wireless LAN > >=20 > > A variation on that is Cisco's recommendation for its=20 > telecommuter population (which is perhaps 1/3 of the company,=20 > at least part-time): we use an 8xx series router, split the=20 > four "inside" ports between two or more subnets, one of which=20 > is for the telecommuter's home office, and provide a wireless=20 > access for use by the telecommuter. In my case, I don't use=20 > the wireless capability, as wired is more reliable and I=20 > pretty much sit at a desk; I instead have a 24 port=20 > 10/100/1000 switch wired to the various rooms in my home,=20 > including two 802.11g access points that effectively extend=20 > that LAN throughout the house. The latter are, however, a=20 > technical detail; if I chose to, I imagine I could build that=20 > all into a higher end router. > >=20 > > 2) Multi-LAN Residential Network > >=20 > > `. ISP ,' > > `--+--' > > | > > +-------+-------+ > > | Residential | > > | CPE Router | > > +-+-----+-----+-+ > > | | | > > ` --+-- --+-- --+-- > > Wired and Wireless LANs > >=20 > > There are two obvious implementations of a multi-LAN=20 > residential network: one could implement separate subnets and=20 > route between them, and one could implement an ND Proxy and=20 > bridge between them. I suspect both implementations have=20 > their cases, and should be treated as the "routed" and=20 > "ND-proxy" subcases of the form. > >=20 > > For internal structure, I think the case I mentioned should=20 > be present, if only because it represents the most general case: > >=20 > > 3) Multi-router subnetted network > >=20 > > This again has two sub-cases; it could be literally a tree,=20 > as I have drawn it, or could include some amount of=20 > complexity such as interconnecting some of the non-backbone=20 > subnets. I might call those "tree" and "redundant" networks. > >=20 > > \ ISP / > > `--+--' > > | > > +--+---+ > > | CPE | > > |Router| > > +---+--+ > > | Home backbone LAN > > -----+----------+-+--------+----------+--- > > | | | | > > +---+--+ +---+--+ +---+--+ +---+--+ > > |His | |Her | |A/V | |HAN | > > |Office| |Office| |LAN | |Router| > > |Router| |Router| |Router| +--+---+ > > +---+--+ +---+--+ +---+--+ | > > | | | | > > -------+--- -----+--- -----+--- ----+---- > >=20 > > There are two more bits of complexity that should not be=20 > omitted: multihoming, and redundant paths. These are each, I=20 > think, special cases of the first three, such as > >=20 > > 4) Multihomed network > >=20 > > The most common version of a multihomed network, I suspect,=20 > is a network in a home where multiple people have offices,=20 > virtual or physical, and whose companies have similar=20 > information security policies to Cisco's; James Polk could=20 > give you some insight there, as Motorola required his wife to=20 > maintain similar separation between work and home. The=20 > amusing thing was that he could hear her on the phone. As in=20 > case 2, each had a router that provided them access to both a=20 > "secured" subnet for their office and an "unsecured" subnet=20 > for the home; they connected the "unsecured" subnets on the=20 > home LAN. Jari Arkko's home is another example, although to=20 > my knowledge his wife doesn't work outside the home - he=20 > simply chooses to have multiple upstreams. So the key=20 > differentiation in this case is that it has multiple upstreams. > >=20 > > \ /\ / > > \ ISP / \ ISP / > > `--+--' `--+--' > > | | > > +--+---+ +--+---+ > > | CPE | | CPE | > > |Router| |Router| > > +---+--+ +---+--+ > > | | Home backbone LAN > > -----+-+--------+-+--------+----------+--- > > | | | | > > Various variations on cases 1, 2, and 3 > >=20 > > So, for my money, six cases and subcases: > > 1) Simple residential network > > 2a) Routed Multi-LAN Residential Network > > 2b) ND-Proxy Multi-LAN Residential Network > > 3a) Tree Multi-router subnetted network > > 3b) Redundant Multi-router subnetted network > > 4) Multihomed Network > >=20 > > The most general case, of course, is a multihomed redundant=20 > multi-router subnetted network. This begins to look like an=20 > SMB network, and might want to be called out explicitly: > >=20 > > 4b) Multihomed Redundant Multi-router subnetted network > >=20 > > \ /\ / > > \ ISP / \ ISP / > > `--+--' `--+--' > > | | > > +--+---+ +--+---+ > > | CPE | | CPE | > > |Router| |Router| > > +---+--+ +---+--+ > > | | Home backbone LAN > > -----+-+--------+-+--------+----------+--- > > | | | | | > > +---+--+ +---+--+ +---+--+ | +---+--+ > > |His | |Her | |A/V +-+ |HAN | > > |Office| |Office| |LAN | +-+Router| > > |Router| |Router| |Router| | +--+---+ > > +---+--+ +---+--+ +---+--+ | | > > | | | | > > -------+--- -----+--- -----+--- ----+---- > >=20 > > As far as the cases we want to cover or not cover; IMHO, if=20 > our solution to the tougher problems, such as the subnet=20 > delegation model, doesn't work in 4b, we're not really done.=20 > That said, for most residential/SOHO purposes, we're talking=20 > about (1), (2a), (2b), and (3a). > >=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf Of > >> Fred Baker > >> Sent: Thursday, March 17, 2011 5:03 PM > >> To: Templin, Fred L > >> Cc: IPv6 Ops WG > >> Subject: Re: [v6ops] I-D=20 > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>=20 > >>=20 > >> On Mar 17, 2011, at 2:29 PM, Templin, Fred L wrote: > >>=20 > >>> Hi Fred, > >>>=20 > >>> What I mean to say is that when a host on the LAN > >>> side of CE 'A' sends packets to a host on the LAN > >>> side of CE 'B', 'A' has to figure out what to do > >>> with them since it all it has in its routing table > >>> is a default route. > >>=20 > >> In any context where routing comes up, there is more than=20 > one LAN in the > >> local area, and the question is how to get a datagram from=20 > one to the other. > >> Consider this simplistic case: > >>=20 > >> ISP > >> | > >> +--+---+ > >> | CPE | > >> |Router| > >> +--+---+ > >> ------+-------+----------------+----- > >> +--+--+ +---+--+ > >> |Alice| |Router| > >> +-----+ +--+---+ > >> ----+----+-------- > >> +-+-+ > >> |Bob| > >> +---+ > >>=20 > >> Alice wants to send a datagram to Bob, and because she got=20 > her RA from the > >> CPE, considers the CPE her default gateway. So sends the=20 > datagram to Bob's > >> address at the IP layer, and to the CPE's address at the=20 > link layer. > >>=20 > >> If you are expecting the CPE to respond with a redirect to=20 > the other router > >> in the picture, the CPE has to know that the other router=20 > is a router and > >> has a LAN behind it, and specifically the LAN that Bob's=20 > subnet is on. More > >> generally, in a home that has them all, one could readily imagine > >>=20 > >> ISP > >> | > >> +--+---+ > >> | CPE | > >> |Router| > >> +---+--+ Home backbone LAN > >> -----+----------+-+--------+----------+--- > >> +---+--+ +---+--+ +---+--+ +---+--+ > >> |His | |Her | |A/V | |HAN | > >> |Office| |Office| |LAN | |Router| > >> |Router| |Router| |Router| +--+---+ > >> +---+--+ +---+--+ +---+--+ | > >> -------+--- -----+--- -----+--- ----+---- > >>=20 > >> If "Alice" is in "Her Office" and "Bob" is in "His=20 > Office", how does Alice's > >> router know where the default route should point to? What=20 > is its "default > >> gateway"? > >>=20 > >> I understand your point that if you have a trivially=20 > simple network, with > >> one router and everything attached to it, it knows what=20 > you're doing. > >> Predicating everything on that simplistic picture is, in=20 > my experience, > >> naive. > >>=20 > >>> So, 'A' bounces the initial packets off its default > >>> router 'C' which forwards them to 'B' but also > >>> returns redirection messages to 'A'. > >>>=20 > >>> 'C' can know about 'B' if it has full topology > >>> information, but it is possible that 'C' also has > >>> only partial topology information and has to default > >>> route the initial packets through some higher level > >>> gateway 'D'. 'D' can then forward the packets on > >>> towards 'B', and can return redirection messages > >>> to 'C', then 'C' can proxy the redirection messages > >>> back to 'A'. > >>>=20 > >>> So, there can be a hierarchy of proxying gateways > >>> in the operator's network, where each higher layer > >>> in the hierarchy has more topology information than > >>> the layer below it. I'm not quite asking for the same > >>> thing as a full-up ND_Proxy, however, since all I'm > >>> asking for is proxying of redirection messages. > >>>=20 > >>> Was this informational or obfuscational? > >>>=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Fred Baker [mailto:fred@cisco.com]=20 > >>>> Sent: Thursday, March 17, 2011 2:10 PM > >>>> To: Templin, Fred L > >>>> Cc: Hemant Singh (shemant); Cameron Byrne; IPv6 Ops WG > >>>> Subject: Re: [v6ops] I-D=20 > >>>> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>>>=20 > >>>> Really? How does the router emitting the ICMP Redirect learn=20 > >>>> where routes should be directed to? How does it compare them? > >>>>=20 > >>>> On Mar 17, 2011, at 1:55 PM, Templin, Fred L wrote: > >>>>=20 > >>>>>=20 > >>>>> Regarding scaling, there is another way to do dynamic > >>>>> routing when traditional proactive routing protocols > >>>>> like OSPFv3 and RIPng cannot be used. For example, if > >>>>> the CEs and BRs can be represented as neighbors on a > >>>>> virtual NBMA link, then ICMP redirection can be used. > >>>>>=20 > >>>>> This would be classified as an on-demand (instead of > >>>>> proactive) dynamic routing protocol, and so does not > >>>>> need to hold non-essential routes in the RIB. > >>>>>=20 > >>>>> I have specified a way to do this for ISATAP in the > >>>>> latest VET spec (draft-templin-intarea-vet) but the > >>>>> same method can be applied to other mainfestations > >>>>> of virtual NBMA links as well. > >>>>>=20 > >>>>> Thanks - Fred > >>>>> fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From fred@cisco.com Fri Apr 1 13:17: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 DD24928B56A for ; Fri, 1 Apr 2011 13:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 e09TzcHAhluJ for ; Fri, 1 Apr 2011 13:17:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6ECD33A6964 for ; Fri, 1 Apr 2011 13:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=14612; q=dns/txt; s=iport; t=1301689153; x=1302898753; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=98MzuEhxdbK666hjMUUriUStZmjBOmiANNGGEIrmQAA=; b=fbYYs1lNwE6WABOMzCkNV7W3aHjb6z+FdUTizxbSbzcqs7Oigb5q7cF1 hKoR1Cgt1jRiky+A/UPvyAoPDOjIUMNHFcfB/zI9pYz+C22qdlSkMdzJg L4fqo+nlD1qJ9wIuZnXoMrPD9jqSYQcoKNGNdDE6wns8tm+/iYr+TOrhI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAG4ylk2Q/khLgWdsb2JhbACYI409FAEBFiYliHmdCZwYhWsEjRuDWQ X-IronPort-AV: E=Sophos;i="4.63,284,1299456000"; d="scan'208";a="24164061" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 20:19:12 +0000 Received: from Freds-Computer.local (dhcp-10-61-105-161.cisco.com [10.61.105.161]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p31KJ6k5021235; Fri, 1 Apr 2011 20:19:11 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 01 Apr 2011 22:19:11 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 01 Apr 2011 22:19:11 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 1 Apr 2011 22:18:56 +0200 Message-Id: <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 01 Apr 2011 20:17:35 -0000 On Apr 1, 2011, at 8:13 PM, Templin, Fred L wrote: > Hi Fred, >=20 > Not sure if you were looking for feedback on this, but all > of these SOHO-network-behind-the-CPE scenarios you outlined > have one thing in common - they can all be supported by > ISATAP. Is it too early to introduce that into the > discussion? I suspect residential/SOHO networks will use native routing, not an = overlay. What would be interesting in an operational group might be = reports from people using ISATAP in these environments. > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 >> On Behalf Of Fred Baker >> Sent: Friday, April 01, 2011 7:09 AM >> To: IPv6 Ops WG >> Subject: [v6ops] Fwd: I-D=20 >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >> As promised Thursday... >>=20 >> This is some ruminations I had regarding CPE routers and=20 >> shared with the design team.=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Fred Baker >>> Date: March 28, 2011 4:36:28 AM GMT+02:00 >>> To: >>> Cc: cpe-router@external.cisco.com >>> Subject: Re: [v6ops] I-D=20 >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>>=20 >>> On Mar 27, 2011, at 11:22 PM, Frank Bulk wrote: >>>=20 >>>> Thanks for the diagram. Because we're talking about multi-homing, >>>> multi-routers, and stacked routers, it may be helpful to create an >>>> exhaustive set of diagrams that cover each scenario so we=20 >> can be on the same >>>> page when talking about this bis draft and also work=20 >> through our ideas in >>>> each of the scenarios. >>>>=20 >>>> It may end up that the scope of this draft is reduced to just a few >>>> scenarios, even though we may *want* to tackle them all. =20 >>>>=20 >>>> Frank >>>=20 >>>=20 >>> Copying the design team; I don't want them to take this as=20 >> direction, but it might be appropriate input to their thoughts. >>>=20 >>> My personal opinion: the use case for a residential or SOHO=20 >> network is very simple. A common one - the one in my=20 >> children's homes - is "I have a router and it connects me to=20 >> the Internet", as James Woodyat has spoken about. This was=20 >> the only case discussed in draft-ietf-v6ops-cpe-router: >>>=20 >>> 1) Simple Residential Network >>>=20 >>> `. ISP ,' >>> `--+--' >>> | >>> +-----+-----+ >>> |Residential| >>> |CPE Router | >>> +-----+-----+ >>> | >>> `----------+---------- >>> Wired and Wireless LAN >>>=20 >>> A variation on that is Cisco's recommendation for its=20 >> telecommuter population (which is perhaps 1/3 of the company,=20 >> at least part-time): we use an 8xx series router, split the=20 >> four "inside" ports between two or more subnets, one of which=20 >> is for the telecommuter's home office, and provide a wireless=20 >> access for use by the telecommuter. In my case, I don't use=20 >> the wireless capability, as wired is more reliable and I=20 >> pretty much sit at a desk; I instead have a 24 port=20 >> 10/100/1000 switch wired to the various rooms in my home,=20 >> including two 802.11g access points that effectively extend=20 >> that LAN throughout the house. The latter are, however, a=20 >> technical detail; if I chose to, I imagine I could build that=20 >> all into a higher end router. >>>=20 >>> 2) Multi-LAN Residential Network >>>=20 >>> `. ISP ,' >>> `--+--' >>> | >>> +-------+-------+ >>> | Residential | >>> | CPE Router | >>> +-+-----+-----+-+ >>> | | | >>> ` --+-- --+-- --+-- >>> Wired and Wireless LANs >>>=20 >>> There are two obvious implementations of a multi-LAN=20 >> residential network: one could implement separate subnets and=20 >> route between them, and one could implement an ND Proxy and=20 >> bridge between them. I suspect both implementations have=20 >> their cases, and should be treated as the "routed" and=20 >> "ND-proxy" subcases of the form. >>>=20 >>> For internal structure, I think the case I mentioned should=20 >> be present, if only because it represents the most general case: >>>=20 >>> 3) Multi-router subnetted network >>>=20 >>> This again has two sub-cases; it could be literally a tree,=20 >> as I have drawn it, or could include some amount of=20 >> complexity such as interconnecting some of the non-backbone=20 >> subnets. I might call those "tree" and "redundant" networks. >>>=20 >>> \ ISP / >>> `--+--' >>> | >>> +--+---+ >>> | CPE | >>> |Router| >>> +---+--+ >>> | Home backbone LAN >>> -----+----------+-+--------+----------+--- >>> | | | | >>> +---+--+ +---+--+ +---+--+ +---+--+ >>> |His | |Her | |A/V | |HAN | >>> |Office| |Office| |LAN | |Router| >>> |Router| |Router| |Router| +--+---+ >>> +---+--+ +---+--+ +---+--+ | >>> | | | | >>> -------+--- -----+--- -----+--- ----+---- >>>=20 >>> There are two more bits of complexity that should not be=20 >> omitted: multihoming, and redundant paths. These are each, I=20 >> think, special cases of the first three, such as >>>=20 >>> 4) Multihomed network >>>=20 >>> The most common version of a multihomed network, I suspect,=20 >> is a network in a home where multiple people have offices,=20 >> virtual or physical, and whose companies have similar=20 >> information security policies to Cisco's; James Polk could=20 >> give you some insight there, as Motorola required his wife to=20 >> maintain similar separation between work and home. The=20 >> amusing thing was that he could hear her on the phone. As in=20 >> case 2, each had a router that provided them access to both a=20 >> "secured" subnet for their office and an "unsecured" subnet=20 >> for the home; they connected the "unsecured" subnets on the=20 >> home LAN. Jari Arkko's home is another example, although to=20 >> my knowledge his wife doesn't work outside the home - he=20 >> simply chooses to have multiple upstreams. So the key=20 >> differentiation in this case is that it has multiple upstreams. >>>=20 >>> \ /\ / >>> \ ISP / \ ISP / >>> `--+--' `--+--' >>> | | >>> +--+---+ +--+---+ >>> | CPE | | CPE | >>> |Router| |Router| >>> +---+--+ +---+--+ >>> | | Home backbone LAN >>> -----+-+--------+-+--------+----------+--- >>> | | | | >>> Various variations on cases 1, 2, and 3 >>>=20 >>> So, for my money, six cases and subcases: >>> 1) Simple residential network >>> 2a) Routed Multi-LAN Residential Network >>> 2b) ND-Proxy Multi-LAN Residential Network >>> 3a) Tree Multi-router subnetted network >>> 3b) Redundant Multi-router subnetted network >>> 4) Multihomed Network >>>=20 >>> The most general case, of course, is a multihomed redundant=20 >> multi-router subnetted network. This begins to look like an=20 >> SMB network, and might want to be called out explicitly: >>>=20 >>> 4b) Multihomed Redundant Multi-router subnetted network >>>=20 >>> \ /\ / >>> \ ISP / \ ISP / >>> `--+--' `--+--' >>> | | >>> +--+---+ +--+---+ >>> | CPE | | CPE | >>> |Router| |Router| >>> +---+--+ +---+--+ >>> | | Home backbone LAN >>> -----+-+--------+-+--------+----------+--- >>> | | | | | >>> +---+--+ +---+--+ +---+--+ | +---+--+ >>> |His | |Her | |A/V +-+ |HAN | >>> |Office| |Office| |LAN | +-+Router| >>> |Router| |Router| |Router| | +--+---+ >>> +---+--+ +---+--+ +---+--+ | | >>> | | | | >>> -------+--- -----+--- -----+--- ----+---- >>>=20 >>> As far as the cases we want to cover or not cover; IMHO, if=20 >> our solution to the tougher problems, such as the subnet=20 >> delegation model, doesn't work in 4b, we're not really done.=20 >> That said, for most residential/SOHO purposes, we're talking=20 >> about (1), (2a), (2b), and (3a). >>>=20 >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org=20 >> [mailto:v6ops-bounces@ietf.org] On Behalf Of >>>> Fred Baker >>>> Sent: Thursday, March 17, 2011 5:03 PM >>>> To: Templin, Fred L >>>> Cc: IPv6 Ops WG >>>> Subject: Re: [v6ops] I-D=20 >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>>>=20 >>>>=20 >>>> On Mar 17, 2011, at 2:29 PM, Templin, Fred L wrote: >>>>=20 >>>>> Hi Fred, >>>>>=20 >>>>> What I mean to say is that when a host on the LAN >>>>> side of CE 'A' sends packets to a host on the LAN >>>>> side of CE 'B', 'A' has to figure out what to do >>>>> with them since it all it has in its routing table >>>>> is a default route. >>>>=20 >>>> In any context where routing comes up, there is more than=20 >> one LAN in the >>>> local area, and the question is how to get a datagram from=20 >> one to the other. >>>> Consider this simplistic case: >>>>=20 >>>> ISP >>>> | >>>> +--+---+ >>>> | CPE | >>>> |Router| >>>> +--+---+ >>>> ------+-------+----------------+----- >>>> +--+--+ +---+--+ >>>> |Alice| |Router| >>>> +-----+ +--+---+ >>>> ----+----+-------- >>>> +-+-+ >>>> |Bob| >>>> +---+ >>>>=20 >>>> Alice wants to send a datagram to Bob, and because she got=20 >> her RA from the >>>> CPE, considers the CPE her default gateway. So sends the=20 >> datagram to Bob's >>>> address at the IP layer, and to the CPE's address at the=20 >> link layer. >>>>=20 >>>> If you are expecting the CPE to respond with a redirect to=20 >> the other router >>>> in the picture, the CPE has to know that the other router=20 >> is a router and >>>> has a LAN behind it, and specifically the LAN that Bob's=20 >> subnet is on. More >>>> generally, in a home that has them all, one could readily imagine >>>>=20 >>>> ISP >>>> | >>>> +--+---+ >>>> | CPE | >>>> |Router| >>>> +---+--+ Home backbone LAN >>>> -----+----------+-+--------+----------+--- >>>> +---+--+ +---+--+ +---+--+ +---+--+ >>>> |His | |Her | |A/V | |HAN | >>>> |Office| |Office| |LAN | |Router| >>>> |Router| |Router| |Router| +--+---+ >>>> +---+--+ +---+--+ +---+--+ | >>>> -------+--- -----+--- -----+--- ----+---- >>>>=20 >>>> If "Alice" is in "Her Office" and "Bob" is in "His=20 >> Office", how does Alice's >>>> router know where the default route should point to? What=20 >> is its "default >>>> gateway"? >>>>=20 >>>> I understand your point that if you have a trivially=20 >> simple network, with >>>> one router and everything attached to it, it knows what=20 >> you're doing. >>>> Predicating everything on that simplistic picture is, in=20 >> my experience, >>>> naive. >>>>=20 >>>>> So, 'A' bounces the initial packets off its default >>>>> router 'C' which forwards them to 'B' but also >>>>> returns redirection messages to 'A'. >>>>>=20 >>>>> 'C' can know about 'B' if it has full topology >>>>> information, but it is possible that 'C' also has >>>>> only partial topology information and has to default >>>>> route the initial packets through some higher level >>>>> gateway 'D'. 'D' can then forward the packets on >>>>> towards 'B', and can return redirection messages >>>>> to 'C', then 'C' can proxy the redirection messages >>>>> back to 'A'. >>>>>=20 >>>>> So, there can be a hierarchy of proxying gateways >>>>> in the operator's network, where each higher layer >>>>> in the hierarchy has more topology information than >>>>> the layer below it. I'm not quite asking for the same >>>>> thing as a full-up ND_Proxy, however, since all I'm >>>>> asking for is proxying of redirection messages. >>>>>=20 >>>>> Was this informational or obfuscational? >>>>>=20 >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Fred Baker [mailto:fred@cisco.com]=20 >>>>>> Sent: Thursday, March 17, 2011 2:10 PM >>>>>> To: Templin, Fred L >>>>>> Cc: Hemant Singh (shemant); Cameron Byrne; IPv6 Ops WG >>>>>> Subject: Re: [v6ops] I-D=20 >>>>>> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>>>>>=20 >>>>>> Really? How does the router emitting the ICMP Redirect learn=20 >>>>>> where routes should be directed to? How does it compare them? >>>>>>=20 >>>>>> On Mar 17, 2011, at 1:55 PM, Templin, Fred L wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Regarding scaling, there is another way to do dynamic >>>>>>> routing when traditional proactive routing protocols >>>>>>> like OSPFv3 and RIPng cannot be used. For example, if >>>>>>> the CEs and BRs can be represented as neighbors on a >>>>>>> virtual NBMA link, then ICMP redirection can be used. >>>>>>>=20 >>>>>>> This would be classified as an on-demand (instead of >>>>>>> proactive) dynamic routing protocol, and so does not >>>>>>> need to hold non-essential routes in the RIB. >>>>>>>=20 >>>>>>> I have specified a way to do this for ISATAP in the >>>>>>> latest VET spec (draft-templin-intarea-vet) but the >>>>>>> same method can be applied to other mainfestations >>>>>>> of virtual NBMA links as well. >>>>>>>=20 >>>>>>> Thanks - Fred >>>>>>> fred.l.templin@boeing.com >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From bingxuere@gmail.com Fri Apr 1 16:41: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 7457228C11A; Fri, 1 Apr 2011 16:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMeNj+HraEB9; Fri, 1 Apr 2011 16:41:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id BA8963A69AC; Fri, 1 Apr 2011 16:41:17 -0700 (PDT) Received: by vws12 with SMTP id 12so3638297vws.31 for ; Fri, 01 Apr 2011 16:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=50to1ZZd4GqJwdl+JCnktMTy1CCuVNd89olMKDntmHY=; b=go1T/SjVsmLygonzFh99sklmFYGS4nUx7IwZwvRG4qzA8/kFTDOAvkrUhFS3zivcHE sGhthE1I3RZkey9A2OC2PZ9iHQBU8mH1fjSwjGv/n5oMA7Ie5UlgosmqoQD3xYDZyIYG EeqI+fHJobxdqidWEvQ7G2XkPbZeUm9doBKx8= 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=MJCFcTyAs46CU2dEE/uP2EmkZnBG1BAPgXx+nPHOYlCOkpmnWNNT01TL+VyZdpSXIG M9+cPzg8uFwoeOflZCyhJ+2y3UO7dL7HsOHObXhnC8MLCbg8d4BHq+/kBHG6lmhdQd/m eO4Y7HmeA6eeDTd1gRRQ/OufMdCZjN+EV34+M= MIME-Version: 1.0 Received: by 10.52.159.3 with SMTP id wy3mr6347029vdb.289.1301701378061; Fri, 01 Apr 2011 16:42:58 -0700 (PDT) Received: by 10.52.157.196 with HTTP; Fri, 1 Apr 2011 16:42:57 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 07:42:57 +0800 Message-ID: From: =?UTF-8?B?5a2Z55C8?= To: v6ops@ietf.org Cc: v6ops-request@ietf.org Content-Type: multipart/alternative; boundary=bcaec53f97973e3467049fe3f860 Subject: Re: [v6ops] v6ops Digest, Vol 8, Issue 1 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 23:41:19 -0000 --bcaec53f97973e3467049fe3f860 Content-Type: text/plain; charset=ISO-8859-1 Hi Roberta, Thank you very much for your comments. I'm Sun Qiong and the co-author of this slides. I agree with you that the allocation of the address for AFTR could be seperated from address allocation process. But as a common problem for tunnel-based solution, we should find a reasonable way to pass that address to B4, either by static configuration, TR-069 based configuration, or a new DHCPv6 option. Maybe the best way is to pass the address via DHCPv6 which would also need to take some changes in DHCPv6 server. I personally think that flexible addressing is good from addressing assignment aspect. However, current stateful solution would also bring a lot of burden for session-based state management, traffic logging, etc. And it would also have scalability problem to deal with massive concurrent sessions especially for large SPs. As a result, we think stateless solutions with flexible addressing ability should be recommended . BTW, we have proposed a solution called LAFT6 ( http://tools.ietf.org/id/draft-sun-v6ops-laft6-01.txt), which aims to achieve lightweight state-management (largely reduce the number of state entries) and lightweight addressing (flexible addressing with no address format). It is a tradeoff between current session-based stateful solution and totally stateless solution. We would be appreciated to have your comments as well. Best regards Qiong ---------- Forwarded message ---------- > From: Maglione Roberta > To: "'v6ops@ietf.org'" > Date: Fri, 1 Apr 2011 09:56:33 +0200 > Subject: [v6ops] comments on stateless mechanism presentation > Hello, > I would like to try to clarify the comment I made yesterday on slide 6. > The third bullet of this slide says: > "ISPs may adopt flexible address rules, no extra requirements on address > format and address allocation" > > My understanding of this is that the purpose of this slide is to compare > the impacts of the different transition mechanisms have on the address > allocation scheme that the ISP has to use. > > dIVI uses a specific format to build the IPv6 address, made by > concatenating an IPv6 prefix with an IPv4 + a port, thus it introduces some > constrains on the addresses scheme to be used in the network > > While DS-Lite does not have any specific requirement on the IPv6 prefix > delegated to the customers. > > The table in slide 6 in the first column for DS-LIte says: > "Address of the tunnel end to be passed" > > This sentence refers to the address of the AFTR that needs to be > provisioned on the B4 in order to allow the B4 to setup the IPv4 over IPv6 > tunnel. > > This is a provisioning issue (and BTY it solved by DHCPv6 option specified > in draft-ietf-softwire-ds-lite-tunnel-option, now in RFC queue). > This point is NOT related to the address allocation scheme to be used by > the ISP, thus I don't think it should appear in this table. > > If you want to compare the provisioning aspects of the different techniques > I would suggest adding a separate slide for them. > > Going to your slide 11: Flexible addressing > In my opinion DS-Lite has some advantages compared to dIVI on Flexible > addressing point because, as I said before, DS-Lite does not requires a > specific format for the IPv6 prefix. > > Thanks, > Regards, > Roberta > > > > > > --bcaec53f97973e3467049fe3f860 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Roberta,=
=A0
Thank you very much for your comments. I'm Sun Qiong and the co-au= thor of=20 this slides.
=A0
I agree with you that the allocation of the address=A0for AFTR could b= e=20 seperated from address allocation process. But as a common problem for=20 tunnel-based solution, we should find a reasonable way to pass that address= to=20 B4, either by static configuration, TR-069 based configuration, or a new DH= CPv6=20 option. Maybe the best way is to pass the address via DHCPv6 which would al= so=20 need to take some changes in DHCPv6 server.=A0
=A0
I personally think that flexible addressing is good f= rom=20 addressing assignment=A0aspect. However, current stateful solution would al= so=20 bring a lot of burden for session-based state management, traffic logging, = etc.=20 And it would also have scalability problem to deal with massive concurrent = sessions=20 especially for large SPs. As a result, we think stateless solutions with=20 flexible addressing ability=A0should be recommended .
=A0
BTW, we have proposed=A0a solution called LAFT6 (http:/= /tools.ietf.org/id/draft-sun-v6ops-laft6-01.txt),=20 which aims to achieve lightweight=A0state-management (largely reduce the nu= mber of=20 state entries)=A0and lightweight addressing (flexible addressing with no ad= dress=20 format). It is a tradeoff between current=A0session-based=A0stateful soluti= on and=20 totally stateless solution. We would be=A0appreciated to have your comments= as=20 well.=A0
=A0
Best regards
=A0
Qiong

---------- Forwarded message ----------
From:=A0Maglione Roberta <roberta.maglione@telecomitalia.it>
To:=A0"'v6ops@ietf.org'" <v6ops@ietf.org>
Date:=A0Fri, 1 Apr 2011 09:56:33 +0200
Subject:=A0[v6ops] comments on st= ateless mechanism presentation
Hello,
=A0 I would like to try to clarify the comment I made yesterday on slide 6= .
The third bullet of this slide says:
"ISPs may adopt flexible address rules, no extra requirements on addre= ss format and address allocation"

My understanding of this is that the purpose of this slide is to compare th= e impacts of the different transition mechanisms have on the address alloca= tion scheme that the ISP has to use.

dIVI uses a specific format to build the IPv6 address, made by concatenatin= g an IPv6 prefix with an IPv4 + a port, thus it introduces some constrains = on the addresses scheme to be used in the network

While DS-Lite does not have any specific requirement on the IPv6 prefix del= egated to the customers.

The table in slide 6 in the first column for DS-LIte says:
"Address of the tunnel end to be passed"

This sentence refers to the address of the AFTR that needs to be provisione= d on the B4 in order to allow the B4 to setup the IPv4 over IPv6 tunnel.
This is a provisioning issue (and BTY it solved by DHCPv6 option specified = in draft-ietf-softwire-ds-lite-tunnel-option, now in RFC queue).
This point is NOT related to the address allocation scheme to be used by th= e ISP, thus I don't think it should appear in this table.

If you want to compare the provisioning aspects of the different techniques= I would suggest adding a separate slide for them.

Going to your slide 11: Flexible addressing
In my opinion DS-Lite has some advantages compared to dIVI on Flexible addr= essing point because, as I said before, DS-Lite does not requires a specifi= c format for the IPv6 prefix.

Thanks,
Regards,
Roberta






--bcaec53f97973e3467049fe3f860-- From bingxuere@gmail.com Fri Apr 1 16: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 F352D28C114 for ; Fri, 1 Apr 2011 16:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lYLsoa-V6ldO for ; Fri, 1 Apr 2011 16:45:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 4BCFD3A69AB for ; Fri, 1 Apr 2011 16:45:49 -0700 (PDT) Received: by vxg33 with SMTP id 33so3652699vxg.31 for ; Fri, 01 Apr 2011 16:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=c4mASFHg5ImUzKN96YSxrXlt2NcfnZXgWEdXh0zO9qc=; b=uOWyufYUi9nYHoLePCYQ/thmHGwNvlW5cMNeHNeh8aJbCsge8ueUy3hlGHMo8GBdF2 GK6npFcL+uXzrNo5aZxO25j5EHezFwyFV2lvuW0chWKGDNnaFASPuPcgrYu8GqNP9+pl huzUptfbM5imVU17iNSWQ+ZBX/+HGHuZy9TJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PkkmekQ8lMY6QFqS1NjK1xNRZVSOTrmSXDD3ePanvTK/Dk/pdTM64NtIljnsstoca8 krI/ciNYp6lSPYAl8vUV6UxpQf31kHa46A2d5TVeUQKwo3mjbAhPfrl6iGUQlFUFpbz/ fhvnrAQZ06IU/QK82ColQMwXMR1NkE7DqTYbI= MIME-Version: 1.0 Received: by 10.52.93.2 with SMTP id cq2mr6505633vdb.49.1301701649682; Fri, 01 Apr 2011 16:47:29 -0700 (PDT) Received: by 10.52.157.196 with HTTP; Fri, 1 Apr 2011 16:47:29 -0700 (PDT) Date: Sat, 2 Apr 2011 07:47:29 +0800 Message-ID: From: =?UTF-8?B?5a2Z55C8?= To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=20cf307f38be6ecfbd049fe40871 Subject: Re: [v6ops] comments on stateless mechanism presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2011 23:45:55 -0000 --20cf307f38be6ecfbd049fe40871 Content-Type: text/plain; charset=ISO-8859-1 Hi Roberta, Thank you very much for your comments. I'm Sun Qiong and the co-author of this slides. I agree with you that the allocation of the address for AFTR could be seperated from address allocation process. But as a common problem for tunnel-based solution, we should find a reasonable way to pass that address to B4, either by static configuration, TR-069 based configuration, or a new DHCPv6 option. Maybe the best way is to pass the address via DHCPv6 which would also need to take some changes in DHCPv6 server. I personally think that flexible addressing is good from addressing assignment aspect. However, current stateful solution would also bring a lot of burden for session-based state management, traffic logging, etc. And it would also have scalability problem with massive concurrent sessions especially for large SPs. As a result, we think stateless solutions with flexible addressing ability should be recommended . BTW, we have proposed a solution called LAFT6 ( http://tools.ietf.org/id/draft-sun-v6ops-laft6-01.txt), which aims to achieve lightweight state-management (largely reduce the number of state entries) and lightweight addressing (flexible addressing with no address format). It is a tradeoff between current session-based stateful solution and totally stateless solution. We would be appreciated to have your comments as well. Best regards Qiong ---------- Forwarded message ---------- > From: Maglione Roberta > To: "'v6ops@ietf.org'" > Date: Fri, 1 Apr 2011 09:56:33 +0200 > Subject: [v6ops] comments on stateless mechanism presentation > Hello, > I would like to try to clarify the comment I made yesterday on slide 6. > The third bullet of this slide says: > "ISPs may adopt flexible address rules, no extra requirements on address > format and address allocation" > > My understanding of this is that the purpose of this slide is to compare > the impacts of the different transition mechanisms have on the address > allocation scheme that the ISP has to use. > > dIVI uses a specific format to build the IPv6 address, made by > concatenating an IPv6 prefix with an IPv4 + a port, thus it introduces some > constrains on the addresses scheme to be used in the network > > While DS-Lite does not have any specific requirement on the IPv6 prefix > delegated to the customers. > > The table in slide 6 in the first column for DS-LIte says: > "Address of the tunnel end to be passed" > > This sentence refers to the address of the AFTR that needs to be > provisioned on the B4 in order to allow the B4 to setup the IPv4 over IPv6 > tunnel. > > This is a provisioning issue (and BTY it solved by DHCPv6 option specified > in draft-ietf-softwire-ds-lite- tunnel-option, now in RFC queue). > This point is NOT related to the address allocation scheme to be used by > the ISP, thus I don't think it should appear in this table. > > If you want to compare the provisioning aspects of the different techniques > I would suggest adding a separate slide for them. > > Going to your slide 11: Flexible addressing > In my opinion DS-Lite has some advantages compared to dIVI on Flexible > addressing point because, as I said before, DS-Lite does not requires a > specific format for the IPv6 prefix. > > Thanks, > Regards, > Roberta --20cf307f38be6ecfbd049fe40871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Roberta,=
=A0
Thank you very much for your comments. I'm Sun Qiong and the co-au= thor of=20 this slides.
=A0
I agree with you that the allocation of the address=A0for AFTR could b= e=20 seperated from address allocation process. But as a common problem for=20 tunnel-based solution, we should find a reasonable way to pass that address= to=20 B4, either by static configuration, TR-069 based configuration, or a new DH= CPv6=20 option. Maybe the best way is to pass the address via DHCPv6 which would al= so=20 need to take some changes in DHCPv6 server.=A0
=A0
I personally think that flexible addressing is good f= rom=20 addressing assignment=A0aspect. However, current stateful solution would al= so=20 bring a lot of burden for session-based state management, traffic logging, = etc.=20 And it would also have scalability problem with=A0massive concurrent sessio= ns=20 especially for large SPs. As a result, we think stateless solutions with=20 flexible addressing ability=A0should be recommended .
=A0
BTW, we have proposed=A0a solution called LAFT6 (http:/= /tools.ietf.org/id/draft-sun-v6ops-laft6-01.txt),=20 which aims to achieve lightweight=A0state-management (largely reduce the nu= mber of=20 state entries)=A0and lightweight addressing (flexible addressing with no ad= dress=20 format). It is a tradeoff between current=A0session-based=A0stateful soluti= on and=20 totally stateless solution. We would be=A0appreciated to have your comments= as=20 well.=A0
=A0
Best regards
=A0
Qiong


=A0--------= -- Forwarded message ----------
=A0 =A0> From: Maglione Roberta <roberta.maglione@telecomitalia.it>
=A0 =A0> To: "'v6ops@ietf.or= g'" <v6ops@ietf.org&g= t;
=A0 =A0> Date: Fri, 1 Apr 2011 09:56:33 +0200
=A0 =A0> Subject: [v6ops] comments on stateless mechanism presentation<= br> =A0 =A0> Hello,
=A0 =A0> =A0 I would like to try to clarify the comment I made yesterda= y on slide 6.
=A0 =A0> The third bullet of this slide says:
=A0 =A0> "ISPs may adopt flexible address rules, no extra requirem= ents on address
=A0 =A0> format and address allocation"
=A0 =A0>
=A0 =A0> My understanding of this is that the purpose of this slide is = to compare
=A0 =A0> the impacts of the different transition mechanisms have on the= address
=A0 =A0> allocation scheme that the ISP has to use.
=A0 =A0>
=A0 =A0> dIVI uses a specific format to build the IPv6 address, made by=
=A0 =A0> concatenating an IPv6 prefix with an IPv4 + a port, thus it in= troduces some
=A0 =A0> constrains on the addresses scheme to be used in the network =A0 =A0>
=A0 =A0> While DS-Lite does not have any specific requirement on the IP= v6 prefix
=A0 =A0> delegated to the customers.
=A0 =A0>
=A0 =A0> The table in slide 6 in the first column for DS-LIte says:
=A0 =A0> "Address of the tunnel end to be passed"
=A0 =A0>
=A0 =A0> This sentence refers to the address of the AFTR that needs to = be
=A0 =A0> provisioned on the B4 in order to allow the B4 to setup the IP= v4 over IPv6
=A0 =A0> tunnel.
=A0 =A0>
=A0 =A0> This is a provisioning issue (and BTY it solved by DHCPv6 opti= on specified
=A0 =A0> in draft-ietf-softwire-ds-lite-
tunnel-option, = now in RFC queue).
=A0 =A0> This point is NOT related to the address allocation scheme to = be used by
=A0 =A0> the ISP, thus I don't think it should appear in this table= .
=A0 =A0>
=A0 =A0> If you want to compare the provisioning aspects of the differe= nt techniques
=A0 =A0> I would suggest adding a separate slide for them.
=A0 =A0>
=A0 =A0> Going to your slide 11: Flexible addressing
=A0 =A0> In my opinion DS-Lite has some advantages compared to dIVI on = Flexible
=A0 =A0> addressing point because, as I said before, DS-Lite does not r= equires a
=A0 =A0> specific format for the IPv6 prefix.
=A0 =A0>
=A0 =A0> Thanks,
=A0 =A0> Regards,
=A0 =A0> Roberta

--20cf307f38be6ecfbd049fe40871-- From Internet-Drafts@ietf.org Sat Apr 2 07: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 089B03A681F; Sat, 2 Apr 2011 07:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 uZuVToSoIO4q; Sat, 2 Apr 2011 07:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573683A6813; Sat, 2 Apr 2011 07:15:02 -0700 (PDT) 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.14 Message-ID: <20110402141502.30348.83936.idtracker@localhost> Date: Sat, 02 Apr 2011 07:15:02 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-3gpp-eps-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, 02 Apr 2011 14:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : J. Korhonen, et al. Filename : draft-ietf-v6ops-3gpp-eps-00.txt Pages : 31 Date : 2011-03-31 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-eps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-02070748.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Sat Apr 2 07: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 2E36D3A6814; Sat, 2 Apr 2011 07:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 iVVSAH3xXau3; Sat, 2 Apr 2011 07:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD5A3A681D; Sat, 2 Apr 2011 07:15:02 -0700 (PDT) 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.14 Message-ID: <20110402141502.30348.47691.idtracker@localhost> Date: Sat, 02 Apr 2011 07:15:02 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-6to4-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, 02 Apr 2011 14:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Advisory Guidelines for 6to4 Deployment Author(s) : B. Carpenter Filename : draft-ietf-v6ops-6to4-advisory-00.txt Pages : 19 Date : 2011-03-31 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-advisory-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-advisory-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-02070810.I-D@ietf.org> --NextPart-- From shemant@cisco.com Sat Apr 2 09:13: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 86F403A6851 for ; Sat, 2 Apr 2011 09:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.36 X-Spam-Level: X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=-0.361, 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 AT1vUrfj2a8K for ; Sat, 2 Apr 2011 09:13:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D900C3A684E for ; Sat, 2 Apr 2011 09:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13562; q=dns/txt; s=iport; t=1301760923; x=1302970523; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=U0ze5qoItHlssFOraw3x99Fcg4riSlFi6JsjlMi/JoQ=; b=Pv5hvpir6MgG3GuI3sXN8kIu1XTEYEaAsBoppgl4zKo57+tJ1IKVyg7n dU1v9pxOtgcldrm5m3hXZnpX+KgRBMiKEkUCfamK2zlaHp1MU0rTx/eog Z1rXv2++EW6se2de9uFmeaWWyG+osdrBBYadkP+rV2XnvW32qgJ2U+h9l A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAACZLl02tJV2b/2dsb2JhbACYJo09d4h5mxubXoVrBIVHiz0 X-IronPort-AV: E=Sophos;i="4.63,288,1299456000"; d="scan'208";a="674873199" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2011 16:15:22 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p32GFMGr013708 for ; Sat, 2 Apr 2011 16:15:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 11:15:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Apr 2011 11:15:20 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3012D48E1@XMB-RCD-109.cisco.com> In-Reply-To: <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvwdl9h3GpatIVdTwKaHRlCgdTsPAA2Ik3A References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "IPv6 Ops WG" X-OriginalArrivalTime: 02 Apr 2011 16:15:22.0840 (UTC) FILETIME=[2B20B580:01CBF151] Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 02 Apr 2011 16:13:43 -0000 Besides working on more complex routed topologies, some other issues were brought up. Alain Durand asked to add PCP to the document. Tom Herbst asked to make the ULA generation on the CE Router LAN a MUST. Sorry, I could not make a note of any other comments. Please let us know of other comments (at the mic or in Jabber) made during the bis document presentation at the IETF in Prague. Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Friday, April 01, 2011 10:09 AM To: IPv6 Ops WG Subject: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt As promised Thursday... This is some ruminations I had regarding CPE routers and shared with the design team.=20 Begin forwarded message: > From: Fred Baker > Date: March 28, 2011 4:36:28 AM GMT+02:00 > To: > Cc: cpe-router@external.cisco.com > Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > On Mar 27, 2011, at 11:22 PM, Frank Bulk wrote: >=20 >> Thanks for the diagram. Because we're talking about multi-homing, >> multi-routers, and stacked routers, it may be helpful to create an >> exhaustive set of diagrams that cover each scenario so we can be on the same >> page when talking about this bis draft and also work through our ideas in >> each of the scenarios. >>=20 >> It may end up that the scope of this draft is reduced to just a few >> scenarios, even though we may *want* to tackle them all. =20 >>=20 >> Frank >=20 >=20 > Copying the design team; I don't want them to take this as direction, but it might be appropriate input to their thoughts. >=20 > My personal opinion: the use case for a residential or SOHO network is very simple. A common one - the one in my children's homes - is "I have a router and it connects me to the Internet", as James Woodyat has spoken about. This was the only case discussed in draft-ietf-v6ops-cpe-router: >=20 > 1) Simple Residential Network >=20 > `. ISP ,' > `--+--' > | > +-----+-----+ > |Residential| > |CPE Router | > +-----+-----+ > | > `----------+---------- > Wired and Wireless LAN >=20 > A variation on that is Cisco's recommendation for its telecommuter population (which is perhaps 1/3 of the company, at least part-time): we use an 8xx series router, split the four "inside" ports between two or more subnets, one of which is for the telecommuter's home office, and provide a wireless access for use by the telecommuter. In my case, I don't use the wireless capability, as wired is more reliable and I pretty much sit at a desk; I instead have a 24 port 10/100/1000 switch wired to the various rooms in my home, including two 802.11g access points that effectively extend that LAN throughout the house. The latter are, however, a technical detail; if I chose to, I imagine I could build that all into a higher end router. >=20 > 2) Multi-LAN Residential Network >=20 > `. ISP ,' > `--+--' > | > +-------+-------+ > | Residential | > | CPE Router | > +-+-----+-----+-+ > | | | > ` --+-- --+-- --+-- > Wired and Wireless LANs >=20 > There are two obvious implementations of a multi-LAN residential network: one could implement separate subnets and route between them, and one could implement an ND Proxy and bridge between them. I suspect both implementations have their cases, and should be treated as the "routed" and "ND-proxy" subcases of the form. >=20 > For internal structure, I think the case I mentioned should be present, if only because it represents the most general case: >=20 > 3) Multi-router subnetted network >=20 > This again has two sub-cases; it could be literally a tree, as I have drawn it, or could include some amount of complexity such as interconnecting some of the non-backbone subnets. I might call those "tree" and "redundant" networks. >=20 > \ ISP / > `--+--' > | > +--+---+ > | CPE | > |Router| > +---+--+ > | Home backbone LAN > -----+----------+-+--------+----------+--- > | | | | > +---+--+ +---+--+ +---+--+ +---+--+ > |His | |Her | |A/V | |HAN | > |Office| |Office| |LAN | |Router| > |Router| |Router| |Router| +--+---+ > +---+--+ +---+--+ +---+--+ | > | | | | > -------+--- -----+--- -----+--- ----+---- >=20 > There are two more bits of complexity that should not be omitted: multihoming, and redundant paths. These are each, I think, special cases of the first three, such as >=20 > 4) Multihomed network >=20 > The most common version of a multihomed network, I suspect, is a network in a home where multiple people have offices, virtual or physical, and whose companies have similar information security policies to Cisco's; James Polk could give you some insight there, as Motorola required his wife to maintain similar separation between work and home. The amusing thing was that he could hear her on the phone. As in case 2, each had a router that provided them access to both a "secured" subnet for their office and an "unsecured" subnet for the home; they connected the "unsecured" subnets on the home LAN. Jari Arkko's home is another example, although to my knowledge his wife doesn't work outside the home - he simply chooses to have multiple upstreams. So the key differentiation in this case is that it has multiple upstreams. >=20 > \ /\ / > \ ISP / \ ISP / > `--+--' `--+--' > | | > +--+---+ +--+---+ > | CPE | | CPE | > |Router| |Router| > +---+--+ +---+--+ > | | Home backbone LAN > -----+-+--------+-+--------+----------+--- > | | | | > Various variations on cases 1, 2, and 3 >=20 > So, for my money, six cases and subcases: > 1) Simple residential network > 2a) Routed Multi-LAN Residential Network > 2b) ND-Proxy Multi-LAN Residential Network > 3a) Tree Multi-router subnetted network > 3b) Redundant Multi-router subnetted network > 4) Multihomed Network >=20 > The most general case, of course, is a multihomed redundant multi-router subnetted network. This begins to look like an SMB network, and might want to be called out explicitly: >=20 > 4b) Multihomed Redundant Multi-router subnetted network >=20 > \ /\ / > \ ISP / \ ISP / > `--+--' `--+--' > | | > +--+---+ +--+---+ > | CPE | | CPE | > |Router| |Router| > +---+--+ +---+--+ > | | Home backbone LAN > -----+-+--------+-+--------+----------+--- > | | | | | > +---+--+ +---+--+ +---+--+ | +---+--+ > |His | |Her | |A/V +-+ |HAN | > |Office| |Office| |LAN | +-+Router| > |Router| |Router| |Router| | +--+---+ > +---+--+ +---+--+ +---+--+ | | > | | | | > -------+--- -----+--- -----+--- ----+---- >=20 > As far as the cases we want to cover or not cover; IMHO, if our solution to the tougher problems, such as the subnet delegation model, doesn't work in 4b, we're not really done. That said, for most residential/SOHO purposes, we're talking about (1), (2a), (2b), and (3a). >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Fred Baker >> Sent: Thursday, March 17, 2011 5:03 PM >> To: Templin, Fred L >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >>=20 >> On Mar 17, 2011, at 2:29 PM, Templin, Fred L wrote: >>=20 >>> Hi Fred, >>>=20 >>> What I mean to say is that when a host on the LAN >>> side of CE 'A' sends packets to a host on the LAN >>> side of CE 'B', 'A' has to figure out what to do >>> with them since it all it has in its routing table >>> is a default route. >>=20 >> In any context where routing comes up, there is more than one LAN in the >> local area, and the question is how to get a datagram from one to the other. >> Consider this simplistic case: >>=20 >> ISP >> | >> +--+---+ >> | CPE | >> |Router| >> +--+---+ >> ------+-------+----------------+----- >> +--+--+ +---+--+ >> |Alice| |Router| >> +-----+ +--+---+ >> ----+----+-------- >> +-+-+ >> |Bob| >> +---+ >>=20 >> Alice wants to send a datagram to Bob, and because she got her RA from the >> CPE, considers the CPE her default gateway. So sends the datagram to Bob's >> address at the IP layer, and to the CPE's address at the link layer. >>=20 >> If you are expecting the CPE to respond with a redirect to the other router >> in the picture, the CPE has to know that the other router is a router and >> has a LAN behind it, and specifically the LAN that Bob's subnet is on. More >> generally, in a home that has them all, one could readily imagine >>=20 >> ISP >> | >> +--+---+ >> | CPE | >> |Router| >> +---+--+ Home backbone LAN >> -----+----------+-+--------+----------+--- >> +---+--+ +---+--+ +---+--+ +---+--+ >> |His | |Her | |A/V | |HAN | >> |Office| |Office| |LAN | |Router| >> |Router| |Router| |Router| +--+---+ >> +---+--+ +---+--+ +---+--+ | >> -------+--- -----+--- -----+--- ----+---- >>=20 >> If "Alice" is in "Her Office" and "Bob" is in "His Office", how does Alice's >> router know where the default route should point to? What is its "default >> gateway"? >>=20 >> I understand your point that if you have a trivially simple network, with >> one router and everything attached to it, it knows what you're doing. >> Predicating everything on that simplistic picture is, in my experience, >> naive. >>=20 >>> So, 'A' bounces the initial packets off its default >>> router 'C' which forwards them to 'B' but also >>> returns redirection messages to 'A'. >>>=20 >>> 'C' can know about 'B' if it has full topology >>> information, but it is possible that 'C' also has >>> only partial topology information and has to default >>> route the initial packets through some higher level >>> gateway 'D'. 'D' can then forward the packets on >>> towards 'B', and can return redirection messages >>> to 'C', then 'C' can proxy the redirection messages >>> back to 'A'. >>>=20 >>> So, there can be a hierarchy of proxying gateways >>> in the operator's network, where each higher layer >>> in the hierarchy has more topology information than >>> the layer below it. I'm not quite asking for the same >>> thing as a full-up ND_Proxy, however, since all I'm >>> asking for is proxying of redirection messages. >>>=20 >>> Was this informational or obfuscational? >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com=20 >>>=20 >>>> -----Original Message----- >>>> From: Fred Baker [mailto:fred@cisco.com]=20 >>>> Sent: Thursday, March 17, 2011 2:10 PM >>>> To: Templin, Fred L >>>> Cc: Hemant Singh (shemant); Cameron Byrne; IPv6 Ops WG >>>> Subject: Re: [v6ops] I-D=20 >>>> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>>>=20 >>>> Really? How does the router emitting the ICMP Redirect learn=20 >>>> where routes should be directed to? How does it compare them? >>>>=20 >>>> On Mar 17, 2011, at 1:55 PM, Templin, Fred L wrote: >>>>=20 >>>>>=20 >>>>> Regarding scaling, there is another way to do dynamic >>>>> routing when traditional proactive routing protocols >>>>> like OSPFv3 and RIPng cannot be used. For example, if >>>>> the CEs and BRs can be represented as neighbors on a >>>>> virtual NBMA link, then ICMP redirection can be used. >>>>>=20 >>>>> This would be classified as an on-demand (instead of >>>>> proactive) dynamic routing protocol, and so does not >>>>> need to hold non-essential routes in the RIB. >>>>>=20 >>>>> I have specified a way to do this for ISATAP in the >>>>> latest VET spec (draft-templin-intarea-vet) but the >>>>> same method can be applied to other mainfestations >>>>> of virtual NBMA links as well. >>>>>=20 >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Sun Apr 3 08: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 E5D703A682D for ; Sun, 3 Apr 2011 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 PjJ6O7-T14Ao for ; Sun, 3 Apr 2011 08:09:45 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 3F7CB3A6813 for ; Sun, 3 Apr 2011 08:09:44 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p33FBPjK020143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 Apr 2011 08:11:25 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p33FBPYD027107; Sun, 3 Apr 2011 08:11:25 -0700 (PDT) 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 p33FBPV9027101 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 3 Apr 2011 08:11:25 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Sun, 3 Apr 2011 08:11:25 -0700 From: "Templin, Fred L" To: Fred Baker Date: Sun, 3 Apr 2011 08:11:23 -0700 Thread-Topic: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvwqhO9BdUyiwMRQ4qcBPNNIw4tOABZkpaw Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> In-Reply-To: <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@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 Ops WG Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Sun, 03 Apr 2011 15:09:47 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, April 01, 2011 1:19 PM > To: Templin, Fred L > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Fwd: I-D > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > > On Apr 1, 2011, at 8:13 PM, Templin, Fred L wrote: > > > Hi Fred, > > > > Not sure if you were looking for feedback on this, but all > > of these SOHO-network-behind-the-CPE scenarios you outlined > > have one thing in common - they can all be supported by > > ISATAP. Is it too early to introduce that into the > > discussion? > > I suspect residential/SOHO networks will use native routing, > not an overlay. What would be interesting in an operational > group might be reports from people using ISATAP in these environments. I fully agree that native IPv6 should be preferred when it is available within these sorts of networks. But, as your wide variety of network topology diagrams show, it may not always be possible to predict the kinds of configurations the end users might have in place. In some scenarios, it might be beneficial to be able to automatically "light up" IPv6 when the new CPE router is dropped into place. Thanks - Fred fred.l.templin@boeing.com > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] > >> On Behalf Of Fred Baker > >> Sent: Friday, April 01, 2011 7:09 AM > >> To: IPv6 Ops WG > >> Subject: [v6ops] Fwd: I-D > >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >> > >> As promised Thursday... > >> > >> This is some ruminations I had regarding CPE routers and > >> shared with the design team. > >> > >> Begin forwarded message: > >> > >>> From: Fred Baker > >>> Date: March 28, 2011 4:36:28 AM GMT+02:00 > >>> To: > >>> Cc: cpe-router@external.cisco.com > >>> Subject: Re: [v6ops] I-D > >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>> > >>> On Mar 27, 2011, at 11:22 PM, Frank Bulk wrote: > >>> > >>>> Thanks for the diagram. Because we're talking about > multi-homing, > >>>> multi-routers, and stacked routers, it may be helpful to > create an > >>>> exhaustive set of diagrams that cover each scenario so we > >> can be on the same > >>>> page when talking about this bis draft and also work > >> through our ideas in > >>>> each of the scenarios. > >>>> > >>>> It may end up that the scope of this draft is reduced to > just a few > >>>> scenarios, even though we may *want* to tackle them all. > >>>> > >>>> Frank > >>> > >>> > >>> Copying the design team; I don't want them to take this as > >> direction, but it might be appropriate input to their thoughts. > >>> > >>> My personal opinion: the use case for a residential or SOHO > >> network is very simple. A common one - the one in my > >> children's homes - is "I have a router and it connects me to > >> the Internet", as James Woodyat has spoken about. This was > >> the only case discussed in draft-ietf-v6ops-cpe-router: > >>> > >>> 1) Simple Residential Network > >>> > >>> `. ISP ,' > >>> `--+--' > >>> | > >>> +-----+-----+ > >>> |Residential| > >>> |CPE Router | > >>> +-----+-----+ > >>> | > >>> `----------+---------- > >>> Wired and Wireless LAN > >>> > >>> A variation on that is Cisco's recommendation for its > >> telecommuter population (which is perhaps 1/3 of the company, > >> at least part-time): we use an 8xx series router, split the > >> four "inside" ports between two or more subnets, one of which > >> is for the telecommuter's home office, and provide a wireless > >> access for use by the telecommuter. In my case, I don't use > >> the wireless capability, as wired is more reliable and I > >> pretty much sit at a desk; I instead have a 24 port > >> 10/100/1000 switch wired to the various rooms in my home, > >> including two 802.11g access points that effectively extend > >> that LAN throughout the house. The latter are, however, a > >> technical detail; if I chose to, I imagine I could build that > >> all into a higher end router. > >>> > >>> 2) Multi-LAN Residential Network > >>> > >>> `. ISP ,' > >>> `--+--' > >>> | > >>> +-------+-------+ > >>> | Residential | > >>> | CPE Router | > >>> +-+-----+-----+-+ > >>> | | | > >>> ` --+-- --+-- --+-- > >>> Wired and Wireless LANs > >>> > >>> There are two obvious implementations of a multi-LAN > >> residential network: one could implement separate subnets and > >> route between them, and one could implement an ND Proxy and > >> bridge between them. I suspect both implementations have > >> their cases, and should be treated as the "routed" and > >> "ND-proxy" subcases of the form. > >>> > >>> For internal structure, I think the case I mentioned should > >> be present, if only because it represents the most general case: > >>> > >>> 3) Multi-router subnetted network > >>> > >>> This again has two sub-cases; it could be literally a tree, > >> as I have drawn it, or could include some amount of > >> complexity such as interconnecting some of the non-backbone > >> subnets. I might call those "tree" and "redundant" networks. > >>> > >>> \ ISP / > >>> `--+--' > >>> | > >>> +--+---+ > >>> | CPE | > >>> |Router| > >>> +---+--+ > >>> | Home backbone LAN > >>> -----+----------+-+--------+----------+--- > >>> | | | | > >>> +---+--+ +---+--+ +---+--+ +---+--+ > >>> |His | |Her | |A/V | |HAN | > >>> |Office| |Office| |LAN | |Router| > >>> |Router| |Router| |Router| +--+---+ > >>> +---+--+ +---+--+ +---+--+ | > >>> | | | | > >>> -------+--- -----+--- -----+--- ----+---- > >>> > >>> There are two more bits of complexity that should not be > >> omitted: multihoming, and redundant paths. These are each, I > >> think, special cases of the first three, such as > >>> > >>> 4) Multihomed network > >>> > >>> The most common version of a multihomed network, I suspect, > >> is a network in a home where multiple people have offices, > >> virtual or physical, and whose companies have similar > >> information security policies to Cisco's; James Polk could > >> give you some insight there, as Motorola required his wife to > >> maintain similar separation between work and home. The > >> amusing thing was that he could hear her on the phone. As in > >> case 2, each had a router that provided them access to both a > >> "secured" subnet for their office and an "unsecured" subnet > >> for the home; they connected the "unsecured" subnets on the > >> home LAN. Jari Arkko's home is another example, although to > >> my knowledge his wife doesn't work outside the home - he > >> simply chooses to have multiple upstreams. So the key > >> differentiation in this case is that it has multiple upstreams. > >>> > >>> \ /\ / > >>> \ ISP / \ ISP / > >>> `--+--' `--+--' > >>> | | > >>> +--+---+ +--+---+ > >>> | CPE | | CPE | > >>> |Router| |Router| > >>> +---+--+ +---+--+ > >>> | | Home backbone LAN > >>> -----+-+--------+-+--------+----------+--- > >>> | | | | > >>> Various variations on cases 1, 2, and 3 > >>> > >>> So, for my money, six cases and subcases: > >>> 1) Simple residential network > >>> 2a) Routed Multi-LAN Residential Network > >>> 2b) ND-Proxy Multi-LAN Residential Network > >>> 3a) Tree Multi-router subnetted network > >>> 3b) Redundant Multi-router subnetted network > >>> 4) Multihomed Network > >>> > >>> The most general case, of course, is a multihomed redundant > >> multi-router subnetted network. This begins to look like an > >> SMB network, and might want to be called out explicitly: > >>> > >>> 4b) Multihomed Redundant Multi-router subnetted network > >>> > >>> \ /\ / > >>> \ ISP / \ ISP / > >>> `--+--' `--+--' > >>> | | > >>> +--+---+ +--+---+ > >>> | CPE | | CPE | > >>> |Router| |Router| > >>> +---+--+ +---+--+ > >>> | | Home backbone LAN > >>> -----+-+--------+-+--------+----------+--- > >>> | | | | | > >>> +---+--+ +---+--+ +---+--+ | +---+--+ > >>> |His | |Her | |A/V +-+ |HAN | > >>> |Office| |Office| |LAN | +-+Router| > >>> |Router| |Router| |Router| | +--+---+ > >>> +---+--+ +---+--+ +---+--+ | | > >>> | | | | > >>> -------+--- -----+--- -----+--- ----+---- > >>> > >>> As far as the cases we want to cover or not cover; IMHO, if > >> our solution to the tougher problems, such as the subnet > >> delegation model, doesn't work in 4b, we're not really done. > >> That said, for most residential/SOHO purposes, we're talking > >> about (1), (2a), (2b), and (3a). > >>> > >>>> -----Original Message----- > >>>> From: v6ops-bounces@ietf.org > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of > >>>> Fred Baker > >>>> Sent: Thursday, March 17, 2011 5:03 PM > >>>> To: Templin, Fred L > >>>> Cc: IPv6 Ops WG > >>>> Subject: Re: [v6ops] I-D > >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>>> > >>>> > >>>> On Mar 17, 2011, at 2:29 PM, Templin, Fred L wrote: > >>>> > >>>>> Hi Fred, > >>>>> > >>>>> What I mean to say is that when a host on the LAN > >>>>> side of CE 'A' sends packets to a host on the LAN > >>>>> side of CE 'B', 'A' has to figure out what to do > >>>>> with them since it all it has in its routing table > >>>>> is a default route. > >>>> > >>>> In any context where routing comes up, there is more than > >> one LAN in the > >>>> local area, and the question is how to get a datagram from > >> one to the other. > >>>> Consider this simplistic case: > >>>> > >>>> ISP > >>>> | > >>>> +--+---+ > >>>> | CPE | > >>>> |Router| > >>>> +--+---+ > >>>> ------+-------+----------------+----- > >>>> +--+--+ +---+--+ > >>>> |Alice| |Router| > >>>> +-----+ +--+---+ > >>>> ----+----+-------- > >>>> +-+-+ > >>>> |Bob| > >>>> +---+ > >>>> > >>>> Alice wants to send a datagram to Bob, and because she got > >> her RA from the > >>>> CPE, considers the CPE her default gateway. So sends the > >> datagram to Bob's > >>>> address at the IP layer, and to the CPE's address at the > >> link layer. > >>>> > >>>> If you are expecting the CPE to respond with a redirect to > >> the other router > >>>> in the picture, the CPE has to know that the other router > >> is a router and > >>>> has a LAN behind it, and specifically the LAN that Bob's > >> subnet is on. More > >>>> generally, in a home that has them all, one could readily imagine > >>>> > >>>> ISP > >>>> | > >>>> +--+---+ > >>>> | CPE | > >>>> |Router| > >>>> +---+--+ Home backbone LAN > >>>> -----+----------+-+--------+----------+--- > >>>> +---+--+ +---+--+ +---+--+ +---+--+ > >>>> |His | |Her | |A/V | |HAN | > >>>> |Office| |Office| |LAN | |Router| > >>>> |Router| |Router| |Router| +--+---+ > >>>> +---+--+ +---+--+ +---+--+ | > >>>> -------+--- -----+--- -----+--- ----+---- > >>>> > >>>> If "Alice" is in "Her Office" and "Bob" is in "His > >> Office", how does Alice's > >>>> router know where the default route should point to? What > >> is its "default > >>>> gateway"? > >>>> > >>>> I understand your point that if you have a trivially > >> simple network, with > >>>> one router and everything attached to it, it knows what > >> you're doing. > >>>> Predicating everything on that simplistic picture is, in > >> my experience, > >>>> naive. > >>>> > >>>>> So, 'A' bounces the initial packets off its default > >>>>> router 'C' which forwards them to 'B' but also > >>>>> returns redirection messages to 'A'. > >>>>> > >>>>> 'C' can know about 'B' if it has full topology > >>>>> information, but it is possible that 'C' also has > >>>>> only partial topology information and has to default > >>>>> route the initial packets through some higher level > >>>>> gateway 'D'. 'D' can then forward the packets on > >>>>> towards 'B', and can return redirection messages > >>>>> to 'C', then 'C' can proxy the redirection messages > >>>>> back to 'A'. > >>>>> > >>>>> So, there can be a hierarchy of proxying gateways > >>>>> in the operator's network, where each higher layer > >>>>> in the hierarchy has more topology information than > >>>>> the layer below it. I'm not quite asking for the same > >>>>> thing as a full-up ND_Proxy, however, since all I'm > >>>>> asking for is proxying of redirection messages. > >>>>> > >>>>> Was this informational or obfuscational? > >>>>> > >>>>> Thanks - Fred > >>>>> fred.l.templin@boeing.com > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Fred Baker [mailto:fred@cisco.com] > >>>>>> Sent: Thursday, March 17, 2011 2:10 PM > >>>>>> To: Templin, Fred L > >>>>>> Cc: Hemant Singh (shemant); Cameron Byrne; IPv6 Ops WG > >>>>>> Subject: Re: [v6ops] I-D > >>>>>> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>>>>> > >>>>>> Really? How does the router emitting the ICMP Redirect learn > >>>>>> where routes should be directed to? How does it compare them? > >>>>>> > >>>>>> On Mar 17, 2011, at 1:55 PM, Templin, Fred L wrote: > >>>>>> > >>>>>>> > >>>>>>> Regarding scaling, there is another way to do dynamic > >>>>>>> routing when traditional proactive routing protocols > >>>>>>> like OSPFv3 and RIPng cannot be used. For example, if > >>>>>>> the CEs and BRs can be represented as neighbors on a > >>>>>>> virtual NBMA link, then ICMP redirection can be used. > >>>>>>> > >>>>>>> This would be classified as an on-demand (instead of > >>>>>>> proactive) dynamic routing protocol, and so does not > >>>>>>> need to hold non-essential routes in the RIB. > >>>>>>> > >>>>>>> I have specified a way to do this for ISATAP in the > >>>>>>> latest VET spec (draft-templin-intarea-vet) but the > >>>>>>> same method can be applied to other mainfestations > >>>>>>> of virtual NBMA links as well. > >>>>>>> > >>>>>>> Thanks - Fred > >>>>>>> fred.l.templin@boeing.com > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > From joelja@bogus.com Sun Apr 3 16:08: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 0BBCB3A68C0 for ; Sun, 3 Apr 2011 16:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 77du5kfABUHF for ; Sun, 3 Apr 2011 16:08:19 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 2F9753A6889 for ; Sun, 3 Apr 2011 16:08:17 -0700 (PDT) Received: from 23173jjaeggli.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 p33N9vis056241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 3 Apr 2011 23:09:58 GMT (envelope-from joelja@bogus.com) Message-ID: <4D98FE45.4050608@bogus.com> Date: Sun, 03 Apr 2011 16:09:57 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: IPv6 Ops WG 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]); Sun, 03 Apr 2011 23:09:59 +0000 (UTC) Subject: [v6ops] draft minutes first session thursday March 31 0900 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2011 23:08:22 -0000 IPv6 Operations - IETF 80 Thursday 31 March, 9:00-11:30 0) Agenda bashing fred baker – presents comments on working group process We're bothered by the amount of time we have available to devote each presentation. Drafts will de considered not because they have made the deadlines but rather because that have archived traction on the mailing list. Chairs will engage in editorial discretion. Presentations without a draft behind them, will continue to be brought to the wg on the basis of relevance. Hum requested to demonstrate consensus around sentiment. More postive than negative volume. 1) Some experiences of common hosts' behavior in broken IPv6 networks http://tools.ietf.org/agenda/80/slides/v6ops-12.pdf Teemu Savolainen - presenting going to share experiences with host behavior Tim Chown - presents rogue ra interaction with happy eyeballs (2nd to last slide) Bad ipv6 behabior due to rogue RAs With no counter-measures, there would have been 250,000 of these rogue Ras. Mostly related to connection sharing. Sample period of 376 days. Dmitri Anipko - With the most recent proposal RFC 3484 bis, 6to4 would be deprioritized compared to IPv4, so if most rogue RAs are 6to4, no other solution may be needed? Simon Perreault – not that simple SwedeMike (jabber) - removing rogue RA is something any service provider should do, it's basic stuff. Don't let customers talk L2 to each other. 2) Happy Eyeballs Implementation Report http://tools.ietf.org/agenda/80/slides/v6ops-17.pdf Simon Perreault - presenting Implmentation of happyballs in draft in Erlang findings: global P mechanism in current drafti is broken P is dominated by single stack ipv4 solutions: only update P for dual stack hosts, update P asyncronously, do per destination P or do away with P findings: do away with useless delays solutions: spec says wait lookup collect but if lookup for ipvX returns no result, ipvY should start connecting immmediately. Janos Mohacsi (jabber)- questions to happy-eyeballs: what about DNS based round-round load-balancing? It is very widely used. Dan Wing – happy eyeballs works fine with dns load balancing. Andri Yurshenko – we do parallel attempts with different address families Jan ker - I don't disagree - why is dns spamming considered out of scope. think it's out of scope. Fred Baker – by the way, we do do api's Janos Mohacsi - Agree with Fred, We should work on API to help proper behaviour - like happy-eyeball. 3) Experimental Observations on Dual Stack Service Performance http://tools.ietf.org/agenda/80/slides/v6ops-1.pdf Geoff Huston - looking at the problem from the side of the server When you look at the world from that vantage point of how much does a server see, you see a huge amount of capability. You have new experiment every time it runs. V6-only test is using ipv6 lteral e.g. no dns full blown tcpdump along with typical server logs Dual stack failures are interesting (e.g. Hosts that deal fine with v6 or v4 only resources but not dual stack) The internet is remarking heterogeneous not homogenious, apnic site users about 5% will prefer v6 on a more popular site it's more like .02%. V6only is 4% why are there 20x more folks that could use v6 but don't use it SwedeMike (jabber) - 6to4 is enabled by default if you have a GUA on windows vista/7 but they don't prefer it geoff - If you prefer v6 in autotunneling things get pretty rough folk coming in on v6 unicast seem to do so at about the same rate (speed) as ipv4 The penatly for 6to4 is around 1.2 seconds, teredo setup is at least 1rtt As part of the experiment tried to mitigate 6to4 variability by putting v6 relay in the server Measure the tcp-3way tunnel setup penalty at 150ms average If you think that's bad lets look at teredo if the only interface you have is teredo it will not retrieve a AAAA , therefore only exercised for literal 30% of clients can pull down the object using terredo, an imense capacity for v6 distribution of setup time, seems to take around 2/3 of a second to setup peaks at 2 seconds and 3 seonds tunnel rtt cost is about 300ms some clients get away with almost no added cost. If you're on unicast v6 be happy and smile, if you're on tunneled v6 turn it off it's dual stack failure .6%, we're not sure why. number is high but unreliable. Connections failure How many folk can send me a syn but not an ack Failure rates for unicast v6 are 2-4% terredo failures = 35% 12-24% of 6to4 failure due to protocol 41 filtering 38% of terredo fail due to icmp filtering, you also don't like outgoing udp so ice/stun/turn probably don't work either. If you want to run v6 tunneling today don't. help us, see url labs.apnic.net tore anderson (jabber) - Regarding 6to4 relay congestion being unlikely due to the low levels of 6to4 traffic: I understand that most of the relayed 6to4 traffic is actually BitTorrent traffic that is rendezvousing with Teredo. This is of course invisible from the web server vantage point, but it might anyway cause congestion on the same 6to4 (and Teredo) relays that also handle the web server traffic that are actually observed in the experiments. Simon Leinen (jabber) - Tore: We have more than 100 Mb/s on our 6to4 relay right now; looks like most of this is indeed BitTorrent. Dave Thaler (jabber) - p2p works much better than non-native to native (which is actually related to why Windows doesn't do AAAA queries if it just has Teredo, as Fred said... by design) Simon P - should it be depricated geoff - killed simon p: would it be better to turn it (relays) off? Igor Gashinsky - killing relay isn't effective kill os. igor G - Counting dns failure rate is atrocious Geoff H - this is tcp failure counting so the dns failures don't show up Rajev - If we look at the data from the weekend do we draw different concusions about tunnel performance? Geoff H - We don't consider 12% failure as drammatically better than 20% it's just bad. Lorenzo C - The results match what we see, we've been looking at the network, we have certain large isps with peaks around 3-4% Geoff - would that we had more data, we seem to have tiny aperatures. badness clumps. the time for automatic tunneling has really passed some operating systems and home routers should turn it on by default we'll discuss this later but I think that a statement from this body supported by this data would be helpful. Dmitry Anipko (jabber) - Comment to Lorentzo: connection from automatic tunneling to native IPv6 is not preferred by default per RFC 3484 geoff h- we can't hop over brokeness in the isps netowrk lorenzo - don't try and make pigs fly Tony Hain - it is insane to insist on deploying a transition technology half-ass, then blame it for failures.. Mark T - qualify statement, in a controlled environment we can hop over v4 netowrks Tony Hain - if the content providers deployed 6to4 on their end the path would be exactly the same as IPv4 door-to-door. 4) Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts http://tools.ietf.org/agenda/80/slides/v6ops-21.pptx 14-Mar-11, Andrew Yourtchenko - changes add srv records section added mif reference added debugstrawman todo need more implmentations address hysteris problem need pluggable name based connect api... write a seperate draft for that? Where to take it? Fred B- The INT area. Jari Arko - yes Dave Thaler - Microsoft's pm's went to content providers, there is level of concern about multiple simulatnious connections and pontetially large number of resets. major agreement that problem needs to be solved. Can we do a better job about which one to try first? Maybe p could actually be fairly large if you had a good guess. Mark Andrews - happy eyeballs is a really generic problem with multihomed machines Janos Mohacsi - Agree with Dave Thaler: Some providers blacklisting clients with high syn and rst rates Fred B - some sort of memory about specifc addresses or prefixes Igor - I'm going to disagree with that sorry, as on operator I'll take the pain from happy eyeballs over the pain from not having happy eyeballs. Andrew - Feedback needs to be incorporated into the list Janos Mohacsi (jabber) - Agree with Simon Leinen. That is the correct solution as I have written earlier on v6ops mailing lists: RFC 3484(bis) can be used as a hint what makes sense and what is not. Dave Thaler - @simon: be careful, you need to it converge fast. starting with 0 knowledge for every s*d would be bad. That was my point about sharing knowledge so you guess right the first time almost always danwing - I disagree with Thaler, because a Happy Eyeballs user will _not_ be sending a lot of SYNs and RSTs. "P" prevents them from doing that. It's only the first connection that would be in parallel. Subsequent connections will continue to trend towards IPv6 (if it's working) or towards IPv4 (if it's working). And content providers have one, and only one primary job in life: deliver content. Happy Eyeballs is aligned with that goal. Which Igor re-inforced at the mic. 5) IPv6 Multihoming without Network Address Translation http://tools.ietf.org/agenda/80/slides/v6ops-10.ppt 6-Dec-10, presenter unknown - next steps? Fred B - Need feedback 6) Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations http://tools.ietf.org/agenda/80/slides/v6ops-4.ppt 14-Mar-11, Fred Templin- problem mitigations For zeroconf dynmic routing, we've come up with proposal that meets these requirements - out of scope for this group. Fred B - Ron asked us to do another parallel last call on WG (on the revised draft) while an ietf last call is carried out. adrew yourtchenko - Well, on approach keep decrimenting the hopcount if it gets below a certain threshold, then throw it out. 7) IPv6 in 3GPP Evolved Packet System http://tools.ietf.org/html/draft-korhonen-v6ops-3gpp-eps 9-Feb-11, j korhonen - updates since ietf79 work to make the draft more opinion neutral add operational aspects of v6only networks added ipv6 address configuration clarifications add ipv6 roaming conisderations adder inter-rat handovers Guillaume Leclanche (jabber) - Problem with v6 in the mobile world is that implementations are way behind the 3gpp releases. Which are themselves way behind IETF specs. J korhonen - needs 3316 recommendations Tina Tsou - about epc, is it addressed here? Fred - Call the question, hum (is this a working group document) Joel J - hum in affirmative not noted opposition. Fred - Hum (in favor of wglc) Joel J - hum in affirmative of WGLC 8) NAT64-CPE Mode Operation for Opening Residential Service http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe 14-Mar-11, Gang Chen - uses requirements changes since 79 pcp upnp and nant-pmp are recomended with nat64cpe Fred B - we'd work on the requirements, the solution would be behave Gang C - we're generating requirepments Fred B- we'll have to take the adoption question to the list. dan wing - First half is a draft for v6ops, second half is a scenario in behave. Hui Deng - ? 9) Experience from NAT64 applications http://tools.ietf.org/agenda/80/slides/v6ops-18.ppt 7-Mar-11, Cathy - test enviroment description scenarios results dan wing - thanks for reasearch. It's easy to draw the wrong conclusion e.g. everyone has breathed air has died Some other examples are caused by ipv4 address sharing I realize this is the first generation of this analysis. in behave we have cgnat in nat444 analysis. We need to uplevel this to the spefic problems in nat65 that make this harder and or which can be addressed. Fred B - feedback and testing on the algorithm that behave has just produced Dan Wing - Failure needs to be traced back to a root cause, where can we help. jari arko - thank you this is important work Also want to emphasis on finding the root cause - different failure modes, some are in application there are some problems with the content, third class where there's something wrong with the nat64 or natpt device. Simon Perreault (jabber) - FYI: We're running a NAT64 experiment right now (SSID: ietf-nat64) with a survey to gather your experiences. Please try it. hui deng - We do need to analyis the issues that those applciations really have jari - it's going ot be a long task tina tsou? - two comments, mainly affected by the p2p applications? who supports nat64 couldn't find it on the market jari - there are vendors with this product already so do nat64 testing Janos Mohacsi (jabber) - to testers: http://ecdysis.viagenie.ca/ 10) Comcast IPv6 Experiences (no slides on agenda) 7-Mar-11, JOHN Brzozowski - trials starting in jan 2010 making determination of need based on volume Deployed 6rdbr performance base on proximity geolocation potentially impacted limited support/manual configuartion native dual stack l2 delivery geographically liimited trial backoffice support project started 4-5 years ago wes george - 6to4 world ipv6 day, 6to4 relays what will happen, we'll shut it off? or there are some relay out there that make it ok. John B - it's (6to4 traffic) gonna go somehwere Fred - could nullroute the anycast address Wes G - assuming the client behaves well in that case John B - trying to suck less, 6to4 relays fred t – use of isatap? John B- we use it internally, our focus is on the native aspect. dave thaler - In 6to4 trials did you run into issues casued by broken relays John B - Return path is still the problem 11) World IPv6 Day Call to Arms http://tools.ietf.org/agenda/80/slides/v6ops-9.pdf 14-Mar-11, tim chown - world ipv6 day call to arms aims issues unmanaged tunnels pmtu connection timeouts next steps do we influence the experiement? Janos M (jabber) - I support tims draft Mark A - we should harden this in advance of june wes george - we need to stop looking at htis as an experiment it's testing for primetime not influencing it is wrong headed Janos Mohacsi (jabber) - about 6to4: discourage for this experiment - 6to4 should be used as a interim solution - not what IPv6 should be used. Tim C - change Fred B - value is 2 fold it's y2k, it's also marketing dave thaler - yes we want to influence the experiment Igor G - I hate to say this but the expierment is to break the users and see how many get fixed the meaningfully data is what happens Lorenzo C- lets not try to demonstrate that we can do this well but rather recognize what problems we have and make them better Somebody may decide to leave this stuff on Igor G- Whatever hacks you deploy please leave them in place 2:36:55 AM jhf: in case they have proven to work well Mark T - deployment on v6 day as though it were more than one day capture that as prime directive Dave Thaler - mark said what I meant... we want people to think and do what they would do if this were longer term, and learn what happens and get experience Lorenzo - More relay won't help or hinder them and if you call that influencing the experiment, then we should. ---- Done From Wesley.E.George@sprint.com Sun Apr 3 17: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 BFAD13A6889 for ; Sun, 3 Apr 2011 17:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDKgMXf4+BHV for ; Sun, 3 Apr 2011 17:09:15 -0700 (PDT) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by core3.amsl.com (Postfix) with ESMTP id B2E3C3A6825 for ; Sun, 3 Apr 2011 17:09:14 -0700 (PDT) Received: from mail116-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 00:10:56 +0000 Received: from mail116-va3 (localhost.localdomain [127.0.0.1]) by mail116-va3-R.bigfish.com (Postfix) with ESMTP id 1F7E58B006B; Mon, 4 Apr 2011 00:10:56 +0000 (UTC) X-SpamScore: -28 X-BigFish: VS-28(zz14dfR9371P542N4015Lzz1202hzzz2fh2a8h668h839h34h61h) 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 X-FB-SS: 0,0, Received: from mail116-va3 (localhost.localdomain [127.0.0.1]) by mail116-va3 (MessageSwitch) id 1301875848925248_21453; Mon, 4 Apr 2011 00:10:48 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.238]) by mail116-va3.bigfish.com (Postfix) with ESMTP id D433F17804F; Mon, 4 Apr 2011 00:10:48 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 00:10:44 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p340AhwX018178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Apr 2011 19:10:43 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0270.001; Sun, 3 Apr 2011 19:10:43 -0500 From: "George, Wes E [NTK]" To: Ole Troan Thread-Topic: 6to4 historic text. Thread-Index: AQHL78fV3tAflWkLQEqoIMxErPP9uJRKsgsQ Date: Mon, 4 Apr 2011 00:10:42 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6ACD9@PLSWM12A.ad.sprint.com> References: <1D97B6C9-F071-4124-B0FC-39026CC65B37@employees.org> In-Reply-To: <1D97B6C9-F071-4124-B0FC-39026CC65B37@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.75] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_015D_01CBF129.C0A8C430" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "IPv6 Operations \(v6ops@ietf.org\)" Subject: Re: [v6ops] 6to4 historic text. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 00:09:15 -0000 ------=_NextPart_000_015D_01CBF129.C0A8C430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ole - Two places I would recommend text: Introduction - I'd recommend removing references to draft-carpenter (and possibly draft-kuarsingh) here and leave just in section 4 (add to the end) - Since there are existing implementations in use today, this draft makes recommendations on how to best wind down support for the service without significant impact to implementations that are currently serving as adequate IPv6 connectivity for their users. Section 4, recommendations for operators - While this document has explained many reasons why 6to4 is not deployed widely and should not continue to be deployed further, the reality is that there are still many devices and users who are actively using 6to4 as a means to pass IPv6 traffic. This is evidenced by the non-trival load on the currently deployed 6to4 relays. For this reason, operators MUST NOT view this document as a recommendation to immediately shut down their existing 6to4 relays. Rather, in order to limit additional end-user impact and ensure an orderly wind-down of 6to4 usage, operators SHOULD retain their existing relays, and follow the recommendations found in [draft-carpenter]. It is quite likely that the combination of additional deployment of native IPv6 support in many networks and the elimination of support in hosts will begin a dramatic reduction in 6to4's use, but the timeframe is uncertain. This draft does not recommend a specific cutoff point where shutting down 6to4 relays is appropriate. Rather, this will be up to each relay operator to determine. Section 5 - Should we recommend something about not advertising capability for IPv6 if the device is trying to do internet connection sharing or serving as a router? I would think that it would be important to cover this as a way to reduce the deployment in the case of IPv6-capable hosts in a network that is configured to use (or try to use) 6to4. Thanks, Wes George -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Thursday, March 31, 2011 1:18 PM To: George, Wes E [NTK] Subject: 6to4 historic text. Wes, just a reminder for your todo box for some text. ;-) cheers, Ole ------=_NextPart_000_015D_01CBF129.C0A8C430 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDIxNTMzMTNaMCMGCSqGSIb3DQEJBDEWBBTor4pX1Hvb IJCYo3uI5/NBYd7wizBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYB1izDWaRzGgDj9djEyZklgApE3PM9w yvJUtzC7GTfNQCvqH9kNkClLR3ZWZgGk5V29R8y3NXQcPlW1D7UntOWacGvLvEY8ExwIXRY0aT20 sdvZBXQnMC6ZT9WIPpqpx2uv4slfKFYyHa5oIqV00cOuUgAf1v23UVCzLwImsdfYwQAAAAAAAA== ------=_NextPart_000_015D_01CBF129.C0A8C430-- From roberta.maglione@telecomitalia.it Mon Apr 4 06:28: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 9C3523A69F0 for ; Mon, 4 Apr 2011 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.902 X-Spam-Level: X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[AWL=-2.583, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhTsD-k97SZA for ; Mon, 4 Apr 2011 06:28:17 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 42CBA3A69BA for ; Mon, 4 Apr 2011 06:28:16 -0700 (PDT) Content-Type: multipart/mixed; boundary="_da7fe5b5-2d12-4911-adcd-27770b6667f5_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Apr 2011 15:29:57 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 4 Apr 2011 15:29:55 +0200 From: Maglione Roberta To: sunqiong , "'v6ops@ietf.org'" Date: Mon, 4 Apr 2011 15:29:47 +0200 Thread-Topic: [v6ops] comments on stateless mechanism presentation Thread-Index: Acvwh+De5Ydi9CMPTXyUm2r9Kgv8UwCQ5GKA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB294F718@GRFMBX704BA020.griffon.local> References: <201104020013357205383@ctbri.com.cn> In-Reply-To: <201104020013357205383@ctbri.com.cn> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Cc: =?gb2312?B?veKz5bfm?= , Ullio Mario Subject: Re: [v6ops] comments on stateless mechanism presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 13:28:24 -0000 --_da7fe5b5-2d12-4911-adcd-27770b6667f5_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB294F718GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB294F718GRFMBX704BA02_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUWlvbmcsDQogICBUaGFua3MgZm9yIHlvdXIgcmVwbHksIHBsZWFzZSBzZWUgaW5saW5lLg0K QmVzdCByZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBzdW5xaW9uZyBbbWFpbHRvOnN1bnFpb25nQGN0YnJpLmNvbS5jbl0NClNlbnQ6 IHZlbmVyZKisIDEgYXByaWxlIDIwMTEgMTguMTQNClRvOiBNYWdsaW9uZSBSb2JlcnRhOyAndjZv cHNAaWV0Zi5vcmcnDQpDYzogveKz5bfmDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBjb21tZW50cyBv biBzdGF0ZWxlc3MgbWVjaGFuaXNtIHByZXNlbnRhdGlvbg0KDQpIaSBSb2JlcnRhLA0KDQpUaGFu ayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiBJJ20gU3VuIFFpb25nIGFuZCB0aGUg Y28tYXV0aG9yIG9mIHRoaXMgc2xpZGVzLg0KDQpJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIGFs bG9jYXRpb24gb2YgdGhlIGFkZHJlc3MgZm9yIEFGVFIgY291bGQgYmUgc2VwZXJhdGVkIGZyb20g YWRkcmVzcyBhbGxvY2F0aW9uIHByb2Nlc3MuIEJ1dCBhcyBhIGNvbW1vbiBwcm9ibGVtIGZvciB0 dW5uZWwtYmFzZWQgc29sdXRpb24sIHdlIHNob3VsZCBmaW5kIGEgcmVhc29uYWJsZSB3YXkgdG8g cGFzcyB0aGF0IGFkZHJlc3MgdG8gQjQsIGVpdGhlciBieSBzdGF0aWMgY29uZmlndXJhdGlvbiwg VFItMDY5IGJhc2VkIGNvbmZpZ3VyYXRpb24sIG9yIGEgbmV3IERIQ1B2NiBvcHRpb24uIE1heWJl IHRoZSBiZXN0IHdheSBpcyB0byBwYXNzIHRoZSBhZGRyZXNzIHZpYSBESENQdjYgd2hpY2ggd291 bGQgYWxzbyBuZWVkIHRvIHRha2Ugc29tZSBjaGFuZ2VzIGluIERIQ1B2NiBzZXJ2ZXIuDQoNCltS TV0gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHdpdGggRFMtTGl0ZSB0aGVyZSBpcyBhIG5lZWQgdG8g ZmluZCBhIHdheSB0byBwYXNzIHRvIHRoZSBCNCB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHR1 bm5lbCB0ZXJtaW5hdG9yLCBidXQgdGhpcyBpbiBteSBvcGluaW9uICBpcyBqdXN0IGEgcHJvdmlz aW9uaW5nIGlzc3VlIHRodXMgaXQgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIGFkZHJlc3Npbmcgc2No ZW1lIHRvIGJlIHVzZWQgaW4gdGhlIFNlcnZpY2UgUHJvdmlkZXKhr3MgbmV0d29yaywgdGhhdKGv cyB3aHkgSSB3YXMgc3VnZ2VzdGluZyB0byBhZGQgYSBzZXBhcmF0ZSBzbGlkZSB0byB0YWxrIGFi b3V0IHByb3Zpc2lvbmluZy4NCg0KSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgZmxleGlibGUgYWRk cmVzc2luZyBpcyBnb29kIGZyb20gYWRkcmVzc2luZyBhc3NpZ25tZW50IGFzcGVjdC4gSG93ZXZl ciwgY3VycmVudCBzdGF0ZWZ1bCBzb2x1dGlvbiB3b3VsZCBhbHNvIGJyaW5nIGEgbG90IG9mIGJ1 cmRlbiBmb3Igc2Vzc2lvbi1iYXNlZCBzdGF0ZSBtYW5hZ2VtZW50LCB0cmFmZmljIGxvZ2dpbmcs IGV0Yy4gQW5kIGl0IHdvdWxkIGFsc28gaGF2ZSBzY2FsYWJpbGl0eSBwcm9ibGVtIHdpdGggbWFz c2l2ZSBjb25jdXJyZW50IHNlc3Npb25zIGVzcGVjaWFsbHkgZm9yIGxhcmdlIFNQcy4gQXMgYSBy ZXN1bHQsIHdlIHRoaW5rIHN0YXRlbGVzcyBzb2x1dGlvbnMgd2l0aCBmbGV4aWJsZSBhZGRyZXNz aW5nIGFiaWxpdHkgc2hvdWxkIGJlIHJlY29tbWVuZGVkIC4NCg0KW1JNXSBFYWNoIHNvbHV0aW9u IGhhcyBpdHMgb3duIHByb3MgYW5kIGNvbnMsIGJ1dCB3ZSBzaG91bGQgYmUgY2FyZWZ1bCBhbmQg dXNlIGNvbXBhcmFibGUgY3JpdGVyaWEgd2hlbiB3ZSB0cnkgdG8gY29tcGFyZSBkaWZmZXJlbnQg YXBwcm9hY2hlcw0KDQoNCkJUVywgd2UgaGF2ZSBwcm9wb3NlZCBhIHNvbHV0aW9uIGNhbGxlZCBM QUZUNiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXN1bi12Nm9wcy1sYWZ0Ni0wMS50 eHQpLCB3aGljaCBhaW1zIHRvIGFjaGlldmUgbGlnaHR3ZWlnaHQgc3RhdGUtbWFuYWdlbWVudCAo bGFyZ2VseSByZWR1Y2UgdGhlIG51bWJlciBvZiBzdGF0ZSBlbnRyaWVzKSBhbmQgbGlnaHR3ZWln aHQgYWRkcmVzc2luZyAoZmxleGlibGUgYWRkcmVzc2luZyB3aXRoIG5vIGFkZHJlc3MgZm9ybWF0 KS4gSXQgaXMgYSB0cmFkZW9mZiBiZXR3ZWVuIGN1cnJlbnQgc2Vzc2lvbi1iYXNlZCBzdGF0ZWZ1 bCBzb2x1dGlvbiBhbmQgdG90YWxseSBzdGF0ZWxlc3Mgc29sdXRpb24uIFdlIHdvdWxkIGJlIGFw cHJlY2lhdGVkIHRvIGhhdmUgeW91ciBjb21tZW50cyBhcyB3ZWxsLg0KW1JNXSBUaGFua3MgZm9y IHRoZSBwb2ludGVyLCBJoa9sbCB0YWtlIGEgbG9vayBhdCB5b3VyIGRyYWZ0Lg0KDQpCZXN0IHJl Z2FyZHMNCiBSZWdhcmRzLA0KUm9iZXJ0YQ0KUWlvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kt6K8/sjLo7ogTWFnbGlvbmUgUm9iZXJ0YQ0Kt6LLzcqxvOSjuiAyMDEx LTA0LTAxICAxNTo1NjozMw0KytW8/sjLo7ogJ3Y2b3BzQGlldGYub3JnJw0Ks63LzaO6DQrW98zi o7ogW3Y2b3BzXSBjb21tZW50cyBvbiBzdGF0ZWxlc3MgbWVjaGFuaXNtIHByZXNlbnRhdGlvbg0K SGVsbG8sDQogICBJIHdvdWxkIGxpa2UgdG8gdHJ5IHRvIGNsYXJpZnkgdGhlIGNvbW1lbnQgSSBt YWRlIHllc3RlcmRheSBvbiBzbGlkZSA2Lg0KVGhlIHRoaXJkIGJ1bGxldCBvZiB0aGlzIHNsaWRl IHNheXM6DQoiSVNQcyBtYXkgYWRvcHQgZmxleGlibGUgYWRkcmVzcyBydWxlcywgbm8gZXh0cmEg cmVxdWlyZW1lbnRzIG9uIGFkZHJlc3MgZm9ybWF0IGFuZCBhZGRyZXNzIGFsbG9jYXRpb24iDQpN eSB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgaXMgdGhhdCB0aGUgcHVycG9zZSBvZiB0aGlzIHNsaWRl IGlzIHRvIGNvbXBhcmUgdGhlIGltcGFjdHMgb2YgdGhlIGRpZmZlcmVudCB0cmFuc2l0aW9uIG1l Y2hhbmlzbXMgaGF2ZSBvbiB0aGUgYWRkcmVzcyBhbGxvY2F0aW9uIHNjaGVtZSB0aGF0IHRoZSBJ U1AgaGFzIHRvIHVzZS4NCmRJVkkgdXNlcyBhIHNwZWNpZmljIGZvcm1hdCB0byBidWlsZCB0aGUg SVB2NiBhZGRyZXNzLCBtYWRlIGJ5IGNvbmNhdGVuYXRpbmcgYW4gSVB2NiBwcmVmaXggd2l0aCBh biBJUHY0ICsgYSBwb3J0LCB0aHVzIGl0IGludHJvZHVjZXMgc29tZSBjb25zdHJhaW5zIG9uIHRo ZSBhZGRyZXNzZXMgc2NoZW1lIHRvIGJlIHVzZWQgaW4gdGhlIG5ldHdvcmsNCldoaWxlIERTLUxp dGUgZG9lcyBub3QgaGF2ZSBhbnkgc3BlY2lmaWMgcmVxdWlyZW1lbnQgb24gdGhlIElQdjYgcHJl Zml4IGRlbGVnYXRlZCB0byB0aGUgY3VzdG9tZXJzLg0KVGhlIHRhYmxlIGluIHNsaWRlIDYgaW4g dGhlIGZpcnN0IGNvbHVtbiBmb3IgRFMtTEl0ZSBzYXlzOg0KIkFkZHJlc3Mgb2YgdGhlIHR1bm5l bCBlbmQgdG8gYmUgcGFzc2VkIg0KVGhpcyBzZW50ZW5jZSByZWZlcnMgdG8gdGhlIGFkZHJlc3Mg b2YgdGhlIEFGVFIgdGhhdCBuZWVkcyB0byBiZSBwcm92aXNpb25lZCBvbiB0aGUgQjQgaW4gb3Jk ZXIgdG8gYWxsb3cgdGhlIEI0IHRvIHNldHVwIHRoZSBJUHY0IG92ZXIgSVB2NiB0dW5uZWwuDQpU aGlzIGlzIGEgcHJvdmlzaW9uaW5nIGlzc3VlIChhbmQgQlRZIGl0IHNvbHZlZCBieSBESENQdjYg b3B0aW9uIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRmLXNvZnR3aXJlLWRzLWxpdGUtdHVubmVsLW9w dGlvbiwgbm93IGluIFJGQyBxdWV1ZSkuDQpUaGlzIHBvaW50IGlzIE5PVCByZWxhdGVkIHRvIHRo ZSBhZGRyZXNzIGFsbG9jYXRpb24gc2NoZW1lIHRvIGJlIHVzZWQgYnkgdGhlIElTUCwgdGh1cyBJ IGRvbid0IHRoaW5rIGl0IHNob3VsZCBhcHBlYXIgaW4gdGhpcyB0YWJsZS4NCklmIHlvdSB3YW50 IHRvIGNvbXBhcmUgdGhlIHByb3Zpc2lvbmluZyBhc3BlY3RzIG9mIHRoZSBkaWZmZXJlbnQgdGVj aG5pcXVlcyBJIHdvdWxkIHN1Z2dlc3QgYWRkaW5nIGEgc2VwYXJhdGUgc2xpZGUgZm9yIHRoZW0u DQpHb2luZyB0byB5b3VyIHNsaWRlIDExOiBGbGV4aWJsZSBhZGRyZXNzaW5nDQpJbiBteSBvcGlu aW9uIERTLUxpdGUgaGFzIHNvbWUgYWR2YW50YWdlcyBjb21wYXJlZCB0byBkSVZJIG9uIEZsZXhp YmxlIGFkZHJlc3NpbmcgcG9pbnQgYmVjYXVzZSwgYXMgSSBzYWlkIGJlZm9yZSwgRFMtTGl0ZSBk b2VzIG5vdCByZXF1aXJlcyBhIHNwZWNpZmljIGZvcm1hdCBmb3IgdGhlIElQdjYgcHJlZml4Lg0K VGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxs ZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNh dGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFu dGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2Ft ZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBw ZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBj b211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6 aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRl bnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y IHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcg b3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkg YXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5r cy4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBl c2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlh IG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFi YmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2Vt ZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRl IGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5 LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNl IGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNl IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lkOjAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAxQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEgbCdhbWJpZW50ZS4g Tm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiCoqCBuZWNlc3NhcmlvLg0KDQo= --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB294F718GRFMBX704BA02_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Qiong,

   Thanks for your reply, please see inli= ne.

Best regards,

Roberta

 

 

From:= sunqiong [mailto:sunqiong@ctbri.com.cn]
Sent: venerd=A8=AC 1 aprile = 2011 18.14
To: Maglione Roberta; 'v6ops@ietf.org'
Cc: =BD=E2=B3=E5=B7=E6
Subject: Re: [v6ops] comment= s on stateless mechanism presentation

 = ;

Hi Roberta,

 

Thank you very much for your comments. I'm Sun Qiong and the co-author of= this slides.

 

I agree with you that the allocation of the address for AFTR could b= e seperated from address allocation process. But as a common problem for tunnel-based solution, we should find a reasonable wa= y to pass that address to B4, either by static configuration, TR-069 based = configuration, or a new DHCPv6 option. Maybe the best way is to pass the ad= dress via DHCPv6 which would also need to take some changes in DHCPv6 server. =

 

[RM] I agree with you that with DS-Lite there is a = need to find a way to pass to the B4 the information about the tunnel terminator, but this in my opinion  is just a provis= ioning issue thus it is not related to the addressing scheme to be used in = the Service Provider=A1=AFs network, that=A1=AFs why I was suggesting to ad= d a separate slide to talk about provisioning.

 

I personally think that flexible addressing is good from addressing assig= nment aspect. However, current stateful solution would also bring a lot of burden for session-based state management, traff= ic logging, etc. And it would also have scalability problem with massi= ve concurrent sessions especially for large SPs. As a result, we think stat= eless solutions with flexible addressing ability should be recommended .

 

[RM] Each solution has its own pros and cons, but we should be = careful and use comparable criteria when we try to compare different approaches=

 

 

BTW, we have proposed a solution called LAFT6 (http://tools.ietf.org/id/draft-sun-v6ops-laft6-01.txt), which aims to achieve lightweight state-management (largely reduce th= e number of state entries) and lightweight addressing (flexible addres= sing with no address format). It is a tradeoff between current session= -based stateful solution and totally stateless solution. We would be appreciated to have your comments as well. = ;

[RM] Thanks for the pointer, I=A1=AFll take a l= ook at your draft. =

 

Best regards

 Regards,

Roberta

Qiong

 

 

= =B7=A2=BC=FE=C8=CB=A3=BA Maglione Roberta

= =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2011-04-01  15:56:33

= =CA=D5=BC=FE=C8=CB=A3=BA 'v6ops@ietf.org' <= /span>

= =B3=AD=CB=CD=A3=BA

= =D6=F7=CC=E2=A3=BA [v6ops] comments on stateless mechanism presentation

Hello,

   I would like to try to cl= arify the comment I made yesterday on sl= ide 6.

The third bullet of this slide says:

"ISPs may adopt flexible address rules,&nbs= p;no extra requirements on address format and=  address allocation"

My understanding of this is that the p= urpose of this slide is to compare the&n= bsp;impacts of the different transition mechanisms=  have on the address allocation scheme t= hat the ISP has to use.

dIVI uses a specific format to build t= he IPv6 address, made by concatenating an&nbs= p;IPv6 prefix with an IPv4 + a port,=  thus it introduces some constrains on t= he addresses scheme to be used in the&nb= sp;network

While DS-Lite does not have any specific&nb= sp;requirement on the IPv6 prefix delegated t= o the customers.

The table in slide 6 in the first = ;column for DS-LIte says:

"Address of the tunnel end to be = passed"

This sentence refers to the address of = ;the AFTR that needs to be provisioned o= n the B4 in order to allow the B4&n= bsp;to setup the IPv4 over IPv6 tunnel.<= /o:p>

This is a provisioning issue (and BTY = it solved by DHCPv6 option specified in = draft-ietf-softwire-ds-lite-tunnel-option, now in RFC q= ueue).

This point is NOT related to the addre= ss allocation scheme to be used by the&n= bsp;ISP, thus I don't think it should ap= pear in this table.

If you want to compare the provisioning&nbs= p;aspects of the different techniques I would=  suggest adding a separate slide for the= m.

Going to your slide 11: Flexible addressing=

In my opinion DS-Lite has some advantages&n= bsp;compared to dIVI on Flexible addressing p= oint because, as I said before, DS-Lite = does not requires a specific format for = the IPv6 prefix.

Thanks,

Regards,

Roberta

Questo messaggio e i suoi allegati sono&nbs= p;indirizzati esclusivamente alle persone indicate.&nbs= p;La diffusione, copia o qualsiasi altra azio= ne derivante dalla conoscenza di queste infor= mazioni sono rigorosamente vietate. Qualora abbiat= e ricevuto questo documento per errore siete&= nbsp;cortesemente pregati di darne immediata comun= icazione al mittente e di provvedere alla&nbs= p;sua distruzione, Grazie.

This e-mail and any attachments is confiden= tial and may contain privileged information i= ntended for the addressee(s) only. Dissemination,&= nbsp;copying, printing or use by anybody else=  is unauthorised. If you are not the&nbs= p;intended recipient, please delete this message&n= bsp;and any attachments and advise the sender=  by return e-mail, Thanks.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB294F718GRFMBX704BA02_-- --_da7fe5b5-2d12-4911-adcd-27770b6667f5_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_da7fe5b5-2d12-4911-adcd-27770b6667f5_-- From fred@cisco.com Mon Apr 4 08:59: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 B736728C114 for ; Mon, 4 Apr 2011 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.028 X-Spam-Level: X-Spam-Status: No, score=-110.028 tagged_above=-999 required=5 tests=[AWL=-0.329, 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 xly7fj9wkpI4 for ; Mon, 4 Apr 2011 08:59:26 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5D5A928C100 for ; Mon, 4 Apr 2011 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2821; q=dns/txt; s=iport; t=1301932869; x=1303142469; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=aBlMmLR2T0RG4+8KhPBQBvcUsx6zpEW2/anJq3oupxI=; b=bOhNAffwLJqIO/Ww0DSXIpuZvpnEpbrrWR9aRebs4jA/h4r/tDbNvRIn pCVJzNZyu3GpFt1FNDjvv4rSdQkdkAJZ+i38RnRjb1oAnO0hOSgfe7Bhj Z4ARTfjAD0HWv7rJi7/I5sfeiLC+sLaWSjHI/6OQbYQnxL5KclXyXZM/0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisEAF7qmU2Q/khMgWdsb2JhbAClYRQBARYmJYh5myubYIVrBI0jg1s X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="24379216" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Apr 2011 16:01:08 +0000 Received: from printer-nice-144-254-53-233.cisco.com (printer-nice-144-254-53-233.cisco.com [144.254.53.233]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34G13e9011605; Mon, 4 Apr 2011 16:01:08 GMT Received: from [127.0.0.1] by printer-nice-144-254-53-233.cisco.com (PGP Universal service); Mon, 04 Apr 2011 18:01:08 +0200 X-PGP-Universal: processed; by printer-nice-144-254-53-233.cisco.com on Mon, 04 Apr 2011 18:01:08 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB294EF8A@GRFMBX704BA020.griffon.local> Date: Mon, 4 Apr 2011 18:00:53 +0200 Message-Id: <8BADEA05-9881-47C9-9D5B-C3BA1EC76C6E@cisco.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB294EF8A@GRFMBX704BA020.griffon.local> To: Maglione Roberta , =?utf-8?B?5a2Z55C8?= X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] comments on stateless mechanism presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:59:33 -0000 Shouldn't this discussion be happening on softwire@? On Apr 1, 2011, at 9:56 AM, Maglione Roberta wrote: > Hello, > I would like to try to clarify the comment I made yesterday on slide = 6. > The third bullet of this slide says: > "ISPs may adopt flexible address rules, no extra requirements on = address format and address allocation" >=20 > My understanding of this is that the purpose of this slide is to = compare the impacts of the different transition mechanisms have on the = address allocation scheme that the ISP has to use. >=20 > dIVI uses a specific format to build the IPv6 address, made by = concatenating an IPv6 prefix with an IPv4 + a port, thus it introduces = some constrains on the addresses scheme to be used in the network >=20 > While DS-Lite does not have any specific requirement on the IPv6 = prefix delegated to the customers. >=20 > The table in slide 6 in the first column for DS-LIte says: > "Address of the tunnel end to be passed" >=20 > This sentence refers to the address of the AFTR that needs to be = provisioned on the B4 in order to allow the B4 to setup the IPv4 over = IPv6 tunnel. >=20 > This is a provisioning issue (and BTY it solved by DHCPv6 option = specified in draft-ietf-softwire-ds-lite-tunnel-option, now in RFC = queue). > This point is NOT related to the address allocation scheme to be used = by the ISP, thus I don't think it should appear in this table. >=20 > If you want to compare the provisioning aspects of the different = techniques I would suggest adding a separate slide for them. >=20 > Going to your slide 11: Flexible addressing > In my opinion DS-Lite has some advantages compared to dIVI on Flexible = addressing point because, as I said before, DS-Lite does not requires a = specific format for the IPv6 prefix. >=20 > Thanks, > Regards, > Roberta >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Mon Apr 4 14: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 381CA3A67FD for ; Mon, 4 Apr 2011 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tW4WKcM0+56 for ; Mon, 4 Apr 2011 14:06:56 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 393BE3A67FC for ; Mon, 4 Apr 2011 14:06:56 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p34L8QKZ001836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 16:08:27 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p34L8QgH006966; Mon, 4 Apr 2011 16:08:26 -0500 (CDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p34L8Qes006946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Apr 2011 16:08:26 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 4 Apr 2011 14:08:26 -0700 From: "Templin, Fred L" To: Fred Baker , "v6ops@ietf.org" Date: Mon, 4 Apr 2011 14:08:24 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC Thread-Index: AcvvhxmOM3+JcZFGRrCPeO6t091UAgDgzYyQ 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: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C69182053XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops 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, 04 Apr 2011 21:06:57 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C69182053XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fred, It may seem unusual for an author to comment on their own document, however in the case of ISATAP at least I am concerned that this new version may encourage router vendors to build products that do not provide necessary support for legacy hosts. In particular, I have come to understand that legacy ISATAP hosts depend on the router advertising non-link-local IPv6 prefixes on its ISATAP interface. If a router vendor were to read the recommendations in this new version of the document, however, they might incorrectly conclude that the use of non-link-local IPv6 prefixes on ISATAP interfaces should be deprecated. This seems like something that could be corrected with the addition of 1-2 sentences. How would you like to proceed? Thanks - Fred ________________________________ From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Thursday, March 31, 2011 2:30 AM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC This is to initiate a one week working group last call of draft-ietf-v6ops-= tunnel-loops; it will close a week from Friday. The IESG reviewed the docum= ent and asked for changes; we need to be sure we are comfortable with the c= hanges. The diff from the version sent to the IESG last November is at http= ://tinyurl.com/6dhowhf Please read it now. If you find nits (spelling errors, minor suggested word= ing 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. --_000_E1829B60731D1740BB7A0626B4FAF0A65C69182053XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Fred,
 
It may seem unusual for an author to comment on th= eir own=20 document,
however in the case of ISATAP at least I am c= oncerned=20 that this new
version may enco= urage router=20 vendors to build products that do not
provide necessary support for legacy hosts.
 
In particular, I have come to understand that lega= cy ISATAP=20 hosts
depend on the router advertising non-link-local IP= v6=20 prefixes on its
ISATAP interface. If a= router=20 vendor were to read the recommendations
in this new version of the document, howe= ver, they=20 might incorrectly
conclude that the use of non-= link-local=20 IPv6 prefixes on ISATAP
interfaces should be deprecated.
 
This seems like something that could be corrected = with the=20 addition
of 1-2 sentences. How would you like to=20 proceed?
 
Thanks - Fred

From: v6ops-bounces@ietf.org=20 [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker
Sent= :=20 Thursday, March 31, 2011 2:30 AM
To: v6ops@ietf.org
Cc:=20 v6ops-chairs@tools.ietf.org; Ron Bonica
Subject: [v6ops]=20 draft-ietf-v6ops-tunnel-loops WGLC

This is to initiate a one week working group last call of=20 draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The IESG= =20 reviewed the document and asked for changes; we need to be sure we a= re=20 comfortable with the changes. The diff from the version sent to the IESG = last=20 November is at http://tinyurl.com/6dhowhf=

Please read it now. If you find nits (spelling errors, minor sug= gested=20 wording changes, etc), comment to the authors; if you find greater issues= ,=20 such as disagreeing with a statement or finding additional issues th= at=20 need to be addressed, please post your comments to the=20 list.
--_000_E1829B60731D1740BB7A0626B4FAF0A65C69182053XCHNW01Vnwnos_-- From fred@cisco.com Mon Apr 4 14:25: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 B65AB3A680F for ; Mon, 4 Apr 2011 14:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4WbbJE-jsQw for ; Mon, 4 Apr 2011 14:25:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 266733A67EC for ; Mon, 4 Apr 2011 14:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2057; q=dns/txt; s=iport; t=1301952413; x=1303162013; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=XWUmJE8A+WdjG+uQocpxpeOxBdkbddwyfG2FgTs2Mzw=; b=bp+DmI5hILQpw6Xxkbl2rZE1RjP9yw0K2VZzC9SwgTABB495y/BQaYAO xlbrcZ/ir5ZE5xESeAjXaqGyyyABtANrDp3PEGjIgCWmHip2xRG/Eip5H lDzArSHDFkGFHYBVQ6Ob3/FbCh17f0iOuts0YrQ4CcNou31PyTdrHftvs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAIo2mk2Q/khLgWdsb2JhbACYII1EFAEBFiYliHmeGpwTgwiCYwSNI4Nb X-IronPort-AV: E=Sophos;i="4.63,299,1299456000"; d="scan'208";a="24406608" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Apr 2011 21:26:51 +0000 Received: from Freds-Computer.local (dhcp-10-61-103-118.cisco.com [10.61.103.118]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p34LQlUp010676; Mon, 4 Apr 2011 21:26:51 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 04 Apr 2011 23:26:51 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 04 Apr 2011 23:26:51 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 4 Apr 2011 23:26:39 +0200 Message-Id: <034350B5-9AD6-46DE-BD29-88B94BE4D1DA@cisco.com> References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops 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, 04 Apr 2011 21:25:11 -0000 For a change to a protocol specification? I would start by finding a = working group chartered to work on protocols, and discuss it with the = chair. We've been over this, Fred, many many times. You knew the answer before = you wrote the email. Act accordingly. On Apr 4, 2011, at 11:08 PM, Templin, Fred L wrote: > Hi Fred, > =20 > It may seem unusual for an author to comment on their own document, > however in the case of ISATAP at least I am concerned that this new > version may encourage router vendors to build products that do not > provide necessary support for legacy hosts. > =20 > In particular, I have come to understand that legacy ISATAP hosts > depend on the router advertising non-link-local IPv6 prefixes on its > ISATAP interface. If a router vendor were to read the recommendations > in this new version of the document, however, they might incorrectly > conclude that the use of non-link-local IPv6 prefixes on ISATAP > interfaces should be deprecated. > =20 > This seems like something that could be corrected with the addition > of 1-2 sentences. How would you like to proceed? > =20 > Thanks - Fred >=20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker > Sent: Thursday, March 31, 2011 2:30 AM > To: v6ops@ietf.org > Cc: v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC >=20 > This is to initiate a one week working group last call of = draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The = IESG reviewed the document and asked for changes; we need to be sure we = are comfortable with the changes. The diff from the version sent to the = IESG last November is at http://tinyurl.com/6dhowhf >=20 > 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. From Fred.L.Templin@boeing.com Mon Apr 4 14:41: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 CCBBE3A67AC for ; Mon, 4 Apr 2011 14:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 XKbTPHFhKiaL for ; Mon, 4 Apr 2011 14:41:18 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 02FA53A66B4 for ; Mon, 4 Apr 2011 14:41:17 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p34Lgnhg019003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2011 16:42:50 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p34Lgn5S005228; Mon, 4 Apr 2011 14:42:49 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p34Lgmoh005204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Apr 2011 14:42:49 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 4 Apr 2011 14:42:48 -0700 From: "Templin, Fred L" To: Fred Baker Date: Mon, 4 Apr 2011 14:42:47 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC Thread-Index: AcvzDxSmbF6pGSJWQZi5HoZUJNEvggAAFqZw Message-ID: References: <034350B5-9AD6-46DE-BD29-88B94BE4D1DA@cisco.com> In-Reply-To: <034350B5-9AD6-46DE-BD29-88B94BE4D1DA@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" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops 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, 04 Apr 2011 21:41:20 -0000 No sir - not for a change to a protocol specification. The protocol specification says what it always has said; that being, that IPv6 ND - including router and prefix discovery - are to be supported as specified in RFC4861 and as qualified by the specifications in RFC5214. This is strictly a clarification to an operational recommendation - that being, if a router vendor were to read the *operational* recommendations in this new version of the document, they might incorrectly conclude that the use of non-link-local IPv6 prefixes on ISATAP interfaces should be deprecated. That would break backwards compat, which would render the tool useless. Hence, the operational recommendations need to be qualified. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Monday, April 04, 2011 2:27 PM > To: Templin, Fred L > Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC >=20 > For a change to a protocol specification? I would start by=20 > finding a working group chartered to work on protocols, and=20 > discuss it with the chair. >=20 > We've been over this, Fred, many many times. You knew the=20 > answer before you wrote the email. Act accordingly. >=20 > On Apr 4, 2011, at 11:08 PM, Templin, Fred L wrote: >=20 > > Hi Fred, > > =20 > > It may seem unusual for an author to comment on their own document, > > however in the case of ISATAP at least I am concerned that this new > > version may encourage router vendors to build products that do not > > provide necessary support for legacy hosts. > > =20 > > In particular, I have come to understand that legacy ISATAP hosts > > depend on the router advertising non-link-local IPv6 prefixes on its > > ISATAP interface. If a router vendor were to read the=20 > recommendations > > in this new version of the document, however, they might incorrectly > > conclude that the use of non-link-local IPv6 prefixes on ISATAP > > interfaces should be deprecated. > > =20 > > This seems like something that could be corrected with the addition > > of 1-2 sentences. How would you like to proceed? > > =20 > > Thanks - Fred > >=20 > > From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > > Sent: Thursday, March 31, 2011 2:30 AM > > To: v6ops@ietf.org > > Cc: v6ops-chairs@tools.ietf.org; Ron Bonica > > Subject: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC > >=20 > > This is to initiate a one week working group last call of=20 > draft-ietf-v6ops-tunnel-loops; it will close a week from=20 > Friday. The IESG reviewed the document and asked for changes;=20 > we need to be sure we are comfortable with the changes. The=20 > diff from the version sent to the IESG last November is at=20 > http://tinyurl.com/6dhowhf > >=20 > > Please read it now. If you find nits (spelling errors,=20 > minor suggested wording changes, etc), comment to the=20 > authors; if you find greater issues, such as disagreeing with=20 > a statement or finding additional issues that need to be=20 > addressed, please post your comments to the list. >=20 > = From John.Border@hughes.com Mon Apr 4 15: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 D05EE3A67D6 for ; Mon, 4 Apr 2011 15:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9TnXT1vFqGk for ; Mon, 4 Apr 2011 15:01:20 -0700 (PDT) Received: from mx0a-00115401.pphosted.com (mx0a-00115401.pphosted.com [67.231.145.24]) by core3.amsl.com (Postfix) with ESMTP id 9E7A53A66B4 for ; Mon, 4 Apr 2011 15:01:20 -0700 (PDT) Received: from pps.filterd (m0000553 [127.0.0.1]) by mx0a-00115401.pphosted.com (8.14.4/8.14.4) with SMTP id p34M33Kc005315 for ; Mon, 4 Apr 2011 15:03:03 -0700 Received: from hnse1.hns.com (hnse1.hns.com [208.236.67.197]) by mx0a-00115401.pphosted.com with ESMTP id v98b6jsax-1 for ; Mon, 04 Apr 2011 15:03:02 -0700 Received: from mail.hughes.com (expexchub.hughes.com [139.85.54.35]) by hnse1.hns.com (Switch-3.3.4/Switch-3.3.4) with ESMTP id p34M2b65017978 for ; Mon, 4 Apr 2011 18:02:38 -0400 (EDT) Received: from EXPEXCVS1.hughes.com ([139.85.54.30]) by expexchub2.hughes.com ([139.85.54.35]) with mapi; Mon, 4 Apr 2011 18:03:01 -0400 From: John Border To: "v6ops@ietf.org" Date: Mon, 4 Apr 2011 18:02:53 -0400 Thread-Topic: IPv6 Support in Home Gateways Thread-Index: AcvzFAv80lMf71OcRRaDXgwcRm7Z4Q== Message-ID: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CT1F C4D1 D2GO EEQy EGZH EkOw FUd0 FbV/ GJ2Q HEDg HOiT Htba Inwn Irxx I3ho KF1S; 1; dgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {1881A641-4AF5-4AA4-BD3C-3F0E2C5042CB}; agBvAGgAbgAuAGIAbwByAGQAZQByAEAAaAB1AGcAaABlAHMALgBjAG8AbQA=; Mon, 04 Apr 2011 22:02:53 GMT; SQBQAHYANgAgAFMAdQBwAHAAbwByAHQAIABpAG4AIABIAG8AbQBlACAARwBhAHQAZQB3AGEAeQBzAA== x-cr-puzzleid: {1881A641-4AF5-4AA4-BD3C-3F0E2C5042CB} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68EXPEXCVS1hu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-04_05:2011-04-04, 2011-04-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=2 spamscore=2 ipscore=0 suspectscore=1 phishscore=0 bulkscore=2 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1104040128 X-Mailman-Approved-At: Mon, 04 Apr 2011 15:06:15 -0700 Subject: [v6ops] IPv6 Support in Home Gateways X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 22:01:23 -0000 --_000_982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68EXPEXCVS1hu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a list maintained somewhere of consumer Home Gateways that su= pport IPv6? I went into my local Best Buy and asked and the response was "= What is IPv6?". John --_000_982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68EXPEXCVS1hu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

     Is there a list maintained so= mewhere of consumer Home Gateways that support IPv6?  I went into my local Best Buy and asked a= nd the response was “What is IPv6?”.

 

 

John

 

--_000_982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68EXPEXCVS1hu_-- From bzamaere@gmail.com Mon Apr 4 16:00: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 5EA883A680F for ; Mon, 4 Apr 2011 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSMffMnby3n8 for ; Mon, 4 Apr 2011 16:00:15 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 4CBF63A67FD for ; Mon, 4 Apr 2011 16:00:15 -0700 (PDT) Received: by pvh1 with SMTP id 1so1036538pvh.31 for ; Mon, 04 Apr 2011 16:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ndlCBsny+8lSc3CnErppupkGtuktYYglsku5q5jVs08=; b=SqqTlEBo2M07Tpfrrz6XJrL2mTi0wwZ/hMc6pUwmu3hJiIFXB8l7t/+7vain1TDxNQ YIXLtOpOS6yecg3ROCC8/Iy1DJC6amWl5DkD5AjrI/DHE050yWEaJ0SuPvAVwL8dX9Oe zXD284wT8ggtPjf+hI51D6bPUn0NV+Z79Az0A= 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=GbsMoy3b6Xq6KrmZwg21o1KX/LMqUJUdLfSr1vrgZ3PYvmMfYuazUlAa1sRkMZI21+ XRN0ApCmoN+oU2Fk1qUzbtQGqwwnCl29tEE28UwkZvucMgWOo22XLiM1JWPJL7Gk5nnK Y/sXRJWb2KEEIjShYeSUOkkn4t76Mb8C9+aPY= MIME-Version: 1.0 Received: by 10.142.237.17 with SMTP id k17mr6815129wfh.41.1301958117602; Mon, 04 Apr 2011 16:01:57 -0700 (PDT) Received: by 10.68.64.68 with HTTP; Mon, 4 Apr 2011 16:01:57 -0700 (PDT) In-Reply-To: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> References: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> Date: Tue, 5 Apr 2011 01:01:57 +0200 Message-ID: From: Bruce Zamaere To: John Border Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 Support in Home Gateways X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:00:16 -0000 Here's an interesting article that I found even more alarming... http://www.networkworld.com/community/blog/most-ipv6-certified-home-network= -gear-buggy Seems Apple and D-Link are hitting the right notes though. /Bruce. On Tue, Apr 5, 2011 at 12:02 AM, John Border wrote= : > > > =A0=A0=A0=A0 Is there a list maintained somewhere of consumer Home Gatewa= ys that > support IPv6?=A0 I went into my local Best Buy and asked and the response= was > =93What is IPv6?=94. > > > > > > John > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From sds@dcs.gla.ac.uk Mon Apr 4 16:46:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774AE3A6828 for ; Mon, 4 Apr 2011 16:46:42 -0700 (PDT) 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 Tn2Q1m6WrCEN for ; Mon, 4 Apr 2011 16:46:41 -0700 (PDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 3B36F3A6827 for ; Mon, 4 Apr 2011 16:46:40 -0700 (PDT) Received: from cpc1-broo7-2-0-cust777.14-2.cable.virginmedia.com ([82.25.175.10]:60641 helo=[192.168.1.111]) by mr1.dcs.gla.ac.uk with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.42) id 1Q6tVN-0007xx-UL; Tue, 05 Apr 2011 00:48:22 +0100 From: Stephen Strowes To: "v6ops@ietf.org" In-Reply-To: References: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Apr 2011 00:48:20 +0100 Message-ID: <1301960900.6800.9.camel@lifou> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: quoted-printable Cc: John Border Subject: Re: [v6ops] IPv6 Support in Home Gateways X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:46:42 -0000 On Tue, 2011-04-05 at 00:01 +0100, Bruce Zamaere wrote: > Here's an interesting article that I found even more alarming... >=20 > http://www.networkworld.com/community/blog/most-ipv6-certified-home-netwo= rk-gear-buggy >=20 > Seems Apple and D-Link are hitting the right notes though. Yes indeed. My D-Link DIR-615 D4 apparently ships from the factory with v6 support. I say "apparently", because my ISP blasted its own firmware (with no v6 support) onto it. -S. > On Tue, Apr 5, 2011 at 12:02 AM, John Border wro= te: > > > > > > Is there a list maintained somewhere of consumer Home Gateways tha= t > > support IPv6? I went into my local Best Buy and asked and the response= was > > =E2=80=9CWhat is IPv6?=E2=80=9D. > > > > > > > > > > > > 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 frnkblk@iname.com Mon Apr 4 19:14: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 E39D53A6849 for ; Mon, 4 Apr 2011 19:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5, 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 VLlyqkzQyvGB for ; Mon, 4 Apr 2011 19:14:04 -0700 (PDT) Received: from premieronline.net (smtp2-4.premieronline.net [96.31.0.29]) by core3.amsl.com (Postfix) with ESMTP id 1AB633A6840 for ; Mon, 4 Apr 2011 19:14:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FRANKBULK (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 24391204-1729245 for multiple; Mon, 04 Apr 2011 21:15:46 -0500 From: "Frank Bulk" To: "'John Border'" , References: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> In-Reply-To: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> Date: Mon, 4 Apr 2011 21:15:44 -0500 Message-ID: <015f01cbf337$5eada420$1c08ec60$@iname.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01CBF30D.75D8D4A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcvzFAv80lMf71OcRRaDXgwcRm7Z4QAIxseg 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=16 Friend=989 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 755, in=11398329, out=43291, spam=0 Known=true ip=199.120.69.26 Subject: Re: [v6ops] IPv6 Support in Home Gateways 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: Tue, 05 Apr 2011 02:14:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0160_01CBF30D.75D8D4A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here's a good place to start: http://www.getipv6.info/index.php/Broadband_CPE. I've documented much of the information on that page and have lots of it sitting behind me, so let me know if you have a question. I would recommend you start with the D-Link DIR-655, followed by the Apple Extreme. Frank From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of John Border Sent: Monday, April 04, 2011 5:03 PM To: v6ops@ietf.org Subject: [v6ops] IPv6 Support in Home Gateways Is there a list maintained somewhere of consumer Home Gateways that support IPv6? I went into my local Best Buy and asked and the response was "What is IPv6?". John ------=_NextPart_000_0160_01CBF30D.75D8D4A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s a good place to start: http://www.getip= v6.info/index.php/Broadband_CPE.  I’ve documented much of = the information on that page and have lots of it sitting behind me, so = let me know if you have a question.

 

I would recommend you start with the D-Link DIR-655, followed by the = Apple Extreme. 

 

Frank

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = John Border
Sent: Monday, April 04, 2011 5:03 = PM
To: v6ops@ietf.org
Subject: [v6ops] IPv6 Support = in Home Gateways

 

 

     Is there a list maintained = somewhere of consumer Home Gateways that support IPv6?  I went into = my local Best Buy and asked and the response was “What is = IPv6?”.

 

 

John

 

------=_NextPart_000_0160_01CBF30D.75D8D4A0-- From swmike@swm.pp.se Mon Apr 4 21:35: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 615CD3A687D for ; Mon, 4 Apr 2011 21:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLQ9ZCxpvgyM for ; Mon, 4 Apr 2011 21:35:06 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 1672C3A6877 for ; Mon, 4 Apr 2011 21:35:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 30C449C; Tue, 5 Apr 2011 06:36:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2A5639A; Tue, 5 Apr 2011 06:36:43 +0200 (CEST) Date: Tue, 5 Apr 2011 06:36:43 +0200 (CEST) From: Mikael Abrahamsson To: Frank Bulk In-Reply-To: <015f01cbf337$5eada420$1c08ec60$@iname.com> Message-ID: References: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> <015f01cbf337$5eada420$1c08ec60$@iname.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, 'John Border' Subject: Re: [v6ops] IPv6 Support in Home Gateways X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:35:14 -0000 On Mon, 4 Apr 2011, Frank Bulk wrote: > I would recommend you start with the D-Link DIR-655, followed by the > Apple Extreme. The DIR-655 doesn't have all IPv6 support in all revisions, evidently you need the B1 (not available in shops in Europe at this time) for full future support and active development. The DIR-815 seems to be a safe bet though, since A1 has full support (ie first revision). I have tested it with SLAAC, DHCPv6, DHCPv6-PD, 6to4 and 6RD and it all seems to work ok. -- Mikael Abrahamsson email: swmike@swm.pp.se From joelja@bogus.com Mon Apr 4 22:11: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 F112A3A68AB for ; Mon, 4 Apr 2011 22:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 4wzdNLXNxis7 for ; Mon, 4 Apr 2011 22:11:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 63F4B3A68AA for ; Mon, 4 Apr 2011 22:11:49 -0700 (PDT) Received: from 23173jjaeggli.local (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 p355DQWT068096 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Apr 2011 05:13:27 GMT (envelope-from joelja@bogus.com) Message-ID: <4D9AA4F5.3090409@bogus.com> Date: Mon, 04 Apr 2011 22:13:25 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Templin, Fred L" References: 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]); Tue, 05 Apr 2011 05:13:28 +0000 (UTC) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 05:11:51 -0000 Seems like an application for an errata, if it indeed is simply an implmentation pitfall. the informational document should not be wrongly be assumed to depricate any part of 5214 since it doesn't claim that from outset. I'd prefer that we continue the last call with the document that we have given this also in the form that has cleared the iesg once already. On 4/4/11 2:08 PM, Templin, Fred L wrote: > Hi Fred, > > It may seem unusual for an author to comment on their own document, > however in the case of ISATAP at least I am concerned that this new > version may encourage router vendors to build products that do not > provide necessary support for legacy hosts. > > In particular, I have come to understand that legacy ISATAP hosts > depend on the router advertising non-link-local IPv6 prefixes on its > ISATAP interface. If a router vendor were to read the recommendations > in this new version of the document, however, they might incorrectly > conclude that the use of non-link-local IPv6 prefixes on ISATAP > interfaces should be deprecated. > > This seems like something that could be corrected with the addition > of 1-2 sentences. How would you like to proceed? > > Thanks - Fred > > ------------------------------------------------------------------------ > *From:* v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On > Behalf Of *Fred Baker > *Sent:* Thursday, March 31, 2011 2:30 AM > *To:* v6ops@ietf.org > *Cc:* v6ops-chairs@tools.ietf.org; Ron Bonica > *Subject:* [v6ops] draft-ietf-v6ops-tunnel-loops WGLC > > This is to initiate a one week working group last call of > draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The > IESG reviewed the document and asked for changes; we need to be sure > we are comfortable with the changes. The diff from the version sent > to the IESG last November is at http://tinyurl.com/6dhowhf > > 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. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Roman.Arcea@orange.md Mon Apr 4 23:53: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 152F23A68CC for ; Mon, 4 Apr 2011 23:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 ir9AsCrid-J7 for ; Mon, 4 Apr 2011 23:53:23 -0700 (PDT) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 7E8A03A68BB for ; Mon, 4 Apr 2011 23:53:22 -0700 (PDT) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id D2BB8C0A429; Tue, 5 Apr 2011 09:55:41 +0300 (EEST) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id A6B24C0A3C6; Tue, 5 Apr 2011 09:55:41 +0300 (EEST) In-Reply-To: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> References: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> To: John Border MIME-Version: 1.0 X-KeepSent: 75090DF6:8A30F6E1-C2257869:0025F312; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Tue, 5 Apr 2011 09:55:10 +0300 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 04/05/2011 09:55:04, Serialize complete at 04/05/2011 09:55:04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 Support in Home Gateways X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 06:53:24 -0000 WW91IG1pZ2h0IHdhbnQgdG8gbG9vayBhdCBNaWtyb3Rpay4gQXQgMzkuOTUkIHlvdSBwcm9iYWJs eSB3b24ndCBmaW5kIGEgDQpjaGVhcGVyL2JldHRlciBzb2x1dGlvbi4gV29ya3Mgd2VsbC4NCmh0 dHA6Ly93d3cubWlrcm90aWsuY29tLw0KDQpoZXJlIGlzIHRoZSBsaXN0IG9mIElQdjYgc3VwcG9y dGVkIGZlYXR1cmVzLg0KaHR0cDovL3dpa2kubWlrcm90aWsuY29tL3dpa2kvTWFudWFsOklQdjZf T3ZlcnZpZXcNCg0KUm9tYW4NCg0KdjZvcHMtYm91bmNlc0BpZXRmLm9yZyB3cm90ZSBvbiAwNS0w NC0yMDExIDAxOjAyOjUzOg0KDQo+IEZyb206IEpvaG4gQm9yZGVyIDxKb2huLkJvcmRlckBodWdo ZXMuY29tPg0KPiBUbzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQo+IERhdGU6 IDA1LTA0LTExIDAxOjA4DQo+IFN1YmplY3Q6IFt2Nm9wc10gSVB2NiBTdXBwb3J0IGluIEhvbWUg R2F0ZXdheXMNCj4gU2VudCBieTogdjZvcHMtYm91bmNlc0BpZXRmLm9yZw0KPiANCj4gIA0KPiAN Cj4gICAgICBJcyB0aGVyZSBhIGxpc3QgbWFpbnRhaW5lZCBzb21ld2hlcmUgb2YgY29uc3VtZXIg SG9tZSBHYXRld2F5cyANCj4gdGhhdCBzdXBwb3J0IElQdjY/ICBJIHdlbnQgaW50byBteSBsb2Nh bCBCZXN0IEJ1eSBhbmQgYXNrZWQgYW5kIHRoZSANCj4gcmVzcG9uc2Ugd2FzIOKAnFdoYXQgaXMg SVB2Nj/igJ0uDQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiBKb2huDQo+IA0KPiAgDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo= From frnkblk@iname.com Tue Apr 5 04:56: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 4714428C0DD for ; Tue, 5 Apr 2011 04:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LW2Wx0plks8 for ; Tue, 5 Apr 2011 04:56:52 -0700 (PDT) Received: from premieronline.net (smtp2-2.premieronline.net [96.31.0.27]) by core3.amsl.com (Postfix) with ESMTP id 55E323A6937 for ; Tue, 5 Apr 2011 04:56:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FRANKBULK (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 24402077-1729245 for multiple; Tue, 05 Apr 2011 06:58:34 -0500 From: "Frank Bulk" To: "'Mikael Abrahamsson'" References: <982B8F9A4E5BDC4B89FF7586464DD2190198AA95CB68@EXPEXCVS1.hughes.com> <015f01cbf337$5eada420$1c08ec60$@iname.com> In-Reply-To: Date: Tue, 5 Apr 2011 06:58:34 -0500 Message-ID: <017201cbf388$ca7c32b0$5f749810$@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: AcvzSx5xcMXtlZMiRzSOk96poSHZfwAPYxjw Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=3 Friend=26 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 756, in=11402638, out=43314, spam=0 Known=true ip=199.120.69.26 Cc: v6ops@ietf.org, 'John Border' Subject: Re: [v6ops] IPv6 Support in Home Gateways 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: Tue, 05 Apr 2011 11:56:53 -0000 That's right, it's just certain hardware revs. DNSSL (DNS Search List) support has recently been added, so look for that in a future firmware upgrade. Frank -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Monday, April 04, 2011 11:37 PM To: Frank Bulk Cc: 'John Border'; v6ops@ietf.org Subject: Re: [v6ops] IPv6 Support in Home Gateways On Mon, 4 Apr 2011, Frank Bulk wrote: > I would recommend you start with the D-Link DIR-655, followed by the > Apple Extreme. The DIR-655 doesn't have all IPv6 support in all revisions, evidently you need the B1 (not available in shops in Europe at this time) for full future support and active development. The DIR-815 seems to be a safe bet though, since A1 has full support (ie first revision). I have tested it with SLAAC, DHCPv6, DHCPv6-PD, 6to4 and 6RD and it all seems to work ok. -- Mikael Abrahamsson email: swmike@swm.pp.se From Internet-Drafts@ietf.org Tue Apr 5 05:30: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 19C8C3A6403; Tue, 5 Apr 2011 05:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 hZswWRHuXtP1; Tue, 5 Apr 2011 05:30:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613A23A67B2; Tue, 5 Apr 2011 05:30:02 -0700 (PDT) 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.14 Message-ID: <20110405123002.20640.18877.idtracker@localhost> Date: Tue, 05 Apr 2011 05:30:02 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-6to4-to-historic-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, 05 Apr 2011 12:30:11 -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 : Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status Author(s) : O. Troan Filename : draft-ietf-v6ops-6to4-to-historic-00.txt Pages : 6 Date : 2011-04-05 Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-to-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05051727.I-D@ietf.org> --NextPart-- From john_brzozowski@cable.comcast.com Tue Apr 5 05: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 350B928C10C for ; Tue, 5 Apr 2011 05:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-3.364, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVoMu-x5vWlD for ; Tue, 5 Apr 2011 05:37:13 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 865AB28C0FE for ; Tue, 5 Apr 2011 05:37:13 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32411280; Tue, 05 Apr 2011 06:41:10 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 5 Apr 2011 08:38:25 -0400 From: "Brzozowski, John" To: "frnkblk@iname.com" , 'Mikael Abrahamsson' Thread-Topic: [v6ops] IPv6 Support in Home Gateways Thread-Index: AcvzFAv80lMf71OcRRaDXgwcRm7Z4QAIxsegAA1cCoAAD25zAP//yBAA Date: Tue, 5 Apr 2011 12:38:24 +0000 Message-ID: In-Reply-To: <017201cbf388$ca7c32b0$5f749810$@iname.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D54EF9FE6F6A043936026B417ACA5CC@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , 'John Border' Subject: Re: [v6ops] IPv6 Support in Home Gateways X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:37:20 -0000 We have observed the following supporting IPv6: Dlink DIR-655 Dlink DIR-825 Apple Airport Extreme (dual band radio) There are also several other makes and models that are introducing support for IPv6. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 4/5/11 7:58 AM, "Frank Bulk" wrote: >That's right, it's just certain hardware revs. DNSSL (DNS Search List) >support has recently been added, so look for that in a future firmware >upgrade. > >Frank > >-----Original Message----- >From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >Sent: Monday, April 04, 2011 11:37 PM >To: Frank Bulk >Cc: 'John Border'; v6ops@ietf.org >Subject: Re: [v6ops] IPv6 Support in Home Gateways > >On Mon, 4 Apr 2011, Frank Bulk wrote: > >> I would recommend you start with the D-Link DIR-655, followed by the >> Apple Extreme. > >The DIR-655 doesn't have all IPv6 support in all revisions, evidently you >need the B1 (not available in shops in Europe at this time) for full >future support and active development. > >The DIR-815 seems to be a safe bet though, since A1 has full support (ie >first revision). I have tested it with SLAAC, DHCPv6, DHCPv6-PD, 6to4 and >6RD and it all seems to work ok. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From roberta.maglione@telecomitalia.it Tue Apr 5 07:39: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 183E628C0EC for ; Tue, 5 Apr 2011 07:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.675 X-Spam-Level: * X-Spam-Status: No, score=1.675 tagged_above=-999 required=5 tests=[AWL=-2.709, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27OMoCyCQNNg for ; Tue, 5 Apr 2011 07:39:28 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 91DBE28C0DE for ; Tue, 5 Apr 2011 07:39:27 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Apr 2011 16:41:07 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 5 Apr 2011 16:41:06 +0200 From: Maglione Roberta To: 'Fred Baker' , =?gb2312?B?J8vvx+0n?= Date: Tue, 5 Apr 2011 16:41:02 +0200 Thread-Topic: [v6ops] comments on stateless mechanism presentation Thread-Index: Acvy4Y2kVsWCkbn9SgGM0n38Xs6b8gAvXXvg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB2A4ECF4@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB294EF8A@GRFMBX704BA020.griffon.local> <8BADEA05-9881-47C9-9D5B-C3BA1EC76C6E@cisco.com> In-Reply-To: <8BADEA05-9881-47C9-9D5B-C3BA1EC76C6E@cisco.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] comments on stateless mechanism presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:39:30 -0000 WWVzIHRoaXMgZGlzY3Vzc2lvbiBiZWxvbmdzIHRvIHNvZnR3aXJlLCB0aGUgcmVhc29uIHdoeSBJ IHN0YXJ0ZWQgdGhlIHRocmVhZCBoZXJlIHdhcyBiZWNhdXNlIG15IGluaXRpYWwgY29tbWVudCBh bmQgc3VnZ2VzdGlvbnMgd2VyZSByZWxhdGVkIHRvIG9uZSBvZiB0aGUgc2xpZGUgcHJlc2VudGVk IGR1cmluZyB2Nm9wcyBtZWV0aW5nLg0KDQpUaGFua3MsDQpSb2JlcnRhDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBGcmVkIEJha2VyIFttYWlsdG86ZnJlZEBjaXNjby5jb21d DQpTZW50OiBsdW5lZKisIDQgYXByaWxlIDIwMTEgMTguMDENClRvOiBNYWdsaW9uZSBSb2JlcnRh OyDL78ftDQpDYzogJ3Y2b3BzQGlldGYub3JnJw0KU3ViamVjdDogUmU6IFt2Nm9wc10gY29tbWVu dHMgb24gc3RhdGVsZXNzIG1lY2hhbmlzbSBwcmVzZW50YXRpb24NCg0KU2hvdWxkbid0IHRoaXMg ZGlzY3Vzc2lvbiBiZSBoYXBwZW5pbmcgb24gc29mdHdpcmVAPw0KDQpPbiBBcHIgMSwgMjAxMSwg YXQgOTo1NiBBTSwgTWFnbGlvbmUgUm9iZXJ0YSB3cm90ZToNCg0KPiBIZWxsbywNCj4gICBJIHdv dWxkIGxpa2UgdG8gdHJ5IHRvIGNsYXJpZnkgdGhlIGNvbW1lbnQgSSBtYWRlIHllc3RlcmRheSBv biBzbGlkZSA2Lg0KPiBUaGUgdGhpcmQgYnVsbGV0IG9mIHRoaXMgc2xpZGUgc2F5czoNCj4gIklT UHMgbWF5IGFkb3B0IGZsZXhpYmxlIGFkZHJlc3MgcnVsZXMsIG5vIGV4dHJhIHJlcXVpcmVtZW50 cyBvbiBhZGRyZXNzIGZvcm1hdCBhbmQgYWRkcmVzcyBhbGxvY2F0aW9uIg0KPg0KPiBNeSB1bmRl cnN0YW5kaW5nIG9mIHRoaXMgaXMgdGhhdCB0aGUgcHVycG9zZSBvZiB0aGlzIHNsaWRlIGlzIHRv IGNvbXBhcmUgdGhlIGltcGFjdHMgb2YgdGhlIGRpZmZlcmVudCB0cmFuc2l0aW9uIG1lY2hhbmlz bXMgaGF2ZSBvbiB0aGUgYWRkcmVzcyBhbGxvY2F0aW9uIHNjaGVtZSB0aGF0IHRoZSBJU1AgaGFz IHRvIHVzZS4NCj4NCj4gZElWSSB1c2VzIGEgc3BlY2lmaWMgZm9ybWF0IHRvIGJ1aWxkIHRoZSBJ UHY2IGFkZHJlc3MsIG1hZGUgYnkgY29uY2F0ZW5hdGluZyBhbiBJUHY2IHByZWZpeCB3aXRoIGFu IElQdjQgKyBhIHBvcnQsIHRodXMgaXQgaW50cm9kdWNlcyBzb21lIGNvbnN0cmFpbnMgb24gdGhl IGFkZHJlc3NlcyBzY2hlbWUgdG8gYmUgdXNlZCBpbiB0aGUgbmV0d29yaw0KPg0KPiBXaGlsZSBE Uy1MaXRlIGRvZXMgbm90IGhhdmUgYW55IHNwZWNpZmljIHJlcXVpcmVtZW50IG9uIHRoZSBJUHY2 IHByZWZpeCBkZWxlZ2F0ZWQgdG8gdGhlIGN1c3RvbWVycy4NCj4NCj4gVGhlIHRhYmxlIGluIHNs aWRlIDYgaW4gdGhlIGZpcnN0IGNvbHVtbiBmb3IgRFMtTEl0ZSBzYXlzOg0KPiAiQWRkcmVzcyBv ZiB0aGUgdHVubmVsIGVuZCB0byBiZSBwYXNzZWQiDQo+DQo+IFRoaXMgc2VudGVuY2UgcmVmZXJz IHRvIHRoZSBhZGRyZXNzIG9mIHRoZSBBRlRSIHRoYXQgbmVlZHMgdG8gYmUgcHJvdmlzaW9uZWQg b24gdGhlIEI0IGluIG9yZGVyIHRvIGFsbG93IHRoZSBCNCB0byBzZXR1cCB0aGUgSVB2NCBvdmVy IElQdjYgdHVubmVsLg0KPg0KPiBUaGlzIGlzIGEgcHJvdmlzaW9uaW5nIGlzc3VlIChhbmQgQlRZ IGl0IHNvbHZlZCBieSBESENQdjYgb3B0aW9uIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRmLXNvZnR3 aXJlLWRzLWxpdGUtdHVubmVsLW9wdGlvbiwgbm93IGluIFJGQyBxdWV1ZSkuDQo+IFRoaXMgcG9p bnQgaXMgTk9UIHJlbGF0ZWQgdG8gdGhlIGFkZHJlc3MgYWxsb2NhdGlvbiBzY2hlbWUgdG8gYmUg dXNlZCBieSB0aGUgSVNQLCB0aHVzIEkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGFwcGVhciBpbiB0 aGlzIHRhYmxlLg0KPg0KPiBJZiB5b3Ugd2FudCB0byBjb21wYXJlIHRoZSBwcm92aXNpb25pbmcg YXNwZWN0cyBvZiB0aGUgZGlmZmVyZW50IHRlY2huaXF1ZXMgSSB3b3VsZCBzdWdnZXN0IGFkZGlu ZyBhIHNlcGFyYXRlIHNsaWRlIGZvciB0aGVtLg0KPg0KPiBHb2luZyB0byB5b3VyIHNsaWRlIDEx OiBGbGV4aWJsZSBhZGRyZXNzaW5nDQo+IEluIG15IG9waW5pb24gRFMtTGl0ZSBoYXMgc29tZSBh ZHZhbnRhZ2VzIGNvbXBhcmVkIHRvIGRJVkkgb24gRmxleGlibGUgYWRkcmVzc2luZyBwb2ludCBi ZWNhdXNlLCBhcyBJIHNhaWQgYmVmb3JlLCBEUy1MaXRlIGRvZXMgbm90IHJlcXVpcmVzIGEgc3Bl Y2lmaWMgZm9ybWF0IGZvciB0aGUgSVB2NiBwcmVmaXguDQo+DQo+IFRoYW5rcywNCj4gUmVnYXJk cywNCj4gUm9iZXJ0YQ0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBRdWVzdG8gbWVzc2Fn Z2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxs ZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9u aSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1 ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBk YXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUg YWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4NCj4gVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQpR dWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVz aXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1 YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3Rl IGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRl IHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUg cHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRp IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K From bingxuere@gmail.com Tue Apr 5 07:45: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 743C828C120 for ; Tue, 5 Apr 2011 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[AWL=-2.725, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s-h6xOqrTWB for ; Tue, 5 Apr 2011 07:45:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4CB4F28C0DE for ; Tue, 5 Apr 2011 07:45:15 -0700 (PDT) Received: by vws12 with SMTP id 12so408411vws.31 for ; Tue, 05 Apr 2011 07:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8ZJi2Rs3aeUAytPWUP9M1WPCuhy/lk3D275i91bfepE=; b=UyYySgSEOnIfOsO5rdtVRoZ4buCtwQwi42fANXmfcKzsFICtNMhwqj8AkRofb4UCy7 /juJJwaRJNiGJUiQKyQ2/o9EaucS5jrxSJ1jK45Ctxi2NPoJoYmxDFEQeEYtlpOsDdeP 5o+dL2YoMIA9PSF2lbRkbsA1BSWWfskl7Qo4M= 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=PuDSWjD+s/MgOZxROG6H9RHmMD8iB9vI1FVJYR33CZO/PFBElsgLcL6s16g97AdDjn /F2cED44FAPuG42aexS/P54maoBzIsSnI/Gw0fIlfoBI+RZ5kQzpCBsC34+upkAGHcqh yRnp1H2TAcQH0bd5u1bvW9RpeSVt7naSLlwis= MIME-Version: 1.0 Received: by 10.52.94.42 with SMTP id cz10mr821589vdb.209.1302014818171; Tue, 05 Apr 2011 07:46:58 -0700 (PDT) Received: by 10.52.157.196 with HTTP; Tue, 5 Apr 2011 07:46:58 -0700 (PDT) In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB2A4ECF4@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB294EF8A@GRFMBX704BA020.griffon.local> <8BADEA05-9881-47C9-9D5B-C3BA1EC76C6E@cisco.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB2A4ECF4@GRFMBX704BA020.griffon.local> Date: Tue, 5 Apr 2011 22:46:58 +0800 Message-ID: From: =?GB2312?B?y+/H7Q==?= To: Maglione Roberta Content-Type: multipart/alternative; boundary=20cf3071cf70babad604a02cf220 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comments on stateless mechanism presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:45:16 -0000 --20cf3071cf70babad604a02cf220 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, all, Thanks. I will update the slides soon and we could discuss it further in softwire. Best regards Qiong 2011/4/5 Maglione Roberta > Yes this discussion belongs to softwire, the reason why I started the > thread here was because my initial comment and suggestions were related t= o > one of the slide presented during v6ops meeting. > > Thanks, > Roberta > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: luned=A8=AC 4 aprile 2011 18.01 > To: Maglione Roberta; =CB=EF=C7=ED > Cc: 'v6ops@ietf.org' > Subject: Re: [v6ops] comments on stateless mechanism presentation > > Shouldn't this discussion be happening on softwire@? > --20cf3071cf70babad604a02cf220 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, all,

Thanks. I will update the slides soon and we could discuss = it further in softwire.

Best regards

Qiong

2011/4/5 Maglione Roberta <roberta.maglione@telecomitali= a.it>
Yes this discussi= on belongs to softwire, the reason why I started the thread here was becaus= e my initial comment and suggestions were related to one of the slide prese= nted during v6ops meeting.

Thanks,
Roberta

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: luned=A8=AC 4 aprile 2011 18.01
To: Maglione Roberta; =CB=EF=C7=ED
Cc: 'v6ops@ietf.org'
Subject: Re: [v6ops] comments on stateless mechanism presentation

Shouldn't this discussion be happening on softwire@?

--20cf3071cf70babad604a02cf220-- From tore.anderson@redpill-linpro.com Tue Apr 5 07:56: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 6D58A3A695E for ; Tue, 5 Apr 2011 07:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, 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 sk-oxxJVSiS7 for ; Tue, 5 Apr 2011 07:56:14 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id EF0863A6958 for ; Tue, 5 Apr 2011 07:56:12 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 747BB1DE20E; Tue, 5 Apr 2011 16:57:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 fx4-BlAoMY7c; Tue, 5 Apr 2011 16:57:55 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Tue, 5 Apr 2011 16:57:55 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 5BB56170C00A; Tue, 5 Apr 2011 16:57:55 +0200 (CEST) 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 d7Ery-v1oqNm; Tue, 5 Apr 2011 16:57:49 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id BBDBF170C00B; Tue, 5 Apr 2011 16:57:49 +0200 (CEST) Message-ID: <4D9B2DED.3060608@redpill-linpro.com> Date: Tue, 05 Apr 2011 16:57:49 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ole Troan References: <20110405123002.20640.18877.idtracker@localhost> In-Reply-To: <20110405123002.20640.18877.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-6to4-to-historic-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, 05 Apr 2011 14:56:21 -0000 * I-D.ietf-v6ops-6to4-to-historic-00.txt > 4. Deprecation > > This document formally deprecates the 6to4 transition mechanism and > the IPv6 6to4 prefix defined in [RFC3056], i.e., 2002::/16. The > prefix MUST NOT be reassigned for other use except by a future IETF > standards action. [...] > 5. IANA Considerations > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > pointing to this document. Reassignment of the prefix for any usage > requires justification via an IETF Standards Action [RFC5226]. > > IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as > "deprecated", pointing to this document. Redelegation of the domain > for any usage requires justification via an IETF Standards Action > [RFC5226].RFC5158 Ole, There's no similar language deprecating the IPv4 WKP 192.88.99.0/24. Is that an omission? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From Dmitry.Anipko@microsoft.com Tue Apr 5 12:32: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 1D9373A6989 for ; Tue, 5 Apr 2011 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQiDlctDGz4D for ; Tue, 5 Apr 2011 12:32:13 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5C58C3A6988 for ; Tue, 5 Apr 2011 12:32:13 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 12:33:55 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 5 Apr 2011 12:33:55 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Tue, 5 Apr 2011 12:32:47 -0700 From: Dmitry Anipko To: "v6ops@ietf.org" Date: Tue, 5 Apr 2011 12:32:45 -0700 Thread-Topic: draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: Acvzoeiv492EQtPDR2e/Z5MSobI7YQAJLPXw Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> In-Reply-To: <4D9B2DED.3060608@redpill-linpro.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: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:32:14 -0000 Hi, I have a question regarding http://tools.ietf.org/html/draft-ietf-v6ops-6to= 4-advisory-00 and IPv6 day.=20 In section 4.1. among other items the draft recommends to vendors to disabl= e Anycast 6to4 functionality by default. If an OS vendor has an ability to = do that for existing implementations, is there a WG consensus whether such = changes should be done before the IPv6 day?=20 I've checked the Prague WG meeting jabber logs, and I see there was a discu= ssion regarding the intent of IPv6 day, but I'm not sure there was a consen= sus. There were arguments both for letting more things break on IPv6 day, i= n order to find what breaks and fix it (e.g. programs not using RFC 3484 so= rting), as well as arguments fixing pro-actively things which can be fixed = in order for users not to encounter already known issues. Thanks. From Fred.L.Templin@boeing.com Tue Apr 5 12: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 767CE3A6983 for ; Tue, 5 Apr 2011 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.043 X-Spam-Level: X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 zJNSX0G2wi25 for ; Tue, 5 Apr 2011 12:35:26 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 276DB3A698A for ; Tue, 5 Apr 2011 12:35:26 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p35JaleF001702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2011 14:36:50 -0500 (CDT) 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 p35JalCM021398; Tue, 5 Apr 2011 12:36:47 -0700 (PDT) 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 p35Jaljb021391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Apr 2011 12:36:47 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 5 Apr 2011 12:36:47 -0700 From: "Templin, Fred L" To: Joel Jaeggli Date: Tue, 5 Apr 2011 12:36:46 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC Thread-Index: AcvzUDRM2mOtkkiRQa2DEaX0IaAQ8gAdJI0g Message-ID: References: <4D9AA4F5.3090409@bogus.com> In-Reply-To: <4D9AA4F5.3090409@bogus.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" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:35:28 -0000 Hi Joel, That's a good idea about filing an errata - the thought hadn't occurred to me, so thanks for mentioning it. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joel Jaeggli [mailto:joelja@bogus.com]=20 > Sent: Monday, April 04, 2011 10:13 PM > To: Templin, Fred L > Cc: Fred Baker; v6ops@ietf.org; v6ops-chairs@tools.ietf.org;=20 > Ron Bonica > Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC >=20 > Seems like an application for an errata, if it indeed is simply an > implmentation pitfall. the informational document should not=20 > be wrongly > be assumed to depricate any part of 5214 since it doesn't claim that > from outset. >=20 > I'd prefer that we continue the last call with the document=20 > that we have > given this also in the form that has cleared the iesg once already. >=20 > On 4/4/11 2:08 PM, Templin, Fred L wrote: > > Hi Fred, > > =20 > > It may seem unusual for an author to comment on their own document, > > however in the case of ISATAP at least I am concerned that this new > > version may encourage router vendors to build products that do not > > provide necessary support for legacy hosts. > > =20 > > In particular, I have come to understand that legacy ISATAP hosts > > depend on the router advertising non-link-local IPv6 prefixes on its > > ISATAP interface. If a router vendor were to read the=20 > recommendations > > in this new version of the document, however, they might incorrectly > > conclude that the use of non-link-local IPv6 prefixes on ISATAP > > interfaces should be deprecated. > > =20 > > This seems like something that could be corrected with the addition > > of 1-2 sentences. How would you like to proceed? > > =20 > > Thanks - Fred > >=20 > > =20 > -------------------------------------------------------------- > ---------- > > *From:* v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] *On > > Behalf Of *Fred Baker > > *Sent:* Thursday, March 31, 2011 2:30 AM > > *To:* v6ops@ietf.org > > *Cc:* v6ops-chairs@tools.ietf.org; Ron Bonica > > *Subject:* [v6ops] draft-ietf-v6ops-tunnel-loops WGLC > >=20 > > This is to initiate a one week working group last call of > > draft-ietf-v6ops-tunnel-loops; it will close a week=20 > from Friday. The > > IESG reviewed the document and asked for changes; we=20 > need to be sure > > we are comfortable with the changes. The diff from the=20 > version sent > > to the IESG last November is at http://tinyurl.com/6dhowhf > >=20 > > Please read it now. If you find nits (spelling errors, minor > > suggested wording changes, etc), comment to the=20 > 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. > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = From swmike@swm.pp.se Tue Apr 5 12: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 5B5923A698D for ; Tue, 5 Apr 2011 12:38:17 -0700 (PDT) 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.042, 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 frFbZMiuLhcS for ; Tue, 5 Apr 2011 12:38:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 0946D3A698A for ; Tue, 5 Apr 2011 12:38:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3AFFC9C; Tue, 5 Apr 2011 21:39:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 37FA59A; Tue, 5 Apr 2011 21:39:58 +0200 (CEST) Date: Tue, 5 Apr 2011 21:39:58 +0200 (CEST) From: Mikael Abrahamsson To: Dmitry Anipko In-Reply-To: Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:38:17 -0000 On Tue, 5 Apr 2011, Dmitry Anipko wrote: > Hi, > > I have a question regarding http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-00 and IPv6 day. > > In section 4.1. among other items the draft recommends to vendors to > disable Anycast 6to4 functionality by default. If an OS vendor has an > ability to do that for existing implementations, is there a WG consensus > whether such changes should be done before the IPv6 day? I don't think there was consensus, but there are quite a few people who would like to see it disabled. What should *really* be done is to disable sending RAs out the WAN interface when ICS is turned on and 6to4 is the only IPv6 available. Please never ever send RAs out the WAN interface at all. This is causing serious breakage. > I've checked the Prague WG meeting jabber logs, and I see there was a > discussion regarding the intent of IPv6 day, but I'm not sure there was > a consensus. There were arguments both for letting more things break on > IPv6 day, in order to find what breaks and fix it (e.g. programs not > using RFC 3484 sorting), as well as arguments fixing pro-actively things > which can be fixed in order for users not to encounter already known > issues. I'm of the opinion that IPv6 tunneling should be default off in devices. If nothing else, please change so that 6to4 reachability is treated the same way as teredo, ie lower than native ipv4. -- Mikael Abrahamsson email: swmike@swm.pp.se From Fred.L.Templin@boeing.com Tue Apr 5 13:14:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2D128C13A for ; Tue, 5 Apr 2011 13:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.343 X-Spam-Level: X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 C8pP-u1dlzeB for ; Tue, 5 Apr 2011 13:14:04 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id BEDE428C141 for ; Tue, 5 Apr 2011 13:14:04 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p35KFfWS007277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2011 13:15:42 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p35KFf0K003269; Tue, 5 Apr 2011 15:15:41 -0500 (CDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p35KFcB4003127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Apr 2011 15:15:40 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 5 Apr 2011 13:15:39 -0700 From: "Templin, Fred L" To: IPv6 Ops WG Date: Tue, 5 Apr 2011 13:15:37 -0700 Thread-Topic: [v6ops] Fwd: I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvwqhO9BdUyiwMRQ4qcBPNNIw4tOABZkpawAG4ikyA= Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@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 Subject: Re: [v6ops] Fwd: I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 20:14:05 -0000 I would like to propose a new section for this draft to cover the use of transition technologies within the end user LAN side network. See below for proposed text: Fred fred.l.templin@boeing.com --- cut here --- 5.5.3 ISATAP The IPv6 CE Router can be used to offer IPv6 services to nodes on IPv4-only segments within the end user LAN. ISATAP [RFC5214] provides for intra-site encapsulation of IPv6 packets over IPv4 networks that connect to the IPv6 Internet via one or more IPv6 CE Routers configured as site border routers. The IPv6 CE Router sub-delegates portions of its IPv6 prefixes for assignment to nodes on the ISATAP link and/or to the ISATAP link itself.=20 ISATAP requirements: ISA-1: If the IPv6 CE Router implements ISATAP functionality, the CE Router LAN interface MUST support at least one ISATAP virtual interface and ISATAP router functionality as specified in [RFC5214]. ISA-2: If the IPv6 CE Router implements ISATAP functionality, it MUST arrange to add itself to the ISATAP Potential Router List (PRL) for the LAN. ISA-3: When the LAN contains legacy ISATAP nodes that support only SLAAC, the IPv6 CE router MUST advertise IPv6 prefixes on the ISATAP interface. ISA-4: The CE router MUST be configured in a manner that ensures that no IPv6 routing loops are enabled via the ISATAP interface [draft-ietf-v6ops-tunnel-loops].= From shemant@cisco.com Tue Apr 5 13:32: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 B8FFA3A6985 for ; Tue, 5 Apr 2011 13:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.354 X-Spam-Level: X-Spam-Status: No, score=-10.354 tagged_above=-999 required=5 tests=[AWL=-0.355, 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 s8ehx14zafQb for ; Tue, 5 Apr 2011 13:32:14 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C95EE3A63D3 for ; Tue, 5 Apr 2011 13:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2114; q=dns/txt; s=iport; t=1302035638; x=1303245238; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KEYrWnNMq4JP5KWK8lX4oknWbx/tHIWdc08KZhRomQg=; b=Cl9CLxVXlaexOJbXwacbhvrq3KINYwt9G87c1gx9Isf+oyZGErlBL4IO zTlqSI24qzHXaLi5iaIUDTxoxWFycNSYU1bfWrYXn70j0qcyDp+ynEhI2 4ikPe8T0x9ra1Hfnq9R1E8HnRtlVL+I6bYC8EbxcQmvS1ISsxMkM8C+HF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAAV8m02tJV2c/2dsb2JhbACYJ41Id6c8nCOFbASFR4s/ X-IronPort-AV: E=Sophos;i="4.63,306,1299456000"; d="scan'208";a="282238613" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2011 20:33:58 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p35KXv6k027806; Tue, 5 Apr 2011 20:33:57 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 15:33:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 15:33:56 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvwqhO9BdUyiwMRQ4qcBPNNIw4tOABZkpawAG4ikyAAAeoMQA== References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "IPv6 Ops WG" X-OriginalArrivalTime: 05 Apr 2011 20:33:58.0421 (UTC) FILETIME=[CA5FBC50:01CBF3D0] Subject: Re: [v6ops] Fwd: I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 20:32:15 -0000 Fred, Thanks for the text. I will run your email by our IPv6 CE Router design team and solicit feedback from them for ISATAP in the IPv6 CE Router specification. Cheers, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Tuesday, April 05, 2011 4:16 PM To: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I would like to propose a new section for this draft to cover the use of transition technologies within the end user LAN side network. See below for proposed text: Fred fred.l.templin@boeing.com --- cut here --- 5.5.3 ISATAP The IPv6 CE Router can be used to offer IPv6 services to nodes on IPv4-only segments within the end user LAN. ISATAP [RFC5214] provides for intra-site encapsulation of IPv6 packets over IPv4 networks that connect to the IPv6 Internet via one or more IPv6 CE Routers configured as site border routers. The IPv6 CE Router sub-delegates portions of its IPv6 prefixes for assignment to nodes on the ISATAP link and/or to the ISATAP link itself.=20 ISATAP requirements: ISA-1: If the IPv6 CE Router implements ISATAP functionality, the CE Router LAN interface MUST support at least one ISATAP virtual interface and ISATAP router functionality as specified in [RFC5214]. ISA-2: If the IPv6 CE Router implements ISATAP functionality, it MUST arrange to add itself to the ISATAP Potential Router List (PRL) for the LAN. ISA-3: When the LAN contains legacy ISATAP nodes that support only SLAAC, the IPv6 CE router MUST advertise IPv6 prefixes on the ISATAP interface. ISA-4: The CE router MUST be configured in a manner that ensures that no IPv6 routing loops are enabled via the ISATAP interface [draft-ietf-v6ops-tunnel-loops]. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Apr 5 14: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 829543A67E1 for ; Tue, 5 Apr 2011 14:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 mhUkl5kLC8fb for ; Tue, 5 Apr 2011 14:39:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 73BD33A67D8 for ; Tue, 5 Apr 2011 14:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2723; q=dns/txt; s=iport; t=1302039693; x=1303249293; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SnB0txyceEKvfIanlzNQVkIaM9xzt9PoSBoHSHtfmGk=; b=LCNnVifPdxWVA7D3VDKQ7Jr35La7S46CWlK0sjcTbmit6DwT5F+uZVKy Bf3VW8ZWObXFwTjFa4HGhdieqSU3sOzClpmPn2MsPmX21SlR1X7531Umz KDFQzEO4zz1Ud8NOBvYCiI4HuhXuCt0ms7sEfCEAtOLBr1uuPhjfO7C63 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAMuLm02tJXG9/2dsb2JhbACYJ41Id6cSnB+FbASFR4s/ X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="331287514" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 05 Apr 2011 21:41:32 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p35LfW6V014700; Tue, 5 Apr 2011 21:41:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 16:41:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 16:41:30 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvwqhO9BdUyiwMRQ4qcBPNNIw4tOABZkpawAG4ikyAAAeoMQAACOq5g References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Templin, Fred L" , "IPv6 Ops WG" X-OriginalArrivalTime: 05 Apr 2011 21:41:32.0581 (UTC) FILETIME=[3AD77550:01CBF3DA] Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 21:39:50 -0000 Fred, One feedback from the design team was to ask how many home or soho networks use ISATAP today before the team would decide to add ISATAP to the bis document? =20 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, April 05, 2011 4:34 PM To: Templin, Fred L; IPv6 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred, Thanks for the text. I will run your email by our IPv6 CE Router design team and solicit feedback from them for ISATAP in the IPv6 CE Router specification. Cheers, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Tuesday, April 05, 2011 4:16 PM To: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I would like to propose a new section for this draft to cover the use of transition technologies within the end user LAN side network. See below for proposed text: Fred fred.l.templin@boeing.com --- cut here --- 5.5.3 ISATAP The IPv6 CE Router can be used to offer IPv6 services to nodes on IPv4-only segments within the end user LAN. ISATAP [RFC5214] provides for intra-site encapsulation of IPv6 packets over IPv4 networks that connect to the IPv6 Internet via one or more IPv6 CE Routers configured as site border routers. The IPv6 CE Router sub-delegates portions of its IPv6 prefixes for assignment to nodes on the ISATAP link and/or to the ISATAP link itself.=20 ISATAP requirements: ISA-1: If the IPv6 CE Router implements ISATAP functionality, the CE Router LAN interface MUST support at least one ISATAP virtual interface and ISATAP router functionality as specified in [RFC5214]. ISA-2: If the IPv6 CE Router implements ISATAP functionality, it MUST arrange to add itself to the ISATAP Potential Router List (PRL) for the LAN. ISA-3: When the LAN contains legacy ISATAP nodes that support only SLAAC, the IPv6 CE router MUST advertise IPv6 prefixes on the ISATAP interface. ISA-4: The CE router MUST be configured in a manner that ensures that no IPv6 routing loops are enabled via the ISATAP interface [draft-ietf-v6ops-tunnel-loops]. _______________________________________________ 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.L.Templin@boeing.com Tue Apr 5 14:57: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 97A9B3A67EE for ; Tue, 5 Apr 2011 14:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 pDhjXBUHmqXq for ; Tue, 5 Apr 2011 14:57:30 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D8CB93A67F7 for ; Tue, 5 Apr 2011 14:57:29 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p35Lx30L004082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2011 16:59:03 -0500 (CDT) 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 p35Lx3dQ014673; Tue, 5 Apr 2011 14:59:03 -0700 (PDT) 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 p35Lx2lk014670 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Apr 2011 14:59:02 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 5 Apr 2011 14:59:02 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , IPv6 Ops WG Date: Tue, 5 Apr 2011 14:59:01 -0700 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvwqhO9BdUyiwMRQ4qcBPNNIw4tOABZkpawAG4ikyAAAeoMQAACOq5gAACQfLA= Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.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 Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 21:57:31 -0000 Hi Hemant, I have no way of knowing how many home or soho networks use ISATAP today, however I do know that there are many (millions of?) hosts that would automatically enable ISATAP if it were available in the home/soho network. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: Tuesday, April 05, 2011 2:42 PM > To: Hemant Singh (shemant); Templin, Fred L; IPv6 Ops WG > Subject: RE: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred, >=20 > One feedback from the design team was to ask how many home or soho > networks use ISATAP today before the team would decide to add=20 > ISATAP to > the bis document? =20 >=20 > Thanks, >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Hemant Singh (shemant) > Sent: Tuesday, April 05, 2011 4:34 PM > To: Templin, Fred L; IPv6 Ops WG > Subject: Re: [v6ops] > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred, >=20 > Thanks for the text. I will run your email by our IPv6 CE=20 > Router design > team and solicit feedback from them for ISATAP in the IPv6 CE Router > specification. >=20 > Cheers, >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Templin, Fred L > Sent: Tuesday, April 05, 2011 4:16 PM > To: IPv6 Ops WG > Subject: Re: [v6ops] Fwd: > I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > I would like to propose a new section for this draft to > cover the use of transition technologies within the end > user LAN side network. See below for proposed text: >=20 > Fred > fred.l.templin@boeing.com >=20 > --- cut here --- >=20 > 5.5.3 ISATAP >=20 > The IPv6 CE Router can be used to offer IPv6 services to nodes > on IPv4-only segments within the end user LAN. ISATAP [RFC5214] > provides for intra-site encapsulation of IPv6 packets over IPv4 > networks that connect to the IPv6 Internet via one or more IPv6 > CE Routers configured as site border routers. The IPv6 CE Router > sub-delegates portions of its IPv6 prefixes for assignment to > nodes on the ISATAP link and/or to the ISATAP link itself.=20 >=20 > ISATAP requirements: >=20 > ISA-1: If the IPv6 CE Router implements ISATAP functionality, the > CE Router LAN interface MUST support at least one ISATAP > virtual interface and ISATAP router functionality as > specified in [RFC5214]. >=20 > ISA-2: If the IPv6 CE Router implements ISATAP functionality, it > MUST arrange to add itself to the ISATAP Potential Router > List (PRL) for the LAN. >=20 > ISA-3: When the LAN contains legacy ISATAP nodes that support > only SLAAC, the IPv6 CE router MUST advertise IPv6 prefixes > on the ISATAP interface. >=20 > ISA-4: The CE router MUST be configured in a manner that ensures > that no IPv6 routing loops are enabled via the ISATAP > interface [draft-ietf-v6ops-tunnel-loops]. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From fred@cisco.com Tue Apr 5 15:28: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 2773E3A67F3 for ; Tue, 5 Apr 2011 15:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.004 X-Spam-Level: X-Spam-Status: No, score=-110.004 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 dHI3tdr2+5W2 for ; Tue, 5 Apr 2011 15:28:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 407A63A66B4 for ; Tue, 5 Apr 2011 15:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3930; q=dns/txt; s=iport; t=1302042622; x=1303252222; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=PQ2LbobuYwCCAWHiV2zPnogmKVRci8em1peMDuDPddU=; b=leABxudBledEM/WKxh7x+c7zTAknDzsHjsrqj9wAJYiFvTRVQeACYjyq RWCwctIIWB1TDSvH+I52tfb0CxXTlqSH446AFMAhmH4K+KtxbJp9VDnYz 8zsYxDZwrN7ARuxJoC0Bpu6TuEphoa8+2xe9KyJC6EgU6D3AwG0bc2oJk k=; X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="82317954" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2011 22:30:21 +0000 Received: from Freds-Computer.local (dhcp-10-61-105-97.cisco.com [10.61.105.97]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p35MU7Bm017395; Tue, 5 Apr 2011 22:30:15 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 06 Apr 2011 00:30:18 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 06 Apr 2011 00:30:18 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 6 Apr 2011 00:29:46 +0200 Message-Id: <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 22:28:40 -0000 Isn't cpe-router-bis is about a native IPv6 residential/SOHO network? = What would ISATAP do in a native IPv6 network? On Apr 5, 2011, at 11:59 PM, Templin, Fred L wrote: > Hi Hemant, >=20 > I have no way of knowing how many home or soho networks > use ISATAP today, however I do know that there are many > (millions of?) hosts that would automatically enable > ISATAP if it were available in the home/soho network. >=20 > Thanks - Fred > fred.l.templin@boeing.com=20 >=20 >> -----Original Message----- >> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 >> Sent: Tuesday, April 05, 2011 2:42 PM >> To: Hemant Singh (shemant); Templin, Fred L; IPv6 Ops WG >> Subject: RE: [v6ops]=20 >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >> Fred, >>=20 >> One feedback from the design team was to ask how many home or soho >> networks use ISATAP today before the team would decide to add=20 >> ISATAP to >> the bis document? =20 >>=20 >> Thanks, >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Hemant Singh (shemant) >> Sent: Tuesday, April 05, 2011 4:34 PM >> To: Templin, Fred L; IPv6 Ops WG >> Subject: Re: [v6ops] >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >> Fred, >>=20 >> Thanks for the text. I will run your email by our IPv6 CE=20 >> Router design >> team and solicit feedback from them for ISATAP in the IPv6 CE Router >> specification. >>=20 >> Cheers, >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Templin, Fred L >> Sent: Tuesday, April 05, 2011 4:16 PM >> To: IPv6 Ops WG >> Subject: Re: [v6ops] Fwd: >> I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >> I would like to propose a new section for this draft to >> cover the use of transition technologies within the end >> user LAN side network. See below for proposed text: >>=20 >> Fred >> fred.l.templin@boeing.com >>=20 >> --- cut here --- >>=20 >> 5.5.3 ISATAP >>=20 >> The IPv6 CE Router can be used to offer IPv6 services to nodes >> on IPv4-only segments within the end user LAN. ISATAP [RFC5214] >> provides for intra-site encapsulation of IPv6 packets over IPv4 >> networks that connect to the IPv6 Internet via one or more IPv6 >> CE Routers configured as site border routers. The IPv6 CE Router >> sub-delegates portions of its IPv6 prefixes for assignment to >> nodes on the ISATAP link and/or to the ISATAP link itself.=20 >>=20 >> ISATAP requirements: >>=20 >> ISA-1: If the IPv6 CE Router implements ISATAP functionality, the >> CE Router LAN interface MUST support at least one ISATAP >> virtual interface and ISATAP router functionality as >> specified in [RFC5214]. >>=20 >> ISA-2: If the IPv6 CE Router implements ISATAP functionality, it >> MUST arrange to add itself to the ISATAP Potential Router >> List (PRL) for the LAN. >>=20 >> ISA-3: When the LAN contains legacy ISATAP nodes that support >> only SLAAC, the IPv6 CE router MUST advertise IPv6 prefixes >> on the ISATAP interface. >>=20 >> ISA-4: The CE router MUST be configured in a manner that ensures >> that no IPv6 routing loops are enabled via the ISATAP >> interface [draft-ietf-v6ops-tunnel-loops]. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Apr 5 15:47: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 1D49328C160 for ; Tue, 5 Apr 2011 15:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 eUUqiu0UOa48 for ; Tue, 5 Apr 2011 15:47:54 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 9D6D828C15C for ; Tue, 5 Apr 2011 15:47:54 -0700 (PDT) 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 p35MnUV1025533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2011 15:49:31 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p35MnUpD018463; Tue, 5 Apr 2011 17:49:30 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p35MnTrQ018431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Apr 2011 17:49:30 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 5 Apr 2011 15:49:28 -0700 From: "Templin, Fred L" To: Fred Baker Date: Tue, 5 Apr 2011 15:49:28 -0700 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGA Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> In-Reply-To: <856E17EA-E3BA-47CE-A1D9-DD10F276991A@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 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 22:47:56 -0000 Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, April 05, 2011 3:30 PM > To: Templin, Fred L > Cc: Hemant Singh (shemant); IPv6 Ops WG > Subject: Re: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > network? Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 seems to acknowledge the existence of current IPv4 End-user networks, and that: "It is not expected that an end-user will change their existing network topology with the introduction of IPv6". It seems therefore that there will be a class of end user networks that would benefit from an intra-site IPv6/IPv4 transition technology. > What would ISATAP do in a native IPv6 network? The host would prefer native IPv6 over ISATAP. But, not all home/soho networks are set up for native IPv6. Thanks - Fred fred.l.templin@boeing.com > On Apr 5, 2011, at 11:59 PM, Templin, Fred L wrote: > > Hi Hemant, > >=20 > > I have no way of knowing how many home or soho networks > > use ISATAP today, however I do know that there are many > > (millions of?) hosts that would automatically enable > > ISATAP if it were available in the home/soho network. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com=20 > >=20 > >> -----Original Message----- > >> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > >> Sent: Tuesday, April 05, 2011 2:42 PM > >> To: Hemant Singh (shemant); Templin, Fred L; IPv6 Ops WG > >> Subject: RE: [v6ops]=20 > >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>=20 > >> Fred, > >>=20 > >> One feedback from the design team was to ask how many home or soho > >> networks use ISATAP today before the team would decide to add=20 > >> ISATAP to > >> the bis document? =20 > >>=20 > >> Thanks, > >>=20 > >> Hemant > >>=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf > >> Of Hemant Singh (shemant) > >> Sent: Tuesday, April 05, 2011 4:34 PM > >> To: Templin, Fred L; IPv6 Ops WG > >> Subject: Re: [v6ops] > >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>=20 > >> Fred, > >>=20 > >> Thanks for the text. I will run your email by our IPv6 CE=20 > >> Router design > >> team and solicit feedback from them for ISATAP in the IPv6=20 > CE Router > >> specification. > >>=20 > >> Cheers, > >>=20 > >> Hemant > >>=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf > >> Of Templin, Fred L > >> Sent: Tuesday, April 05, 2011 4:16 PM > >> To: IPv6 Ops WG > >> Subject: Re: [v6ops] Fwd: > >> I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>=20 > >> I would like to propose a new section for this draft to > >> cover the use of transition technologies within the end > >> user LAN side network. See below for proposed text: > >>=20 > >> Fred > >> fred.l.templin@boeing.com > >>=20 > >> --- cut here --- > >>=20 > >> 5.5.3 ISATAP > >>=20 > >> The IPv6 CE Router can be used to offer IPv6 services to nodes > >> on IPv4-only segments within the end user LAN. ISATAP [RFC5214] > >> provides for intra-site encapsulation of IPv6 packets over IPv4 > >> networks that connect to the IPv6 Internet via one or more IPv6 > >> CE Routers configured as site border routers. The IPv6 CE Router > >> sub-delegates portions of its IPv6 prefixes for assignment to > >> nodes on the ISATAP link and/or to the ISATAP link itself.=20 > >>=20 > >> ISATAP requirements: > >>=20 > >> ISA-1: If the IPv6 CE Router implements ISATAP=20 > functionality, the > >> CE Router LAN interface MUST support at least one ISATAP > >> virtual interface and ISATAP router functionality as > >> specified in [RFC5214]. > >>=20 > >> ISA-2: If the IPv6 CE Router implements ISATAP functionality, it > >> MUST arrange to add itself to the ISATAP Potential Router > >> List (PRL) for the LAN. > >>=20 > >> ISA-3: When the LAN contains legacy ISATAP nodes that support > >> only SLAAC, the IPv6 CE router MUST advertise=20 > IPv6 prefixes > >> on the ISATAP interface. > >>=20 > >> ISA-4: The CE router MUST be configured in a manner that ensures > >> that no IPv6 routing loops are enabled via the ISATAP > >> interface [draft-ietf-v6ops-tunnel-loops]. > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >>=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = From shemant@cisco.com Tue Apr 5 16:01: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 CD6523A6989 for ; Tue, 5 Apr 2011 16:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.643 X-Spam-Level: X-Spam-Status: No, score=-10.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 ujw7rt38UQjY for ; Tue, 5 Apr 2011 16:01:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B88973A681B for ; Tue, 5 Apr 2011 16:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1690; q=dns/txt; s=iport; t=1302044603; x=1303254203; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZfjBihgrgIjPu4WY1ExFf3ALifvaT6ttTy00JEDTlpI=; b=JVxBeB/Y93iisqcyQ1SaI4QUlKWVMrlV41Imb+NbLRcNxQaGOZhViChZ thRICiSuh4lsrDGrv6XIdZgtRdfUIHITmFSgjCw6lV5ALibjip2T0DqNl J0vM8bMFQCYxpHkbmbuHFutGh/5opc1c0iIjFrXrjfmWm3eUFZI9owPFA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAJuem02tJXG9/2dsb2JhbACYKo1Id4h5ng6cJoVsBIVHiz8 X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="676299693" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2011 23:03:23 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p35N3Mu2009508; Tue, 5 Apr 2011 23:03:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 18:03:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 18:03:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjA= References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Fred Baker (fred)" X-OriginalArrivalTime: 05 Apr 2011 23:03:22.0948 (UTC) FILETIME=[A9A60040:01CBF3E5] Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 23:01:41 -0000 Fred T., If the CE router gets a public IPv4 address the CE router goes directly to the public IPv4 Internet. If the CE router gets a "private" IPv4 address where private is RFC 1918 address space + the specific subnet defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also takes care of shared IPv4 addresses between multiple homes. Can ISATAP take care of shared IPv4 address between different homes?=20 Hemant -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Tuesday, April 05, 2011 6:49 PM To: Fred Baker (fred) Cc: Hemant Singh (shemant); IPv6 Ops WG Subject: RE: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, April 05, 2011 3:30 PM > To: Templin, Fred L > Cc: Hemant Singh (shemant); IPv6 Ops WG > Subject: Re: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > network? Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 seems to acknowledge the existence of current IPv4 End-user networks, and that: "It is not expected that an end-user will change their existing network topology with the introduction of IPv6". It seems therefore that there will be a class of end user networks that would benefit from an intra-site IPv6/IPv4 transition technology. > What would ISATAP do in a native IPv6 network? The host would prefer native IPv6 over ISATAP. But, not all home/soho networks are set up for native IPv6. Thanks - Fred fred.l.templin@boeing.com From shemant@cisco.com Tue Apr 5 16:13: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 349723A698D for ; Tue, 5 Apr 2011 16:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.642 X-Spam-Level: X-Spam-Status: No, score=-10.642 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 CyeNwPEmgu5O for ; Tue, 5 Apr 2011 16:13:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7AD3E3A6999 for ; Tue, 5 Apr 2011 16:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=960; q=dns/txt; s=iport; t=1302045296; x=1303254896; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=w+zxgkoICliVFOh9z9jdhKepr7u9ghI01jWTgnnQBa0=; b=flW8mXyVxQ+2hqkcHf3xL1PA5/fWLTMLNP5++Lg4sIdwqVGdCbci4NUy lhkyG8i7nLHzdBUPiBSqcKxCfBGom6vZcWtEKenoD1x4CxbX/tPHg9glq Ul6QPABeHUdN4mAwRw6shWzPa816GFdMonQoyBfG2gecriXENyQkie5gP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO2hm02tJXG9/2dsb2JhbAClcnenBZwghWwEhUeLPw X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="331337247" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 05 Apr 2011 23:14:55 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p35NEsni012581; Tue, 5 Apr 2011 23:14:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 18:14:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 18:14:53 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301391408@XMB-RCD-109.cisco.com> In-Reply-To: <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4QywM3yCfYRfR6WnykC+IZzxHwAAdxOQ References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> From: "Hemant Singh (shemant)" To: "Alain Durand" X-OriginalArrivalTime: 05 Apr 2011 23:14:55.0631 (UTC) FILETIME=[468509F0:01CBF3E7] Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 23:13:13 -0000 Alain, Since you asked at the mic during the IETF 80 in Prague to add PCP to the IPv6 CE Router bis document, I have been looking at draft-ietf-pcp-base-07 that you pointed me to. As Lee said in response that we try and not add I-D's to the IPv6 CE router document. We need specifications in RFC form. You said the document is going to LastCall soon. Well, the document has lot of other document dependencies such a PCP Proxy, pcp-upnp-igd-interworking, etc. Thus I am not sure how soon can draft-ietf-pcp-base-07 become an RFC. However, I do see use cases for PCP in the CE router. I use a Linux machine in my home and sometimes from the road I access the machine with SSH. With CGN in the SP serving my home, I can certainly see the SSH default port be mapped to some other port. Can anyone on the PCP document team provide some text for use of PCP in the IPv6 CE Router document? Let's take is from there.=20 Thanks, Hemant From shemant@cisco.com Tue Apr 5 16:55: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 CAA3C3A6812 for ; Tue, 5 Apr 2011 16:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.641 X-Spam-Level: X-Spam-Status: No, score=-10.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 XOiMPqDLQN+w for ; Tue, 5 Apr 2011 16:55:51 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0A24A3A67E4 for ; Tue, 5 Apr 2011 16:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1161; q=dns/txt; s=iport; t=1302047854; x=1303257454; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9/ksWmwIvmgVz2N1vxfKXiY5RhfgWNMYEfzl5xCblxc=; b=YTWjpCvoXPUt3NuMxtnRaW+O/uLAFtcNWR/ID1z2TmTrGFw6ozCODfKj uJvpjWqFlBdOZevVO6nMG28XiJGinHN+XzjosKuLcXn+JvkC2thiMpQw2 szNP/hzRApNXhWMnPd5z+PzkXqudrQ6oVFk/7vwArZJ5aONof2xEMrSxT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAO2rm02tJV2c/2dsb2JhbACYLY1Id6ZunCiFbASFR4s/ X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="282254783" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2011 23:57:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p35NvY2e005240; Tue, 5 Apr 2011 23:57:34 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 18:57:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 18:57:31 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoA== References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Templin, Fred L" , "Fred Baker (fred)" X-OriginalArrivalTime: 05 Apr 2011 23:57:33.0949 (UTC) FILETIME=[3B6562D0:01CBF3ED] Cc: IPv6 Ops WG , "Tony Hain \(ahain\)" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 05 Apr 2011 23:55:51 -0000 Fred T., Someone else pointed out to me use of ISATAP is in the home LAN. Thus I need not compare ISATAP to WAN 6to4 transition tech. However, the use case for ISATAP is not clear in the home LAN. Let's assume the home has multiple subnets. Why can't the home use dual-stack in the LAN with private IPv4 addresses and ULA and global IPv6 addresses with routing and instead use ISATAP? Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, April 05, 2011 7:03 PM To: Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG Subject: Re: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred T., If the CE router gets a public IPv4 address the CE router goes directly to the public IPv4 Internet. If the CE router gets a "private" IPv4 address where private is RFC 1918 address space + the specific subnet defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also takes care of shared IPv4 addresses between multiple homes. Can ISATAP take care of shared IPv4 address between different homes?=20 Hemant From jason.weil@twcable.com Tue Apr 5 17:13: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 DEE4E3A695A for ; Tue, 5 Apr 2011 17:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpVPr9u3aHqd for ; Tue, 5 Apr 2011 17:13:32 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id ED18D3A6844 for ; Tue, 5 Apr 2011 17:13:31 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.63,307,1299474000"; d="scan'208";a="198194114" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 05 Apr 2011 20:15:51 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 5 Apr 2011 20:15:14 -0400 From: "Weil, Jason" To: "Hemant Singh (shemant)" , "Templin, Fred L" , "Fred Baker (fred)" Date: Tue, 5 Apr 2011 20:15:14 -0400 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoAAAvcPq Message-ID: <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.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 Ops WG , "Tony Hain \(ahain\)" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 00:13:33 -0000 If I recall correctly ISATAP was designed to support duals-stack hosts thro= ugh IPv4-only intermediate hops. The use case that I tried hard not to pond= er but is the only one I could think of here is an intermediate hop IPv4-on= ly CE router connected between a dual-stack host and the dual-stack on LAN = CPE Router. While it is possibly and maybe even likely this will happen, as= Hemant alluded, the uses cases currently being considered were assuming Du= al-stack home network and IPv4-only or IPv6-only WAN connection to the serv= ice provider. I would say this belongs in the 3rd Phase draft for complex m= ulti-router home networks. Thanks, Jason ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Hemant S= ingh (shemant) [shemant@cisco.com] Sent: Tuesday, April 05, 2011 7:57 PM To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG; Tony Hain (ahain) Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-= 00.txt Fred T., Someone else pointed out to me use of ISATAP is in the home LAN. Thus I need not compare ISATAP to WAN 6to4 transition tech. However, the use case for ISATAP is not clear in the home LAN. Let's assume the home has multiple subnets. Why can't the home use dual-stack in the LAN with private IPv4 addresses and ULA and global IPv6 addresses with routing and instead use ISATAP? Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, April 05, 2011 7:03 PM To: Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG Subject: Re: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred T., If the CE router gets a public IPv4 address the CE router goes directly to the public IPv4 Internet. If the CE router gets a "private" IPv4 address where private is RFC 1918 address space + the specific subnet defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also takes care of shared IPv4 addresses between multiple homes. Can ISATAP take care of shared IPv4 address between different homes? Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From tena@huawei.com Tue Apr 5 17:24: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 B2FF53A68D2 for ; Tue, 5 Apr 2011 17:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.98 X-Spam-Level: X-Spam-Status: No, score=-105.98 tagged_above=-999 required=5 tests=[AWL=0.019, 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 xnDQ2RkwvLH8 for ; Tue, 5 Apr 2011 17:24:48 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 588CB3A6844 for ; Tue, 5 Apr 2011 17:24:48 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ7004W7FW7NS@usaga02-in.huawei.com> for v6ops@ietf.org; Tue, 05 Apr 2011 17:26:31 -0700 (PDT) Received: from TingZousc1 ([10.193.34.126]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJ700EE4FW6F6@usaga02-in.huawei.com> for v6ops@ietf.org; Tue, 05 Apr 2011 17:26:31 -0700 (PDT) Date: Tue, 05 Apr 2011 17:26:37 -0700 From: Tina Tsou In-reply-to: <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> To: "'Weil, Jason'" , "'Hemant Singh (shemant)'" , "'Templin, Fred L'" , "'Fred Baker (fred)'" Message-id: <009b01cbf3f1$4b22c970$e1685c50$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoAAAvcPqAACaBUA= References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> Cc: 'IPv6 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 00:24:49 -0000 Hi Jason, Do you mean like this? Host [CE router] [CPE Router: LAN] [CE-Router: WAN] Network DS IPv4-only DS IPv4-only DS IPv4-only DS IPv6-only We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Tuesday, April 05, 2011 5:15 PM To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG; Tony Hain (ahain) Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt If I recall correctly ISATAP was designed to support duals-stack hosts through IPv4-only intermediate hops. The use case that I tried hard not to ponder but is the only one I could think of here is an intermediate hop IPv4-only CE router connected between a dual-stack host and the dual-stack on LAN CPE Router. While it is possibly and maybe even likely this will happen, as Hemant alluded, the uses cases currently being considered were assuming Dual-stack home network and IPv4-only or IPv6-only WAN connection to the service provider. I would say this belongs in the 3rd Phase draft for complex multi-router home networks. Thanks, Jason ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) [shemant@cisco.com] Sent: Tuesday, April 05, 2011 7:57 PM To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG; Tony Hain (ahain) Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred T., Someone else pointed out to me use of ISATAP is in the home LAN. Thus I need not compare ISATAP to WAN 6to4 transition tech. However, the use case for ISATAP is not clear in the home LAN. Let's assume the home has multiple subnets. Why can't the home use dual-stack in the LAN with private IPv4 addresses and ULA and global IPv6 addresses with routing and instead use ISATAP? Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, April 05, 2011 7:03 PM To: Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG Subject: Re: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred T., If the CE router gets a public IPv4 address the CE router goes directly to the public IPv4 Internet. If the CE router gets a "private" IPv4 address where private is RFC 1918 address space + the specific subnet defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also takes care of shared IPv4 addresses between multiple homes. Can ISATAP take care of shared IPv4 address between different homes? Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Dmitry.Anipko@microsoft.com Tue Apr 5 20:06: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 2DC503A684E for ; Tue, 5 Apr 2011 20:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW3p4ZjvroZx for ; Tue, 5 Apr 2011 20:06:23 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 25E313A684B for ; Tue, 5 Apr 2011 20:06:23 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 20:08:05 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 5 Apr 2011 20:08:05 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Tue, 5 Apr 2011 20:08:05 -0700 From: Dmitry Anipko To: Mikael Abrahamsson Date: Tue, 5 Apr 2011 20:08:03 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AcvzyUMzPTtmrEWzRyiMoCECN8FRKQAPNH9g Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 03:06:24 -0000 Thanks Mikael. I agree there are many sources which can contribute to IPv6 = brokenness. Some of them are easier to fix than others.=20 My question, however, specifically is whether for IPv6 day it is preferred = that the known issues are fixed, or rather not fixed in case it helps to un= cover other issues contributing to the brokenness. -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, April 05, 2011 12:40 PM To: Dmitry Anipko Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n On Tue, 5 Apr 2011, Dmitry Anipko wrote: > Hi, > > I have a question regarding http://tools.ietf.org/html/draft-ietf-v6ops-6= to4-advisory-00 and IPv6 day. > > In section 4.1. among other items the draft recommends to vendors to=20 > disable Anycast 6to4 functionality by default. If an OS vendor has an=20 > ability to do that for existing implementations, is there a WG consensus= =20 > whether such changes should be done before the IPv6 day? I don't think there was consensus, but there are quite a few people who=20 would like to see it disabled. What should *really* be done is to disable sending RAs out the WAN=20 interface when ICS is turned on and 6to4 is the only IPv6 available.=20 Please never ever send RAs out the WAN interface at all. This is causing=20 serious breakage. > I've checked the Prague WG meeting jabber logs, and I see there was a=20 > discussion regarding the intent of IPv6 day, but I'm not sure there was=20 > a consensus. There were arguments both for letting more things break on=20 > IPv6 day, in order to find what breaks and fix it (e.g. programs not=20 > using RFC 3484 sorting), as well as arguments fixing pro-actively things= =20 > which can be fixed in order for users not to encounter already known=20 > issues. I'm of the opinion that IPv6 tunneling should be default off in devices.=20 If nothing else, please change so that 6to4 reachability is treated the=20 same way as teredo, ie lower than native ipv4. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Tue Apr 5 20:39: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 44E643A684F for ; Tue, 5 Apr 2011 20:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 08-QqZ9QxYbP for ; Tue, 5 Apr 2011 20:39:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 227DA3A684E for ; Tue, 5 Apr 2011 20:39:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E455C5F984C; Wed, 6 Apr 2011 03:41:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 B454E216C31; Wed, 6 Apr 2011 03:41:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C23A8DDC893; Wed, 6 Apr 2011 13:41:20 +1000 (EST) To: Dmitry Anipko From: Mark Andrews References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> In-reply-to: Your message of "Tue, 05 Apr 2011 20:08:03 MST." Date: Wed, 06 Apr 2011 13:41:20 +1000 Message-Id: <20110406034120.C23A8DDC893@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 03:39:59 -0000 In message , Dmitry Anipko writes: > Thanks Mikael. I agree there are many sources which can contribute to IPv6 br > okenness. Some of them are easier to fix than others. > > My question, however, specifically is whether for IPv6 day it is preferred th > at the known issues are fixed, or rather not fixed in case it helps to uncove > r other issues contributing to the brokenness. I would say leave 6to4 along. If 6to4 is broken and it results in a application breaking then that application is not RFC 1123 compliant and needs to be fixed. If a application is excessively slow due to 6to4 not working it also needs to be fixed. > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, April 05, 2011 12:40 PM > To: Dmitry Anipko > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question > > On Tue, 5 Apr 2011, Dmitry Anipko wrote: > > > Hi, > > > > I have a question regarding http://tools.ietf.org/html/draft-ietf-v6ops-6to > 4-advisory-00 and IPv6 day. > > > > In section 4.1. among other items the draft recommends to vendors to > > disable Anycast 6to4 functionality by default. If an OS vendor has an > > ability to do that for existing implementations, is there a WG consensus > > whether such changes should be done before the IPv6 day? > > I don't think there was consensus, but there are quite a few people who > would like to see it disabled. > > What should *really* be done is to disable sending RAs out the WAN > interface when ICS is turned on and 6to4 is the only IPv6 available. > Please never ever send RAs out the WAN interface at all. This is causing > serious breakage. > > > I've checked the Prague WG meeting jabber logs, and I see there was a > > discussion regarding the intent of IPv6 day, but I'm not sure there was > > a consensus. There were arguments both for letting more things break on > > IPv6 day, in order to find what breaks and fix it (e.g. programs not > > using RFC 3484 sorting), as well as arguments fixing pro-actively things > > which can be fixed in order for users not to encounter already known > > issues. > > I'm of the opinion that IPv6 tunneling should be default off in devices. > If nothing else, please change so that 6to4 reachability is treated the > same way as teredo, ie lower than native ipv4. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Tue Apr 5 21:15: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 D9B303A6860 for ; Tue, 5 Apr 2011 21:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 AePKgFvt6Ss6 for ; Tue, 5 Apr 2011 21:15:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 315B23A685B for ; Tue, 5 Apr 2011 21:15:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2B11F9C; Wed, 6 Apr 2011 06:17:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 267079A; Wed, 6 Apr 2011 06:17:11 +0200 (CEST) Date: Wed, 6 Apr 2011 06:17:11 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20110406034120.C23A8DDC893@drugs.dv.isc.org> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 04:15:29 -0000 On Wed, 6 Apr 2011, Mark Andrews wrote: > If a application is excessively slow due to 6to4 not working it also > needs to be fixed. The behaviour is already known, there is nothing to be learnt from leaving this broken for 3 more months. I'd say get rid of 6to4 (or downprio it) asap and get that process going, little or nothing is gained by waiting. I want as little breakage as possible on IPv6 day so that content providers feel confident to turn on dual stack on their content. If the result is bad and we THEN say "ok, we confirmed that 6to4 is causing problems, please turn it off", we will have lost time. -- Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Tue Apr 5 22:57: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 3CD283A6886 for ; Tue, 5 Apr 2011 22:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 nG5Mqq3N+HYV for ; Tue, 5 Apr 2011 22:57:41 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id EAB8F3A6882 for ; Tue, 5 Apr 2011 22:57:40 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 587D6C9423; Wed, 6 Apr 2011 05:59:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 E03EB216C31; Wed, 6 Apr 2011 05:59:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 74A8BDDD8AB; Wed, 6 Apr 2011 15:59:18 +1000 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 06 Apr 2011 06:17:11 +0200." Date: Wed, 06 Apr 2011 15:59:18 +1000 Message-Id: <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 05:57:42 -0000 In message , Mikael Abrah amsson writes: > On Wed, 6 Apr 2011, Mark Andrews wrote: > > > If a application is excessively slow due to 6to4 not working it also > > needs to be fixed. > > The behaviour is already known, there is nothing to be learnt from leaving > this broken for 3 more months. If you have a fix for a application, install it. However part of the point is to find the list of applications which don't work correctly in a non optimal environment or are you claiming links won't go down and the broken applications don't need to be discovered. Similarly we need to check the applications in a IPv6-only environment. iChat and iCal don't work in such a environment, Apple have been informed. They require A IPv4 address to be configured even if it is a link-local address. While vendors should be testing in all sorts of environments there is nothing like the real world to find something new. > I'd say get rid of 6to4 (or downprio it) asap and get that process going, > little or nothing is gained by waiting. > > I want as little breakage as possible on IPv6 day so that content > providers feel confident to turn on dual stack on their content. > > If the result is bad and we THEN say "ok, we confirmed that 6to4 is > causing problems, please turn it off", we will have lost time. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Tue Apr 5 23: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 34EEF3A689E for ; Tue, 5 Apr 2011 23:15:52 -0700 (PDT) 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 Rh70PnupYulK for ; Tue, 5 Apr 2011 23:15:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 1CA6D3A688C for ; Tue, 5 Apr 2011 23:15:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 907E69C; Wed, 6 Apr 2011 08:17:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8C0369A; Wed, 6 Apr 2011 08:17:31 +0200 (CEST) Date: Wed, 6 Apr 2011 08:17:31 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 06:15:52 -0000 On Wed, 6 Apr 2011, Mark Andrews wrote: > If you have a fix for a application, install it. However part of the > point is to find the list of applications which don't work correctly in > a non optimal environment or are you claiming links won't go down and > the broken applications don't need to be discovered. IPv6 day will discover applications that don't work well in a dual stack as content providers turn on A/AAAA. The main impact that I've heard they are afraid of, is people not being able to reach their websites. 23 second delay for each object counts as "not being able to reach". It is my opinion that this behaviour is well known. There is little to be learnt here, we just need to fix it. Fixing it might be "happy eyeballs", but that is really far away. Turning off 6to4 would be a quick fix for a lot of the brokenness seen by eyeballs. If we feel likely that we want 6to4 to be turned off after ipv6 world day, why not do it immediately and have less brokenness that day, so content providers will feel more secure in turning on dual stack for their content, so that the "real" ipv6 connectivity that we know works better (managed tunnels and real dual stack) can be measured. For me, changing the 6to4 recommendation so that it would work exactly like teredo and not do AAAA questions when only 6to4 or teredo is available, would work as well. I just don't want users to use 6to4 and teredo to reach websites that are dual stack. > Similarly we need to check the applications in a IPv6-only environment. > iChat and iCal don't work in such a environment, Apple have been > informed. They require A IPv4 address to be configured even if it is a > link-local address. While vendors should be testing in all sorts of > environments there is nothing like the real world to find something new. Afaik World IPv6 day is not about testing ipv6 single stack. I agree it needs to be done (I'm pushing microsoft to fix MSN messenger for NAT64 use for instance), but that's something that for me has less priority than trying to get dual stack content working. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Tue Apr 5 23:52: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 9CED03A68AF for ; Tue, 5 Apr 2011 23:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl7h2TYZb3Du for ; Tue, 5 Apr 2011 23:52:14 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2AAAF3A68A7 for ; Tue, 5 Apr 2011 23:52:14 -0700 (PDT) Received: by wwa36 with SMTP id 36so934682wwa.13 for ; Tue, 05 Apr 2011 23:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l+KjW/FMgLdZD40N+T77+hPIQcZOXnHmk2FARU36kTU=; b=GMU+4FAIcO63YBJFrZ/HzQx5895Yvm7tICO8zwBhoshZRo0cy0e0S3vKNCGr8UQAGo pxqeeT/safEL6x4qTnaPE6DfoWBf+FPnnMrK72eRzSfFVUYKOOQ16pvvdJT+NUqMMrQL xl3CiX59dCIKSkD4ZRZbNvSrLituNdophDP8w= 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=mcEgl8V0mYdDdlE0rYlR2tkBmIt2Xg2njFPvLHr1fJJCFtm/7MpXbYdFg4YVYw+0Cv SPiJ3vwnW+T0CHr58d8fP9fbtR52W60Yz1AfsEubS/9iKaRXU9WtYlId6wLQIEiP8RAM uynBVBip57DqI2l1bQeNSYR5rQyDsUU24Kwj8= Received: by 10.227.151.15 with SMTP id a15mr600339wbw.184.1302072837236; Tue, 05 Apr 2011 23:53:57 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id l24sm144730wbc.30.2011.04.05.23.53.55 (version=SSLv3 cipher=OTHER); Tue, 05 Apr 2011 23:53:55 -0700 (PDT) Message-ID: <4D9C0E00.10303@gmail.com> Date: Wed, 06 Apr 2011 18:53:52 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 06:52:15 -0000 My personal opinion is that the recommendations in 6to4-advisory should be applied as soon as possible by as many operators as possible, regardless of IPv6 Day. The reason I would like to get it finalised before IPv6 Day is so that, when operators suffer from 6to4-related issues on that day, they can be pointed to the document as the way to mitigate them. Regards Brian On 2011-04-06 18:17, Mikael Abrahamsson wrote: > On Wed, 6 Apr 2011, Mark Andrews wrote: > >> If you have a fix for a application, install it. However part of the >> point is to find the list of applications which don't work correctly >> in a non optimal environment or are you claiming links won't go down >> and the broken applications don't need to be discovered. > > IPv6 day will discover applications that don't work well in a dual stack > as content providers turn on A/AAAA. The main impact that I've heard > they are afraid of, is people not being able to reach their websites. 23 > second delay for each object counts as "not being able to reach". It is > my opinion that this behaviour is well known. > > There is little to be learnt here, we just need to fix it. Fixing it > might be "happy eyeballs", but that is really far away. Turning off 6to4 > would be a quick fix for a lot of the brokenness seen by eyeballs. If we > feel likely that we want 6to4 to be turned off after ipv6 world day, why > not do it immediately and have less brokenness that day, so content > providers will feel more secure in turning on dual stack for their > content, so that the "real" ipv6 connectivity that we know works better > (managed tunnels and real dual stack) can be measured. > > For me, changing the 6to4 recommendation so that it would work exactly > like teredo and not do AAAA questions when only 6to4 or teredo is > available, would work as well. I just don't want users to use 6to4 and > teredo to reach websites that are dual stack. > >> Similarly we need to check the applications in a IPv6-only >> environment. iChat and iCal don't work in such a environment, Apple >> have been informed. They require A IPv4 address to be configured even >> if it is a link-local address. While vendors should be testing in all >> sorts of environments there is nothing like the real world to find >> something new. > > Afaik World IPv6 day is not about testing ipv6 single stack. I agree it > needs to be done (I'm pushing microsoft to fix MSN messenger for NAT64 > use for instance), but that's something that for me has less priority > than trying to get dual stack content working. > From swmike@swm.pp.se Wed Apr 6 00: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 D0EA63A68B6 for ; Wed, 6 Apr 2011 00:04:43 -0700 (PDT) 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 9b8146utAFpj for ; Wed, 6 Apr 2011 00:04:43 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2A96C3A68AF for ; Wed, 6 Apr 2011 00:04:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 48CC99C; Wed, 6 Apr 2011 09:06:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 45A9E9A; Wed, 6 Apr 2011 09:06:26 +0200 (CEST) Date: Wed, 6 Apr 2011 09:06:26 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4D9C0E00.10303@gmail.com> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 07:04:43 -0000 On Wed, 6 Apr 2011, Brian E Carpenter wrote: > The reason I would like to get it finalised before IPv6 Day is so that, > when operators suffer from 6to4-related issues on that day, they can be > pointed to the document as the way to mitigate them. Operators? I thought this was an end-user problem primarily? We don't want operators to turn off 6to4 relays, we want end-systems to turn off using them, right? -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Wed Apr 6 00:18: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 4AE0E3A68BB for ; Wed, 6 Apr 2011 00:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3feqg5mP8yX for ; Wed, 6 Apr 2011 00:18:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 777783A68C7 for ; Wed, 6 Apr 2011 00:18:37 -0700 (PDT) Received: by wwa36 with SMTP id 36so949542wwa.13 for ; Wed, 06 Apr 2011 00:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GqQSO6jVVs38R/xiTT0tmXylvENrKCMuKNFiuY4/UnM=; b=NDsyDddEfOAZ0+5yaS/aGV5TByL55BWrxz1XlFsPs6oKpbG0EbfawftKgh5BgGpP3j kwGloaVS3/ci3EektnK7qFG6bBqmP/ZZwVr2b36k7qV8EJ1B16k6UB8Rb8V9MAXMGMgR lU7zEw3KxkICTscr83LXDQxBp5xiLUbub5QoA= 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=ULjg1xpeJLAD3qHf9vKLwBHArcHtkAlROec2uTukYOHnejRWf847ejlsmpZWy+uJOk YqzLlekpfta1LRNZjwrguv49xM1NaO8wuWCXniBE0YEwTuPFrJTAw2CbmmroETS9CZZJ 0kvlyI+bAbChAC9SK7vjMmNXEflBqeGKc6M18= Received: by 10.227.196.208 with SMTP id eh16mr630497wbb.224.1302074420454; Wed, 06 Apr 2011 00:20:20 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id y12sm155061wby.59.2011.04.06.00.20.18 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 00:20:19 -0700 (PDT) Message-ID: <4D9C1430.8060900@gmail.com> Date: Wed, 06 Apr 2011 19:20:16 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 07:18:38 -0000 On 2011-04-06 19:06, Mikael Abrahamsson wrote: > On Wed, 6 Apr 2011, Brian E Carpenter wrote: > >> The reason I would like to get it finalised before IPv6 Day is so >> that, when operators suffer from 6to4-related issues on that day, they >> can be pointed to the document as the way to mitigate them. > > Operators? I thought this was an end-user problem primarily? End users are the victims, but the mitigations are in the hands of operators. > We don't want operators to turn off 6to4 relays, we want end-systems to > turn off using them, right? Indeed. But I don't think many end users will be reading my draft. Brian From swmike@swm.pp.se Wed Apr 6 00:36: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 2BB713A68CB for ; Wed, 6 Apr 2011 00:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 qGSr9niN6NGA for ; Wed, 6 Apr 2011 00:36:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 668993A68C8 for ; Wed, 6 Apr 2011 00:36:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9EEB69C; Wed, 6 Apr 2011 09:38:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C9849A; Wed, 6 Apr 2011 09:38:27 +0200 (CEST) Date: Wed, 6 Apr 2011 09:38:27 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4D9C1430.8060900@gmail.com> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 07:36:47 -0000 On Wed, 6 Apr 2011, Brian E Carpenter wrote: > End users are the victims, but the mitigations are in the hands of > operators. How? The only thing an ISP can try to do is handle the access they provide and run a local 6to4 relay, that doesn't mitigate someone else running a bad relay or blocking at their end. > Indeed. But I don't think many end users will be reading my draft. No, but Microsoft can turn off (or change the behaviour of) 6to4 via a patch release on all Vista and Win7 systems. But this would have to be decided quickly to make it for May patch-tuesday. I'm afraid we're too late anyway... -- Mikael Abrahamsson email: swmike@swm.pp.se From ichiroumakino@gmail.com Wed Apr 6 00:50: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 098333A68CC for ; Wed, 6 Apr 2011 00:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 BR28oksjPVCx for ; Wed, 6 Apr 2011 00:50:00 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id F422E3A68C6 for ; Wed, 6 Apr 2011 00:49:59 -0700 (PDT) Received: by ewy19 with SMTP id 19so420097ewy.31 for ; Wed, 06 Apr 2011 00:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=NXFf711Yo0sNqGmSfdjje/6orqFQyreZKBrMGWILkZQ=; b=wM9njXJ6XF7sg6qSWqj0/tn/YKsuaX74Qk3uv6SzUu+JmG9hT0eH4yJip8DKERqoTp NWvu5oW9STj/v6AB2hgKc+LOaD9ag+4MLVOP3G/Osvf8i2ttTZANun7IogDOkebyVj2O 3o2NAokaru7VRfYH80lbCZgI2tneu1JFKZ3N0= 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=M5WxIX9A9fbQHZebG8WJh9FI0uoLxdvLY/htYgBGYh+2E4hgXKeFizcLjkWFO+E5GM V/e8aYh6btmQj/JPdrtpNNOB7U1qMo/D07d7+dJAxD10OuwlpXZReqwJAwFg1Nwc4mNj WoYtzwuARlkuEDh8FE2zWwGkwyiQlV67nH+qg= Received: by 10.14.32.13 with SMTP id n13mr265709eea.21.1302076302856; Wed, 06 Apr 2011 00:51:42 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id k51sm197966eei.3.2011.04.06.00.51.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 00:51:41 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D9B2DED.3060608@redpill-linpro.com> Date: Wed, 6 Apr 2011 09:51:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9938CF61-737C-43B8-B8DF-CE60793F0959@employees.org> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-6to4-to-historic-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: Wed, 06 Apr 2011 07:50:01 -0000 Tore, >> 4. Deprecation >>=20 >> This document formally deprecates the 6to4 transition mechanism and >> the IPv6 6to4 prefix defined in [RFC3056], i.e., 2002::/16. The >> prefix MUST NOT be reassigned for other use except by a future IETF >> standards action. > [...] >> 5. IANA Considerations >>=20 >> IANA is requested to mark the 2002::/16 prefix as "deprecated", >> pointing to this document. Reassignment of the prefix for any usage >> requires justification via an IETF Standards Action [RFC5226]. >>=20 >> IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as >> "deprecated", pointing to this document. Redelegation of the domain >> for any usage requires justification via an IETF Standards Action >> [RFC5226].RFC5158 >=20 > There's no similar language deprecating the IPv4 WKP 192.88.99.0/24. = Is > that an omission? yes, that is an omission. I will add that. just have to make sure to find text that doesn't encourage operators to = immediately black hole 192.88.99.0/24. that would just make the = situation worse. cheers, Ole= From Roman.Arcea@orange.md Wed Apr 6 01:35: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 916593A68D9; Wed, 6 Apr 2011 01:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLTovlRMrQ3E; Wed, 6 Apr 2011 01:35:21 -0700 (PDT) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 1198D3A68E2; Wed, 6 Apr 2011 01:35:21 -0700 (PDT) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id A8D58C0A39D; Wed, 6 Apr 2011 11:37:39 +0300 (EEST) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 8C6D9C0A301; Wed, 6 Apr 2011 11:37:39 +0300 (EEST) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> To: Mikael Abrahamsson MIME-Version: 1.0 X-KeepSent: 4930DD0C:29EB99CC-C225786A:002E84CB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Wed, 6 Apr 2011 11:37:08 +0300 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2FP2|March 22, 2011) at 04/06/2011 11:37:01, Serialize complete at 04/06/2011 11:37:01 Content-Type: text/plain; charset="US-ASCII" Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org, Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 08:35:24 -0000 > No, but Microsoft can turn off (or change the behaviour of) 6to4 via a > patch release on all Vista and Win7 systems. But this would have to be > decided quickly to make it for May patch-tuesday. > I'm afraid we're too late anyway... there is already such a patch http://support.microsoft.com/kb/929852, so it might be a matter of decision making. For that I suppose IETF should agree on making 6to4 historic in the first place to give enough reason to vendors to turn it off during software updates. As an operator you can link to that from your website. From brian.e.carpenter@gmail.com Wed Apr 6 01:45: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 CBF8428C0E6; Wed, 6 Apr 2011 01:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUAw65OimJKb; Wed, 6 Apr 2011 01:45:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7A7893A681D; Wed, 6 Apr 2011 01:45:45 -0700 (PDT) Received: by fxm15 with SMTP id 15so949118fxm.31 for ; Wed, 06 Apr 2011 01:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=11AmLeD26aYFDJ1PcsREbUvE1Drs+URnEUIyqVr0RhU=; b=WPldUrAyVg+Ez2kxKpjyPBcq44h8ihtBygkpTzYW5rGvdsTDHRnPeahxveU4GRmnaJ LvvvyzvvrwcC47iJppy822Zu8sZfadDnu/HVc8vILBr/9aTH11a/TrLNyQZl2KuP1oRE jbXGsjft/o0VcdGfx6ZbufGsCUSXqOIw/g95M= 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=R5hVxatYK3QNHvTJ4CjV6V3wiURZR6x9kaHqPRZ9Q/fO5BI9LOMYs7nmKXRVy4v+Nu O/DtPp5QaR9FK512O62WgEbFp7Ay0YXM1bMmIhWmIN1T/yXoYOqg+dD0muxl0g038uTF RYqIr0Ui3cIa/bnuypJZChnupOquiMK1KLylU= Received: by 10.223.63.212 with SMTP id c20mr762503fai.37.1302079648754; Wed, 06 Apr 2011 01:47:28 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id e23sm104797faa.42.2011.04.06.01.47.26 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 01:47:27 -0700 (PDT) Message-ID: <4D9C2898.6070401@gmail.com> Date: Wed, 06 Apr 2011 20:47:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roman.Arcea@orange.md References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko , v6ops-bounces@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 08:45:46 -0000 On 2011-04-06 20:37, Roman.Arcea@orange.md wrote: >> No, but Microsoft can turn off (or change the behaviour of) 6to4 via a >> patch release on all Vista and Win7 systems. But this would have to be >> decided quickly to make it for May patch-tuesday. > >> I'm afraid we're too late anyway... > > there is already such a patch http://support.microsoft.com/kb/929852, so > it might be a matter of decision making. > For that I suppose IETF should agree on making 6to4 historic in the first > place to give enough reason to vendors to turn it off during software > updates. As an operator you can link to that from your website. Turning it off as the default is quite common practice already in managed enterprise networks, but that isn't the main target "market" here - it's unmanaged SOHO hosts, and an optional patch isn't going to help there. Brian From brian.e.carpenter@gmail.com Wed Apr 6 01:52: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 00F993A6849 for ; Wed, 6 Apr 2011 01:52:45 -0700 (PDT) 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 g7yFi+cwA3kG for ; Wed, 6 Apr 2011 01:52:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2B9A43A681D for ; Wed, 6 Apr 2011 01:52:44 -0700 (PDT) Received: by fxm15 with SMTP id 15so953892fxm.31 for ; Wed, 06 Apr 2011 01:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6ka4rFGtVNgzidl9ZvAqKcj4aQG943yfUJReNijZl8s=; b=Ni7nONWLngqkAL5hvxMjJsbXi23W8yygf8o+SS7JVUn4kUOlqHF1JrOK2zZGAjkkjk cpD+qmpNphtUfWbwCxHbWsNrDY89DmAwcl+YKSOsVCtZmd8hjQ3pNfNw5cklWp3RQAmB xyXIpFebHVeMJD5Rt1wbSTrbE6b6Y+iwLaB0k= 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=ga47UF1uAePlh1uxa/S7G2HzdCgP9HiirPFTxGunhbyWDdhy0e7y9M0t6rmvwWqO8n +1xYDvik6a2lJGSXwFZ1ciGApJjbSE+IdHEd277bDB0mP+D1Pe3WI7S2QfmkMiqH9K0H NgFXxoj3lwYvEXfLsCCa298bXhhU+yKglh6R8= Received: by 10.223.14.207 with SMTP id h15mr760140faa.50.1302080067492; Wed, 06 Apr 2011 01:54:27 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id 21sm107603fav.41.2011.04.06.01.54.25 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 01:54:26 -0700 (PDT) Message-ID: <4D9C2A3F.6010507@gmail.com> Date: Wed, 06 Apr 2011 20:54:23 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 08:52:45 -0000 On 2011-04-06 19:38, Mikael Abrahamsson wrote: > On Wed, 6 Apr 2011, Brian E Carpenter wrote: > >> End users are the victims, but the mitigations are in the hands of >> operators. > > How? The only thing an ISP can try to do is handle the access they > provide and run a local 6to4 relay, that doesn't mitigate someone else > running a bad relay or blocking at their end. Well, there's a reason that the draft is structured the way it is: show each category of ISP why it's in their selfish interest to mitigate 6to4 problems. However, indeed the word is 'mitigate' not 'fix'. > >> Indeed. But I don't think many end users will be reading my draft. > > No, but Microsoft can turn off (or change the behaviour of) 6to4 via a > patch release on all Vista and Win7 systems. But this would have to be > decided quickly to make it for May patch-tuesday. It's a bit tricky to turn it off under the nose of existing users, who may be using it quite happily. Remember that many 6to4 sessions are completely successful. 6to4-to-historic is trying to change the default for *future* products. For current users, it's quite unclear how to deal with it in a way that doesn't generate millions of help-desk calls. > > I'm afraid we're too late anyway... Oh, the "day" is rather symbolic - the issue exists before, during, and after the day. Brian From brian.e.carpenter@gmail.com Wed Apr 6 01:54:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D2C3A68E6 for ; Wed, 6 Apr 2011 01:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, 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 geyjxz4kfliO for ; Wed, 6 Apr 2011 01:54:07 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7C8413A6849 for ; Wed, 6 Apr 2011 01:54:07 -0700 (PDT) Received: by wyb29 with SMTP id 29so1183175wyb.31 for ; Wed, 06 Apr 2011 01:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jd69DUBHJqFNfswh80ISK4q5cFEF7sqZ6ez3Fygp08Y=; b=xbGs2ukT7ji8JtvwbNig7H4SVIey0qQmZ13OK+VSU/4HMEu1Rt1TnShjAC4bJfiURV +Y4/J1zy/g+RLJSuyEsnIlTWmvoZrr98tGbdwD9Hx/LHyMREUHV0zZis7RJHm9mv+LkQ /P6/xQT4M6hHkjKBp13EXpZa0rwAy3+kmCMl8= 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=W2thnB35wtiZW+mkmN676q5v52zA8yBUUZHfrDBaLJAMXZMUkxpaw4DV+nwUM4/KI2 gAKYxF7mmpDhhWJsi/ZuLkmMCvKZaIradhdJ8Poobs8JGfitwtbFtlOZnBojqFwmMGj4 Q6/AAypJTJr/0K/kVRNUMgfEXJWmt/pqR6OyA= Received: by 10.216.254.82 with SMTP id g60mr6280728wes.36.1302080150650; Wed, 06 Apr 2011 01:55:50 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id o6sm209987wbo.20.2011.04.06.01.55.49 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 01:55:49 -0700 (PDT) Message-ID: <4D9C2A92.6090905@gmail.com> Date: Wed, 06 Apr 2011 20:55:46 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <9938CF61-737C-43B8-B8DF-CE60793F0959@employees.org> In-Reply-To: <9938CF61-737C-43B8-B8DF-CE60793F0959@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-6to4-to-historic-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: Wed, 06 Apr 2011 08:54:08 -0000 On 2011-04-06 19:51, Ole Troan wrote: > Tore, > >>> 4. Deprecation >>> >>> This document formally deprecates the 6to4 transition mechanism and >>> the IPv6 6to4 prefix defined in [RFC3056], i.e., 2002::/16. The >>> prefix MUST NOT be reassigned for other use except by a future IETF >>> standards action. >> [...] >>> 5. IANA Considerations >>> >>> IANA is requested to mark the 2002::/16 prefix as "deprecated", >>> pointing to this document. Reassignment of the prefix for any usage >>> requires justification via an IETF Standards Action [RFC5226]. >>> >>> IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as >>> "deprecated", pointing to this document. Redelegation of the domain >>> for any usage requires justification via an IETF Standards Action >>> [RFC5226].RFC5158 >> There's no similar language deprecating the IPv4 WKP 192.88.99.0/24. Is >> that an omission? > > yes, that is an omission. I will add that. > just have to make sure to find text that doesn't encourage operators to immediately black hole 192.88.99.0/24. that would just make the situation worse. For that you can refer (non-normatively) to my draft, I think. Brian From Roman.Arcea@orange.md Wed Apr 6 01: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 7AC1B3A69B7; Wed, 6 Apr 2011 01:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVIdrXYCPyF6; Wed, 6 Apr 2011 01:54:15 -0700 (PDT) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 7CB4E3A69B4; Wed, 6 Apr 2011 01:54:15 -0700 (PDT) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id BE943C0A415; Wed, 6 Apr 2011 11:56:37 +0300 (EEST) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 9FCDDC0A3F0; Wed, 6 Apr 2011 11:56:37 +0300 (EEST) In-Reply-To: <4D9C2898.6070401@gmail.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2898.6070401@gmail.com> To: Brian E Carpenter MIME-Version: 1.0 X-KeepSent: 9DA7C604:EE45F2CC-C225786A:0030D237; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Wed, 6 Apr 2011 11:56:06 +0300 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2FP2|March 22, 2011) at 04/06/2011 11:55:59, Serialize complete at 04/06/2011 11:55:59 Content-Type: text/plain; charset="US-ASCII" Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org, Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 08:54:16 -0000 Brian E Carpenter wrote on 06-04-2011 11:47:20: > From: Brian E Carpenter > To: Roman.Arcea@orange.md > Cc: Mikael Abrahamsson , Dmitry Anipko > , "v6ops@ietf.org" , > v6ops-bounces@ietf.org > Date: 06-04-11 11:47 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question > > On 2011-04-06 20:37, Roman.Arcea@orange.md wrote: > >> No, but Microsoft can turn off (or change the behaviour of) 6to4 via a > >> patch release on all Vista and Win7 systems. But this would have to be > >> decided quickly to make it for May patch-tuesday. > > > >> I'm afraid we're too late anyway... > > > > there is already such a patch http://support.microsoft.com/kb/929852, so > > it might be a matter of decision making. > > For that I suppose IETF should agree on making 6to4 historic in the first > > place to give enough reason to vendors to turn it off during software > > updates. As an operator you can link to that from your website. > Turning it off as the default is quite common practice already in > managed enterprise networks, but that isn't the main target "market" > here - it's unmanaged SOHO hosts, and an optional patch isn't going > to help there. If by hosts you mean PCs, then it might make a lot of difference by simply adding the modification in the automatic software updates. A lot of users rely on automatic update procedures and it will make a difference. For CPEs with automatic 6to4 tunneling, this is indeed a different story. > Brian From swmike@swm.pp.se Wed Apr 6 01: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 359AA3A68E6 for ; Wed, 6 Apr 2011 01:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, 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 87UYkQKDO-TX for ; Wed, 6 Apr 2011 01:57:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 8ABC73A6849 for ; Wed, 6 Apr 2011 01:57:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 22E649C; Wed, 6 Apr 2011 10:58:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2089A9A; Wed, 6 Apr 2011 10:58:55 +0200 (CEST) Date: Wed, 6 Apr 2011 10:58:55 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4D9C2A3F.6010507@gmail.com> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 08:57:13 -0000 On Wed, 6 Apr 2011, Brian E Carpenter wrote: > It's a bit tricky to turn it off under the nose of existing users, who > may be using it quite happily. Remember that many 6to4 sessions are > completely successful. 6to4-to-historic is trying to change the default > for *future* products. For current users, it's quite unclear how to deal > with it in a way that doesn't generate millions of help-desk calls. Well, I could imagine a "recommended" patch could do this. -- Mikael Abrahamsson email: swmike@swm.pp.se From Roman.Arcea@orange.md Wed Apr 6 01:58: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 E141E3A68F2; Wed, 6 Apr 2011 01:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, 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 MWZPu27ryvbP; Wed, 6 Apr 2011 01:58:58 -0700 (PDT) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 45C673A681D; Wed, 6 Apr 2011 01:58:58 -0700 (PDT) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 860CBB18004; Wed, 6 Apr 2011 12:01:20 +0300 (EEST) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 5DA99B18003; Wed, 6 Apr 2011 12:01:20 +0300 (EEST) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> To: Mikael Abrahamsson MIME-Version: 1.0 X-KeepSent: C12BEBDB:B5C8AAF5-C225786A:0031687D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Wed, 6 Apr 2011 12:00:49 +0300 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2FP2|March 22, 2011) at 04/06/2011 12:00:42, Serialize complete at 04/06/2011 12:00:42 Content-Type: text/plain; charset="US-ASCII" Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org, Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 08:58:59 -0000 v6ops-bounces@ietf.org wrote on 06-04-2011 11:58:55: > From: Mikael Abrahamsson > To: Brian E Carpenter > Cc: "v6ops@ietf.org" , Dmitry Anipko > > Date: 06-04-11 11:59 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question > Sent by: v6ops-bounces@ietf.org > > On Wed, 6 Apr 2011, Brian E Carpenter wrote: > > > It's a bit tricky to turn it off under the nose of existing users, who > > may be using it quite happily. Remember that many 6to4 sessions are > > completely successful. 6to4-to-historic is trying to change the default > > for *future* products. For current users, it's quite unclear how to deal > > with it in a way that doesn't generate millions of help-desk calls. > > Well, I could imagine a "recommended" patch could do this. +1 And as long as this fix is nothing more than a registry change, a tech savvy user who knows what he is doing and wants to have the 6to4 back can reverse the process in no time. From brian.e.carpenter@gmail.com Wed Apr 6 02:11: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 19D313A68F9 for ; Wed, 6 Apr 2011 02:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 b9BP-0IWejTH for ; Wed, 6 Apr 2011 02:11:03 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CA3A83A68EE for ; Wed, 6 Apr 2011 02:11:02 -0700 (PDT) Received: by wwa36 with SMTP id 36so1023408wwa.13 for ; Wed, 06 Apr 2011 02:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BcL6608zVkfWuc1gPrWyjDk7QwY/3cknFr/vP2ikjKQ=; b=sIgea21THCKsXrTGg+04Ac2F/5kKwJEGqZXNklZ7NqVqiB0QAhqcG9mfokJND1R4OG 64D4BLY5AZjhYYMElmv/wF8doWK9V/+d8MlFpR7fktzIjuSaDft4IQPC1WeDGHKLu08H ktU/MbosZySXd5DoVpx/1wV1JXFUQUyOp7ZI0= 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=tbk5TvAQhurBlBf3PinCl/TDUqd0m9S9PsiRVFhLskAIicrP8zU7Lma2YEPUH04hyx mbXq7M3yvIkVKEp3Ugw/q1zmmQmGZ0K/a/XBXXU4xBvQmwM6gNHwHE5bVj0C1+XlYrBO LT2vy90097t6cGguP3y9j3zR5rKa6L6gwMkWQ= Received: by 10.216.140.219 with SMTP id e69mr534223wej.45.1302081165927; Wed, 06 Apr 2011 02:12:45 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id y12sm217652wby.42.2011.04.06.02.12.44 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 02:12:45 -0700 (PDT) Message-ID: <4D9C2E89.3000708@gmail.com> Date: Wed, 06 Apr 2011 21:12:41 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 09:11:05 -0000 On 2011-04-06 20:58, Mikael Abrahamsson wrote: > On Wed, 6 Apr 2011, Brian E Carpenter wrote: > >> It's a bit tricky to turn it off under the nose of existing users, who >> may be using it quite happily. Remember that many 6to4 sessions are >> completely successful. 6to4-to-historic is trying to change the >> default for *future* products. For current users, it's quite unclear >> how to deal with it in a way that doesn't generate millions of >> help-desk calls. > > Well, I could imagine a "recommended" patch could do this. How? In my mind the patch would have to bring up a dialogue box saying something like: Hi, this is your friendly Microsoft Connectivity wizard!! I've noticed that you are running a connectivity mechanism called 6to4. To find out more about this, please look here . Do you really want to run this mechanism? To find out if it's causing you trouble, please click here . OK, if you want to keep running it, you can just click . But if you want to disable it, please click . From swmike@swm.pp.se Wed Apr 6 02:55: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 5A7303A68E6 for ; Wed, 6 Apr 2011 02:55:58 -0700 (PDT) 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 F4GgT9EyM5Of for ; Wed, 6 Apr 2011 02:55:57 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 7C8B328C105 for ; Wed, 6 Apr 2011 02:55:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 59EAE9C; Wed, 6 Apr 2011 11:57:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5468E9A; Wed, 6 Apr 2011 11:57:39 +0200 (CEST) Date: Wed, 6 Apr 2011 11:57:39 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4D9C2E89.3000708@gmail.com> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> <4D9C2E89.3000708@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 09:55:58 -0000 On Wed, 6 Apr 2011, Brian E Carpenter wrote: > How? In my mind the patch would have to bring up a dialogue box > saying something like: No, it would just disable 6to4 (or lower the prefix preference so that IPv4 is preferred) outright. My guess is that 99% of people running 6to4 have no idea they're doing that. -- Mikael Abrahamsson email: swmike@swm.pp.se From Teemu.Kiviniemi@csc.fi Wed Apr 6 03:58: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 6D6C23A6907 for ; Wed, 6 Apr 2011 03:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7cCv8p1STxm for ; Wed, 6 Apr 2011 03:58:35 -0700 (PDT) Received: from smtp3.csc.fi (smtp3.csc.fi [193.166.7.53]) by core3.amsl.com (Postfix) with ESMTP id E5C1E3A68C8 for ; Wed, 6 Apr 2011 03:58:34 -0700 (PDT) Received: from kusti.csc.fi (kusti.csc.fi [193.166.0.100]) by smtp3.csc.fi (8.14.3/8.14.3/CSC) with ESMTP id p36B0Gpg029872 for ; Wed, 6 Apr 2011 14:00:16 +0300 Received: from [193.166.4.142] (193.166.4.142) by kusti.csc.fi (192.168.120.3) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Apr 2011 14:01:09 +0300 From: Teemu Kiviniemi To: Content-Type: text/plain Date: Wed, 6 Apr 2011 14:00:15 +0300 Message-ID: <1302087615.30282.357.camel@merihanhi.csc.fi> MIME-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=193.166.0.100; country=FI; latitude=64.0000; longitude=26.0000; http://maps.google.com/maps?q=64.0000,26.0000&z=6 X-CanItPRO-Stream: 00_Opt_Out (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 193.166.7.53 Subject: [v6ops] FYI: GN3 IPv6 Workshop presentations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 10:58:36 -0000 Hi all, On the 24th and 25th of March a GN3 IPv6 Workshop was arranged: "Networking without IPv4?" The discussed topics may be of interest also to the participants of this list. The presentation materials are available here: https://ow.feide.no/geantcampus:ipv6_mar_2011 Videos of all presentations are also available: http://tv.funet.fi/medar/showDirectory.do?directory=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6&lang=en -- Teemu From jason.weil@twcable.com Wed Apr 6 06:47: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 5E0C23A69A6 for ; Wed, 6 Apr 2011 06:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77S+v1hPcRGE for ; Wed, 6 Apr 2011 06:47:22 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id DD5163A6938 for ; Wed, 6 Apr 2011 06:47:21 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.63,310,1299474000"; d="scan'208";a="198345339" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 06 Apr 2011 09:49:42 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 6 Apr 2011 09:49:05 -0400 From: "Weil, Jason" To: Tina Tsou , "'Hemant Singh (shemant)'" , "'Templin, Fred L'" , "'Fred Baker (fred)'" Date: Wed, 6 Apr 2011 09:49:03 -0400 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoAAAvcPqAACaBUAAG47DEA== Message-ID: <34E4F50CAFA10349A41E0756550084FB049FEF81@PRVPEXVS04.corp.twcable.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> <009b01cbf3f1$4b22c970$e1685c50$@com> In-Reply-To: <009b01cbf3f1$4b22c970$e1685c50$@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 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 13:47:23 -0000 Tina, I am not able clearly parse the data to the column headings, but if it help= s the diagram below is what I was suggesting. [DS HOST]--[v4 CE ROUTER]--[v6 BIS ROUTER]-->Service Provider | [DS HOST] The issue in the topology depicted above is the IPv4-only CE (interior) ROU= TER is out of scope for the -bis draft today. The current scope covers tran= sition technologies on the WAN (6rd and DS-LITE) and a simple two router se= tup with the interior router being an IPv6 CE router. Thanks, Jason -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Tuesday, April 05, 2011 8:27 PM To: Weil, Jason; 'Hemant Singh (shemant)'; 'Templin, Fred L'; 'Fred Baker (= fred)' Cc: 'IPv6 Ops WG'; 'Tony Hain (ahain)' Subject: RE: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.= txt Hi Jason, Do you mean like this? Host [CE router] [CPE Router: LAN] [CE-Router:= WAN] Network DS IPv4-only DS IPv4-only DS IPv4-only DS IPv6-only We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Tuesday, April 05, 2011 5:15 PM To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG; Tony Hain (ahain) Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt If I recall correctly ISATAP was designed to support duals-stack hosts through IPv4-only intermediate hops. The use case that I tried hard not to ponder but is the only one I could think of here is an intermediate hop IPv4-only CE router connected between a dual-stack host and the dual-stack on LAN CPE Router. While it is possibly and maybe even likely this will happen, as Hemant alluded, the uses cases currently being considered were assuming Dual-stack home network and IPv4-only or IPv6-only WAN connection to the service provider. I would say this belongs in the 3rd Phase draft fo= r complex multi-router home networks. Thanks, Jason ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) [shemant@cisco.com] Sent: Tuesday, April 05, 2011 7:57 PM To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG; Tony Hain (ahain) Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred T., Someone else pointed out to me use of ISATAP is in the home LAN. Thus I need not compare ISATAP to WAN 6to4 transition tech. However, the use case for ISATAP is not clear in the home LAN. Let's assume the home has multiple subnets. Why can't the home use dual-stack in the LAN with private IPv4 addresses and ULA and global IPv6 addresses with routing and instead use ISATAP? Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, April 05, 2011 7:03 PM To: Templin, Fred L; Fred Baker (fred) Cc: IPv6 Ops WG Subject: Re: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Fred T., If the CE router gets a public IPv4 address the CE router goes directly to the public IPv4 Internet. If the CE router gets a "private" IPv4 address where private is RFC 1918 address space + the specific subnet defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also takes care of shared IPv4 addresses between multiple homes. Can ISATAP take care of shared IPv4 address between different homes? Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely fo= r the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may b= e unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mark@townsley.net Wed Apr 6 07:34:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E437F3A693C for ; Wed, 6 Apr 2011 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph1DV1rQonHI for ; Wed, 6 Apr 2011 07:34:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 141E63A6905 for ; Wed, 6 Apr 2011 07:34:00 -0700 (PDT) Received: by iwn39 with SMTP id 39so1883780iwn.31 for ; Wed, 06 Apr 2011 07:35:44 -0700 (PDT) Received: by 10.42.149.200 with SMTP id x8mr1741051icv.195.1302100544647; Wed, 06 Apr 2011 07:35:44 -0700 (PDT) Received: from [10.1.234.199] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id d9sm461975ibb.36.2011.04.06.07.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 07:35:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 6 Apr 2011 07:35:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <19FAA2E9-39F3-4AC2-B713-B3376BA594C4@townsley.net> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> <4D9C2E89.3000708@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 14:34:02 -0000 On Apr 6, 2011, at 2:57 AM, Mikael Abrahamsson wrote: > On Wed, 6 Apr 2011, Brian E Carpenter wrote: >=20 >> How? In my mind the patch would have to bring up a dialogue box >> saying something like: >=20 > No, it would just disable 6to4 (or lower the prefix preference so that = IPv4 is preferred) outright. My guess is that 99% of people running 6to4 = have no idea they're doing that. +1 Let's not forget there is precedence here. Did Apple receive a million = support calls when they lowered the preference of 6to4 in 10.6.5? I = doubt it. Did they throw a dialog box up at the user? No. - Mark >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Wed Apr 6 07:40: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 52B633A693C for ; Wed, 6 Apr 2011 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0XN8csvy+bI for ; Wed, 6 Apr 2011 07:40:30 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 844EF3A6905 for ; Wed, 6 Apr 2011 07:40:30 -0700 (PDT) Received: by pzk30 with SMTP id 30so713271pzk.31 for ; Wed, 06 Apr 2011 07:42:14 -0700 (PDT) Received: by 10.142.169.18 with SMTP id r18mr1018371wfe.83.1302100934085; Wed, 06 Apr 2011 07:42:14 -0700 (PDT) Received: from [10.1.234.199] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id z10sm890235wfj.3.2011.04.06.07.42.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 07:42:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 6 Apr 2011 07:42:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 14:40:31 -0000 Dmitry, I heard pretty strong consensus at the meeting last week for a comment I = made at the mic which was roughly "Do on IPv6 day what you would do if = it wasn't just one day". I also heard consensus to make 6to4 historic. = Put these together, and I would say that if your intention is to disable = or lower the preference of 6to4 by default long-term (which I sincerely = hope it is), please do so before World IPv6 Day. If we can help it, we = don't want to be testing something that isn't going to be around = long-term. - Mark On Apr 5, 2011, at 12:32 PM, Dmitry Anipko wrote: > Hi, >=20 > I have a question regarding = http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-00 and IPv6 = day.=20 >=20 > In section 4.1. among other items the draft recommends to vendors to = disable Anycast 6to4 functionality by default. If an OS vendor has an = ability to do that for existing implementations, is there a WG consensus = whether such changes should be done before the IPv6 day?=20 >=20 > I've checked the Prague WG meeting jabber logs, and I see there was a = discussion regarding the intent of IPv6 day, but I'm not sure there was = a consensus. There were arguments both for letting more things break on = IPv6 day, in order to find what breaks and fix it (e.g. programs not = using RFC 3484 sorting), as well as arguments fixing pro-actively things = which can be fixed in order for users not to encounter already known = issues. >=20 > Thanks. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Wed Apr 6 07:42: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 63E1728C0F1 for ; Wed, 6 Apr 2011 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-1.788, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RCVD_IN_PBL=0.905, 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 MAoi7IBScurD for ; Wed, 6 Apr 2011 07:42:18 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by core3.amsl.com (Postfix) with ESMTP id 56B4A28C103 for ; Wed, 6 Apr 2011 07:42:18 -0700 (PDT) Received: from [172.20.10.4] (unknown [109.33.171.113]) by mail.sintact.nl (Postfix) with ESMTP id 56DB8200E; Wed, 6 Apr 2011 16:43:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> Date: Wed, 6 Apr 2011 16:43:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 14:42:51 -0000 > I heard pretty strong consensus at the meeting last week for a comment = I made at the mic which was roughly "Do on IPv6 day what you would do if = it wasn't just one day". I also heard consensus to make 6to4 historic. = Put these together, and I would say that if your intention is to disable = or lower the preference of 6to4 by default long-term (which I sincerely = hope it is), please do so before World IPv6 Day. If we can help it, we = don't want to be testing something that isn't going to be around = long-term. +1 Thanks, Sander From fred@cisco.com Wed Apr 6 07:57: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 A5CDC28C10A for ; Wed, 6 Apr 2011 07:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 lc9qkTvogqy4 for ; Wed, 6 Apr 2011 07:57:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A384628C10E for ; Wed, 6 Apr 2011 07:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=739; q=dns/txt; s=iport; t=1302101970; x=1303311570; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=LUm+2MH4Jwm2Jc/ftZzKbeRO/PK5og1b0wpqe5RUFWY=; b=GyFjSDCXlXIMtyC4Kbgsjx1SkIE4Feo4mrQkBARSr09uzZhH0AwdCdzK eSedkhb8WDO+s+VtECwp4XUZYOU4Mdz6sBynAWGj5w+mwynuJGEhlTcP+ 7BvggfWLwjMu+hovep5JAYCvaF4v8j+lLrhDhVUoOPmp/EI4RVnvi2/rD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoEAGV/nE2Q/khMgWdsb2JhbACldhQBARYmJYh5nC+cQIVsBI08g2M X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="24677396" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 14:59:29 +0000 Received: from printer-nice-144-254-53-233.cisco.com (printer-nice-144-254-53-233.cisco.com [144.254.53.233]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36ExNf6031212; Wed, 6 Apr 2011 14:59:28 GMT Received: from [127.0.0.1] by printer-nice-144-254-53-233.cisco.com (PGP Universal service); Wed, 06 Apr 2011 16:59:27 +0200 X-PGP-Universal: processed; by printer-nice-144-254-53-233.cisco.com on Wed, 06 Apr 2011 16:59:27 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 6 Apr 2011 16:59:11 +0200 Message-Id: References: To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-tunnel-loops 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: Wed, 06 Apr 2011 14:57:46 -0000 On Mar 31, 2011, at 11:30 AM, Fred Baker wrote: > This is to initiate a one week working group last call of = draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The = IESG reviewed the document and asked for changes; we need to be sure we = are comfortable with the changes. The diff from the version sent to the = IESG last November is at http://tinyurl.com/6dhowhf >=20 > 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. WGLC closing Sunday. Any comments on the draft?= From cb.list6@gmail.com Wed Apr 6 08: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 9124A28C10A for ; Wed, 6 Apr 2011 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 X45UoBtrIpMd for ; Wed, 6 Apr 2011 08:31:48 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 64C6E28B23E for ; Wed, 6 Apr 2011 08:31:48 -0700 (PDT) Received: by eye13 with SMTP id 13so582961eye.31 for ; Wed, 06 Apr 2011 08:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/k3W7kIeiGmtdFc1LqF1aNgNb7SiUFqcqSZtc63KcpA=; b=vXrYXKr4zOGgqUf/jPQirDAXbadJnANal6YxN04I3znf30JWkJf99XwGEbwpmfeduu 4A86AfPHsmpix0HjPlCfrNfcGyFTXfPcvdYv/yuchfqsftOx0YVRSbnN3MALvvu47b4a IfU+LMT3Atx4JnHH4Zyhfog2Cg0zAm0rW+Zqk= 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=QAJ1M9a3Jr0okkJB6wgCbRKzy18uyYhU7zG/wJ70i6rIJnoQgxXI698MNbiQwzfvnC uWRAKRYlGUt32B+lq0aFnoWzPaL7lkef1xX2vdp7LohmCLYRSl+i6n7ngGlrAlsIyXqA 9VmFfxKtjvD4uaFaaVJq8CCZg3JiIJgL6f51g= MIME-Version: 1.0 Received: by 10.213.2.78 with SMTP id 14mr365552ebi.6.1302104011538; Wed, 06 Apr 2011 08:33:31 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Wed, 6 Apr 2011 08:33:31 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Wed, 6 Apr 2011 08:33:31 -0700 (PDT) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> Date: Wed, 6 Apr 2011 08:33:31 -0700 Message-ID: From: Cameron Byrne To: Sander Steffann Content-Type: multipart/alternative; boundary=0015173ff83611831304a041b782 Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 15:31:49 -0000 --0015173ff83611831304a041b782 Content-Type: text/plain; charset=ISO-8859-1 On Apr 6, 2011 7:44 AM, "Sander Steffann" wrote: > > > I heard pretty strong consensus at the meeting last week for a comment I made at the mic which was roughly "Do on IPv6 day what you would do if it wasn't just one day". I also heard consensus to make 6to4 historic. Put these together, and I would say that if your intention is to disable or lower the preference of 6to4 by default long-term (which I sincerely hope it is), please do so before World IPv6 Day. If we can help it, we don't want to be testing something that isn't going to be around long-term. > > +1 > +1. 6to4 is a know challenge that should not be on or preferred by default. There is no value in extending the pain to new heights. Cb > Thanks, > Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0015173ff83611831304a041b782 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 6, 2011 7:44 AM, "Sander Steffann" <sander@steffann.nl> wrote:
>
> > I heard pretty strong consensus at the meeting last week for a co= mment I made at the mic which was roughly "Do on IPv6 day what you wou= ld do if it wasn't just one day". I also heard consensus to make 6= to4 historic. Put these together, and I would say that if your intention is= to disable or lower the preference of 6to4 by default long-term (which I s= incerely hope it is), please do so before World IPv6 Day. If we can help it= , we don't want to be testing something that isn't going to be arou= nd long-term.
>
> +1
>

+1. 6to4 is a know challenge that should not be on or preferred by defau= lt. There is no value in extending the pain to new heights.

Cb

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

--0015173ff83611831304a041b782-- From Guillaume.Leclanche@swisscom.com Wed Apr 6 08:49: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 6366F3A6874 for ; Wed, 6 Apr 2011 08:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp+3xja4XOn8 for ; Wed, 6 Apr 2011 08:49:44 -0700 (PDT) Received: from mail.swisscom.com (outmail100.swisscom.com [193.222.81.100]) by core3.amsl.com (Postfix) with ESMTP id 686863A6819 for ; Wed, 6 Apr 2011 08:49:42 -0700 (PDT) Received: by intmail1.corproot.net; Wed, 6 Apr 2011 17:51:25 +0200 From: To: , Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AQHL88hyZ+96861RJEOuDjqya2hX1JRQyIYAgAAAfgCAADEVQA== Date: Wed, 6 Apr 2011 15:51:24 +0000 Message-ID: <1BE5D090C6244A49B9815F339F76EA4507AD615C@SG000708.corproot.net> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> In-Reply-To: Accept-Language: fr-CH, de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.222.84.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org, Dmitry.Anipko@microsoft.com Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 15:49:45 -0000 > > I heard pretty strong consensus at the meeting last week for a > comment I made at the mic which was roughly "Do on IPv6 day what you > would do if it wasn't just one day". I also heard consensus to make > 6to4 historic. Put these together, and I would say that if your > intention is to disable or lower the preference of 6to4 by default > long-term (which I sincerely hope it is), please do so before World > IPv6 Day. If we can help it, we don't want to be testing something that > isn't going to be around long-term. >=20 > +1 +1 as well I believe that nobody does need 6to4 right now, nor in the next few months = (although it could be argued due to APNIC exhaustion, but it would be specu= lation, and we know that native v6, not 6to4, is the solution there). Furthermore there's consensus regarding the fact that it's breaking connect= ivity and makes things worse, so why wait? By the way, probably a stupid idea : would Operating Systems understand and= disable 6to4 if ISPs were sending back "host unreachable" for the 6to4 IPv= 4 address ? Guillaume From Fred.L.Templin@boeing.com Wed Apr 6 08:52: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 912463A6874 for ; Wed, 6 Apr 2011 08:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 oxwAf3qINgge for ; Wed, 6 Apr 2011 08:52:38 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id DDF823A6819 for ; Wed, 6 Apr 2011 08:52:38 -0700 (PDT) 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 p36FsME7018861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 08:54:22 -0700 (PDT) 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 p36FsMki000715; Wed, 6 Apr 2011 08:54:22 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p36FsLOc000697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 08:54:21 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 6 Apr 2011 08:54:21 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 08:54:19 -0700 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAI2nQgA== Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco. c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.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 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 15:52:39 -0000 Hi Hemant, The particular use case for ISATAP I am describing is for within the home, i.e., the ISATAP-tunneled packets do not leak out and interact with other homes. In that case, it does not matter whether home A numbers its internal interfaces and links with the same IPv4 addresses that are internal to home B - the two are treated as separate and non-intersecting ISATAP links. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: Tuesday, April 05, 2011 4:03 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: RE: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred T., >=20 > If the CE router gets a public IPv4 address the CE router=20 > goes directly > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > address where private is RFC 1918 address space + the specific subnet > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > takes care > of shared IPv4 addresses between multiple homes. Can ISATAP take care > of shared IPv4 address between different homes?=20 >=20 > Hemant >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Tuesday, April 05, 2011 6:49 PM > To: Fred Baker (fred) > Cc: Hemant Singh (shemant); IPv6 Ops WG > Subject: RE: [v6ops] > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Fred,=20 >=20 > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com]=20 > > Sent: Tuesday, April 05, 2011 3:30 PM > > To: Templin, Fred L > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > Subject: Re: [v6ops]=20 > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > > network? >=20 > Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 > seems to acknowledge the existence of current IPv4 End-user > networks, and that: "It is not expected that an end-user > will change their existing network topology with the > introduction of IPv6". >=20 > It seems therefore that there will be a class of end > user networks that would benefit from an intra-site > IPv6/IPv4 transition technology. >=20 > > What would ISATAP do in a native IPv6 network? >=20 > The host would prefer native IPv6 over ISATAP. But, > not all home/soho networks are set up for native IPv6. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > = From Fred.L.Templin@boeing.com Wed Apr 6 09:10: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 4F36F3A68EC for ; Wed, 6 Apr 2011 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 3Ftn3isBvyir for ; Wed, 6 Apr 2011 09:10:44 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 7955F3A69CC for ; Wed, 6 Apr 2011 09:10:44 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p36GCChh028901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 09:12:12 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p36GCBhS002874; Wed, 6 Apr 2011 09:12:11 -0700 (PDT) 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 p36GCAuP002787 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 09:12:10 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 6 Apr 2011 09:12:10 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 09:12:09 -0700 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoAAiX4lg Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om>< 5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9F E2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9- DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.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 Ops WG , "Tony Hain \(ahain\)" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 16:10:45 -0000 Hi Hemant, I don't think we should assume anything about how the home/soho network is configured internally. Customers will want to drop a new CPE router in-place and expect that hosts within their network will magically start to use IPv6. If the home/soho network has lots of IPv4 links and routers, the only way that can happen is if the CPE router implements the ISATAP router function. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: Tuesday, April 05, 2011 4:58 PM > To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG; Tony Hain (ahain) > Subject: RE:=20 > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred T., >=20 > Someone else pointed out to me use of ISATAP is in the home=20 > LAN. Thus I > need not compare ISATAP to WAN 6to4 transition tech. =20 > However, the use > case for ISATAP is not clear in the home LAN. Let's assume=20 > the home has > multiple subnets. Why can't the home use dual-stack in the LAN with > private IPv4 addresses and ULA and global IPv6 addresses with routing > and instead use ISATAP? >=20 > Thanks, >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Hemant Singh (shemant) > Sent: Tuesday, April 05, 2011 7:03 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: Re: > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred T., >=20 > If the CE router gets a public IPv4 address the CE router=20 > goes directly > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > address where private is RFC 1918 address space + the specific subnet > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > takes care > of shared IPv4 addresses between multiple homes. Can ISATAP take care > of shared IPv4 address between different homes?=20 >=20 > Hemant >=20 > = From Fred.L.Templin@boeing.com Wed Apr 6 09:17: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 099063A6957 for ; Wed, 6 Apr 2011 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.047 X-Spam-Level: X-Spam-Status: No, score=-6.047 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 4m4DuvBsPUPW for ; Wed, 6 Apr 2011 09:17:27 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0BFCA3A67CF for ; Wed, 6 Apr 2011 09:17:26 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p36GJ9qk003630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 09:19:10 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p36GJ9ro022272; Wed, 6 Apr 2011 09:19:09 -0700 (PDT) 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 p36GJ952022266 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 09:19:09 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 6 Apr 2011 09:19:09 -0700 From: "Templin, Fred L" To: "Weil, Jason" , "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 09:19:08 -0700 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoAAAvcPqACHeDfA= Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om>< 5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9F E2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9- DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109. cisco.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG , "Tony Hain \(ahain\)" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 16:17:28 -0000 Hi Jason, I'm not sure I understand that. We have no idea what varieties of topologies are set up in home/soho networks today, however it seems reasonable to assume that many have lots of IPv4 links and routers internally. That class of network would like to see IPv6 automatically turned on when their new CPE router is dropped in place the same as for simple home/soho networks with trivial internal topologies. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Weil, Jason [mailto:jason.weil@twcable.com]=20 > Sent: Tuesday, April 05, 2011 5:15 PM > To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG; Tony Hain (ahain) > Subject: RE:=20 > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 >=20 > If I recall correctly ISATAP was designed to support=20 > duals-stack hosts through IPv4-only intermediate hops. The=20 > use case that I tried hard not to ponder but is the only one=20 > I could think of here is an intermediate hop IPv4-only CE=20 > router connected between a dual-stack host and the dual-stack=20 > on LAN CPE Router. While it is possibly and maybe even likely=20 > this will happen, as Hemant alluded, the uses cases currently=20 > being considered were assuming Dual-stack home network and=20 > IPv4-only or IPv6-only WAN connection to the service=20 > provider. I would say this belongs in the 3rd Phase draft for=20 > complex multi-router home networks. >=20 > Thanks, >=20 > Jason > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On=20 > Behalf Of Hemant Singh (shemant) [shemant@cisco.com] > Sent: Tuesday, April 05, 2011 7:57 PM > To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG; Tony Hain (ahain) > Subject: Re: [v6ops] =20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred T., >=20 > Someone else pointed out to me use of ISATAP is in the home=20 > LAN. Thus I > need not compare ISATAP to WAN 6to4 transition tech. =20 > However, the use > case for ISATAP is not clear in the home LAN. Let's assume=20 > the home has > multiple subnets. Why can't the home use dual-stack in the LAN with > private IPv4 addresses and ULA and global IPv6 addresses with routing > and instead use ISATAP? >=20 > Thanks, >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Hemant Singh (shemant) > Sent: Tuesday, April 05, 2011 7:03 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: Re: > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred T., >=20 > If the CE router gets a public IPv4 address the CE router=20 > goes directly > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > address where private is RFC 1918 address space + the specific subnet > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > takes care > of shared IPv4 addresses between multiple homes. Can ISATAP take care > of shared IPv4 address between different homes? >=20 > Hemant >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time=20 > Warner Cable proprietary information, which is privileged,=20 > confidential, or subject to copyright belonging to Time=20 > Warner Cable. This E-mail is intended solely for the use of=20 > the individual or entity to which it is addressed. If you are=20 > not the intended recipient of this E-mail, you are hereby=20 > notified that any dissemination, distribution, copying, or=20 > action taken in relation to the contents of and attachments=20 > to this E-mail is strictly prohibited and may be unlawful. If=20 > you have received this E-mail in error, please notify the=20 > sender immediately and permanently delete the original and=20 > any copy of this E-mail and any printout. > = From jhw@apple.com Wed Apr 6 10:10: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 8F78628C0D6 for ; Wed, 6 Apr 2011 10:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 EuCsjT+n5myS for ; Wed, 6 Apr 2011 10:10:15 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id 7CC5A3A68AB for ; Wed, 6 Apr 2011 10:10:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ8006M3QFTFJK0@localhost.apple.com> for v6ops@ietf.org; Wed, 06 Apr 2011 10:11:57 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-0b-4d9c9edd36b2 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id 3E.83.29082.DDE9C9D4; Wed, 06 Apr 2011 10:11:57 -0700 (PDT) Received: from [17.193.13.64] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ8008NBQFWU860@elliott.apple.com> for v6ops@ietf.org; Wed, 06 Apr 2011 10:11:56 -0700 (PDT) From: james woodyatt In-reply-to: <19FAA2E9-39F3-4AC2-B713-B3376BA594C4@townsley.net> Date: Wed, 06 Apr 2011 10:11:56 -0700 Message-id: <4C53DD1A-59C1-46BD-9645-C715BE46BCE3@apple.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> <4D9C2E89.3000708@gmail.com> <19FAA2E9-39F3-4AC2-B713-B3376BA594C4@townsley.net> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 17:10:16 -0000 On Apr 6, 2011, at 07:35 , Mark Townsley wrote: > > Did Apple receive a million support calls when they lowered the preference of 6to4 in 10.6.5? No, but Apple *was* criticized in the press for it, and I remember wasting valuable time explaining to alarmed managers how Apple did not actually "fix broken IPv6 by breaking it some more" despite popular reports to the contrary. -- james woodyatt member of technical staff, core os networking From Dmitry.Anipko@microsoft.com Wed Apr 6 11:09: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 BFBE928C102 for ; Wed, 6 Apr 2011 11:09:25 -0700 (PDT) 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 xoZtET2zkmqh for ; Wed, 6 Apr 2011 11:09:24 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D251928C0D6 for ; Wed, 6 Apr 2011 11:09:24 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 11:11:08 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 11:11:08 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Wed, 6 Apr 2011 11:09:15 -0700 From: Dmitry Anipko To: "Templin, Fred L" , "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 11:09:14 -0700 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAI2nQgAAEIIcg Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco. c om> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.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 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 18:09:25 -0000 Hi Fred, Do I understand correctly that draft-ietf-v6ops-ipv6-cpe-router-bis-00 does= n't preclude a deployment where the CE router would hand out public IPv4 ad= dresses on the LAN? I could not find a statement of the opposite in the dra= ft, please let me know if I missed it. If such deployments are in scope for draft-ietf-v6ops-ipv6-cpe-router-bis-0= 0, then if CE routers with ISATAP support enable automatically ISATAP for s= uch hosts with public IPv4 addresses, will such hosts be on single IPv6 vir= tual link?=20 Thanks, Dmitry -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= emplin, Fred L Sent: Wednesday, April 06, 2011 8:54 AM To: Hemant Singh (shemant); Fred Baker (fred) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.= txt Hi Hemant, The particular use case for ISATAP I am describing is for within the home, i.e., the ISATAP-tunneled packets do not leak out and interact with other homes. In that case, it does not matter whether home A numbers its internal interfaces and links with the same IPv4 addresses that are internal to home B - the two are treated as separate and non-intersecting ISATAP links. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: Tuesday, April 05, 2011 4:03 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: RE: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred T., >=20 > If the CE router gets a public IPv4 address the CE router=20 > goes directly > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > address where private is RFC 1918 address space + the specific subnet > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > takes care > of shared IPv4 addresses between multiple homes. Can ISATAP take care > of shared IPv4 address between different homes?=20 >=20 > Hemant >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Tuesday, April 05, 2011 6:49 PM > To: Fred Baker (fred) > Cc: Hemant Singh (shemant); IPv6 Ops WG > Subject: RE: [v6ops] > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Fred,=20 >=20 > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com]=20 > > Sent: Tuesday, April 05, 2011 3:30 PM > > To: Templin, Fred L > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > Subject: Re: [v6ops]=20 > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > > network? >=20 > Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 > seems to acknowledge the existence of current IPv4 End-user > networks, and that: "It is not expected that an end-user > will change their existing network topology with the > introduction of IPv6". >=20 > It seems therefore that there will be a class of end > user networks that would benefit from an intra-site > IPv6/IPv4 transition technology. >=20 > > What would ISATAP do in a native IPv6 network? >=20 > The host would prefer native IPv6 over ISATAP. But, > not all home/soho networks are set up for native IPv6. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Dmitry.Anipko@microsoft.com Wed Apr 6 11:18: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 8181228C119 for ; Wed, 6 Apr 2011 11:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 sIyQcQvJizGO for ; Wed, 6 Apr 2011 11:18:06 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A500728C0D6 for ; Wed, 6 Apr 2011 11:18:06 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 11:19:48 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 11:19:48 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Wed, 6 Apr 2011 11:19:47 -0700 From: Dmitry Anipko To: Cameron Byrne , Sander Steffann Date: Wed, 6 Apr 2011 11:19:46 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: Acv0cAAfa+K7YmFvT1G0HM38Vb2ljgAFtIWQ Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E003DNAEXMSGS702_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 18:18:07 -0000 --_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E003DNAEXMSGS702_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you all for your responses, they answered my question. Best regards, Dmitry From: Cameron Byrne [mailto:cb.list6@gmail.com] Sent: Wednesday, April 06, 2011 8:34 AM To: Sander Steffann Cc: Dmitry Anipko; Mark Townsley; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n On Apr 6, 2011 7:44 AM, "Sander Steffann" > wrote: > > > I heard pretty strong consensus at the meeting last week for a comment = I made at the mic which was roughly "Do on IPv6 day what you would do if it= wasn't just one day". I also heard consensus to make 6to4 historic. Put th= ese together, and I would say that if your intention is to disable or lower= the preference of 6to4 by default long-term (which I sincerely hope it is)= , please do so before World IPv6 Day. If we can help it, we don't want to b= e testing something that isn't going to be around long-term. > > +1 > +1. 6to4 is a know challenge that should not be on or preferred by default.= There is no value in extending the pain to new heights. Cb > Thanks, > Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E003DNAEXMSGS702_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you all for your responses, they answered my question.=

 

Best regards,

Dmitry

 

From: Cameron Byrne [mailto:cb.list6@gmail.com]
Sent: Wednesday, April 06, 2011 8:34 AM
To: Sander Steffann
Cc: Dmitry Anipko; Mark Townsley; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

 


On Apr 6, 2011 7:44 AM, "Sander Steffann" <sander@steffann.nl> wrote:
>
> > I heard pretty strong consensus at the meeting last week for a comment I made at the mic which was roughly "Do on IPv6 day what you w= ould do if it wasn't just one day". I also heard consensus to make 6to4 historic. Put these together, and I would say that if your intention is to disable or lower the preference of 6to4 by default long-term (which I since= rely hope it is), please do so before World IPv6 Day. If we can help it, we don'= t want to be testing something that isn't going to be around long-term.
>
> +1
>

+1. 6to4 is a know challenge that should not be on or preferred by defau= lt. There is no value in extending the pain to new heights.

Cb

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

--_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E003DNAEXMSGS702_-- From brian.e.carpenter@gmail.com Wed Apr 6 11:26: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 ECE3728C117 for ; Wed, 6 Apr 2011 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 VO4NdT9MIRPD for ; Wed, 6 Apr 2011 11:26:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A002128C114 for ; Wed, 6 Apr 2011 11:26:37 -0700 (PDT) Received: by wwa36 with SMTP id 36so1487373wwa.13 for ; Wed, 06 Apr 2011 11:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2HnMsQI92H9KydRKfdYTav/fHcOgp4slEADATbJNx3c=; b=fiPa5v+4tNr2sfkULygy9Udl24w6AuQ0XF35T/458ya+i2IQV/nTTs4EgJF1EjOHnk JI+KcQ3okyCKgjHXqibL/XUNZRsv63v99cBcif7tYG/RRB2ypgR+53xqnVbkc1QGtJuu PcblZ0e5JzyBO8xHZrdhftSUkZuPT5bdT474s= 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=mjTTtvhklWLbhjViUCFDmtHXYDZfPGoMvd96CCMibW7PVstYYgvcIS3rMb91Lmu+Qk M+3oHTOz67la19rw2IenSkX8A0zBV+ixfsGktPWvvyAAdUBGHCspiwlNhVIpmgCxlMwP C02W08QJK/+/+Q6qraFcpNa88U2hEJ3WeQxXI= Received: by 10.227.182.67 with SMTP id cb3mr1422871wbb.141.1302114500965; Wed, 06 Apr 2011 11:28:20 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id o6sm544252wbo.54.2011.04.06.11.28.19 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:28:20 -0700 (PDT) Message-ID: <4D9CB0C0.4000300@gmail.com> Date: Thu, 07 Apr 2011 06:28:16 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> <20110406055918.74A8BDDD8AB@drugs.dv.isc.org> <4D9C0E00.10303@gmail.com> <4D9C1430.8060900@gmail.com> <4D9C2A3F.6010507@gmail.com> <4D9C2E89.3000708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 18:26:40 -0000 On 2011-04-06 21:57, Mikael Abrahamsson wrote: > On Wed, 6 Apr 2011, Brian E Carpenter wrote: > >> How? In my mind the patch would have to bring up a dialogue box >> saying something like: > > No, it would just disable 6to4 (or lower the prefix preference so that > IPv4 is preferred) outright. My guess is that 99% of people running 6to4 > have no idea they're doing that. Well, we just don't know and disabling running code silently is not something I could support. Brian From brian.e.carpenter@gmail.com Wed Apr 6 11:29: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 5280728C104 for ; Wed, 6 Apr 2011 11:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 psHI6iHEr1x7 for ; Wed, 6 Apr 2011 11:29:07 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6AF043A690A for ; Wed, 6 Apr 2011 11:29:07 -0700 (PDT) Received: by wyb29 with SMTP id 29so1723533wyb.31 for ; Wed, 06 Apr 2011 11:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z/LyGMsNKOaPjgD2X6ouyLqXkPD65/UeFU5tHzxq000=; b=xc7pjqU1QF7l1oAP8o69isx2G2R2xwsB5r3I2GkRpwnC4AjPByFgmQ4IOjsbJwxZvH zK6PmxeRvHODUbHHE2rbTwkYHIkNwcrIbCtx2gjo3gvIRMeOfCyYPxHBlcIbwRcbgZ7E 3SmUFVnmVcbAII2V1k+FIli0CI+wExXqik/9s= 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=srHZOxMaFPsEgyO1x3K/srfZP6n/7UFkj1pfiXAS5RneunYtCpPfzRZ++Aii6PhS6n fRMdcU7eerr0I7D16IprY3iLEXfcFq4qze0mtqwhFiPtY1SDTFKWKBVhHqnEKWcQibh1 n5ByEGeFj0N9tKICALJO8ReMYKuaiSuBMBDHw= Received: by 10.227.1.102 with SMTP id 38mr1383014wbe.109.1302114650890; Wed, 06 Apr 2011 11:30:50 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id h11sm549014wbc.9.2011.04.06.11.30.49 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:30:49 -0700 (PDT) Message-ID: <4D9CB156.308@gmail.com> Date: Thu, 07 Apr 2011 06:30:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 18:29:08 -0000 On 2011-04-07 03:33, Cameron Byrne wrote: > On Apr 6, 2011 7:44 AM, "Sander Steffann" wrote: >>> I heard pretty strong consensus at the meeting last week for a comment I > made at the mic which was roughly "Do on IPv6 day what you would do if it > wasn't just one day". I also heard consensus to make 6to4 historic. Put > these together, and I would say that if your intention is to disable or > lower the preference of 6to4 by default long-term (which I sincerely hope it > is), please do so before World IPv6 Day. If we can help it, we don't want to > be testing something that isn't going to be around long-term. >> +1 >> > > +1. 6to4 is a know challenge that should not be on or preferred by default. > There is no value in extending the pain to new heights. That isn't the point. The point is the millions (literally) of systems out there that *will* be running 6to4 by default for, very likely, years to come. Brian From swmike@swm.pp.se Wed Apr 6 11: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 C50113A68B9 for ; Wed, 6 Apr 2011 11:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, 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 lxSiwMui-vaX for ; Wed, 6 Apr 2011 11:32:15 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 1164B28C101 for ; Wed, 6 Apr 2011 11:32:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EF00E9C; Wed, 6 Apr 2011 20:33:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EBB3C9A; Wed, 6 Apr 2011 20:33:57 +0200 (CEST) Date: Wed, 6 Apr 2011 20:33:57 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4D9CB156.308@gmail.com> Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 18:32:19 -0000 On Thu, 7 Apr 2011, Brian E Carpenter wrote: > That isn't the point. The point is the millions (literally) of systems > out there that *will* be running 6to4 by default for, very likely, years > to come. Absolutely, but many tens of millions of systems can be fixed by vendor patch. So again, there is little ISPs can do to mitigate the problem (at least if it's not at their end), so let's at least try to make end system behaviour change where we can and try to inform the rest. The solution should be to turn off tunneling we know is bad, otherwise the "solution" will be to turn off IPv6 totally, and then those systems will be stuck in IPv4only-land for a long-time. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Wed Apr 6 11:37: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 41A7A28C0FE for ; Wed, 6 Apr 2011 11:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 pY0F0uBqqzAN for ; Wed, 6 Apr 2011 11:37:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3A43728C0DE for ; Wed, 6 Apr 2011 11:37:16 -0700 (PDT) Received: by wyb29 with SMTP id 29so1730127wyb.31 for ; Wed, 06 Apr 2011 11:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZniPNJMUvknHJBk5nhqrWYlXiIAEiNqAqDEhNz7WtBg=; b=H5kLPWZUiCkwwlXNmyNgFcEQ5oEE2Mem8dvPU9bxblj4AcLDrBgSISy81D+KU3p2aE JE+cx1WkvVhSxRDORPoI1GFhmcgz36y7Ctqq+aCBnseaabbnmB8tJH5R7VHF8lvX9xK0 mKGeofECxAXPwmdv+f5BlUH4qssBPVrTWQWXs= 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=Z1+qc4PXKzDdbjzZjp6/biSMmu554c+nIZbU2fGsajcOOqZxBDYk2Rrd4C/5qjH8Y8 DsVEHhY9wBOaAPp8wuV0Gn4jJ4HYxPQu5fX/XY+c56WZe1yNs0iB5OZzNCVn3LGufsKB BzJMDrYPzaW/j3Bt26ICtbyRI5jjeGvJcvFPA= Received: by 10.227.20.13 with SMTP id d13mr1422486wbb.133.1302115139765; Wed, 06 Apr 2011 11:38:59 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id x1sm551964wbh.19.2011.04.06.11.38.58 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:38:59 -0700 (PDT) Message-ID: <4D9CB33F.3050609@gmail.com> Date: Thu, 07 Apr 2011 06:38:55 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 18:37:17 -0000 On 2011-04-07 06:33, Mikael Abrahamsson wrote: > On Thu, 7 Apr 2011, Brian E Carpenter wrote: > >> That isn't the point. The point is the millions (literally) of systems >> out there that *will* be running 6to4 by default for, very likely, >> years to come. > > Absolutely, but many tens of millions of systems can be fixed by vendor > patch. > > So again, there is little ISPs can do to mitigate the problem (at least > if it's not at their end), so let's at least try to make end system > behaviour change where we can and try to inform the rest. > > The solution should be to turn off tunneling we know is bad, otherwise > the "solution" will be to turn off IPv6 totally, and then those systems > will be stuck in IPv4only-land for a long-time. I would still like it to be a choice, not a patch that arbitrarily changes system behaviour, but in any case is not in the IETF's hands. The 6to4-to-historic draft is pretty clear on the recommended behaviour. Brian From Fred.L.Templin@boeing.com Wed Apr 6 11:42: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 8340528B23E for ; Wed, 6 Apr 2011 11:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 9ASWeFEEu+Sy for ; Wed, 6 Apr 2011 11:42:40 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id C0AB43A6957 for ; Wed, 6 Apr 2011 11:42:39 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p36IiKM7019296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 11:44:21 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p36IiKln020286; Wed, 6 Apr 2011 13:44:20 -0500 (CDT) 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 p36IiIlt020227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 13:44:19 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 6 Apr 2011 11:44:19 -0700 From: "Templin, Fred L" To: Dmitry Anipko , "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 11:44:18 -0700 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAI2nQgAAEIIcgAAEDpxA= Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco. com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B6 4C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A 1D9-DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD- 109.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 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 18:42:42 -0000 Hi Dmitry,=20 > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com]=20 > Sent: Wednesday, April 06, 2011 11:09 AM > To: Templin, Fred L; Hemant Singh (shemant); Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: RE:=20 > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Fred, >=20 > Do I understand correctly that=20 > draft-ietf-v6ops-ipv6-cpe-router-bis-00 doesn't preclude a=20 > deployment where the CE router would hand out public IPv4=20 > addresses on the LAN? I could not find a statement of the=20 > opposite in the draft, please let me know if I missed it. I don't see a problem if the CE router hands out public IPv4 addresses on the LAN, and I can't see a reason for the draft to preclude that. > If such deployments are in scope for=20 > draft-ietf-v6ops-ipv6-cpe-router-bis-00, I don't see why they would not be in-scope. > then if CE routers=20 > with ISATAP support enable automatically ISATAP for such=20 > hosts with public IPv4 addresses, will such hosts be on=20 > single IPv6 virtual link? There are actually two questions wrapped up in this, being: 1) Will the CE router automatically enable ISATAP for hosts with public IPv4 addresses? 2) If so, will such hosts be on a single IPv6 virtual link? As to 1), it is a question of fact as to whether the CE router would enable ISATAP or simply leave the hosts to their own devices do host-based 6to4. Personally, I think the CE router could play it both ways, i.e., allow host-based 6to4 hosts to do their own thing while also providing ISATAP managed services to those hosts that prefer to use ISATAP. As to 2), the hosts within the home/soho network would logicially be on a single IPv6 virtual link (along with all other hosts wordlwide that enable ISATAP using public IPv4 addresses), but the CE router should institute filtering so that only those hosts within the same home/soho network get to see each other as neighbors on the link. The home/soho network then becomes a logical partition on the global IPv6 virtual link, and is connected to other partitions and the rest of the IPv6 Internet via IPv6 routing (beginning with the CE router as the default router for the partition). A question for you: do Microsoft hosts prefer to use host-based 6to4 or ISATAP? Based on these numerous discussion threads on the list right now, it seems like they would be better off doing ISATAP when it is available, right? Thanks - Fred fred.l.templin@boeing.com > Thanks, > Dmitry >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Templin, Fred L > Sent: Wednesday, April 06, 2011 8:54 AM > To: Hemant Singh (shemant); Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: Re: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Hemant, >=20 > The particular use case for ISATAP I am describing is > for within the home, i.e., the ISATAP-tunneled packets > do not leak out and interact with other homes. In that > case, it does not matter whether home A numbers its > internal interfaces and links with the same IPv4 > addresses that are internal to home B - the two are > treated as separate and non-intersecting ISATAP links. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > > Sent: Tuesday, April 05, 2011 4:03 PM > > To: Templin, Fred L; Fred Baker (fred) > > Cc: IPv6 Ops WG > > Subject: RE: [v6ops]=20 > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Fred T., > >=20 > > If the CE router gets a public IPv4 address the CE router=20 > > goes directly > > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > > address where private is RFC 1918 address space + the=20 > specific subnet > > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > > takes care > > of shared IPv4 addresses between multiple homes. Can=20 > ISATAP take care > > of shared IPv4 address between different homes?=20 > >=20 > > Hemant > >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > > Sent: Tuesday, April 05, 2011 6:49 PM > > To: Fred Baker (fred) > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > Subject: RE: [v6ops] > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Hi Fred,=20 > >=20 > > > -----Original Message----- > > > From: Fred Baker [mailto:fred@cisco.com]=20 > > > Sent: Tuesday, April 05, 2011 3:30 PM > > > To: Templin, Fred L > > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > > Subject: Re: [v6ops]=20 > > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > >=20 > > > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > > > network? > >=20 > > Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 > > seems to acknowledge the existence of current IPv4 End-user > > networks, and that: "It is not expected that an end-user > > will change their existing network topology with the > > introduction of IPv6". > >=20 > > It seems therefore that there will be a class of end > > user networks that would benefit from an intra-site > > IPv6/IPv4 transition technology. > >=20 > > > What would ISATAP do in a native IPv6 network? > >=20 > > The host would prefer native IPv6 over ISATAP. But, > > not all home/soho networks are set up for native IPv6. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = From Christopher.Palmer@microsoft.com Wed Apr 6 12:04: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 4FC083A68B9 for ; Wed, 6 Apr 2011 12:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[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 hUvGyTb9OBNi for ; Wed, 6 Apr 2011 12:04:33 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3686C3A67B6 for ; Wed, 6 Apr 2011 12:04:33 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 12:06:16 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 12:06:17 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 12:06:16 -0700 From: Christopher Palmer To: Cameron Byrne , Sander Steffann Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AQHL88hvpgRk+wlPLkatpLmbV9eqIJRRX2YAgAAAfgCAAA3bgP//v0jQ Date: Wed, 6 Apr 2011 19:06:15 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_0AB09EDBCD1C484EBE45978D62F3513C3CD899D4TK5EX14MBXW601w_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 19:04:38 -0000 --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD899D4TK5EX14MBXW601w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From the perspective of Windows... Isn't it fair to say: 6to4 is enabled by default on Windows Vista and Windows 7 Windows Vista and Windows 7 implement RFC 3484 Thus, the only sources of "brokenness" - scoped to Windows: Applications that sort addresses correctly (by not followin= g Windows guidance) Hosts that are behind Windows when it has been configured w= ith Internet Connection Sharing, and do not have RFC 3484. (we know about the ICS and 6to4 bugs that e= xacerbate this issue) Are there other categories of brokenness from an experience perspective? Ma= jor applications that are broken? ---------------------------- Christopher.Palmer@Microsoft.com Program Manager IPv6 @ Windows From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of C= ameron Byrne Sent: Wednesday, April 06, 2011 8:34 AM To: Sander Steffann Cc: v6ops@ietf.org; Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n On Apr 6, 2011 7:44 AM, "Sander Steffann" > wrote: > > > I heard pretty strong consensus at the meeting last week for a comment = I made at the mic which was roughly "Do on IPv6 day what you would do if it= wasn't just one day". I also heard consensus to make 6to4 historic. Put th= ese together, and I would say that if your intention is to disable or lower= the preference of 6to4 by default long-term (which I sincerely hope it is)= , please do so before World IPv6 Day. If we can help it, we don't want to b= e testing something that isn't going to be around long-term. > > +1 > +1. 6to4 is a know challenge that should not be on or preferred by default.= There is no value in extending the pain to new heights. Cb > Thanks, > Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD899D4TK5EX14MBXW601w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From the perspective of Windows…<= o:p>

 

Isn’t it fair to say:<= /span>

      &nb= sp;         6to4 is enabled by defa= ult on Windows Vista and Windows 7

      &nb= sp;         Windows Vista and Windo= ws 7 implement RFC 3484

      &nb= sp;        

Thus, the only sources of “broken= ness” – scoped to Windows:

      &nb= sp;         Applications that sort = addresses correctly (by not following Windows guidance)

      &nb= sp;         Hosts that are behind W= indows when it has been configured with Internet Connection Sharing, and do= not have RFC 3484.

      &nb= sp;             = ;            (we kno= w about the ICS and 6to4 bugs that exacerbate this issue)=

 

Are there other categories of brokennes= s from an experience perspective? Major applications that are broken?

 

----------------------------=

Christopher.Palmer@Microsoft.com

Program Manager

IPv6 @ Windows

 

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Cameron Byrne
Sent: Wednesday, April 06, 2011 8:34 AM
To: Sander Steffann
Cc: v6ops@ietf.org; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day = question

 


On Apr 6, 2011 7:44 AM, "Sander Steffann" <sander@steffann.nl> wrote:
>
> > I heard pretty strong consensus at the meeting last week for a co= mment I made at the mic which was roughly "Do on IPv6 day what you wou= ld do if it wasn't just one day". I also heard consensus to make 6to4 = historic. Put these together, and I would say that if your intention is to disable or lower the preference of 6to4 by default= long-term (which I sincerely hope it is), please do so before World IPv6 D= ay. If we can help it, we don't want to be testing something that isn't goi= ng to be around long-term.
>
> +1
>

+1. 6to4 is a know challenge that should not be on or preferred by d= efault. There is no value in extending the pain to new heights.<= /p>

Cb

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

--_000_0AB09EDBCD1C484EBE45978D62F3513C3CD899D4TK5EX14MBXW601w_-- From ichiroumakino@gmail.com Wed Apr 6 12:32: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 D616A3A68C3 for ; Wed, 6 Apr 2011 12:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqHu4qbbrFeg for ; Wed, 6 Apr 2011 12:32:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 99C0A3A6973 for ; Wed, 6 Apr 2011 12:32:38 -0700 (PDT) Received: by eye13 with SMTP id 13so663404eye.31 for ; Wed, 06 Apr 2011 12:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=TWhQy2Rqli/mXlTPFQhbAFIwpJrozU7zwUzbhCjy4gM=; b=t9uct54UdbNN3nEZH7Q1GJxjpy8zjbMvplzaqmcwWiKqBl1/NSILnEPAW+p1dLFvTO 5OOGIJp0KEfF89T+12D483AsG7cpajwAJBqydMX45KLWZr09JhbhTHlzNvKtEFER2snL ii9W/dN1qGjyfCxLcM0gJjUa1nTooRkCTXbvg= 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=QLqUWNGygEX+x2wOOk01VwrCAHwrRwTHb1KSUSiC2JtG0QmjOExg8cOukD5RQQmDHR LOEZB+pDYqRAVnOP1oMT1wVdz5U8LrzCrf6Rzs3dJsu9/znnzyYwxr5V1UFv/PZlB55R brcgBlH2X0NutdgCG/OvS7+4KU7Mx55VjCRV0= Received: by 10.14.135.139 with SMTP id u11mr4935eei.9.1302118462075; Wed, 06 Apr 2011 12:34:22 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id x54sm567708eeh.19.2011.04.06.12.34.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 12:34:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 21:34:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Christopher Palmer X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 19:32:47 -0000 Christopher, > =46rom the perspective of Windows=85 > =20 > Isn=92t it fair to say: > 6to4 is enabled by default on Windows Vista and = Windows 7 > Windows Vista and Windows 7 implement RFC 3484 > =20 > Thus, the only sources of =93brokenness=94 =96 scoped to Windows: > Applications that sort addresses correctly (by not = following Windows guidance) > Hosts that are behind Windows when it has been = configured with Internet Connection Sharing, and do not have RFC 3484. > (we know about the ICS and 6to4 bugs = that exacerbate this issue) > =20 > Are there other categories of brokenness from an experience = perspective? Major applications that are broken? the ICS 'rouge RA' issue: - host A is on a dual stack link with native IPv6 support (IPv6 default = router with native IPv6 connectivity) - host B on the same link, turns on ICS and advertises itself as a = default router - host A picks host B as default router instead of the correct one cheers, Ole= From Dmitry.Anipko@microsoft.com Wed Apr 6 12:35:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48443A6978 for ; Wed, 6 Apr 2011 12:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 kgDfckSzkrQv for ; Wed, 6 Apr 2011 12:35:30 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6B3A63A63EB for ; Wed, 6 Apr 2011 12:35:30 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 12:37:13 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 12:37:12 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Wed, 6 Apr 2011 12:37:08 -0700 From: Dmitry Anipko To: "Templin, Fred L" , "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 12:37:07 -0700 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAI2nQgAAEIIcgAAEDpxAAAX2nUA== Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco. com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B6 4C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A 1D9-DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD- 109.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 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 19:35:31 -0000 Hi Fred, >> but the CE router should institute filtering so that only those hosts wi= thin the same home/soho network get to see each other as neighbors on the l= ink. Should this requirement be included into the list of ISATAP-related require= ments you sent earlier for section 5.5.3? Also, as I understand the filteri= ng would have to distinguish ISATAP use of protocol 41 from any other use -= however is it feasible, since it is required that ISATAP addresses have t= he particular interface ID format, but non-ISATAP links may also have inter= face ID in the same format and should not be subject to such filtering (man= ually configured tunnels)? >> A question for you: do Microsoft hosts prefer to use host-based 6to4 or = ISATAP? By default on Windows 6to4 is not enabled if there are other global non-Ter= edo IPv6 addresses - so if there is an ISATAP global IPv6 address, there wo= n't be 6to4 interface by default, and ISATAP will be used.=20 If 6to4 is enabled by explicit configuration, then for a destination, match= ing default route on both interfaces and not matching any more specific rou= tes (such as e.g. 2002::/16 or ISATAP subnet prefix), the choice depends on= the preference advertized by ISATAP router and detected RTT to the 6to4 re= lay, either one can win. If relay is unreachable, Windows doesn't configure= default route on 6to4. Please let me know whether that answers your questi= on. Thank you, Dmitry=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Wednesday, April 06, 2011 11:44 AM To: Dmitry Anipko; Hemant Singh (shemant); Fred Baker (fred) Cc: IPv6 Ops WG Subject: RE: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.t= xt Hi Dmitry,=20 > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com]=20 > Sent: Wednesday, April 06, 2011 11:09 AM > To: Templin, Fred L; Hemant Singh (shemant); Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: RE:=20 > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Fred, >=20 > Do I understand correctly that=20 > draft-ietf-v6ops-ipv6-cpe-router-bis-00 doesn't preclude a=20 > deployment where the CE router would hand out public IPv4=20 > addresses on the LAN? I could not find a statement of the=20 > opposite in the draft, please let me know if I missed it. I don't see a problem if the CE router hands out public IPv4 addresses on the LAN, and I can't see a reason for the draft to preclude that. > If such deployments are in scope for=20 > draft-ietf-v6ops-ipv6-cpe-router-bis-00, I don't see why they would not be in-scope. > then if CE routers=20 > with ISATAP support enable automatically ISATAP for such=20 > hosts with public IPv4 addresses, will such hosts be on=20 > single IPv6 virtual link? There are actually two questions wrapped up in this, being: 1) Will the CE router automatically enable ISATAP for hosts with public IPv4 addresses? 2) If so, will such hosts be on a single IPv6 virtual link? As to 1), it is a question of fact as to whether the CE router would enable ISATAP or simply leave the hosts to their own devices do host-based 6to4. Personally, I think the CE router could play it both ways, i.e., allow host-based 6to4 hosts to do their own thing while also providing ISATAP managed services to those hosts that prefer to use ISATAP. As to 2), the hosts within the home/soho network would logicially be on a single IPv6 virtual link (along with all other hosts wordlwide that enable ISATAP using public IPv4 addresses), but the CE router should institute filtering so that only those hosts within the same home/soho network get to see each other as neighbors on the link. The home/soho network then becomes a logical partition on the global IPv6 virtual link, and is connected to other partitions and the rest of the IPv6 Internet via IPv6 routing (beginning with the CE router as the default router for the partition). A question for you: do Microsoft hosts prefer to use host-based 6to4 or ISATAP? Based on these numerous discussion threads on the list right now, it seems like they would be better off doing ISATAP when it is available, right? Thanks - Fred fred.l.templin@boeing.com > Thanks, > Dmitry >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Templin, Fred L > Sent: Wednesday, April 06, 2011 8:54 AM > To: Hemant Singh (shemant); Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: Re: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Hemant, >=20 > The particular use case for ISATAP I am describing is > for within the home, i.e., the ISATAP-tunneled packets > do not leak out and interact with other homes. In that > case, it does not matter whether home A numbers its > internal interfaces and links with the same IPv4 > addresses that are internal to home B - the two are > treated as separate and non-intersecting ISATAP links. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > > Sent: Tuesday, April 05, 2011 4:03 PM > > To: Templin, Fred L; Fred Baker (fred) > > Cc: IPv6 Ops WG > > Subject: RE: [v6ops]=20 > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Fred T., > >=20 > > If the CE router gets a public IPv4 address the CE router=20 > > goes directly > > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > > address where private is RFC 1918 address space + the=20 > specific subnet > > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > > takes care > > of shared IPv4 addresses between multiple homes. Can=20 > ISATAP take care > > of shared IPv4 address between different homes?=20 > >=20 > > Hemant > >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > > Sent: Tuesday, April 05, 2011 6:49 PM > > To: Fred Baker (fred) > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > Subject: RE: [v6ops] > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Hi Fred,=20 > >=20 > > > -----Original Message----- > > > From: Fred Baker [mailto:fred@cisco.com]=20 > > > Sent: Tuesday, April 05, 2011 3:30 PM > > > To: Templin, Fred L > > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > > Subject: Re: [v6ops]=20 > > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > >=20 > > > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > > > network? > >=20 > > Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 > > seems to acknowledge the existence of current IPv4 End-user > > networks, and that: "It is not expected that an end-user > > will change their existing network topology with the > > introduction of IPv6". > >=20 > > It seems therefore that there will be a class of end > > user networks that would benefit from an intra-site > > IPv6/IPv4 transition technology. > >=20 > > > What would ISATAP do in a native IPv6 network? > >=20 > > The host would prefer native IPv6 over ISATAP. But, > > not all home/soho networks are set up for native IPv6. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 From Christopher.Palmer@microsoft.com Wed Apr 6 12:36: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 D7FFB3A6973 for ; Wed, 6 Apr 2011 12:36:08 -0700 (PDT) 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.301, 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 92kGSD8oFBNx for ; Wed, 6 Apr 2011 12:36:08 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 270BB3A68C3 for ; Wed, 6 Apr 2011 12:36:08 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 12:37:51 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 12:37:52 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 12:37:52 -0700 From: Christopher Palmer To: Ole Troan Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AQHL88hvpgRk+wlPLkatpLmbV9eqIJRRX2YAgAAAfgCAAA3bgP//v0jQgACD/gD//4qaMA== Date: Wed, 6 Apr 2011 19:37:51 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 19:36:08 -0000 Yeah, we know about the rouge RAs (that's what I meant by ICS bugs that exa= cerbate the issue).=20 Anything else? Best! Chris -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Wednesday, April 06, 2011 12:34 PM To: Christopher Palmer Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n Christopher, > From the perspective of Windows... > =20 > Isn't it fair to say: > 6to4 is enabled by default on Windows Vista and Windows 7 > Windows Vista and Windows 7 implement RFC 3484 > =20 > Thus, the only sources of "brokenness" - scoped to Windows: > Applications that sort addresses correctly (by not follow= ing Windows guidance) > Hosts that are behind Windows when it has been configured= with Internet Connection Sharing, and do not have RFC 3484. > (we know about the ICS and 6to4 bugs that= exacerbate this issue) > =20 > Are there other categories of brokenness from an experience perspective? = Major applications that are broken? the ICS 'rouge RA' issue: - host A is on a dual stack link with native IPv6 support (IPv6 default ro= uter with native IPv6 connectivity) - host B on the same link, turns on ICS and advertises itself as a default= router - host A picks host B as default router instead of the correct one cheers, Ole From ichiroumakino@gmail.com Wed Apr 6 12: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 6BE053A697B for ; Wed, 6 Apr 2011 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 YbErMcvTP1Mu for ; Wed, 6 Apr 2011 12:42:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 4476728C106 for ; Wed, 6 Apr 2011 12:42:33 -0700 (PDT) Received: by eye13 with SMTP id 13so666631eye.31 for ; Wed, 06 Apr 2011 12:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=jwqStqhjrgxkA82Qr1zZ+qT/sM5wJgo2/9oFiRaudas=; b=viAGj+fx+opo2HpWBK7yN1RaDLKtZWZkXIuvHbJdSCycnTE7wmhtKaguxfvU36I5xX 3HDjrkFYIHwzrughbE3W82CkdhLmfgrR4EXmLzfPfAyfU0DKWRHmxiAUQ+/v+HOgMpHV xDfaRa3JjR0vfGNwJFABtZ601G1TF3isMZd54= 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=NLik4rYO4d5gwm6F+SXY9/XxnUvxDb/a+0crXOzvJmkxxT0bywZydTqc8nNMxO2AiG dFa+UcijFLKg8cF9vY6Qblp3fbqz+S8EGbzC6C0gink1XNu7RgtwN8yyxAplXsFNRmeK tMdzg0Je9QpQetPTMVXnWek6sKAWK+cJpHEH8= Received: by 10.213.21.8 with SMTP id h8mr2500ebb.111.1302119056595; Wed, 06 Apr 2011 12:44:16 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id y7sm578635eeh.0.2011.04.06.12.44.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 12:44:15 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <34E4F50CAFA10349A41E0756550084FB049FEF81@PRVPEXVS04.corp.twcable.com> Date: Wed, 6 Apr 2011 21:44:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6634030F-7E3D-439F-97D0-E6C85ACECA76@employees.org> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> <009b01cbf3f1$4b22c970$e1685c50$@com> <34E4F50CAFA10349A41E0756550084FB049FEF81@P RVPEXVS04.corp.twcable.com> To: "Weil, Jason" X-Mailer: Apple Mail (2.1084) Cc: 'IPv6 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 19:42:34 -0000 > I am not able clearly parse the data to the column headings, but if it = helps the diagram below is what I was suggesting. >=20 > [DS HOST]--[v4 CE ROUTER]--[v6 BIS ROUTER]-->Service Provider > | > [DS HOST] >=20 > The issue in the topology depicted above is the IPv4-only CE = (interior) ROUTER is out of scope for the -bis draft today. The current = scope covers transition technologies on the WAN (6rd and DS-LITE) and a = simple two router setup with the interior router being an IPv6 CE = router. what is the proposal, that the IPv6 CE comes with ISATAP supported on by = default or be capable of doing ISATAP tunneling? (remember we are trying = to make these routers require no management). if ISATAP is enabled by default, how do we know that the user hasn't = intended a topology separating host on different links and by building a = single virtual link we are violating that policy? e.g. why were the = extra routers there in the first place. how is ISATAP provisioning supposed to work? so far the IPv6 CE router = work has focused on the profile of the router itself, and it has = references standards track document for WAN side and LAN side behaviour. cheers, Ole= From cb.list6@gmail.com Wed Apr 6 12:45: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 0107828C124 for ; Wed, 6 Apr 2011 12:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=-0.241, 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 sKBGu+dxKTFD for ; Wed, 6 Apr 2011 12:45:11 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 9DC0C3A6981 for ; Wed, 6 Apr 2011 12:45:10 -0700 (PDT) Received: by ewy19 with SMTP id 19so665555ewy.31 for ; Wed, 06 Apr 2011 12:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3ZxR8vfrxrM2ryPIckuRDtfYJ91/FNcHHAXy4W5wgRA=; b=tr+ZJVzZ4I1/vRyb74a7fNsLAapz8TAAQ0AetbLEpO0YUFQ8VQsDTL1k6+V0G/QuED tWjinIFZXwp05Cf00EIzmYnGAojfXb2DYJQAP0VF938OThbAY8LRwcE+6CEpMaR2HnHm TXgM5rWMLfUDCMAGfY9qUcRzu/YPb/lVSDuxk= 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=cSnByjuS53dDzYy98EMNTzkmwyrREnMhN8iZ/sgmekeS3PDCtD4fys92hZvDYBFjO0 4/aZ23HadGqrceRuoOXyW8sAH+SaIpVgHM18S2kBaygIqhP22s6f8E4FEVrYmOYk9IFQ EZu8SznWu21+ZdtrjTF/w4iStxs5oC+IrCVeo= MIME-Version: 1.0 Received: by 10.213.27.22 with SMTP id g22mr2561ebc.120.1302119211351; Wed, 06 Apr 2011 12:46:51 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Wed, 6 Apr 2011 12:46:51 -0700 (PDT) In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 12:46:51 -0700 Message-ID: From: Cameron Byrne To: Christopher Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 19:45:14 -0000 On Wed, Apr 6, 2011 at 12:06 PM, Christopher Palmer wrote: > From the perspective of Windows=85 > > > > Isn=92t it fair to say: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6to4 is enabled by default = on Windows Vista and Windows 7 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Windows Vista and Windows 7= implement RFC 3484 > > > > Thus, the only sources of =93brokenness=94 =96 scoped to Windows: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Applications that sort addr= esses correctly (by not following > Windows guidance) > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hosts that are behind Windo= ws when it has been configured > with Internet Connection Sharing, and do not have RFC 3484. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 (we know about the ICS and 6to4 bugs that > exacerbate this issue) > > > > Are there other categories of brokenness from an experience perspective? > Major applications that are broken? > > I would be careful that all that appears to be public IP assigned to the PC are not in fact public IPs ... they are BOGONs used by SPs for various reasons like NAT44 in mobile or NAT444 in broadband. I am not saying BOGONs are good or anybody should use them, but they are in use now and will be used in the future and consequently they will be a source for pain when a Windows computers thinks 6to4 will work because it has a public address, but it fact, it is going via NAT and 6to4 will blackhole. Cameron > > ---------------------------- > > Christopher.Palmer@Microsoft.com > > Program Manager > > IPv6 @ Windows > > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Cameron Byrne > > Sent: Wednesday, April 06, 2011 8:34 AM > To: Sander Steffann > Cc: v6ops@ietf.org; Dmitry Anipko > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day quest= ion > > > > On Apr 6, 2011 7:44 AM, "Sander Steffann" wrote: >> >> > I heard pretty strong consensus at the meeting last week for a comment= I >> > made at the mic which was roughly "Do on IPv6 day what you would do if= it >> > wasn't just one day". I also heard consensus to make 6to4 historic. Pu= t >> > these together, and I would say that if your intention is to disable o= r >> > lower the preference of 6to4 by default long-term (which I sincerely h= ope it >> > is), please do so before World IPv6 Day. If we can help it, we don't w= ant to >> > be testing something that isn't going to be around long-term. >> >> +1 >> > > +1. 6to4 is a know challenge that should not be on or preferred by defaul= t. > There is no value in extending the pain to new heights. > > Cb > >> Thanks, >> Sander >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Wed Apr 6 12:49: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 3D3073A696F for ; Wed, 6 Apr 2011 12:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JaNJzI9X+Y7 for ; Wed, 6 Apr 2011 12:49:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 42F173A67DA for ; Wed, 6 Apr 2011 12:49:53 -0700 (PDT) Received: by eye13 with SMTP id 13so668920eye.31 for ; Wed, 06 Apr 2011 12:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=CXt3V53b2txJIJB7A8KTgeQbRGTWKLbxRJA0xCtWX3k=; b=CBkIyGw7+iijzO3fgDl56axH9k/Wl9oCXGifAt6KpyXi8Gl09geqSOXCZWsbk6Vghe OzDvlDqIkoZ5rQdMhAuJr3VdOAeqGaNDvqXqAJwcoU0y0yoMQlRBZ8P7/twwKa6BPyib MOV6fxinNHHpHxFU8QqDQ1JOAU3+hYXMOdCnU= 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=XdkDdByea3Z3LoaAIdROMNXC+ZMHKqdNEwIUeC/9icgXmkPBroP1QHEup/U0q9Fa+F hyRUWn1JtF+nTXXd3Ga1UJxK53byLPI2Qz11M2nnZx8zqU8SpIVhGXiyifE3LIXE6E1h F5ISMHTScEphM1v6xaEn+9lMY1sX3flXIaAjU= Received: by 10.14.13.134 with SMTP id b6mr6932eeb.94.1302119496719; Wed, 06 Apr 2011 12:51:36 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id k51sm581766eei.3.2011.04.06.12.51.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 12:51:36 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 21:51:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Christopher Palmer X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 19:49:54 -0000 Christopher, > Yeah, we know about the rouge RAs (that's what I meant by ICS bugs = that exacerbate the issue).=20 ack. becoming a 6to4 router should be very hard for the uninitiated to = turn on, and there should be some sort of check that automatically = disables it if the interface is connected to a different network. > Anything else? from the top of my mind: - no reachability test towards the 6to4 relay router. - doesn't react to ICMPs(?) - how does it work with "bogons"? non-routable non-RFC1918 IPv4 = addresses? (result of some CGN deployments). cheers, Ole > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Troan > Sent: Wednesday, April 06, 2011 12:34 PM > To: Christopher Palmer > Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day = question >=20 > Christopher, >=20 >=20 >> =46rom the perspective of Windows... >>=20 >> Isn't it fair to say: >> 6to4 is enabled by default on Windows Vista and = Windows 7 >> Windows Vista and Windows 7 implement RFC 3484 >>=20 >> Thus, the only sources of "brokenness" - scoped to Windows: >> Applications that sort addresses correctly (by not = following Windows guidance) >> Hosts that are behind Windows when it has been = configured with Internet Connection Sharing, and do not have RFC 3484. >> (we know about the ICS and 6to4 bugs = that exacerbate this issue) >>=20 >> Are there other categories of brokenness from an experience = perspective? Major applications that are broken? >=20 > the ICS 'rouge RA' issue: > - host A is on a dual stack link with native IPv6 support (IPv6 = default router with native IPv6 connectivity) > - host B on the same link, turns on ICS and advertises itself as a = default router > - host A picks host B as default router instead of the correct one >=20 > cheers, > Ole From martin@millnert.se Wed Apr 6 13:40: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 A5CC13A692F for ; Wed, 6 Apr 2011 13:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6uRFeSikKv4 for ; Wed, 6 Apr 2011 13:40:28 -0700 (PDT) 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 9AF323A67A3 for ; Wed, 6 Apr 2011 13:40:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 5F61D77A2; Wed, 6 Apr 2011 22:55:00 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tfgm4HLJNta; Wed, 6 Apr 2011 22:55:00 +0200 (CEST) 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 8AB9276C2; Wed, 6 Apr 2011 22:54:57 +0200 (CEST) From: Martin Millnert To: Brian E Carpenter In-Reply-To: <4D9CB156.308@gmail.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Apr 2011 16:41:52 -0400 Message-ID: <1302122512.4072.38.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 20:40:29 -0000 On Thu, 2011-04-07 at 06:30 +1200, Brian E Carpenter wrote: > That isn't the point. The point is the millions (literally) of systems > out there that *will* be running 6to4 by default for, very likely, > years to come. > Brian, If I am reading Dmitry and Christopher correctly, and if I'm correct in expecting a high level of competent engineering at MS, we have: anticimex@shakira:~$ host 6to4.ipv6.microsoft.com 6to4.ipv6.microsoft.com has address 192.88.99.1 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8 And (from http://technet.microsoft.com/en-us/library/cc779985(WS.10).aspx ): "Automatically performs a Domain Name System (DNS) query for the name 6to4.ipv6.microsoft.com to obtain the IPv4 address of the Microsoft 6to4 relay router on the Internet. You can use the netsh interface ipv6 6to4 set relay command to specify which DNS name to query." Thus the "fix" for a very substantial amount of today's Internet hosts (and more to come with current ongoing enterprise win7 migration rollouts) could be in fact, very, very simple. Obviously shipping new code to machines requires patches to go out -- but the above could possibly be done swiftly. But how much has already been hidden in the Windows stack for this day, we'll have to see. :) I could imagine that updating hosts to query instead "6to4".$DOMAIN may be something one could consider, and MS aren't strangers to configure the netstack via DNS queries on $DOMAIN, but we'll see what they do. All in all, MS has a unique position to make a big impact here, one that I welcome warmly. If they are willing to do this (by biting the PR bullet) to fix the current circular non-IPv6-deploying-dependency-situation we have, I'd be extremely happy. :) Cheers, Martin From Fred.L.Templin@boeing.com Wed Apr 6 15:35: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 DC05D3A68B9 for ; Wed, 6 Apr 2011 15:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 Eofk3SEV3mdM for ; Wed, 6 Apr 2011 15:35:54 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 9170C3A6801 for ; Wed, 6 Apr 2011 15:35:54 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p36MbZ4P017010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 15:37:35 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p36MbZGg019727; Wed, 6 Apr 2011 15:37:35 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p36MbZ1Q019717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 15:37:35 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 6 Apr 2011 15:37:34 -0700 From: "Templin, Fred L" To: Dmitry Anipko , "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Wed, 6 Apr 2011 15:37:33 -0700 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAI2nQgAAEIIcgAAEDpxAAAX2nUAABi+hw Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco. com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B6 4C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A 1D9-DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD- 109.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 Ops WG Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 22:35:57 -0000 Hi Dmitry,=20 > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com]=20 > Sent: Wednesday, April 06, 2011 12:37 PM > To: Templin, Fred L; Hemant Singh (shemant); Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: RE:=20 > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Fred, >=20 > >> but the CE router should institute filtering so that only=20 > those hosts within the same home/soho network get to see each=20 > other as neighbors on the link. >=20 > Should this requirement be included into the list of=20 > ISATAP-related requirements you sent earlier for section=20 > 5.5.3? Also, as I understand the filtering would have to=20 > distinguish ISATAP use of protocol 41 from any other use -=20 > however is it feasible, since it is required that ISATAP=20 > addresses have the particular interface ID format, but=20 > non-ISATAP links may also have interface ID in the same=20 > format and should not be subject to such filtering (manually=20 > configured tunnels)? It would be very messy to get into the business of trying to discern one type of ip-proto-41 tunnel from another. So, instead of disallowing ip-proto-41 from crossing between the LAN and WAN sides of the CE router, we can make a simple requirement that only those IPv4 addresses that are on the LAN side of the CE are permitted to tunnel *to* the LAN side interface of the CE. In other words, only LAN-side devices are permitted to use the CE as an ISATAP default router. This could then go into my list of Section 5.5.3 requirements - does that make sense? > >> A question for you: do Microsoft hosts prefer to use=20 > host-based 6to4 or ISATAP? >=20 > By default on Windows 6to4 is not enabled if there are other=20 > global non-Teredo IPv6 addresses - so if there is an ISATAP=20 > global IPv6 address, there won't be 6to4 interface by=20 > default, and ISATAP will be used.=20 >=20 > If 6to4 is enabled by explicit configuration, then for a=20 > destination, matching default route on both interfaces and=20 > not matching any more specific routes (such as e.g. 2002::/16=20 > or ISATAP subnet prefix), the choice depends on the=20 > preference advertized by ISATAP router and detected RTT to=20 > the 6to4 relay, either one can win. If relay is unreachable,=20 > Windows doesn't configure default route on 6to4. Please let=20 > me know whether that answers your question. Yes, I think so. Please also let me know if the requirement I articulated above seems reasoanble. Thanks - Fred fred.l.templin@boeing.com > Thank you, > Dmitry=20 >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Wednesday, April 06, 2011 11:44 AM > To: Dmitry Anipko; Hemant Singh (shemant); Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: RE:=20 > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Hi Dmitry,=20 >=20 > > -----Original Message----- > > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com]=20 > > Sent: Wednesday, April 06, 2011 11:09 AM > > To: Templin, Fred L; Hemant Singh (shemant); Fred Baker (fred) > > Cc: IPv6 Ops WG > > Subject: RE:=20 > > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Hi Fred, > >=20 > > Do I understand correctly that=20 > > draft-ietf-v6ops-ipv6-cpe-router-bis-00 doesn't preclude a=20 > > deployment where the CE router would hand out public IPv4=20 > > addresses on the LAN? I could not find a statement of the=20 > > opposite in the draft, please let me know if I missed it. >=20 > I don't see a problem if the CE router hands out public > IPv4 addresses on the LAN, and I can't see a reason for > the draft to preclude that. >=20 > > If such deployments are in scope for=20 > > draft-ietf-v6ops-ipv6-cpe-router-bis-00, >=20 > I don't see why they would not be in-scope. >=20 > > then if CE routers=20 > > with ISATAP support enable automatically ISATAP for such=20 > > hosts with public IPv4 addresses, will such hosts be on=20 > > single IPv6 virtual link? >=20 > There are actually two questions wrapped up in this, > being: >=20 > 1) Will the CE router automatically enable ISATAP for > hosts with public IPv4 addresses? > 2) If so, will such hosts be on a single IPv6 virtual > link? >=20 > As to 1), it is a question of fact as to whether the > CE router would enable ISATAP or simply leave the hosts > to their own devices do host-based 6to4. Personally, I > think the CE router could play it both ways, i.e., allow > host-based 6to4 hosts to do their own thing while also > providing ISATAP managed services to those hosts that > prefer to use ISATAP. >=20 > As to 2), the hosts within the home/soho network would > logicially be on a single IPv6 virtual link (along with > all other hosts wordlwide that enable ISATAP using public > IPv4 addresses), but the CE router should institute > filtering so that only those hosts within the same > home/soho network get to see each other as neighbors on > the link. The home/soho network then becomes a logical > partition on the global IPv6 virtual link, and is > connected to other partitions and the rest of the IPv6 > Internet via IPv6 routing (beginning with the CE router > as the default router for the partition). >=20 > A question for you: do Microsoft hosts prefer to use > host-based 6to4 or ISATAP? Based on these numerous > discussion threads on the list right now, it seems > like they would be better off doing ISATAP when it > is available, right? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >=20 >=20 > > Thanks, > > Dmitry > >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > > On Behalf Of Templin, Fred L > > Sent: Wednesday, April 06, 2011 8:54 AM > > To: Hemant Singh (shemant); Fred Baker (fred) > > Cc: IPv6 Ops WG > > Subject: Re: [v6ops]=20 > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >=20 > > Hi Hemant, > >=20 > > The particular use case for ISATAP I am describing is > > for within the home, i.e., the ISATAP-tunneled packets > > do not leak out and interact with other homes. In that > > case, it does not matter whether home A numbers its > > internal interfaces and links with the same IPv4 > > addresses that are internal to home B - the two are > > treated as separate and non-intersecting ISATAP links. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > > -----Original Message----- > > > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > > > Sent: Tuesday, April 05, 2011 4:03 PM > > > To: Templin, Fred L; Fred Baker (fred) > > > Cc: IPv6 Ops WG > > > Subject: RE: [v6ops]=20 > > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > >=20 > > > Fred T., > > >=20 > > > If the CE router gets a public IPv4 address the CE router=20 > > > goes directly > > > to the public IPv4 Internet. If the CE router gets a=20 > "private" IPv4 > > > address where private is RFC 1918 address space + the=20 > > specific subnet > > > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also=20 > > > takes care > > > of shared IPv4 addresses between multiple homes. Can=20 > > ISATAP take care > > > of shared IPv4 address between different homes?=20 > > >=20 > > > Hemant > > >=20 > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > > > Sent: Tuesday, April 05, 2011 6:49 PM > > > To: Fred Baker (fred) > > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > > Subject: RE: [v6ops] > > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > >=20 > > > Hi Fred,=20 > > >=20 > > > > -----Original Message----- > > > > From: Fred Baker [mailto:fred@cisco.com]=20 > > > > Sent: Tuesday, April 05, 2011 3:30 PM > > > > To: Templin, Fred L > > > > Cc: Hemant Singh (shemant); IPv6 Ops WG > > > > Subject: Re: [v6ops]=20 > > > > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > > >=20 > > > > Isn't cpe-router-bis is about a native IPv6 residential/SOHO=20 > > > > network? > > >=20 > > > Well, Section 3.1 of draft-ietf-v6ops-ipv6-cpe-router-09 > > > seems to acknowledge the existence of current IPv4 End-user > > > networks, and that: "It is not expected that an end-user > > > will change their existing network topology with the > > > introduction of IPv6". > > >=20 > > > It seems therefore that there will be a class of end > > > user networks that would benefit from an intra-site > > > IPv6/IPv4 transition technology. > > >=20 > > > > What would ISATAP do in a native IPv6 network? > > >=20 > > > The host would prefer native IPv6 over ISATAP. But, > > > not all home/soho networks are set up for native IPv6. > > >=20 > > > Thanks - Fred > > > fred.l.templin@boeing.com > > >=20 > > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > >=20 > = From Christopher.Palmer@microsoft.com Wed Apr 6 15:41: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 901AD3A67EB for ; Wed, 6 Apr 2011 15:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s-g9pN7Ze9U for ; Wed, 6 Apr 2011 15:41:54 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 103E43A67D8 for ; Wed, 6 Apr 2011 15:41:53 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 15:43:38 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 15:43:38 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 15:43:37 -0700 From: Christopher Palmer To: "v6ops@ietf.org" Thread-Topic: Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv0q/0Z/RyklE39TrerPIyoUARNXw== Date: Wed, 6 Apr 2011 22:43:37 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A349TK5EX14MBXW601w_" MIME-Version: 1.0 Subject: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 22:41:57 -0000 --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A349TK5EX14MBXW601w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to H= istoric status" There is this recommendation: IANA is requested to mark the 2002::/16 prefix as "deprecated", pointing to this document. Reassignment of the prefix for any usage requires justification via an IETF Standards Action [RFC5226]. It is not clear why this is necessary. If major vendors were to disable 6to4 by default, that would fix the broken= ness issue, while still allow for this prefix to be used in specialized or = enthusiast scenarios. Isn't any other action overkill? Thanks! ---------------------------- Christopher.Palmer@Microsoft.com Program Manager IPv6 @ Windows --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A349TK5EX14MBXW601w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In  “Request to move Connection of IPv6 D= omains via IPv4 Clouds (6to4) to Historic status”

 

There is this recommendation:

 

IANA is requested to mark the 2002::/16 prefix as &q= uot;deprecated",

   pointing to this document.  Reassi= gnment of the prefix for any usage

   requires justification via an IETF Stan= dards Action [RFC5226].

 

It is not clear why this is necessary.

 

If major vendors were to disable 6to4 by default, th= at would fix the brokenness issue, while still allow for this prefix to be = used in specialized or enthusiast scenarios. Isn’t any other action o= verkill?

 

Thanks!

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

Christopher.Palmer@Microsoft.com

Program Manager

IPv6 @ Windows

 

 

 

 

--_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A349TK5EX14MBXW601w_-- From Christopher.Palmer@microsoft.com Wed Apr 6 15:44: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 570223A67EE for ; Wed, 6 Apr 2011 15:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 RgRiaM59Zdrl for ; Wed, 6 Apr 2011 15:44:24 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 64ED43A67EB for ; Wed, 6 Apr 2011 15:44:24 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 15:46:08 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 15:46:08 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 15:46:08 -0700 From: Christopher Palmer To: Martin Millnert , Brian E Carpenter Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AQHL88hvpgRk+wlPLkatpLmbV9eqIJRRX2YAgAAAfgCAAA3bgIAAMYUAgAAkoQD//6yS8A== Date: Wed, 6 Apr 2011 22:46:07 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> In-Reply-To: <1302122512.4072.38.camel@shakira.millnert.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 22:44:25 -0000 The flattery makes one feel warm in the heart. Yes - Windows clients currently "learn" the 6to4 anycast prefix by resolvin= g 6to4.ipv6.microsoft.com.=20 Modification of this A record could be used to modify Windows Vista/7 behav= ior without requiring a Windows Update, and fix the perceived issue semi-ma= gically. Best! Chris -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= artin Millnert Sent: Wednesday, April 06, 2011 1:42 PM To: Brian E Carpenter Cc: v6ops@ietf.org; Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n On Thu, 2011-04-07 at 06:30 +1200, Brian E Carpenter wrote: > That isn't the point. The point is the millions (literally) of systems=20 > out there that *will* be running 6to4 by default for, very likely,=20 > years to come. >=20 Brian, If I am reading Dmitry and Christopher correctly, and if I'm correct in exp= ecting a high level of competent engineering at MS, we have: anticimex@shakira:~$ host 6to4.ipv6.microsoft.com 6to4.ipv6.microsoft.com h= as address 192.88.99.1 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:2= 13c:1:e0:8f08:f020:8 And (from http://technet.microsoft.com/en-us/library/cc779985(WS.10).aspx ): "Automatically performs a Domain Name System (DNS) query for the name 6to4.= ipv6.microsoft.com to obtain the IPv4 address of the Microsoft 6to4 relay r= outer on the Internet. You can use the netsh interface ipv6 6to4 set relay = command to specify which DNS name to query." Thus the "fix" for a very substantial amount of today's Internet hosts (and= more to come with current ongoing enterprise win7 migration rollouts) could be in fact, very, very simple. Obviously shipping new code to machines requires patches to go out -- but t= he above could possibly be done swiftly. But how much has already been hid= den in the Windows stack for this day, we'll have to see. :) I could imagine that updating hosts to query instead "6to4".$DOMAIN may be = something one could consider, and MS aren't strangers to configure the nets= tack via DNS queries on $DOMAIN, but we'll see what they do. All in all, MS has a unique position to make a big impact here, one that I = welcome warmly. If they are willing to do this (by biting the PR bullet) to fix the current circular non-IPv6-deploying-dependency-situation we have, I'd be extremely happy. :) Cheers, Martin _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Christopher.Palmer@microsoft.com Wed Apr 6 15:57: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 D02893A67EE for ; Wed, 6 Apr 2011 15:57:38 -0700 (PDT) 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 1gWcwYdZYOWG for ; Wed, 6 Apr 2011 15:57:38 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2FB1B3A67EB for ; Wed, 6 Apr 2011 15:57:38 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 15:59:22 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 15:59:22 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 15:59:21 -0700 From: Christopher Palmer To: Ole Troan Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AQHL88hvpgRk+wlPLkatpLmbV9eqIJRRX2YAgAAAfgCAAA3bgP//v0jQgACD/gD//4qaMIAAejiA//+7R1A= Date: Wed, 6 Apr 2011 22:59:21 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A3FF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 22:57:38 -0000 - no reachability test towards the 6to4 relay router. - doesn't react to ICMPs(?) - how does it work with "bogons"? non-routable non-RFC1918 IPv4 addresses? = (result of some CGN deployments). These won't translate into user problems - a correctly configured applicati= on or a 3484-compliant host will be fine in these situations.=20 They might eventually try a broken connection which is unfortunate, but cor= rect sorting will make 6to4 a last resort. So really, the brokenness will n= ever establish itself except in the following 2 scenarios, AFAIK. Applications that sort addresses correctly (by not following= Windows guidance) Hosts that are behind Windows when it has been configured wi= th Internet Connection Sharing, and do not have RFC 3484. (exacerbated by the rouge RA issue with ICS= ) Best! Chris -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Wednesday, April 06, 2011 12:52 PM To: Christopher Palmer Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n Christopher, > Yeah, we know about the rouge RAs (that's what I meant by ICS bugs that e= xacerbate the issue).=20 ack. becoming a 6to4 router should be very hard for the uninitiated to turn= on, and there should be some sort of check that automatically disables it = if the interface is connected to a different network. > Anything else? from the top of my mind: - no reachability test towards the 6to4 relay router. - doesn't react to ICMPs(?) - how does it work with "bogons"? non-routable non-RFC1918 IPv4 addresses? = (result of some CGN deployments). cheers, Ole > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Wednesday, April 06, 2011 12:34 PM > To: Christopher Palmer > Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day quest= ion >=20 > Christopher, >=20 >=20 >> From the perspective of Windows... >>=20 >> Isn't it fair to say: >> 6to4 is enabled by default on Windows Vista and Windows 7 >> Windows Vista and Windows 7 implement RFC 3484 >>=20 >> Thus, the only sources of "brokenness" - scoped to Windows: >> Applications that sort addresses correctly (by not follow= ing Windows guidance) >> Hosts that are behind Windows when it has been configured= with Internet Connection Sharing, and do not have RFC 3484. >> (we know about the ICS and 6to4 bugs that= exacerbate this issue) >>=20 >> Are there other categories of brokenness from an experience perspective?= Major applications that are broken? >=20 > the ICS 'rouge RA' issue: > - host A is on a dual stack link with native IPv6 support (IPv6 default r= outer with native IPv6 connectivity) > - host B on the same link, turns on ICS and advertises itself as a defaul= t router > - host A picks host B as default router instead of the correct one >=20 > cheers, > Ole From carlosm3011@gmail.com Wed Apr 6 15:57: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 097E028C0FA for ; Wed, 6 Apr 2011 15:57:44 -0700 (PDT) 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.050, 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 i4T4KzzGhF4x for ; Wed, 6 Apr 2011 15:57:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C302928C0EF for ; Wed, 6 Apr 2011 15:57:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so2369457iwn.31 for ; Wed, 06 Apr 2011 15:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9wAy8SP8QhocfTm0SGA8iX9J2Ot5Z6uwNbKGO+wY12c=; b=yDcl/mfMvkX5VOTkGvUhHOZDdd+aGYtcFkU+XUN02IiVXjJOMFId40Gcic5jObVeeq rcrvXnSDYKEIIU726v6KQlpjeEvRTQ7GcMtC3s6/DveefagMvM+8v1uxJezmCcsHVtvu BJ0IfyoUjO/PazFNrftyEQ+f5ryLV+m9gJqdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=fgsdhTGQH3PhjpkfW4ZiXOUGQqQNSNzJ68s2Kr8rdZ6ZlIPsM4yj/Tjj2NJvPYglXf EDh9YFhOUfz48MbGPjkr3ZsEyCSe6VDdSIGONuj6AhrjaalQGTLxy6SfNAmE8juoU6FV HfZYYm+nHApLPLmGth5WLBa8yiKlJPZ46kIaw= MIME-Version: 1.0 Received: by 10.43.64.196 with SMTP id xj4mr315839icb.51.1302130766346; Wed, 06 Apr 2011 15:59:26 -0700 (PDT) Received: by 10.42.244.73 with HTTP; Wed, 6 Apr 2011 15:59:26 -0700 (PDT) In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 19:59:26 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: Christopher Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:57:44 -0000 I agree with Cristopher's comment. Personally I believe we should fix what is wrong with 6to4 (mostly the anycast part), and make it more manageable from an operators point of view rather than just dispose of what can be a very valuable transition tool. regards Carlos On Wed, Apr 6, 2011 at 7:43 PM, Christopher Palmer wrote: > In =A0=93Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4= ) to > Historic status=94 > > > > There is this recommendation: > > > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > > =A0=A0 pointing to this document.=A0 Reassignment of the prefix for any u= sage > > =A0=A0 requires justification via an IETF Standards Action [RFC5226]. > > > > It is not clear why this is necessary. > > > > If major vendors were to disable 6to4 by default, that would fix the > brokenness issue, while still allow for this prefix to be used in > specialized or enthusiast scenarios. Isn=92t any other action overkill? > > > > Thanks! > > ---------------------------- > > Christopher.Palmer@Microsoft.com > > Program Manager > > IPv6 @ Windows > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From martin@millnert.se Wed Apr 6 15:57: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 1A6953A680B for ; Wed, 6 Apr 2011 15:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 1lnFGuyCCmj4 for ; Wed, 6 Apr 2011 15:57:56 -0700 (PDT) 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 CD1843A67EB for ; Wed, 6 Apr 2011 15:57:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 00B6C778B; Thu, 7 Apr 2011 01:12:29 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAEWKCURMJaK; Thu, 7 Apr 2011 01:12:29 +0200 (CEST) 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 53F5676C2; Thu, 7 Apr 2011 01:12:28 +0200 (CEST) From: Martin Millnert To: Christopher Palmer In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Apr 2011 18:59:23 -0400 Message-ID: <1302130763.4072.94.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 22:57:57 -0000 Chris, On Wed, 2011-04-06 at 22:46 +0000, Christopher Palmer wrote: > The flattery makes one feel warm in the heart. > > Yes - Windows clients currently "learn" the 6to4 anycast prefix by resolving 6to4.ipv6.microsoft.com. > > Modification of this A record could be used to modify Windows Vista/7 behavior without requiring a Windows Update, and fix the perceived issue semi-magically. That sounds absolutely terrific. If pushing this draft through helps in this effort (i.e. the IETF making clear recommendations to OS vendors), it's a strong motivation to do so, to say the least. Cheers, Martin > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Martin Millnert > Sent: Wednesday, April 06, 2011 1:42 PM > To: Brian E Carpenter > Cc: v6ops@ietf.org; Dmitry Anipko > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question > > On Thu, 2011-04-07 at 06:30 +1200, Brian E Carpenter wrote: > > > That isn't the point. The point is the millions (literally) of systems > > out there that *will* be running 6to4 by default for, very likely, > > years to come. > > > > Brian, > > If I am reading Dmitry and Christopher correctly, and if I'm correct in expecting a high level of competent engineering at MS, we have: > > anticimex@shakira:~$ host 6to4.ipv6.microsoft.com 6to4.ipv6.microsoft.com has address 192.88.99.1 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8 > > And (from > http://technet.microsoft.com/en-us/library/cc779985(WS.10).aspx ): > "Automatically performs a Domain Name System (DNS) query for the name 6to4.ipv6.microsoft.com to obtain the IPv4 address of the Microsoft 6to4 relay router on the Internet. You can use the netsh interface ipv6 6to4 set relay command to specify which DNS name to query." > > Thus the "fix" for a very substantial amount of today's Internet hosts (and more to come with current ongoing enterprise win7 migration > rollouts) could be in fact, very, very simple. > > Obviously shipping new code to machines requires patches to go out -- but the above could possibly be done swiftly. But how much has already been hidden in the Windows stack for this day, we'll have to see. :) > > I could imagine that updating hosts to query instead "6to4".$DOMAIN may be something one could consider, and MS aren't strangers to configure the netstack via DNS queries on $DOMAIN, but we'll see what they do. > > > All in all, MS has a unique position to make a big impact here, one that I welcome warmly. If they are willing to do this (by biting the PR > bullet) to fix the current circular > non-IPv6-deploying-dependency-situation we have, I'd be extremely happy. :) > > Cheers, > Martin > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ek@google.com Wed Apr 6 16:11: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 6D9B128C0FE for ; Wed, 6 Apr 2011 16:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JKrXNuGlRoQw for ; Wed, 6 Apr 2011 16:11:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2B9AD28C0E7 for ; Wed, 6 Apr 2011 16:11:43 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p36NDQXb019220 for ; Wed, 6 Apr 2011 16:13:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302131607; bh=e9MblURLX04Uc6MTV+5c4/nBBqM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YTa0vlxm+uN0LqQru/pIXG5YoQ1GLXn7ReSfI4KS+YG1tRI/CPZ0GdxDb/QNpKc2I gW6T5qKk3J2PlvF9bdZlQ== Received: from qyg14 (qyg14.prod.google.com [10.241.82.142]) by kpbe17.cbf.corp.google.com with ESMTP id p36NBrWQ022957 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 16:13:25 -0700 Received: by qyg14 with SMTP id 14so1399961qyg.19 for ; Wed, 06 Apr 2011 16:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a5caYetvRouA/Zlc6f6MikCr8XkSeUaaoi9CoyXqhpg=; b=LHrLGFi9lovmz7HKtIimb6RGB5yF6cfLrfsX8XpKxhF1yaJvWGMFCfOsXQD06N0aTC /WDz8V6Fvo6uS1YCTVLQ== 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=tg/P2U1EJI7QXxDLHJh/23YhoqnMGswRPQBH4wr+7Drdf53CBq3qjoVr9kEGrmbyCv HIjD62gS+s9T8maYr6VQ== MIME-Version: 1.0 Received: by 10.229.40.139 with SMTP id k11mr148313qce.135.1302131604659; Wed, 06 Apr 2011 16:13:24 -0700 (PDT) Received: by 10.229.253.203 with HTTP; Wed, 6 Apr 2011 16:13:24 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 23:13:24 +0000 Message-ID: From: Erik Kline To: carlos@lacnic.net Content-Type: multipart/alternative; boundary=001636834014bf1ea504a048236c X-System-Of-Record: true Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 23:11:44 -0000 --001636834014bf1ea504a048236c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Were you able to watch Geoff Huston's presentation? It generally addressed these misconceptions. On 6 April 2011 22:59, Carlos Martinez-Cagnazzo wrot= e: > I agree with Cristopher's comment. Personally I believe we should fix > what is wrong with 6to4 (mostly the anycast part), and make it more > manageable from an operators point of view rather than just dispose of > what can be a very valuable transition tool. > > regards > > Carlos > > On Wed, Apr 6, 2011 at 7:43 PM, Christopher Palmer > wrote: > > In =E2=80=9CRequest to move Connection of IPv6 Domains via IPv4 Clouds= (6to4) to > > Historic status=E2=80=9D > > > > > > > > There is this recommendation: > > > > > > > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > > > > pointing to this document. Reassignment of the prefix for any usage > > > > requires justification via an IETF Standards Action [RFC5226]. > > > > > > > > It is not clear why this is necessary. > > > > > > > > If major vendors were to disable 6to4 by default, that would fix the > > brokenness issue, while still allow for this prefix to be used in > > specialized or enthusiast scenarios. Isn=E2=80=99t any other action ove= rkill? > > > > > > > > Thanks! > > > > ---------------------------- > > > > Christopher.Palmer@Microsoft.com > > > > Program Manager > > > > IPv6 @ Windows > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > -- > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Carlos M. Martinez-Cagnazzo > http://www.labs.lacnic.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001636834014bf1ea504a048236c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Were you able to watch Geoff Huston's presentation? =C2=A0It generally = addressed these misconceptions.

On 6 Apri= l 2011 22:59, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
I agree with Cristopher's comment. Pers= onally I believe we should fix
what is wrong with 6to4 (mostly the anycast part), and make it more
manageable from an operators point of view rather than just dispose of
what can be a very valuable transition tool.

regards

Carlos

On Wed, Apr 6, 2011 at 7:43 PM, Christopher Palmer
<Christopher.Palmer@= microsoft.com> wrote:
> In =C2=A0=E2=80=9CRequest to move Connection of IPv6 Domains via IPv4 = Clouds (6to4) to
> Historic status=E2=80=9D
>
>
>
> There is this recommendation:
>
>
>
> IANA is requested to mark the 2002::/16 prefix as "deprecated&quo= t;,
>
> =C2=A0=C2=A0 pointing to this document.=C2=A0 Reassignment of the pref= ix for any usage
>
> =C2=A0=C2=A0 requires justification via an IETF Standards Action [RFC5= 226].
>
>
>
> It is not clear why this is necessary.
>
>
>
> If major vendors were to disable 6to4 by default, that would fix the > brokenness issue, while still allow for this prefix to be used in
> specialized or enthusiast scenarios. Isn=E2=80=99t any other action ov= erkill?
>
>
>
> Thanks!
>
> ----------------------------
>
> Christopher.Palmer@Microsoft.com
>
> Program Manager
>
> IPv6 @ Windows
>
>
>
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>



--
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Carlos M. Martinez-Cagnazzo
http://www.labs.la= cnic.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--001636834014bf1ea504a048236c-- From jhw@apple.com Wed Apr 6 16:13:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97B63A6804 for ; Wed, 6 Apr 2011 16:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 M7cXm6Mg7gZF for ; Wed, 6 Apr 2011 16:13:28 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by core3.amsl.com (Postfix) with ESMTP id 6A73E3A67FC for ; Wed, 6 Apr 2011 16:13:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJ9002DY791GUB0@localhost.apple.com> for v6ops@ietf.org; Wed, 06 Apr 2011 16:15:12 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-40-4d9cf400626d Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id 08.22.18996.004FC9D4; Wed, 06 Apr 2011 16:15:12 -0700 (PDT) Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ900DSY79C7X20@et.apple.com> for v6ops@ietf.org; Wed, 06 Apr 2011 16:15:12 -0700 (PDT) From: james woodyatt In-reply-to: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 06 Apr 2011 16:15:12 -0700 Message-id: <83AB39A1-0B36-40E3-AB4A-7D8437A5B941@apple.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1214) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 23:13:28 -0000 On Apr 6, 2011, at 15:43 , Christopher Palmer wrote: > > There is this recommendation: > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > pointing to this document. Reassignment of the prefix for any usage > requires justification via an IETF Standards Action [RFC5226]. > > It is not clear why this is necessary. Because this draft obsoletes the documents to which IANA currently points for the 2002::/16 prefix. Not sure what having IANA mark the prefix as "deprecated" is hoped to accomplish... but the rest of the IANA Considerations section is fine with me. -- james woodyatt member of technical staff, core os networking From carlosm3011@gmail.com Wed Apr 6 16:19: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 758F33A67F3 for ; Wed, 6 Apr 2011 16:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QqQFHTadAnQ for ; Wed, 6 Apr 2011 16:19:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A1C113A66B4 for ; Wed, 6 Apr 2011 16:19:18 -0700 (PDT) Received: by iwn39 with SMTP id 39so2385250iwn.31 for ; Wed, 06 Apr 2011 16:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fo3yBK1xytsldD/S1jREQVytSwk7rjUvaW2Gc+Fp0D4=; b=TSZLAOgox6x0R2/FPzL1u9y74cADn7UWlnPEMw8dSjYsNvumCMKnR31vC6SRT00sSO rMZCrF+bld5+Sh6DV3OocGyL13PW8Xi5PbrmPnEU3ffl+mRO1FATWgQ2cDrv11Zeab2M 6SqPMykDE492OUHTUkeciDpfyAdxDLSshivwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZHVCnu+r2aZLdAnAFbwFVXaZ9Bjxx8yDbCMpGBvYkShHyGweMask/lvbY/syoIVbay nRhhRrLmOFm4YyrvVB0QEnkvVKuW+YXzGkQB7GOwNJFv9GDvI42JhySfsGthQGddWs8X Wb7x5tSXFUCtGInlTWWFD9qJJz/gjQm2sghU4= MIME-Version: 1.0 Received: by 10.43.58.208 with SMTP id wl16mr279212icb.319.1302132062787; Wed, 06 Apr 2011 16:21:02 -0700 (PDT) Sender: carlosm3011@gmail.com Received: by 10.42.244.73 with HTTP; Wed, 6 Apr 2011 16:21:02 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 20:21:02 -0300 X-Google-Sender-Auth: GOSqS8ngQ_mqvrrPYkEnZU-QyXs Message-ID: From: Carlos Martinez-Cagnazzo To: Erik Kline Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 23:19:43 -0000 I was there, but I'm not sure I follow what you mean. If you can be more specific, I would appreciate it. On Wed, Apr 6, 2011 at 8:13 PM, Erik Kline wrote: > Were you able to watch Geoff Huston's presentation? =A0It generally addre= ssed > these misconceptions. > > On 6 April 2011 22:59, Carlos Martinez-Cagnazzo > wrote: >> >> I agree with Cristopher's comment. Personally I believe we should fix >> what is wrong with 6to4 (mostly the anycast part), and make it more >> manageable from an operators point of view rather than just dispose of >> what can be a very valuable transition tool. >> >> regards >> >> Carlos >> >> On Wed, Apr 6, 2011 at 7:43 PM, Christopher Palmer >> wrote: >> > In =A0=93Request to move Connection of IPv6 Domains via IPv4 Clouds (6= to4) >> > to >> > Historic status=94 >> > >> > >> > >> > There is this recommendation: >> > >> > >> > >> > IANA is requested to mark the 2002::/16 prefix as "deprecated", >> > >> > =A0=A0 pointing to this document.=A0 Reassignment of the prefix for an= y usage >> > >> > =A0=A0 requires justification via an IETF Standards Action [RFC5226]. >> > >> > >> > >> > It is not clear why this is necessary. >> > >> > >> > >> > If major vendors were to disable 6to4 by default, that would fix the >> > brokenness issue, while still allow for this prefix to be used in >> > specialized or enthusiast scenarios. Isn=92t any other action overkill= ? >> > >> > >> > >> > Thanks! >> > >> > ---------------------------- >> > >> > Christopher.Palmer@Microsoft.com >> > >> > Program Manager >> > >> > IPv6 @ Windows >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > >> >> >> >> -- >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> Carlos M. Martinez-Cagnazzo >> http://www.labs.lacnic.net >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From ek@google.com Wed Apr 6 16:27: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 747F03A695E for ; Wed, 6 Apr 2011 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.916 X-Spam-Level: X-Spam-Status: No, score=-105.916 tagged_above=-999 required=5 tests=[AWL=0.060, 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 vBnahAhThILl for ; Wed, 6 Apr 2011 16:27:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 277683A6810 for ; Wed, 6 Apr 2011 16:27:54 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p36NTbBo016748 for ; Wed, 6 Apr 2011 16:29:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302132578; bh=zEo/3FuZlJkbRak+6sDmvuRQYb0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UvL19jDKKil6uIpDl1X0WKw/g3ZwcuUTMR9FlhdhDdEobjbMudFlWKgj6EO335ctt qQUFhZqjVzAuoHs7geFDA== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by kpbe14.cbf.corp.google.com with ESMTP id p36NTOcR020284 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 16:29:36 -0700 Received: by qwj9 with SMTP id 9so1733671qwj.21 for ; Wed, 06 Apr 2011 16:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HlobWiNdEZaDF74rOR16udTNiGPgxnB9aDR87onryIs=; b=UF3Ni6s7L0Cx5J11TAN9aRMBxnlTQSKFwJ2Dx8ugR1n8i0Wr7+hMAb/MYVxH3U2suz 2DcGYMPMw6ZJU+2GA0uw== 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=gnKobZIPDQs3n+ChVFdE0o9HmPPJOavY8w9xLjsQfyBQb+2vvmLeALVfIKt+QHUhFi YolHRqQy2IJvGxuwfsGw== MIME-Version: 1.0 Received: by 10.229.117.95 with SMTP id p31mr159248qcq.97.1302132576518; Wed, 06 Apr 2011 16:29:36 -0700 (PDT) Received: by 10.229.253.203 with HTTP; Wed, 6 Apr 2011 16:29:36 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 Apr 2011 23:29:36 +0000 Message-ID: From: Erik Kline To: Carlos Martinez-Cagnazzo Content-Type: multipart/alternative; boundary=000e0cd60836ac836404a0485d0a X-System-Of-Record: true Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2011 23:27:57 -0000 --000e0cd60836ac836404a0485d0a Content-Type: text/plain; charset=UTF-8 I would refer specifically to the numbers for 6to4 customers where the return path was directly on the server, i.e. the client-to-server relay was not a problem (because the SYN packet reached the servers) and the server-to-client relay was not a problem (because the server was encapsulating directly). Even in that scenario the connection completion rate was abysmal, IIRC. All of which reinforces the notion that it's not a valuable transition mechanism. It's a experimental thing, and plenty useful as such. But it's not production quality unless it's fully managed (i.e. it can be confirmed that no proto41 blocking is going on, etc). In which case it's basically 6rd or static tunnels. On 6 April 2011 23:21, Carlos Martinez-Cagnazzo wrote: > I was there, but I'm not sure I follow what you mean. If you can be > more specific, I would appreciate it. --000e0cd60836ac836404a0485d0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would refer specifically to the numbers for 6to4 customers where the retu= rn path was directly on the server, i.e. the client-to-server relay was not= a problem (because the SYN packet reached the servers) and the server-to-c= lient relay was not a problem (because the server was encapsulating directl= y). =C2=A0Even in that scenario the connection completion rate was abysmal,= IIRC.

All of which reinforces the notion that it's not a valua= ble transition mechanism. =C2=A0It's a experimental thing, and plenty u= seful as such. =C2=A0But it's not production quality unless it's fu= lly managed (i.e. it can be confirmed that no proto41 blocking is going on,= etc). =C2=A0In which case it's basically 6rd or static tunnels.

On 6 April 2011 23:21, Carlos Martinez-Cagna= zzo <carlos@lacni= c.net> wrote:
I was there, but I'm not sure I follow what you mean. If you can be
more specific, I would appreciate it.
--000e0cd60836ac836404a0485d0a-- From Fred.L.Templin@boeing.com Wed Apr 6 16: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 29AB33A6811 for ; Wed, 6 Apr 2011 16:35:11 -0700 (PDT) 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.250, 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 r4y19bzDn-Bi for ; Wed, 6 Apr 2011 16:35:10 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 2F2383A6804 for ; Wed, 6 Apr 2011 16:35:10 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p36NachY004561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 16:36:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p36NackN012616; Wed, 6 Apr 2011 18:36:38 -0500 (CDT) 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 p36NabvX012606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Apr 2011 18:36:38 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Wed, 6 Apr 2011 16:36:37 -0700 From: "Templin, Fred L" To: Ole Troan , "Weil, Jason" Date: Wed, 6 Apr 2011 16:36:35 -0700 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acv0kwUL4M9acvFhTiGtfN0HnpWdIQAGLbNA Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> <009b01cbf3f1$4b22c970$e1685c50$@com> <34E4F50CAFA10349A41E0756550084FB049FEF81@!PRVPEXVS04.corp.twcable.com> <6634030F-7E3D-439F-97D0-E6C85ACECA76@employees.org> In-Reply-To: <6634030F-7E3D-439F-97D0-E6C85ACECA76@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 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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: Wed, 06 Apr 2011 23:35:11 -0000 Hi Ole,=20 > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of=20 > Ole Troan > Sent: Wednesday, April 06, 2011 12:44 PM > To: Weil, Jason > Cc: Tina Tsou; 'Hemant Singh (shemant)'; Templin, Fred L;=20 > 'Fred Baker (fred)'; 'IPv6 Ops WG'; 'Tony Hain (ahain)' > Subject: Re: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > > I am not able clearly parse the data to the column=20 > headings, but if it helps the diagram below is what I was suggesting. > >=20 > > [DS HOST]--[v4 CE ROUTER]--[v6 BIS ROUTER]-->Service Provider > > | > > [DS HOST] > >=20 > > The issue in the topology depicted above is the IPv4-only=20 > CE (interior) ROUTER is out of scope for the -bis draft=20 > today. The current scope covers transition technologies on=20 > the WAN (6rd and DS-LITE) and a simple two router setup with=20 > the interior router being an IPv6 CE router. >=20 > what is the proposal, that the IPv6 CE comes with ISATAP=20 > supported on by default or be capable of doing ISATAP=20 > tunneling? (remember we are trying to make these routers=20 > require no management). At least capable of acting as an ISATAP router on the LAN side. On by default would require some means of selecting one or more IPv6 prefixes to assign to the ISATAP link, but that should be easy to carve off of whatever stateful or stateless prefix delegations the CE receives via its WAN connection. > if ISATAP is enabled by default, how do we know that the user=20 > hasn't intended a topology separating host on different links=20 > and by building a single virtual link we are violating that=20 > policy? Such a user would be in a more competent position to disable and/or reconfigure the on-by-default settings than a novice user would be to enable an off-by-default setting. Besides, the ISATAP virtual link would not magically bypass any IPv4 filtering gateways in the network. So, the ISATAP virtual link might be partitioned, but the IPv4 filtering policies would not be violated.=20 > e.g. why were the extra routers there in the first place. For the same reasons that any IPv4 site administrator would portion the site off into separate subnets separated by IPv4 routers. > how is ISATAP provisioning supposed to work? so far the IPv6=20 > CE router work has focused on the profile of the router=20 > itself, and it has references standards track document for=20 > WAN side and LAN side behaviour. There is a lot of documented operational guidance on how to provision an ISATAP site service outside of the IETF document series - some of it from your company. Thanks - Fred fred.l.templin@boeing.com =20 > cheers, > Ole= From marka@isc.org Wed Apr 6 17:06: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 083DC3A699D for ; Wed, 6 Apr 2011 17:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 NzIz7cR1fyzm for ; Wed, 6 Apr 2011 17:06:28 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 333503A699A for ; Wed, 6 Apr 2011 17:06:28 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 616325F984C; Thu, 7 Apr 2011 00:07:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 7C85B216C31; Thu, 7 Apr 2011 00:07:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6C6DEDE2FEB; Thu, 7 Apr 2011 10:07:52 +1000 (EST) To: Erik Kline From: Mark Andrews References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-reply-to: Your message of "Wed, 06 Apr 2011 23:29:36 GMT." Date: Thu, 07 Apr 2011 10:07:52 +1000 Message-Id: <20110407000752.6C6DEDE2FEB@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 00:06:29 -0000 In message , Erik Kline wri tes: > I would refer specifically to the numbers for 6to4 customers where the > return path was directly on the server, i.e. the client-to-server relay was > not a problem (because the SYN packet reached the servers) and the > server-to-client relay was not a problem (because the server was > encapsulating directly). Even in that scenario the connection completion > rate was abysmal, IIRC. > > All of which reinforces the notion that it's not a valuable transition > mechanism. It's a experimental thing, and plenty useful as such. But it's > not production quality unless it's fully managed (i.e. it can be confirmed > that no proto41 blocking is going on, etc). In which case it's basically > 6rd or static tunnels. I suspect that a lot of the problem isn't 6to4 but rather just IPv6. Just blocking IPv6 in and failing to block IPv6 out will produce exactly these symptoms. 6to4 is just the working IPv6 path they have. The packets do get back to the originating machine where they are dropped before getting to the application. Sure there is some protocol 41 filtering and there are some firewalls that only allow return traffic from the anycast address but I suspect that if we followed up and found out the actual failure causes in most cases it isn't 6to4 that is the problem. 6to4 is working fine. The packets get out and back to the originating machine. Sites that have deliberately turned on IPv6 don't have this problem as the firewalls have been configured to permit IPv6 traffic. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Christopher.Palmer@microsoft.com Wed Apr 6 17:19: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 D2DF13A68B1 for ; Wed, 6 Apr 2011 17:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRUP-OnWgAsE for ; Wed, 6 Apr 2011 17:19:42 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4E2393A67A7 for ; Wed, 6 Apr 2011 17:19:42 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 17:21:26 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 17:21:26 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 17:21:26 -0700 From: Christopher Palmer To: Erik Kline , Carlos Martinez-Cagnazzo Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv0q/0Z/RyklE39TrerPIyoUARNXwAPPYYAAAB83wAAAERAAAAATJcAAAzpz5A= Date: Thu, 7 Apr 2011 00:21:25 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A848@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A848TK5EX14MBXW601w_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 00:19:44 -0000 --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A848TK5EX14MBXW601w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc3RpbGwgc2VlbXMgbGlrZSBvdmVya2lsbC4NCg0KSWYgaG9zdHMgbm8gbG9uZ2VyIGVuYWJs ZSA2dG80IGJ5IGRlZmF1bHQsIHRoaXMgc2NlbmFyaW8gd2lsbCBuZXZlciBvY2N1ci4gVGhlcmUg aXMgbm8gbmVlZCB0byBhZGRpdGlvbmFsbHkgZGVwcmVjYXRlIHRoZSBwcmVmaXgg4oCTIHRvIGVz c2VudGlhbGx5IHR1cm4gb2ZmIDZ0bzQgdHdpY2U/DQoNCldoYXQgb3BlcmF0aW9uYWwgdmFsdWUg ZG9lcyBkZXByZWNhdGluZyB0aGUgcHJlZml4IHByb3ZpZGU/DQoNCkJlc3QhDQpDaHJpcw0KDQpG cm9tOiBFcmlrIEtsaW5lIFttYWlsdG86ZWtAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMDYsIDIwMTEgNDozMCBQTQ0KVG86IENhcmxvcyBNYXJ0aW5lei1DYWduYXp6bw0KQ2M6 IENocmlzdG9waGVyIFBhbG1lcjsgdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNd IERlcHJlY2F0aW5nIDIwMDI6Oi8xNiAtIDZ0bzQgSGlzdG9yaWMgU3RhdHVzDQoNCkkgd291bGQg cmVmZXIgc3BlY2lmaWNhbGx5IHRvIHRoZSBudW1iZXJzIGZvciA2dG80IGN1c3RvbWVycyB3aGVy ZSB0aGUgcmV0dXJuIHBhdGggd2FzIGRpcmVjdGx5IG9uIHRoZSBzZXJ2ZXIsIGkuZS4gdGhlIGNs aWVudC10by1zZXJ2ZXIgcmVsYXkgd2FzIG5vdCBhIHByb2JsZW0gKGJlY2F1c2UgdGhlIFNZTiBw YWNrZXQgcmVhY2hlZCB0aGUgc2VydmVycykgYW5kIHRoZSBzZXJ2ZXItdG8tY2xpZW50IHJlbGF5 IHdhcyBub3QgYSBwcm9ibGVtIChiZWNhdXNlIHRoZSBzZXJ2ZXIgd2FzIGVuY2Fwc3VsYXRpbmcg ZGlyZWN0bHkpLiAgRXZlbiBpbiB0aGF0IHNjZW5hcmlvIHRoZSBjb25uZWN0aW9uIGNvbXBsZXRp b24gcmF0ZSB3YXMgYWJ5c21hbCwgSUlSQy4NCg0KQWxsIG9mIHdoaWNoIHJlaW5mb3JjZXMgdGhl IG5vdGlvbiB0aGF0IGl0J3Mgbm90IGEgdmFsdWFibGUgdHJhbnNpdGlvbiBtZWNoYW5pc20uICBJ dCdzIGEgZXhwZXJpbWVudGFsIHRoaW5nLCBhbmQgcGxlbnR5IHVzZWZ1bCBhcyBzdWNoLiAgQnV0 IGl0J3Mgbm90IHByb2R1Y3Rpb24gcXVhbGl0eSB1bmxlc3MgaXQncyBmdWxseSBtYW5hZ2VkIChp LmUuIGl0IGNhbiBiZSBjb25maXJtZWQgdGhhdCBubyBwcm90bzQxIGJsb2NraW5nIGlzIGdvaW5n IG9uLCBldGMpLiAgSW4gd2hpY2ggY2FzZSBpdCdzIGJhc2ljYWxseSA2cmQgb3Igc3RhdGljIHR1 bm5lbHMuDQpPbiA2IEFwcmlsIDIwMTEgMjM6MjEsIENhcmxvcyBNYXJ0aW5lei1DYWduYXp6byA8 Y2FybG9zQGxhY25pYy5uZXQ8bWFpbHRvOmNhcmxvc0BsYWNuaWMubmV0Pj4gd3JvdGU6DQpJIHdh cyB0aGVyZSwgYnV0IEknbSBub3Qgc3VyZSBJIGZvbGxvdyB3aGF0IHlvdSBtZWFuLiBJZiB5b3Ug Y2FuIGJlDQptb3JlIHNwZWNpZmljLCBJIHdvdWxkIGFwcHJlY2lhdGUgaXQuDQo= --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A848TK5EX14MBXW601w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHN0aWxsIHNlZW1zIGxpa2Ugb3ZlcmtpbGwuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmIGhvc3RzIG5vIGxvbmdlciBlbmFibGUgNnRvNCBieSBkZWZhdWx0LCB0aGlzIHNjZW5h cmlvIHdpbGwgbmV2ZXIgb2NjdXIuIFRoZXJlIGlzIG5vIG5lZWQgdG8gYWRkaXRpb25hbGx5IGRl cHJlY2F0ZSB0aGUgcHJlZml4IOKAkyB0byBlc3NlbnRpYWxseSB0dXJuIG9mZiA2dG80DQogdHdp Y2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5XaGF0IG9wZXJhdGlvbmFsIHZhbHVlIGRvZXMgZGVwcmVjYXRpbmcgdGhl IHByZWZpeCBwcm92aWRlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2hyaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWsgS2xpbmUgW21haWx0bzpla0Bnb29nbGUuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMDYsIDIwMTEgNDozMCBQTTxi cj4NCjxiPlRvOjwvYj4gQ2FybG9zIE1hcnRpbmV6LUNhZ25henpvPGJyPg0KPGI+Q2M6PC9iPiBD aHJpc3RvcGhlciBQYWxtZXI7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdjZvcHNdIERlcHJlY2F0aW5nIDIwMDI6Oi8xNiAtIDZ0bzQgSGlzdG9yaWMgU3RhdHVzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcmVmZXIgc3BlY2lm aWNhbGx5IHRvIHRoZSBudW1iZXJzIGZvciA2dG80IGN1c3RvbWVycyB3aGVyZSB0aGUgcmV0dXJu IHBhdGggd2FzIGRpcmVjdGx5IG9uIHRoZSBzZXJ2ZXIsIGkuZS4gdGhlIGNsaWVudC10by1zZXJ2 ZXIgcmVsYXkgd2FzIG5vdCBhIHByb2JsZW0gKGJlY2F1c2UgdGhlIFNZTiBwYWNrZXQgcmVhY2hl ZCB0aGUgc2VydmVycykgYW5kIHRoZSBzZXJ2ZXItdG8tY2xpZW50IHJlbGF5DQogd2FzIG5vdCBh IHByb2JsZW0gKGJlY2F1c2UgdGhlIHNlcnZlciB3YXMgZW5jYXBzdWxhdGluZyBkaXJlY3RseSku ICZuYnNwO0V2ZW4gaW4gdGhhdCBzY2VuYXJpbyB0aGUgY29ubmVjdGlvbiBjb21wbGV0aW9uIHJh dGUgd2FzIGFieXNtYWwsIElJUkMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFsbCBvZiB3aGljaCByZWlu Zm9yY2VzIHRoZSBub3Rpb24gdGhhdCBpdCdzIG5vdCBhIHZhbHVhYmxlIHRyYW5zaXRpb24gbWVj aGFuaXNtLiAmbmJzcDtJdCdzIGEgZXhwZXJpbWVudGFsIHRoaW5nLCBhbmQgcGxlbnR5IHVzZWZ1 bCBhcyBzdWNoLiAmbmJzcDtCdXQgaXQncyBub3QgcHJvZHVjdGlvbiBxdWFsaXR5IHVubGVzcyBp dCdzIGZ1bGx5IG1hbmFnZWQgKGkuZS4gaXQgY2FuDQogYmUgY29uZmlybWVkIHRoYXQgbm8gcHJv dG80MSBibG9ja2luZyBpcyBnb2luZyBvbiwgZXRjKS4gJm5ic3A7SW4gd2hpY2ggY2FzZSBpdCdz IGJhc2ljYWxseSA2cmQgb3Igc3RhdGljIHR1bm5lbHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNiBBcHJpbCAyMDExIDIzOjIxLCBDYXJsb3MgTWFydGlu ZXotQ2FnbmF6em8gJmx0OzxhIGhyZWY9Im1haWx0bzpjYXJsb3NAbGFjbmljLm5ldCI+Y2FybG9z QGxhY25pYy5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd2FzIHRoZXJlLCBidXQgSSdtIG5vdCBzdXJlIEkgZm9sbG93IHdoYXQgeW91IG1l YW4uIElmIHlvdSBjYW4gYmU8YnI+DQptb3JlIHNwZWNpZmljLCBJIHdvdWxkIGFwcHJlY2lhdGUg aXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_0AB09EDBCD1C484EBE45978D62F3513C3CD8A848TK5EX14MBXW601w_-- From joelja@bogus.com Wed Apr 6 18: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 119F83A6834 for ; Wed, 6 Apr 2011 18:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRuJ4cHc71EG for ; Wed, 6 Apr 2011 18:24:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id CD2E43A6828 for ; Wed, 6 Apr 2011 18:24:39 -0700 (PDT) Received: from [64.9.233.35] (user-64-9-233-35.googlewifi.com [64.9.233.35]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p371QH1k087338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 01:26:18 GMT (envelope-from joelja@bogus.com) References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> X-Mailer: iPad Mail (8G4) From: Joel Jaeggli Date: Wed, 6 Apr 2011 18:26:37 -0700 To: Carlos Martinez-Cagnazzo X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 07 Apr 2011 01:26:19 +0000 (UTC) Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 01:24:41 -0000 It can't be fixed. You can engage in incremental improvements which you shou= ld do (even as it is deprecated), but 6to4 remains a pitfall which hosts tha= t have it enabled will trip over in the dark due to properties of their ipv4= connectivity. A host with a public but natted v4 address will alwas get hos= ed by this. Joel's widget number 2 On Apr 6, 2011, at 16:21, Carlos Martinez-Cagnazzo wrote= : > I was there, but I'm not sure I follow what you mean. If you can be > more specific, I would appreciate it. >=20 > On Wed, Apr 6, 2011 at 8:13 PM, Erik Kline wrote: >> Were you able to watch Geoff Huston's presentation? It generally address= ed >> these misconceptions. >>=20 >> On 6 April 2011 22:59, Carlos Martinez-Cagnazzo >> wrote: >>>=20 >>> I agree with Cristopher's comment. Personally I believe we should fix >>> what is wrong with 6to4 (mostly the anycast part), and make it more >>> manageable from an operators point of view rather than just dispose of >>> what can be a very valuable transition tool. >>>=20 >>> regards >>>=20 >>> Carlos >>>=20 >>> On Wed, Apr 6, 2011 at 7:43 PM, Christopher Palmer >>> wrote: >>>> In =E2=80=9CRequest to move Connection of IPv6 Domains via IPv4 Clouds= (6to4) >>>> to >>>> Historic status=E2=80=9D >>>>=20 >>>>=20 >>>>=20 >>>> There is this recommendation: >>>>=20 >>>>=20 >>>>=20 >>>> IANA is requested to mark the 2002::/16 prefix as "deprecated", >>>>=20 >>>> pointing to this document. Reassignment of the prefix for any usage= >>>>=20 >>>> requires justification via an IETF Standards Action [RFC5226]. >>>>=20 >>>>=20 >>>>=20 >>>> It is not clear why this is necessary. >>>>=20 >>>>=20 >>>>=20 >>>> If major vendors were to disable 6to4 by default, that would fix the >>>> brokenness issue, while still allow for this prefix to be used in >>>> specialized or enthusiast scenarios. Isn=E2=80=99t any other action ove= rkill? >>>>=20 >>>>=20 >>>>=20 >>>> Thanks! >>>>=20 >>>> ---------------------------- >>>>=20 >>>> Christopher.Palmer@Microsoft.com >>>>=20 >>>> Program Manager >>>>=20 >>>> IPv6 @ Windows >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> Carlos M. Martinez-Cagnazzo >>> http://www.labs.lacnic.net >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From Christopher.Palmer@microsoft.com Wed Apr 6 18:36:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8425C3A69A5 for ; Wed, 6 Apr 2011 18:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 OFhdojx0FKDG for ; Wed, 6 Apr 2011 18:36:45 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 257EC3A6824 for ; Wed, 6 Apr 2011 18:36:45 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 18:38:29 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 18:38:29 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 18:38:29 -0700 From: Christopher Palmer To: Joel Jaeggli , Carlos Martinez-Cagnazzo Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv0q/0Z/RyklE39TrerPIyoUARNXwAPPYYAAAB83wAAAERAAAAEYs2AAA6Hu1A= Date: Thu, 7 Apr 2011 01:38:29 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> In-Reply-To: <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 01:36:46 -0000 IkEgaG9zdCB3aXRoIGEgcHVibGljIGJ1dCBuYXR0ZWQgdjQgYWRkcmVzcyB3aWxsIGFsd2FzIGdl dCBob3NlZCBieSB0aGlzLiINCg0KQSBob3N0IGluIHRoYXQgY29uZGl0aW9uIHdpbGwgaGF2ZSBh IGJyb2tlbiA2dG80IGFkZHJlc3MsIGJ1dCB3b24ndCBleHBlcmllbmNlIGEgZGVncmFkYXRpb24g aW4gdGhlaXIgd2ViIGV4cGVyaWVuY2UgaWYgdGhleSBoYXZlIFJGQyAzNDg0IGltcGxlbWVudGVk LiANCg0KU28gcmVhbGx5IHRoaXMgd291bGQgYmUgdGhlIHRoaXJkIHByb3Bvc2VkIDZ0bzQgbWl0 aWdhdGlvbjoNCg0KMS4gRW5zdXJpbmcgdGhhdCBJUHY0LT5JUHY0IGlzIHJhbmtlZCBoaWdoZXIg dGhhbiA2dG80LT5JUHY2IGluIHRoZSBSRkMgMzQ4NC4NCjIuIENoYW5naW5nIGRlZmF1bHQgaG9z dCBiZWhhdmlvci4gKHN0aWxsIGJlaW5nIGRlYmF0ZWQpDQozLiBEZXByZWNhdGlvbiBvZiB0aGUg cHJlZml4Lg0KDQpHaXZlbiAoMSkgYW5kICgyKSwgdGhlIG9wZXJhdGlvbmFsIHZhbHVlIG9mIDMg aXMgc3RpbGwgbG9zdCBvbiBtZS4gSXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgSVNQcyBzdG9wIHJv dXRpbmcgNnRvNCBwYWNrZXRzPyBJcyB0aGlzIGEgc2lnbmFsIHRoYXQgd2UgZG9uJ3QganVzdCBo YXRlIDZ0bzQsIGJ1dCB3ZSBzdXBlciBoYXRlIGl0Pw0KDQpDaHJpcw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9lbCBKYWVnZ2xpIFttYWlsdG86am9lbGphQGJvZ3VzLmNv bV0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDExIDY6MjcgUE0NClRvOiBDYXJsb3Mg TWFydGluZXotQ2FnbmF6em8NCkNjOiBFcmlrIEtsaW5lOyB2Nm9wc0BpZXRmLm9yZzsgQ2hyaXN0 b3BoZXIgUGFsbWVyDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBEZXByZWNhdGluZyAyMDAyOjovMTYg LSA2dG80IEhpc3RvcmljIFN0YXR1cw0KDQpJdCBjYW4ndCBiZSBmaXhlZC4gWW91IGNhbiBlbmdh Z2UgaW4gaW5jcmVtZW50YWwgaW1wcm92ZW1lbnRzIHdoaWNoIHlvdSBzaG91bGQgZG8gKGV2ZW4g YXMgaXQgaXMgZGVwcmVjYXRlZCksIGJ1dCA2dG80IHJlbWFpbnMgYSBwaXRmYWxsIHdoaWNoIGhv c3RzIHRoYXQgaGF2ZSBpdCBlbmFibGVkIHdpbGwgdHJpcCBvdmVyIGluIHRoZSBkYXJrIGR1ZSB0 byBwcm9wZXJ0aWVzIG9mIHRoZWlyIGlwdjQgY29ubmVjdGl2aXR5LiBBIGhvc3Qgd2l0aCBhIHB1 YmxpYyBidXQgbmF0dGVkIHY0IGFkZHJlc3Mgd2lsbCBhbHdhcyBnZXQgaG9zZWQgYnkgdGhpcy4N Cg0KSm9lbCdzIHdpZGdldCBudW1iZXIgMg0KDQpPbiBBcHIgNiwgMjAxMSwgYXQgMTY6MjEsIENh cmxvcyBNYXJ0aW5lei1DYWduYXp6byA8Y2FybG9zQGxhY25pYy5uZXQ+IHdyb3RlOg0KDQo+IEkg d2FzIHRoZXJlLCBidXQgSSdtIG5vdCBzdXJlIEkgZm9sbG93IHdoYXQgeW91IG1lYW4uIElmIHlv dSBjYW4gYmUNCj4gbW9yZSBzcGVjaWZpYywgSSB3b3VsZCBhcHByZWNpYXRlIGl0Lg0KPiANCj4g T24gV2VkLCBBcHIgNiwgMjAxMSBhdCA4OjEzIFBNLCBFcmlrIEtsaW5lIDxla0Bnb29nbGUuY29t PiB3cm90ZToNCj4+IFdlcmUgeW91IGFibGUgdG8gd2F0Y2ggR2VvZmYgSHVzdG9uJ3MgcHJlc2Vu dGF0aW9uPyAgSXQgZ2VuZXJhbGx5IGFkZHJlc3NlZA0KPj4gdGhlc2UgbWlzY29uY2VwdGlvbnMu DQo+PiANCj4+IE9uIDYgQXByaWwgMjAxMSAyMjo1OSwgQ2FybG9zIE1hcnRpbmV6LUNhZ25henpv IDxjYXJsb3NtMzAxMUBnbWFpbC5jb20+DQo+PiB3cm90ZToNCj4+PiANCj4+PiBJIGFncmVlIHdp dGggQ3Jpc3RvcGhlcidzIGNvbW1lbnQuIFBlcnNvbmFsbHkgSSBiZWxpZXZlIHdlIHNob3VsZCBm aXgNCj4+PiB3aGF0IGlzIHdyb25nIHdpdGggNnRvNCAobW9zdGx5IHRoZSBhbnljYXN0IHBhcnQp LCBhbmQgbWFrZSBpdCBtb3JlDQo+Pj4gbWFuYWdlYWJsZSBmcm9tIGFuIG9wZXJhdG9ycyBwb2lu dCBvZiB2aWV3IHJhdGhlciB0aGFuIGp1c3QgZGlzcG9zZSBvZg0KPj4+IHdoYXQgY2FuIGJlIGEg dmVyeSB2YWx1YWJsZSB0cmFuc2l0aW9uIHRvb2wuDQo+Pj4gDQo+Pj4gcmVnYXJkcw0KPj4+IA0K Pj4+IENhcmxvcw0KPj4+IA0KPj4+IE9uIFdlZCwgQXByIDYsIDIwMTEgYXQgNzo0MyBQTSwgQ2hy aXN0b3BoZXIgUGFsbWVyDQo+Pj4gPENocmlzdG9waGVyLlBhbG1lckBtaWNyb3NvZnQuY29tPiB3 cm90ZToNCj4+Pj4gSW4gIOKAnFJlcXVlc3QgdG8gbW92ZSBDb25uZWN0aW9uIG9mIElQdjYgRG9t YWlucyB2aWEgSVB2NCBDbG91ZHMgKDZ0bzQpDQo+Pj4+IHRvDQo+Pj4+IEhpc3RvcmljIHN0YXR1 c+KAnQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBUaGVyZSBpcyB0aGlzIHJlY29tbWVuZGF0 aW9uOg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBJQU5BIGlzIHJlcXVlc3RlZCB0byBtYXJr IHRoZSAyMDAyOjovMTYgcHJlZml4IGFzICJkZXByZWNhdGVkIiwNCj4+Pj4gDQo+Pj4+ICAgIHBv aW50aW5nIHRvIHRoaXMgZG9jdW1lbnQuICBSZWFzc2lnbm1lbnQgb2YgdGhlIHByZWZpeCBmb3Ig YW55IHVzYWdlDQo+Pj4+IA0KPj4+PiAgICByZXF1aXJlcyBqdXN0aWZpY2F0aW9uIHZpYSBhbiBJ RVRGIFN0YW5kYXJkcyBBY3Rpb24gW1JGQzUyMjZdLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ PiBJdCBpcyBub3QgY2xlYXIgd2h5IHRoaXMgaXMgbmVjZXNzYXJ5Lg0KPj4+PiANCj4+Pj4gDQo+ Pj4+IA0KPj4+PiBJZiBtYWpvciB2ZW5kb3JzIHdlcmUgdG8gZGlzYWJsZSA2dG80IGJ5IGRlZmF1 bHQsIHRoYXQgd291bGQgZml4IHRoZQ0KPj4+PiBicm9rZW5uZXNzIGlzc3VlLCB3aGlsZSBzdGls bCBhbGxvdyBmb3IgdGhpcyBwcmVmaXggdG8gYmUgdXNlZCBpbg0KPj4+PiBzcGVjaWFsaXplZCBv ciBlbnRodXNpYXN0IHNjZW5hcmlvcy4gSXNu4oCZdCBhbnkgb3RoZXIgYWN0aW9uIG92ZXJraWxs Pw0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBUaGFua3MhDQo+Pj4+IA0KPj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IA0KPj4+PiBDaHJpc3RvcGhlci5QYWxtZXJATWlj cm9zb2Z0LmNvbQ0KPj4+PiANCj4+Pj4gUHJvZ3JhbSBNYW5hZ2VyDQo+Pj4+IA0KPj4+PiBJUHY2 IEAgV2luZG93cw0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+Pj4gdjZvcHNAaWV0Zi5v cmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4+ PiANCj4+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiAtLQ0KPj4+ID09PT09PT09 PT09PT09PT09PT09PT09PT0NCj4+PiBDYXJsb3MgTS4gTWFydGluZXotQ2FnbmF6em8NCj4+PiBo dHRwOi8vd3d3LmxhYnMubGFjbmljLm5ldA0KPj4+ID09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4+IHY2b3BzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4gDQo+PiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0 DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMNCj4gDQoNCg== From dougb@dougbarton.us Wed Apr 6 20:18: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 B71B93A69AA for ; Wed, 6 Apr 2011 20:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxUx9XYSDAKo for ; Wed, 6 Apr 2011 20:18:06 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 970E43A69A9 for ; Wed, 6 Apr 2011 20:18:06 -0700 (PDT) Received: (qmail 4158 invoked by uid 399); 7 Apr 2011 03:19:48 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 7 Apr 2011 03:19:48 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4D9D2D50.4040801@dougbarton.us> Date: Wed, 06 Apr 2011 20:19:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Christopher Palmer References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.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: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 03:18:07 -0000 On 04/06/2011 18:38, Christopher Palmer wrote: > "A host with a public but natted v4 address will alwas get hosed by this." > > A host in that condition will have a broken 6to4 address, but won't experience a degradation in their web experience if they have RFC 3484 implemented. > > So really this would be the third proposed 6to4 mitigation: > > 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3484. > 2. Changing default host behavior. (still being debated) > 3. Deprecation of the prefix. > > Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it? You're attaching emotion to something that is purely a technical issue. 2002::/16 is prominently located in the global unicast block (arguably a mistake to start with) and therefore IANA needs explicit instructions that it should not be allocated for any other purpose until a suitable "cooling off" period. I'd say about 50 years ought to do it. :) Marking it deprecated for use on the public Internet doesn't prevent someone else from using the range for private purposes, as you alluded to in your first post. hth, 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 Christopher.Palmer@microsoft.com Wed Apr 6 21:27: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 6118E28B797 for ; Wed, 6 Apr 2011 21:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 eqn5ALoCLv9a for ; Wed, 6 Apr 2011 21:27:41 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 332B73A685D for ; Wed, 6 Apr 2011 21:27:41 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 21:29:25 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 6 Apr 2011 21:29:24 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.99]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 21:29:24 -0700 From: Christopher Palmer To: Doug Barton Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv0q/0Z/RyklE39TrerPIyoUARNXwAPPYYAAAB83wAAAERAAAAEYs2AAA6Hu1D//6tcAIAAaf5A Date: Thu, 7 Apr 2011 04:29:24 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> In-Reply-To: <4D9D2D50.4040801@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 04:27:43 -0000 So, a 6to4 client will experience no change in their 6to4 experience. Relay= s will still be as available and routable (or not) as they are today? I'm very green in terms of IETF participation, so I apologize if my request= s for clarity concerning this matter are entirely foolish.=20 (1) It would be good to indicate that the anycast prefix and general routin= g of 6to4 relays would be unchanged by this proposal. From this conversatio= n it would appear that is the case. This line is comforting: " In order to limit the impact of end-users, it is recommended that operato= rs retain their existing 6to4 relay routers..." Maybe a bit more would be nice?=20 (2) It would be nice to indicate that Intranets can still use 6to4 addressi= ng (section 5.9 of RFC 3056).=20 I again apologize for being pedantic, but 6to4 is not a "non-feature" from = our perspective.=20 I'm fairly concerned about pulling out the rug on the arguable small, but c= ertainly enthusiastic group of folks who intentionally use 6to4 as a method= of enjoying the growing IPv6 Internet. Making them opt-in is one thing, ju= st killing the technology entirely and immediately is a more hairy idea. Best! Chris -----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us]=20 Sent: Wednesday, April 06, 2011 8:20 PM To: Christopher Palmer Cc: Joel Jaeggli; Carlos Martinez-Cagnazzo; v6ops@ietf.org Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status On 04/06/2011 18:38, Christopher Palmer wrote: > "A host with a public but natted v4 address will alwas get hosed by this.= " > > A host in that condition will have a broken 6to4 address, but won't exper= ience a degradation in their web experience if they have RFC 3484 implement= ed. > > So really this would be the third proposed 6to4 mitigation: > > 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3= 484. > 2. Changing default host behavior. (still being debated) > 3. Deprecation of the prefix. > > Given (1) and (2), the operational value of 3 is still lost on me. Is the= expectation that ISPs stop routing 6to4 packets? Is this a signal that we = don't just hate 6to4, but we super hate it? You're attaching emotion to something that is purely a technical issue.=20 2002::/16 is prominently located in the global unicast block (arguably a=20 mistake to start with) and therefore IANA needs explicit instructions=20 that it should not be allocated for any other purpose until a suitable=20 "cooling off" period. I'd say about 50 years ought to do it. :) Marking it deprecated for use on the public Internet doesn't prevent=20 someone else from using the range for private purposes, as you alluded=20 to in your first post. hth, Doug --=20 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 swmike@swm.pp.se Wed Apr 6 22:14: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 0975A3A69F6 for ; Wed, 6 Apr 2011 22:14:58 -0700 (PDT) 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 IevWpXSUYD+j for ; Wed, 6 Apr 2011 22:14:57 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 38A613A6876 for ; Wed, 6 Apr 2011 22:14:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 586C09C; Thu, 7 Apr 2011 07:16:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 555459A; Thu, 7 Apr 2011 07:16:39 +0200 (CEST) Date: Thu, 7 Apr 2011 07:16:39 +0200 (CEST) From: Mikael Abrahamsson To: Christopher Palmer In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 05:14:58 -0000 On Thu, 7 Apr 2011, Christopher Palmer wrote: > I'm fairly concerned about pulling out the rug on the arguable small, > but certainly enthusiastic group of folks who intentionally use 6to4 as > a method of enjoying the growing IPv6 Internet. Making them opt-in is > one thing, just killing the technology entirely and immediately is a > more hairy idea. I don't think there is consensus to kill it. The consensus is that preferring 6to4 above IPv4 is bad right now (and in the forseeable future). My preference as to what should happen are in the order of preference (this is Microsoft Windows Vista and Win7 specifically): 1. Fix ICS (quickly) so that it doesn't send out RA on the WAN interface. Stop by default issuing AAAA queries if only connectivity is 6to4 (but make it configurable). Still prefer IPv4 over IPv6. Keep 6to4 on, just like teredo. 2. Turn off default turned on 6to4 by means of a quick patch, make it configurable so user can turn it on again. Fix ICS and preference a bit later. 3. Kill Windows 6to4 totally by means of removing A record. If possible, make workaround so user can enter 192.88.99.1 manually somewhere if they want to enable it. If 1 and 2 can't be done before IPv6 day, I'd prefer 3. 1 and 2 needs to be high enough priority that Windows Update installs it automatically. I want operators to keep their 6to4 relays up and running for at least 1-2 years still, I agree that users should be migrated off of 6to4 first, THEN we remove the infrastructure when most of them are gone. -- Mikael Abrahamsson email: swmike@swm.pp.se From dougb@dougbarton.us Wed Apr 6 22:31: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 A32A43A6989 for ; Wed, 6 Apr 2011 22:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm304FJt09QG for ; Wed, 6 Apr 2011 22:31:21 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 79E3F3A6863 for ; Wed, 6 Apr 2011 22:31:21 -0700 (PDT) Received: (qmail 2017 invoked by uid 399); 7 Apr 2011 05:33:04 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 7 Apr 2011 05:33:04 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4D9D4C8B.1020005@dougbarton.us> Date: Wed, 06 Apr 2011 22:32:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mikael Abrahamsson References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 05:31:22 -0000 On 4/6/2011 10:16 PM, Mikael Abrahamsson wrote: > I don't think there is consensus to kill it. The consensus is that > preferring 6to4 above IPv4 is bad right now (and in the forseeable future). I think moving it down the list is the absolute minimum. My preference personally is that it be killed, but I'm interested in arguments that people might have about what benefits it can provide here and now. 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 Wed Apr 6 23: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 EE31F3A680B for ; Wed, 6 Apr 2011 23:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.461 X-Spam-Level: X-Spam-Status: No, score=-110.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 2RJAyn8XpjQg for ; Wed, 6 Apr 2011 23:17:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7F3EF3A67F3 for ; Wed, 6 Apr 2011 23:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3374; q=dns/txt; s=iport; t=1302157139; x=1303366739; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=BrRtsESter0lVqoNfYwhsVCnbO/0LnXJtKkrRIQ1oYQ=; b=Hl+yJDltjsbhuXo4ChB3O4EH+19894txIUnY+iP+uT6C9fLvjDoOZG+Z ddDRX/ppj4J+Ezd96jYF8AO6g9h74xFSsN1GT9yoqHFxK7ZEfziO/MD+G y6iWKs/6OCy/UsqT2Shsek+w4Q7SNnOPoPUeXvo0Bdqb+2yo3uyW6Y4MW M=; X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="82540689" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2011 06:18:58 +0000 Received: from Freds-Computer.local (dhcp-10-61-103-75.cisco.com [10.61.103.75]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p376IsVQ016988; Thu, 7 Apr 2011 06:18:57 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 07 Apr 2011 08:18:58 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 07 Apr 2011 08:18:58 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 7 Apr 2011 08:18:45 +0200 Message-Id: <00F8378B-279A-4F17-80D4-2F005A197FFF@cisco.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> <009b01cbf3f1$4b22c970$e1685c50$@com> <34E4F50CAFA10349A41E0756550084FB049FEF81@! PRVPEXVS04.corp.twcable.com> <6634030F-7E3D-439F-97D0-E6C85ACECA76@employees.org> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 07 Apr 2011 06:17:16 -0000 Fred, it might be most appropriate for you to write a draft on the = configuration and use of ISATAP in a residential network. To my = knowledge, it is rarely if ever used in the absence of an IT department = to support it, or in the presence of a native IPv6 network, which is the = topic of the CPE Router Draft. If you think it makes sense, maybe you = can tell us how in the usual manner. On Apr 7, 2011, at 1:36 AM, Templin, Fred L wrote: > Hi Ole,=20 >=20 >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of=20 >> Ole Troan >> Sent: Wednesday, April 06, 2011 12:44 PM >> To: Weil, Jason >> Cc: Tina Tsou; 'Hemant Singh (shemant)'; Templin, Fred L;=20 >> 'Fred Baker (fred)'; 'IPv6 Ops WG'; 'Tony Hain (ahain)' >> Subject: Re: [v6ops]=20 >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>=20 >>> I am not able clearly parse the data to the column=20 >> headings, but if it helps the diagram below is what I was suggesting. >>>=20 >>> [DS HOST]--[v4 CE ROUTER]--[v6 BIS ROUTER]-->Service Provider >>> | >>> [DS HOST] >>>=20 >>> The issue in the topology depicted above is the IPv4-only=20 >> CE (interior) ROUTER is out of scope for the -bis draft=20 >> today. The current scope covers transition technologies on=20 >> the WAN (6rd and DS-LITE) and a simple two router setup with=20 >> the interior router being an IPv6 CE router. >>=20 >> what is the proposal, that the IPv6 CE comes with ISATAP=20 >> supported on by default or be capable of doing ISATAP=20 >> tunneling? (remember we are trying to make these routers=20 >> require no management). >=20 > At least capable of acting as an ISATAP router on the LAN > side. On by default would require some means of selecting one > or more IPv6 prefixes to assign to the ISATAP link, but that > should be easy to carve off of whatever stateful or stateless > prefix delegations the CE receives via its WAN connection. >=20 >> if ISATAP is enabled by default, how do we know that the user=20 >> hasn't intended a topology separating host on different links=20 >> and by building a single virtual link we are violating that=20 >> policy? >=20 > Such a user would be in a more competent position to disable > and/or reconfigure the on-by-default settings than a novice > user would be to enable an off-by-default setting. Besides, > the ISATAP virtual link would not magically bypass any IPv4 > filtering gateways in the network. So, the ISATAP virtual > link might be partitioned, but the IPv4 filtering policies > would not be violated.=20 >=20 >> e.g. why were the extra routers there in the first place. >=20 > For the same reasons that any IPv4 site administrator > would portion the site off into separate subnets separated > by IPv4 routers. >=20 >> how is ISATAP provisioning supposed to work? so far the IPv6=20 >> CE router work has focused on the profile of the router=20 >> itself, and it has references standards track document for=20 >> WAN side and LAN side behaviour. >=20 > There is a lot of documented operational guidance on how > to provision an ISATAP site service outside of the IETF > document series - some of it from your company. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> cheers, >> Ole From ichiroumakino@gmail.com Thu Apr 7 00:03:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E4D3A67F3 for ; Thu, 7 Apr 2011 00:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 FDpa4oRPZTy4 for ; Thu, 7 Apr 2011 00:03:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 340753A68AA for ; Thu, 7 Apr 2011 00:03:19 -0700 (PDT) Received: by wyb29 with SMTP id 29so2137314wyb.31 for ; Thu, 07 Apr 2011 00:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=WAYXwvvX7nMGXNxAq65pD0tb2P+EysMeYHLS2q4HDXo=; b=RNzWBkK6e1xvbDqQFASRvRJ/jckJgvpvBnirzDdLEN8rM7FT/UFZ9LH+AkFpPn9NlE 5MKfstHE6rmSLSnXFtRVUZiRM4E+eCxzjXlq5N0H5R+Jl68p5vah8TCnQcICEAeZ7Z24 SMAamI0YwJbPIQISzwJsr/+Uml5dhczZNIZqk= 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=sN4JmkqRC5eIDFBjw06Ria/T9dPmc5/bHbXl3Dadywv1dRGaAWu8TC++Xl2Ydexvoj C1wckB+NuYLLPCyXIH8nXq1tnS39Q92DZIKdAOER4/R2B/5S3x0m6LXtBe2abTg5yy/M dr9xD7bCOEAfzEvV7l/ugdg18CGbWB8eMBj+8= Received: by 10.227.179.196 with SMTP id br4mr507382wbb.81.1302159902806; Thu, 07 Apr 2011 00:05:02 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-125.cisco.com (dhcp-osl-vl300-64-103-53-125.cisco.com [64.103.53.125]) by mx.google.com with ESMTPS id ed10sm832582wbb.66.2011.04.07.00.05.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:05:01 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A3FF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 7 Apr 2011 09:04:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75F0470B-F936-4B2B-9E9C-6CF69090E2CC@employees.org> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A3FF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Christopher Palmer X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:03:20 -0000 Chris, > - no reachability test towards the 6to4 relay router. > - doesn't react to ICMPs(?) > - how does it work with "bogons"? non-routable non-RFC1918 IPv4 = addresses? (result of some CGN deployments). >=20 > These won't translate into user problems - a correctly configured = application or a 3484-compliant host will be fine in these situations.=20= did you mean 3484-revise compliant? what happens if there is a broken 6to4 connectivity but working Teredo = connectivity? then because of the lack of reachability tests, processing = of ICMPs, will lead to much longer time outs than required. > They might eventually try a broken connection which is unfortunate, = but correct sorting will make 6to4 a last resort. So really, the = brokenness will never establish itself except in the following 2 = scenarios, AFAIK. >=20 > Applications that sort addresses correctly (by not = following Windows guidance) > Hosts that are behind Windows when it has been = configured with Internet Connection Sharing, and do not have RFC 3484. > (exacerbated by the rouge RA issue with = ICS) happy eyeballs. btw: I was looking at this from a more general point of view than just = the Windows implementation (that appears to have gotten the SAS/DAS = selection sorted out). cheers, Ole From tore.anderson@redpill-linpro.com Thu Apr 7 00:04: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 D0AFD3A688F for ; Thu, 7 Apr 2011 00:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 ofNg4-mMuz39 for ; Thu, 7 Apr 2011 00:04:09 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 6FCD63A688B for ; Thu, 7 Apr 2011 00:04:09 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 2A2B6CC099; Thu, 7 Apr 2011 09:05:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 l35WI5X+Vo7J; Thu, 7 Apr 2011 09:05:52 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 7 Apr 2011 09:05:52 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id B6250170C00B; Thu, 7 Apr 2011 09:05:51 +0200 (CEST) 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 ii3ysQdBJuil; Thu, 7 Apr 2011 09:05:51 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 36848170C00F; Thu, 7 Apr 2011 09:05:51 +0200 (CEST) Message-ID: <4D9D6236.5000302@redpill-linpro.com> Date: Thu, 07 Apr 2011 09:05:26 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Christopher Palmer References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:04:11 -0000 Hi Chris, * Christopher Palmer > Yes - Windows clients currently "learn" the 6to4 anycast prefix by > resolving 6to4.ipv6.microsoft.com. > > Modification of this A record could be used to modify Windows Vista/7 > behavior without requiring a Windows Update, and fix the perceived > issue semi-magically. Unfortunately, last I checked, it does not help to override the A record to resolve to nothing. The Default Gateway field in the ipconfig output shows an empty value (where it usually says 2002:c058:6301::). The 6to4 adapter is enabled, and ICS continues to annouce it with RAs. Doing this is equivalent to disabling anycast 6to4 (RFC 3068) but leaving router 6to4 (RFC 3056) functionality intact. It does *not* help *at* *all* against dual-stack brokenness, since the hosts that receive the RA will get an IPv6 address and an IPv6 default router, and will try to use that to get to the IPv6 internet. Which is guaranteed to not work, and you're guaranteed end-user brokenness. This problem is the biggest reason why I strongly feel that 3056 should be marked historic along with 3068. However, if it is possible to muck around with the 6to4.ipv6.microsoft.com record in a way that prevents the 6to4 interface from being enabled (and, by extension, RAs from ICS) - please do share! I know of several network operators who would be absolutely ecstatic about having a way to disable rogue RAs from 6to4/ICS for their entire user base in one fell swoop. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From Dmitry.Anipko@microsoft.com Thu Apr 7 00:36: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 DFD5E28C0D9 for ; Thu, 7 Apr 2011 00:36:15 -0700 (PDT) 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 1L0zbwc0SNOQ for ; Thu, 7 Apr 2011 00:36:15 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 29CEC3A68C2 for ; Thu, 7 Apr 2011 00:36:15 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Apr 2011 00:37:58 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 7 Apr 2011 00:37:58 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Thu, 7 Apr 2011 00:36:32 -0700 From: Dmitry Anipko To: Ole Troan , Christopher Palmer Date: Thu, 7 Apr 2011 00:36:31 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: Acv08h8kLs1n5HQFSS6JDgIjMcT1PAAAt1SH Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A3FF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, <75F0470B-F936-4B2B-9E9C-6CF69090E2CC@employees.org> In-Reply-To: <75F0470B-F936-4B2B-9E9C-6CF69090E2CC@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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:36:16 -0000 Hi Ole, >>did you mean 3484-revise compliant? >>what happens if there is a broken 6to4 connectivity but working Teredo co= nnectivity? then >>because of the lack of reachability tests, processing of= ICMPs, will lead to much longer time outs than required. As I understand, people are mostly concerned regarding how broken 6to4 is c= ompared to native IPv6 and IPv4, and not how much Teredo works better than = 6to4. In that regard, for native IPv6 destinations (since relay router was mentio= ned below) and IPv4, connections 6to4->native would not be preferred over n= ative->native or IPv4->IPv4 even by the original (not revised) RFC 3484 due= to 6to4->Native label mismatch. Hence, an application using OS sorting or = following RFC 3484 would not be affected by bad relay, and should have firs= t tried native IPv6 or IPv4. Regarding Teredo - if the destination has native IPv6 address only, then th= e interface choice is determined by route and interface metric, and not RFC= 3484, so revised RFC would not help. And if destination has both Teredo an= d native, then again because of label match for Teredo<->Teredo will win ov= er 6to4->Native.=20 Thanks, Dmitry ________________________________________ From: Ole Troan [ichiroumakino@gmail.com] On Behalf Of Ole Troan [otroan@em= ployees.org] Sent: Thursday, April 07, 2011 12:04 AM To: Christopher Palmer Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n Chris, > - no reachability test towards the 6to4 relay router. > - doesn't react to ICMPs(?) > - how does it work with "bogons"? non-routable non-RFC1918 IPv4 addresses= ? (result of some CGN deployments). > > These won't translate into user problems - a correctly configured applica= tion or a 3484-compliant host will be fine in these situations. did you mean 3484-revise compliant? what happens if there is a broken 6to4 connectivity but working Teredo conn= ectivity? then because of the lack of reachability tests, processing of ICM= Ps, will lead to much longer time outs than required. > They might eventually try a broken connection which is unfortunate, but c= orrect sorting will make 6to4 a last resort. So really, the brokenness will= never establish itself except in the following 2 scenarios, AFAIK. > > Applications that sort addresses correctly (by not followin= g Windows guidance) > Hosts that are behind Windows when it has been configured w= ith Internet Connection Sharing, and do not have RFC 3484. > (exacerbated by the rouge RA issue with IC= S) happy eyeballs. btw: I was looking at this from a more general point of view than just the = Windows implementation (that appears to have gotten the SAS/DAS selection s= orted out). cheers, Ole= From tore.anderson@redpill-linpro.com Thu Apr 7 00:40: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 9DE893A68E1 for ; Thu, 7 Apr 2011 00:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 SI6JJT0-k1Kp for ; Thu, 7 Apr 2011 00:40:21 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 6B1663A67F3 for ; Thu, 7 Apr 2011 00:40:21 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 5F97DC3E22; Thu, 7 Apr 2011 09:42:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 YkGDL+eS5++r; Thu, 7 Apr 2011 09:42:05 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 7 Apr 2011 09:42:05 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 32B8A170C00C; Thu, 7 Apr 2011 09:42:05 +0200 (CEST) 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 hkL1b-QrxluZ; Thu, 7 Apr 2011 09:41:52 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id E5CED170C00A; Thu, 7 Apr 2011 09:41:52 +0200 (CEST) Message-ID: <4D9D6AC0.7030907@redpill-linpro.com> Date: Thu, 07 Apr 2011 09:41:52 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mikael Abrahamsson References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:40:22 -0000 Hi Mikael, * Mikael Abrahamsson > 1. Fix ICS (quickly) so that it doesn't send out RA on the WAN > interface. IMO, fix *any* router or «internet sharing» implementation that sends out RAs without having a proper native IPv6 prefix available for this purpose (for example from DHCPv6-PD). Including, but not limited to, RAs with a 6to4 Prefix Information Option, a site-local PIO, and with no PIO. In a nutshell, if there's no IPv6 connectivity to share in the first place, don't attempt to magically conjure one up. Windows ICS is certainly not the only implementation that does this, but I suspect it's the most ubiquitous one. > 3. Kill Windows 6to4 totally by means of removing A record. Doesn't work - see my recent message to the 6to4-advisory thread. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From brian.e.carpenter@gmail.com Thu Apr 7 00: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 954E03A68C2 for ; Thu, 7 Apr 2011 00:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.269 X-Spam-Level: X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 zU3CM4aLqnkQ for ; Thu, 7 Apr 2011 00:42:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2BA623A693A for ; Thu, 7 Apr 2011 00:42:37 -0700 (PDT) Received: by wwa36 with SMTP id 36so1887950wwa.13 for ; Thu, 07 Apr 2011 00:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=skzogYfbVWkq8Yboi/lWQ5D0ILwmn2gamin3DGux58k=; b=GtAjG5A1JhL537Vcft9VZD9aMOdtU/bmtcId3Bzqp1MEKLbjF8v+/GLHyfdSi+uYlF Q3tuhCbzN59eA/UZZCIo5ljvkj0ohy/SwezupTSNCn0tUksOI7YNnz1HsdA56BJjTRYa i0RPr4rKzNxvcvtC2CHMCvVZ2Tey70QNP5P3A= 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=ldUBiyF7tJhG3eD72TQTaq5Ok47Us0caRE58Doa1OB9UydHi37r/q9xbXkuXY27YCE cbrkOjAUQAHb1ANhX1ORQa6a3ULEwrBshd5gQQ8XGRK/9T5KCo2rx5VnjRmp9OrYht6s QkUeMnGWTY3HId4r/bmpiH74jS0g4l2p3wWEA= Received: by 10.227.198.199 with SMTP id ep7mr542034wbb.40.1302162260768; Thu, 07 Apr 2011 00:44:20 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id u9sm856615wbg.17.2011.04.07.00.44.19 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:44:20 -0700 (PDT) Message-ID: <4D9D6B50.4020508@gmail.com> Date: Thu, 07 Apr 2011 19:44:16 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> In-Reply-To: <1302130763.4072.94.camel@shakira.millnert.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko , Christopher Palmer Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:42:39 -0000 Firstly, many thanks to Chris for engaging in this discussion. On 2011-04-07 10:59, Martin Millnert wrote: > Chris, > > On Wed, 2011-04-06 at 22:46 +0000, Christopher Palmer wrote: >> The flattery makes one feel warm in the heart. >> >> Yes - Windows clients currently "learn" the 6to4 anycast prefix by resolving 6to4.ipv6.microsoft.com. >> >> Modification of this A record could be used to modify Windows Vista/7 behavior without requiring a Windows Update, and fix the perceived issue semi-magically. > > That sounds absolutely terrific. If pushing this draft through helps in > this effort (i.e. the IETF making clear recommendations to OS vendors), > it's a strong motivation to do so, to say the least. But how will that affect people who are happily using 6to4? Please don't forget that many 6to4 sessions are entirely successful. I really don't see how we could legitimately mess those people up to eliminate the cases that don't work. Brian > > Cheers, > Martin > > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Martin Millnert >> Sent: Wednesday, April 06, 2011 1:42 PM >> To: Brian E Carpenter >> Cc: v6ops@ietf.org; Dmitry Anipko >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question >> >> On Thu, 2011-04-07 at 06:30 +1200, Brian E Carpenter wrote: >> >>> That isn't the point. The point is the millions (literally) of systems >>> out there that *will* be running 6to4 by default for, very likely, >>> years to come. >>> >> Brian, >> >> If I am reading Dmitry and Christopher correctly, and if I'm correct in expecting a high level of competent engineering at MS, we have: >> >> anticimex@shakira:~$ host 6to4.ipv6.microsoft.com 6to4.ipv6.microsoft.com has address 192.88.99.1 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8 >> >> And (from >> http://technet.microsoft.com/en-us/library/cc779985(WS.10).aspx ): >> "Automatically performs a Domain Name System (DNS) query for the name 6to4.ipv6.microsoft.com to obtain the IPv4 address of the Microsoft 6to4 relay router on the Internet. You can use the netsh interface ipv6 6to4 set relay command to specify which DNS name to query." >> >> Thus the "fix" for a very substantial amount of today's Internet hosts (and more to come with current ongoing enterprise win7 migration >> rollouts) could be in fact, very, very simple. >> >> Obviously shipping new code to machines requires patches to go out -- but the above could possibly be done swiftly. But how much has already been hidden in the Windows stack for this day, we'll have to see. :) >> >> I could imagine that updating hosts to query instead "6to4".$DOMAIN may be something one could consider, and MS aren't strangers to configure the netstack via DNS queries on $DOMAIN, but we'll see what they do. >> >> >> All in all, MS has a unique position to make a big impact here, one that I welcome warmly. If they are willing to do this (by biting the PR >> bullet) to fix the current circular >> non-IPv6-deploying-dependency-situation we have, I'd be extremely happy. :) >> >> Cheers, >> Martin >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > From pekkas@netcore.fi Thu Apr 7 00:42: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 B0CAE3A69FD for ; Thu, 7 Apr 2011 00:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 Gu6mAXThROBe for ; Thu, 7 Apr 2011 00:42:44 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 637913A69FC for ; Thu, 7 Apr 2011 00:42:44 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p377iIoQ014564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 10:44:18 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p377iHIE014561; Thu, 7 Apr 2011 10:44:17 +0300 Date: Thu, 7 Apr 2011 10:44:17 +0300 (EEST) From: Pekka Savola To: Christopher Palmer In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.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.97 at otso.netcore.fi X-Virus-Status: Clean Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:42:45 -0000 On Thu, 7 Apr 2011, Christopher Palmer wrote: > "A host with a public but natted v4 address will alwas get hosed by this." > > A host in that condition will have a broken 6to4 address, but won't experience a degradation in their web experience if they have RFC 3484 implemented. > > So really this would be the third proposed 6to4 mitigation: > > 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3484. > 2. Changing default host behavior. (still being debated) > 3. Deprecation of the prefix. > > Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it? This will require an update in the RFC 3484 implementation. Maybe this is what you meant, or maybe not. Joel is probably referring to this: http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02#section-2.4 (This issue has a lot of history -- known for some 7-8yrs, see http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03#section-2.1) If I understand this correctly: The NAT44ting/6to4 gateway has public IP 1.1.1.1 (WAN) It is advertising 2002:0101:0101:0::/64 out on LAN. It is doing NAT on LAN. Hence, hosts behind such gateway have IPv6 address 2002:0101:0101:0::EUI64 and 192.168.1.1. When connecting to a dual-stack server with IP addresses 2.2.2.2 and 2001:db8::1. It will use 6to4 instead of IPv4 through NAT. FAIL. If the client would have had IP address 1.1.1.2 and 2002:0101:0101:0::EUI64, with (current) RFC3484 implementation, it would have preferred IPv4 instead of 6to4. So, there are are really two layers of RFC3484 brokenness: 1) not implemented at all 2) 6to4 is used if v4 has mismatching scope (private->public) -- 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 Roman.Arcea@orange.md Thu Apr 7 00:49: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 717D03A68CD; Thu, 7 Apr 2011 00:49:04 -0700 (PDT) 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 41G24ROJiZEH; Thu, 7 Apr 2011 00:49:03 -0700 (PDT) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 7DFB63A68C2; Thu, 7 Apr 2011 00:49:03 -0700 (PDT) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 9E5C0C0A3D9; Thu, 7 Apr 2011 10:51:26 +0300 (EEST) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 7FD42C0A3C0; Thu, 7 Apr 2011 10:51:26 +0300 (EEST) In-Reply-To: <4D9D6B50.4020508@gmail.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> To: Brian E Carpenter MIME-Version: 1.0 X-KeepSent: EACC8B7A:895D026B-C225786B:002AC9FE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Thu, 7 Apr 2011 10:50:53 +0300 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2FP2|March 22, 2011) at 04/07/2011 10:50:46, Serialize complete at 04/07/2011 10:50:46 Content-Type: text/plain; charset="US-ASCII" Cc: "v6ops@ietf.org" , Dmitry Anipko , v6ops-bounces@ietf.org, Christopher Palmer Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:49:04 -0000 > > Chris, > > > > On Wed, 2011-04-06 at 22:46 +0000, Christopher Palmer wrote: > >> The flattery makes one feel warm in the heart. > >> > >> Yes - Windows clients currently "learn" the 6to4 anycast prefix > by resolving 6to4.ipv6.microsoft.com. > >> > >> Modification of this A record could be used to modify Windows > Vista/7 behavior without requiring a Windows Update, and fix the > perceived issue semi-magically. > > > > That sounds absolutely terrific. If pushing this draft through helps in > > this effort (i.e. the IETF making clear recommendations to OS vendors), > > it's a strong motivation to do so, to say the least. > But how will that affect people who are happily using 6to4? Please > don't forget > that many 6to4 sessions are entirely successful. I really don't see how > we could legitimately mess those people up to eliminate the cases that don't > work. +1 Killing it entirely seems a bit too much. It is still a way to get reasonably working IPv6 for some purposes. I believe it will be good enough to disable the 6to4 and teredo by default with a patch, but still leave it configurable from cli for whoever understands why he is doing that. deprecating 2002::/16 prefix is also unreasonable at this point. Roman From brian.e.carpenter@gmail.com Thu Apr 7 00:56: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 E71083A68B5 for ; Thu, 7 Apr 2011 00:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 POXEZ8oiffu1 for ; Thu, 7 Apr 2011 00:56:53 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 16D5E3A67F3 for ; Thu, 7 Apr 2011 00:56:52 -0700 (PDT) Received: by wwa36 with SMTP id 36so1896762wwa.13 for ; Thu, 07 Apr 2011 00:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S4mL2KUkbMhdrMuoWucOTHacAFWlP7IYGD7hkPpXcGg=; b=Oo8JXjsVt2OePZ15OSRydfXOzNAHrMUzfQktNsK22m6tyLIAbbiDtfBOwrtNvTSk2l mz9ObvW2wG78fwFu/nrHdoLxXRu3aJ3FbLDVYTB/a7JslfLx2PYSwjqgmNd4m7NcjMna aVkzrz3DmIGHalpkSD7Biwot40883WW5xwqI0= 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=Cy0ewy0W9fNz0c6PIB3oeb+d63WUGLm+L6kanTN6IU+MTvehtg4bxZIHBAh7TcjZd1 uFUnKmWP0Xp0H5l/Uy5hc4FsLY7z/FQmlUhDaAoPVp2SnDvw5H58RDRNEIbdOgqS6Iqn 3k0NJnQhdTxKut2Xmyl6rBIEiy3e3+SuNB+yI= Received: by 10.216.241.4 with SMTP id f4mr546971wer.42.1302163116878; Thu, 07 Apr 2011 00:58:36 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id d6sm666462wer.26.2011.04.07.00.58.35 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:58:36 -0700 (PDT) Message-ID: <4D9D6EA9.3020706@gmail.com> Date: Thu, 07 Apr 2011 19:58:33 +1200 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: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> In-Reply-To: <4D9D2D50.4040801@dougbarton.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 07:56:54 -0000 On 2011-04-07 15:19, Doug Barton wrote: > On 04/06/2011 18:38, Christopher Palmer wrote: >> "A host with a public but natted v4 address will alwas get hosed by >> this." >> >> A host in that condition will have a broken 6to4 address, but won't >> experience a degradation in their web experience if they have RFC 3484 >> implemented. >> >> So really this would be the third proposed 6to4 mitigation: >> >> 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the >> RFC 3484. >> 2. Changing default host behavior. (still being debated) >> 3. Deprecation of the prefix. >> >> Given (1) and (2), the operational value of 3 is still lost on me. Is >> the expectation that ISPs stop routing 6to4 packets? Is this a signal >> that we don't just hate 6to4, but we super hate it? > > You're attaching emotion to something that is purely a technical issue. > 2002::/16 is prominently located in the global unicast block (arguably a > mistake to start with) and therefore IANA needs explicit instructions > that it should not be allocated for any other purpose until a suitable > "cooling off" period. I'd say about 50 years ought to do it. :) > > Marking it deprecated for use on the public Internet doesn't prevent > someone else from using the range for private purposes, as you alluded > to in your first post. The essential point is that the IANA listing should refer to the new RFCs and not just to RFC 3056 and 3068. I think it's OK to use the word 'deprecated' - that doesn't mean forbidden. Nobody should be slapping on arbitrary route filters as a result - they should be doing what the -advisory- draft suggests, which is to proactively manage the routing of the deprecated prefixes. BTW, classful addressing was deprecated 18 years ago (RFC 1519) but there are still plenty of people who use the A,B,C terminology. I don't think we need to worry about deprecation of 2002::/16 having immediate effect on the running network. Brian From ichiroumakino@gmail.com Thu Apr 7 01:02: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 4356E28C119 for ; Thu, 7 Apr 2011 01:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 o7Mgmfw1eJFe for ; Thu, 7 Apr 2011 01:02:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2F82E28C114 for ; Thu, 7 Apr 2011 01:02:58 -0700 (PDT) Received: by wwa36 with SMTP id 36so1900490wwa.13 for ; Thu, 07 Apr 2011 01:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=sdvefiFcuMJXU4CPmq9UtRbA/W2+JW9/lg134ZmMqbQ=; b=HkjdqbkjxiysMRBXEqhPfQfEWnZkOCcsE08U74ulax6VuDSeZYy9ADC4RkPBnTVmly AdgFE4BS2lE0MBSYJ7LfzIrkstGScwoObfKwjI0Ao6rl3O568Bu4ykFRxtChQmuz70H4 ahJS/MKoEoY62lIf+doGuKGZ/h7hfDXO82CRQ= 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=aTfj3JjUNo+xnj8mb9s3xQLY0DVLdMxiINWCPNMtYpQB1e9Zxk4vbMnkDhXSy3eVpm V571vyGXn8rnv0XjZ7QPmjHMmOXfyRPW5vHmxEhPT+d2lPmrs0iWMNIXXPFBLiCBa15p t9rHdNc8MoBlIjjW8uFSOCKmcSNYt4YQH1Rug= Received: by 10.216.171.133 with SMTP id r5mr523219wel.91.1302163482139; Thu, 07 Apr 2011 01:04:42 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-125.cisco.com (dhcp-osl-vl300-64-103-53-125.cisco.com [64.103.53.125]) by mx.google.com with ESMTPS id h39sm668385wes.29.2011.04.07.01.04.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 01:04:41 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 7 Apr 2011 10:04:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Christopher Palmer X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:02:59 -0000 Chris, are you happy with the use of "deprecate" given the explanations = provided in this thread? not to forego matters, but I think we have managed to get a time slot in = the chair's busy WGLC schedule, so there would be another opportunity to = discuss this before sending the document onwards. cheers, Ole > In =93Request to move Connection of IPv6 Domains via IPv4 Clouds = (6to4) to Historic status=94 > =20 > There is this recommendation: > =20 > IANA is requested to mark the 2002::/16 prefix as "deprecated", > pointing to this document. Reassignment of the prefix for any = usage > requires justification via an IETF Standards Action [RFC5226]. > =20 > It is not clear why this is necessary. > =20 > If major vendors were to disable 6to4 by default, that would fix the = brokenness issue, while still allow for this prefix to be used in = specialized or enthusiast scenarios. Isn=92t any other action overkill? > =20 > Thanks! > ---------------------------- > Christopher.Palmer@Microsoft.com > Program Manager > IPv6 @ Windows > =20 > =20 > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Dmitry.Anipko@microsoft.com Thu Apr 7 01:14: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 63EA828C105 for ; Thu, 7 Apr 2011 01:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 C-LNpeucGJgZ for ; Thu, 7 Apr 2011 01:13:59 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4EBDA28C11F for ; Thu, 7 Apr 2011 01:13:59 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Apr 2011 01:15:43 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 7 Apr 2011 01:15:43 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Thu, 7 Apr 2011 01:15:17 -0700 From: Dmitry Anipko To: Pekka Savola , Christopher Palmer Date: Thu, 7 Apr 2011 01:15:16 -0700 Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv096+gNbE3Vu/YT2WvkS4T8BS0uQAA9jBw Message-ID: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.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" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:14:00 -0000 Hi Pekka, >> When connecting to a dual-stack server with IP addresses 2.2.2.2 and=20 2001:db8::1.It will use 6to4 instead of IPv4 through NAT. FAIL. >> 2) 6to4 is used if v4 has mismatching scope (private->public) Windows implementation treats RFC 1918 prefixes as public, specifically due= to this reason, so on Windows, in this scenario v4->v4 is preferred over 6= to4->native v6. Thank you, Dmitry -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of P= ekka Savola Sent: Thursday, April 07, 2011 12:44 AM To: Christopher Palmer Cc: v6ops@ietf.org; Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status On Thu, 7 Apr 2011, Christopher Palmer wrote: > "A host with a public but natted v4 address will alwas get hosed by this.= " > > A host in that condition will have a broken 6to4 address, but won't exper= ience a degradation in their web experience if they have RFC 3484 implement= ed. > > So really this would be the third proposed 6to4 mitigation: > > 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3= 484. > 2. Changing default host behavior. (still being debated) > 3. Deprecation of the prefix. > > Given (1) and (2), the operational value of 3 is still lost on me. Is the= expectation that ISPs stop routing 6to4 packets? Is this a signal that we = don't just hate 6to4, but we super hate it? This will require an update in the RFC 3484 implementation. Maybe=20 this is what you meant, or maybe not. Joel is probably referring to this: http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02#section-2.4 (This issue has a lot of history -- known for some 7-8yrs, see=20 http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03#section-2.1) If I understand this correctly: The NAT44ting/6to4 gateway has public IP 1.1.1.1 (WAN) It is advertising 2002:0101:0101:0::/64 out on LAN. It is doing NAT on LAN. Hence, hosts behind such gateway have IPv6 address=20 2002:0101:0101:0::EUI64 and 192.168.1.1. When connecting to a dual-stack server with IP addresses 2.2.2.2 and=20 2001:db8::1. It will use 6to4 instead of IPv4 through NAT. FAIL. If the client would have had IP address 1.1.1.2 and=20 2002:0101:0101:0::EUI64, with (current) RFC3484 implementation, it=20 would have preferred IPv4 instead of 6to4. So, there are are really two layers of RFC3484 brokenness: 1) not implemented at all 2) 6to4 is used if v4 has mismatching scope (private->public) --=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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From HahnC@t-systems.com Thu Apr 7 01:27: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 125F23A68C6 for ; Thu, 7 Apr 2011 01:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlw4qSqSEws for ; Thu, 7 Apr 2011 01:27:07 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 55F3D3A67F3 for ; Thu, 7 Apr 2011 01:27:06 -0700 (PDT) From: Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 07 Apr 2011 10:28:46 +0200 Received: from HE101453.emea1.cds.t-internal.com ([169.254.3.101]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Thu, 7 Apr 2011 10:28:46 +0200 To: Date: Thu, 7 Apr 2011 10:28:44 +0200 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: AQHL88hvpgRk+wlPLkatpLmbV9eqIJRRX2YAgAAAfgCAAA3bgP//v0jQgACD/gD//4qaMIAA1Kuw Message-ID: <901586CA8F92D543BFFFD6E1122F5A36026BBDF61912@HE101453.emea1.cds.t-internal.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:27:09 -0000 > >Yeah, we know about the rouge RAs (that's what I meant by ICS=20 >bugs that exacerbate the issue).=20 > >Anything else? > Christopher, there is a bug still existing since 2009 which relates to state changes of = IPv6 addresses. For history please see: http://lists.cluenet.de/pipermail/ipv6-ops/2009-Dec= ember/002718.html Actual discussion: http://lists.cluenet.de/pipermail/ipv6-ops/2011-April/00= 5188.html How to reproduce? Case A: 1) advertise IPv6 prefix to SLAAC enabled Vista/Win7 hosts 2) withdraw this prefix by sending RA with PIO and PrefLT=3D0 3) re-advertise the same prefix with common timers Results in deprecated, unusable IPv6 addresses on the systems despite the f= act that timers are updated according to the recent PIO information. Case B (quoting myself from ipv6-ops list): You can reproduce this behavior without sending PIO with PrefLT=3D0 if you = send the Vista/Win7 system in standby and wake it up after time X. Where X is defined as ValidLifetime > X > PreferredLifetime. Same result as in case A. best regards, Christian <><><><><><><><><><><><><><> Christian Hahn T-Systems International GmbH Systems Integration=20 IP Products, Services and Networks Goslarer Ufer 35, 10589 Berlin Tel +49 30 -3497 3164 Fax +49 30 -3497 3165 Mobil +49 170 7641791 E-Mail: hahnc@t-systems.com Internet: <>=20 >Best! >Chris > >-----Original Message----- >From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan >Sent: Wednesday, April 06, 2011 12:34 PM >To: Christopher Palmer >Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko >Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and=20 >IPv6 day question > >Christopher, > > >> From the perspective of Windows... >> =20 >> Isn't it fair to say: >> 6to4 is enabled by default on Windows Vista=20 >and Windows 7 >> Windows Vista and Windows 7 implement RFC 3484 >> =20 >> Thus, the only sources of "brokenness" - scoped to Windows: >> Applications that sort addresses correctly=20 >(by not following Windows guidance) >> Hosts that are behind Windows when it has=20 >been configured with Internet Connection Sharing, and do not=20 >have RFC 3484. >> (we know about the ICS and 6to4 bugs=20 >> that exacerbate this issue) >> =20 >> Are there other categories of brokenness from an experience=20 >perspective? Major applications that are broken? > >the ICS 'rouge RA' issue: > - host A is on a dual stack link with native IPv6 support=20 >(IPv6 default router with native IPv6 connectivity) > - host B on the same link, turns on ICS and advertises itself=20 >as a default router > - host A picks host B as default router instead of the correct one > >cheers, >Ole >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From rogerj@gmail.com Thu Apr 7 01:27: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 617FE3A68C6 for ; Thu, 7 Apr 2011 01:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.167, 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 CyArMI2EQWlF for ; Thu, 7 Apr 2011 01:27:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 33C483A67F3 for ; Thu, 7 Apr 2011 01:27:52 -0700 (PDT) Received: by iwn39 with SMTP id 39so2786509iwn.31 for ; Thu, 07 Apr 2011 01:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sXqZEcIRZ18yCrEpSx74G3rpUvhbPQCVhj6PA9J+TAI=; b=UQQZal1dFHRhQh72GkhEIEvHyV+Ng9xQmIY88WRf8li2hXyU0/7mKdRPHnXQ12FCUh pUYc24hRpJ+wNh9RR2Dih+LVTEmfuLaevgc+3P5eLtKwbXzY39h89y8gWSvSiKFGt0Py pGpW2/UOULHi1pjqoH3YuzsDNGFCmawY7w/IQ= 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=Rz8Wj5uKHuFJG8bWt3prC/RJMfpKYIhxnQ4dzz4Pc0+FytVPg0dm2kP+wlnU3RKnWM knrM8KGShRTJLjQcfRrNaqOYwSNWhvF8QZ/+7izA+qOWY5vw8NcGJ6gYAjt0/L5LZnwD lXSYlibeUWmWSvS3mhrMWAtb6Yo1Dtjwaq/z0= MIME-Version: 1.0 Received: by 10.42.147.3 with SMTP id l3mr962419icv.353.1302164976451; Thu, 07 Apr 2011 01:29:36 -0700 (PDT) Received: by 10.231.36.75 with HTTP; Thu, 7 Apr 2011 01:29:36 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 7 Apr 2011 10:29:36 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: carlos@lacnic.net, Christopher.Palmer@Microsoft.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:27:53 -0000 On Thu, Apr 7, 2011 at 12:59 AM, Carlos Martinez-Cagnazzo wrote: > I agree with Cristopher's comment. Personally I believe we should fix > what is wrong with 6to4 (mostly the anycast part), and make it more > manageable from an operators point of view rather than just dispose of > what can be a very valuable transition tool. 6to4 cause problem with IPv6 and is/will be seen as a problem, maybe even showstopper for some not-so-technical people wanting to implementy IPv6. I would think it is a very good idea to make it deprecated so everyone can see that we have done something with the problem. ... and on the more technical side, lots of other people have given their input on why. --=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 rogerj@gmail.com Thu Apr 7 01: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 737973A69E7 for ; Thu, 7 Apr 2011 01:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=0.125, 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 kIZWpB2kQQKg for ; Thu, 7 Apr 2011 01:33:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E902D3A6961 for ; Thu, 7 Apr 2011 01:33:02 -0700 (PDT) Received: by iwn39 with SMTP id 39so2791617iwn.31 for ; Thu, 07 Apr 2011 01:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h6VNYpjp8zZk3P1rWg5Nd2e/lRkPJ1IJcdYI9ceYogk=; b=YZMcPiHqn68KCHyg2s2YxONHpPeo6W5nG39hTF9QHUB07va1G8Mk25ODh36MQHJ0ig 7j5qu5gn4p0C7LjAVor4hQw50R9INbokH4+uPaMYG4ci1U/rdCMJL59ua2yYvAqNGXt8 6A/DZdBsR7bLhu05gsT55txEzkrn/gYOjpUNc= 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=Y109ikkQPRPc3PNRHQLAijSijPbvgFsecoaoQ7ccGx+VnGBTrVMqJP2uiLkmShLgzM aNwQAl8hlSrOIioUWUsYKqJSfS7K9wcW+UDiAogp3EGKiFajmaV2XkBkJLpQc6y+VB/R mfNWCzs+57tSX0vaEvRqn5x8hcYTOAcNflihs= MIME-Version: 1.0 Received: by 10.231.61.18 with SMTP id r18mr616490ibh.71.1302165287346; Thu, 07 Apr 2011 01:34:47 -0700 (PDT) Received: by 10.231.36.75 with HTTP; Thu, 7 Apr 2011 01:34:47 -0700 (PDT) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <20110406034120.C23A8DDC893@drugs.dv.isc.org> Date: Thu, 7 Apr 2011 10:34:47 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:33:05 -0000 On Wed, Apr 6, 2011 at 6:17 AM, Mikael Abrahamsson wrote= : > On Wed, 6 Apr 2011, Mark Andrews wrote: > >> If a application is excessively slow due to 6to4 not working it also nee= ds >> to be fixed. > > The behaviour is already known, there is nothing to be learnt from leavin= g > this broken for 3 more months. > > I'd say get rid of 6to4 (or downprio it) asap and get that process going, > little or nothing is gained by waiting. > > I want as little breakage as possible on IPv6 day so that content provide= rs > feel confident to turn on dual stack on their content. > > If the result is bad and we THEN say "ok, we confirmed that 6to4 is causi= ng > problems, please turn it off", we will have lost time. ... and that is time we are running quite low on already. I can't argue that it's safe to have IPv6 on if we know it will cause problem in our network. However, if I can show that that issue (in this case 6to4) are already handled and all we have todo is ito apply a patch to the OS (from the vendor) it will be just another point to remove form the todo list instead of being a possible problem left open. --=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 tore.anderson@redpill-linpro.com Thu Apr 7 01:44: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 09F473A6961 for ; Thu, 7 Apr 2011 01:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 F0cIBnFvAieJ for ; Thu, 7 Apr 2011 01:44:01 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 62B483A6952 for ; Thu, 7 Apr 2011 01:44:01 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 03CF4CC0A3; Thu, 7 Apr 2011 10:45:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 8DeNi+7U6Cwp; Thu, 7 Apr 2011 10:45:43 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 7 Apr 2011 10:45:43 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 9415C170C00B; Thu, 7 Apr 2011 10:45:42 +0200 (CEST) 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 U4eIAwsobsIo; Thu, 7 Apr 2011 10:45:41 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id D17DF170C00A; Thu, 7 Apr 2011 10:45:41 +0200 (CEST) Message-ID: <4D9D79B5.7090202@redpill-linpro.com> Date: Thu, 07 Apr 2011 10:45:41 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Christopher Palmer References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:44:03 -0000 Hi Chris, * Christopher Palmer > So, a 6to4 client will experience no change in their 6to4 experience. > Relays will still be as available and routable (or not) as they are > today? > > I'm very green in terms of IETF participation, so I apologize if my > requests for clarity concerning this matter are entirely foolish. > > (1) It would be good to indicate that the anycast prefix and general > routing of 6to4 relays would be unchanged by this proposal. From this > conversation it would appear that is the case. > > This line is comforting: > " In order to limit the impact of end-users, it is recommended that > operators retain their existing 6to4 relay routers..." > > Maybe a bit more would be nice? The document you're looking for is I-D.ietf-v6ops-6to4-advisory. The point of the 6to4-to-historic document is not to tell operators to immediately shut off all relays, drop all proto-41 traffic, and null-route 2002::/16 and 192.88.99.0/24. It is not intended to pull the rug out from under anyone. The point is to send a clear message that the technology has problems that won't/can't get properly fixed, and that vendors are therefore discouraged from implementing it in any new products (especially in a on-by-default fashion). The expectation is that eventually, (almost) all of the 6to4 users have gone away voluntary, either because they have replaced their old hardware/software with newer stuff that do not implement 6to4 [by default], or ideally because they have been provisioned with native IPv6 connectivity and no longer have use for it. When 6to4 has fallen into disuse, then the operators can start shutting off their relays. In the interim, I-D.ietf-v6ops-6to4-advisory attempts to ensure that the existing user base will have the best possible service. > I'm fairly concerned about pulling out the rug on the arguable small, > but certainly enthusiastic group of folks who intentionally use 6to4 > as a method of enjoying the growing IPv6 Internet. Making them opt-in > is one thing, just killing the technology entirely and immediately is > a more hairy idea. I'm assuming you're speaking specifically about Windows here, and what to do with its 6to4-on-by default legacy, so I'll answer specifically. >From my point of view as a operator of dual-stacked web sites, the local 6to4 adapter being on by default in Windows is largely unproblematic, due to the fact that all major web browsers are using the RFC3484-compliant Windows system resolver these days. (Note, I have absolutely no idea whether or not most other applications, e.g. MUAs, are all using the system resolver or if they would get into 6to4-related problems connecting to dual-stacked SMTP/IMAP servers.) However, the ICS behaviour of sharing the on-by-default 6to4 connectivity (or non-connectivity) is *very* problematic, along with all the other RA types it transmits by default (site-local PIO and no PIO). Especially in flat layer-2 campus style networks with unmananged clients. So, a Windows Update that changes ICS to not send out RAs *at all* (unless the Windows host in question has *native* IPv6 connectivity to share of course), would be an absolute godsend. At least make it configurable, and make the setting default to off. There is already some precedent for doing so - both Cisco Linksys and Apple has recently done so in software updates for their respective home router products. In Windows 8, however, I hope you disable 6to4 by default. :-) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From mohacsi@niif.hu Thu Apr 7 01:54:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4813A68DF for ; Thu, 7 Apr 2011 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsZu7rDc8uCD for ; Thu, 7 Apr 2011 01:54:42 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 250693A68D6 for ; Thu, 7 Apr 2011 01:54:42 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 57A5C8723F; Thu, 7 Apr 2011 10:56:25 +0200 (CEST) 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 LfirLNmsc9h0; Thu, 7 Apr 2011 10:56:09 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 4D82B8720B; Thu, 7 Apr 2011 10:56:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 45DE686D16; Thu, 7 Apr 2011 10:56:09 +0200 (CEST) Date: Thu, 7 Apr 2011 10:56:09 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Dmitry Anipko In-Reply-To: Message-ID: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> 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" , Carlos Martinez-Cagnazzo , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 08:54:43 -0000 On Thu, 7 Apr 2011, Dmitry Anipko wrote: > Hi Pekka, > >>> When connecting to a dual-stack server with IP addresses 2.2.2.2 and > 2001:db8::1.It will use 6to4 instead of IPv4 through NAT. FAIL. >>> 2) 6to4 is used if v4 has mismatching scope (private->public) > > Windows implementation treats RFC 1918 prefixes as public, specifically > due to this reason, so on Windows, in this scenario v4->v4 is preferred > over 6to4->native v6. Same for FreeBSD, OpenBSD and NetBSD. > > Thank you, > Dmitry > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Pekka Savola > Sent: Thursday, April 07, 2011 12:44 AM > To: Christopher Palmer > Cc: v6ops@ietf.org; Carlos Martinez-Cagnazzo > Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status > > On Thu, 7 Apr 2011, Christopher Palmer wrote: >> "A host with a public but natted v4 address will alwas get hosed by this." >> >> A host in that condition will have a broken 6to4 address, but won't experience a degradation in their web experience if they have RFC 3484 implemented. >> >> So really this would be the third proposed 6to4 mitigation: >> >> 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3484. >> 2. Changing default host behavior. (still being debated) >> 3. Deprecation of the prefix. >> >> Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it? > > This will require an update in the RFC 3484 implementation. Maybe > this is what you meant, or maybe not. > > Joel is probably referring to this: > > http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02#section-2.4 > > (This issue has a lot of history -- known for some 7-8yrs, see > http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03#section-2.1) > > If I understand this correctly: > > The NAT44ting/6to4 gateway has public IP 1.1.1.1 (WAN) > It is advertising 2002:0101:0101:0::/64 out on LAN. > It is doing NAT on LAN. > > Hence, hosts behind such gateway have IPv6 address > 2002:0101:0101:0::EUI64 and 192.168.1.1. > > When connecting to a dual-stack server with IP addresses 2.2.2.2 and > 2001:db8::1. > > It will use 6to4 instead of IPv4 through NAT. FAIL. > > If the client would have had IP address 1.1.1.2 and > 2002:0101:0101:0::EUI64, with (current) RFC3484 implementation, it > would have preferred IPv4 instead of 6to4. > > So, there are are really two layers of RFC3484 brokenness: > > 1) not implemented at all > 2) 6to4 is used if v4 has mismatching scope (private->public) > > -- > 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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tore.anderson@redpill-linpro.com Thu Apr 7 02:05: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 43F6B3A6970 for ; Thu, 7 Apr 2011 02:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 EUkXyi1fHawh for ; Thu, 7 Apr 2011 02:05:49 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id EAE313A68DF for ; Thu, 7 Apr 2011 02:05:48 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 372A6C3E3D; Thu, 7 Apr 2011 11:07:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 32PsynRA5ZPQ; Thu, 7 Apr 2011 11:07:31 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 7 Apr 2011 11:07:31 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 157B1170C00C; Thu, 7 Apr 2011 11:07:31 +0200 (CEST) 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 crjRzX2u4DES; Thu, 7 Apr 2011 11:07:30 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 96C35170C00A; Thu, 7 Apr 2011 11:07:30 +0200 (CEST) Message-ID: <4D9D7ED2.1050400@redpill-linpro.com> Date: Thu, 07 Apr 2011 11:07:30 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: carlos@lacnic.net References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 09:05:50 -0000 Carlos, * Carlos Martinez-Cagnazzo > Personally I believe we should fix what is wrong with 6to4 (mostly > the anycast part) The unicast part is also broken. Last year I was measuring the dual-stack brokenness levels in the Norwegian end-user population. Someone suggested to me to try to take the 6to4 anycast brokenness out of the equation, which I tried to do by «triple-stacking» the web server, going from: dualstack.api.no. A 87.238.40.2 dualstack.api.no. AAAA 2a02:c0:1010:2::2 To: dualstack.api.no. A 87.238.40.2 dualstack.api.no. AAAA 2002:57ee:2802::1 dualstack.api.no. AAAA 2a02:c0:1010:2::2 This shifted the traffic from the 6to4-enabled end users from using the anycast relays, to using the original unicast «router 6to4». The result was that the overall measured brokenness increased about ten-fold (from around 0.03% to 0.3%). Make sure to also check Geoff Huston's «Stacking it up» presentation, he's confirmed a huge failure rate (~15% IIRC) in the situation where he see a TCP SYN come in from a 6to4 client (so it's known that the inbound relay is working), and when he runs a local return relay (so it's known that the outbound relay is working too). After having spent two years doing everything I can think of in my power to «fix» the operational problems 6to4 is causing me, I've come to the conclusion that it's simply not possible. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From nantoniello@gmail.com Thu Apr 7 07:01: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 3953C28B56A for ; Thu, 7 Apr 2011 07:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPC0OvipAkTj for ; Thu, 7 Apr 2011 07:01:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D63983A68C4 for ; Thu, 7 Apr 2011 07:01:06 -0700 (PDT) Received: by iwn39 with SMTP id 39so3125378iwn.31 for ; Thu, 07 Apr 2011 07:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u+9br5mtIHGQCDtaeMwwtUWuGrmZr6pPOwhX+3i8N3Y=; b=PQIIACJjMJ/Z8tDfogJRtrLDsBork9fXcneUDKows2X0bue0nrEBbp6gQJCZjIVi5S heOJO/UJT9H37t0zvP4SFHPlW8mEr0EHje7oLXAQ/wT5kg7Y4A21foKM1PnPpATPT68/ VmQte6tTsqZuWJXEyR6AuQc6wik0E7jJUNbhQ= 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=UDwn1WSGfQXG/vc6rE5kPeTHbb9sTFDYaz7GxGucX/2sIoINbdgGammM/vJ8oKRwYS u1Hs2wZOvTlXHXEgjEapiuNhRt0EDdN6yOPTgTBBb2vrMUjs7lGMHVyRTmQ5HwBOeBp+ bS7opKuJAEqcFZwbrAtW8uxdA9YD4S79D2dQk= Received: by 10.231.193.202 with SMTP id dv10mr940700ibb.136.1302184971136; Thu, 07 Apr 2011 07:02:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.77 with HTTP; Thu, 7 Apr 2011 07:02:31 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> From: Nicolas Antoniello Date: Thu, 7 Apr 2011 11:02:31 -0300 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=005045016d9ea2fab604a054907c Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 14:01:08 -0000 --005045016d9ea2fab604a054907c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, I believe this discussion has as technical as non-technical points to consider... but just to clarify myself: Why setting the 2002::/16 as "deprecated" (whether this mean that it can be re-assigned or not) when we are still selling PCs OSs and router OSs with 6to4 support; and no talking about the bunch of 6to4 still working out there. Why don't (in case it could not be fixed) first stop supporting 6to4 (at least put it at the bottom of the OS options for transition mechanisms), wait a relative prudent time, and then (just then) "deprecate" the prefix? I have the sense we are putting the carriage in front of the horses here (why the sudden hurry?). Opinion? Best, Nicolas On Thu, Apr 7, 2011 at 05:04, Ole Troan wrote: > Chris, > > are you happy with the use of "deprecate" given the explanations provided > in this thread? > > not to forego matters, but I think we have managed to get a time slot in > the chair's busy WGLC schedule, so there would be another opportunity to > discuss this before sending the document onwards. > > cheers, > Ole > > > > > In =93Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4= ) to > Historic status=94 > > > > There is this recommendation: > > > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > > pointing to this document. Reassignment of the prefix for any usage > > requires justification via an IETF Standards Action [RFC5226]. > > > > It is not clear why this is necessary. > > > > If major vendors were to disable 6to4 by default, that would fix the > brokenness issue, while still allow for this prefix to be used in > specialized or enthusiast scenarios. Isn=92t any other action overkill? > > > > Thanks! > > ---------------------------- > > Christopher.Palmer@Microsoft.com > > Program Manager > > IPv6 @ Windows > > > > > > > > > > _______________________________________________ > > 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 > --005045016d9ea2fab604a054907c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all,

I believe this discussion has as technical as non-technica= l points to consider... but just to clarify myself:
Why setting the 2002= ::/16 as "deprecated" (whether this mean that it can be re-assign= ed or not) when we are still selling PCs OSs and router OSs with 6to4 suppo= rt; and no talking about the bunch of 6to4 still working out there.

Why don't (in case it could not be fixed) first stop supporting 6to= 4 (at least put it at the bottom of the OS options for transition mechanism= s), wait a relative prudent time, and then (just then) "deprecate"= ; the prefix?

I have the sense we are putting the carriage in front of the horses her= e (why the sudden hurry?).

Opinion?

Best,
Nicolas

<= br>
On Thu, Apr 7, 2011 at 05:04, Ole Troan <otroan@employees.o= rg> wrote:
Chris,

are you happy with the use of "deprecate" given the explanations = provided in this thread?

not to forego matters, but I think we have managed to get a time slot in th= e chair's busy WGLC schedule, so there would be another opportunity to = discuss this before sending the document onwards.

cheers,
Ole



> In =A0=93Request to move Connection of IPv6 Domains via IPv4 Clouds (6= to4) to Historic status=94
>
> There is this recommendation:
>
> IANA is requested to mark the 2002::/16 prefix as "deprecated&quo= t;,
> =A0 =A0pointing to this document. =A0Reassignment of the prefix for an= y usage
> =A0 =A0requires justification via an IETF Standards Action [RFC5226].<= br> >
> It is not clear why this is necessary.
>
> If major vendors were to disable 6to4 by default, that would fix the b= rokenness issue, while still allow for this prefix to be used in specialize= d or enthusiast scenarios. Isn=92t any other action overkill?
>
> Thanks!
> ----------------------------
> Christopher.Palmer@Microsoft.com
> Program Manager
> IPv6 @ Windows
>
>
>
>
> ________________________= _______________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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

--005045016d9ea2fab604a054907c-- From Fred.L.Templin@boeing.com Thu Apr 7 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 4675E28C0DD for ; Thu, 7 Apr 2011 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 T73u6TI4GWD8 for ; Thu, 7 Apr 2011 07:06:39 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 790423A68C4 for ; Thu, 7 Apr 2011 07:06:39 -0700 (PDT) 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 p37E825T019664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2011 07:08:03 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p37E8206004873; Thu, 7 Apr 2011 09:08:02 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p37E7wpM004767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 7 Apr 2011 09:08:02 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 7 Apr 2011 07:07:59 -0700 From: "Templin, Fred L" To: Fred Baker Date: Thu, 7 Apr 2011 07:07:57 -0700 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acv067C8dJvlWe33TzCJZF9Y5nvpGgAP/BAg Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> <009b01cbf3f1$4b22c970$e1685c50$@com> <34E4F50CAFA10349A41E0756550084FB049FEF81@!!PRVPEXVS04.corp.twcable.com> <6634030F-7E3D-439F-97D0-E6C85ACECA76@employees.org> <00F8378B-279A-4F17-80D4-2F005A197FFF@cisco.com> In-Reply-To: <00F8378B-279A-4F17-80D4-2F005A197FFF@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 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 07 Apr 2011 14:06:40 -0000 Hi Fred, Until your message, this discussion has had traction with the working group. I am not in a position to release a new draft without permission from my company which can require a considerable internal review cycle, after which this discussion thread will have grown stone cold. I wish you would have floated the idea to me off-list first. To your points, I believe this document needs to consider the case of a CPE router deployed at the border of a predominantly IPv4 network. In that case, ISATAP enables an automatic IPv6 capability for hosts in the end user network. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Wednesday, April 06, 2011 11:19 PM > To: Templin, Fred L > Cc: Ole Troan; Weil, Jason; Tina Tsou; 'Hemant Singh=20 > (shemant)'; 'IPv6 Ops WG'; 'Tony Hain (ahain)' > Subject: Re: [v6ops]=20 > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred, it might be most appropriate for you to write a draft=20 > on the configuration and use of ISATAP in a residential=20 > network. To my knowledge, it is rarely if ever used in the=20 > absence of an IT department to support it, or in the presence=20 > of a native IPv6 network, which is the topic of the CPE=20 > Router Draft. If you think it makes sense, maybe you can tell=20 > us how in the usual manner. >=20 > On Apr 7, 2011, at 1:36 AM, Templin, Fred L wrote: >=20 > > Hi Ole,=20 > >=20 > >> -----Original Message----- > >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of=20 > >> Ole Troan > >> Sent: Wednesday, April 06, 2011 12:44 PM > >> To: Weil, Jason > >> Cc: Tina Tsou; 'Hemant Singh (shemant)'; Templin, Fred L;=20 > >> 'Fred Baker (fred)'; 'IPv6 Ops WG'; 'Tony Hain (ahain)' > >> Subject: Re: [v6ops]=20 > >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>=20 > >>> I am not able clearly parse the data to the column=20 > >> headings, but if it helps the diagram below is what I was=20 > suggesting. > >>>=20 > >>> [DS HOST]--[v4 CE ROUTER]--[v6 BIS ROUTER]-->Service Provider > >>> | > >>> [DS HOST] > >>>=20 > >>> The issue in the topology depicted above is the IPv4-only=20 > >> CE (interior) ROUTER is out of scope for the -bis draft=20 > >> today. The current scope covers transition technologies on=20 > >> the WAN (6rd and DS-LITE) and a simple two router setup with=20 > >> the interior router being an IPv6 CE router. > >>=20 > >> what is the proposal, that the IPv6 CE comes with ISATAP=20 > >> supported on by default or be capable of doing ISATAP=20 > >> tunneling? (remember we are trying to make these routers=20 > >> require no management). > >=20 > > At least capable of acting as an ISATAP router on the LAN > > side. On by default would require some means of selecting one > > or more IPv6 prefixes to assign to the ISATAP link, but that > > should be easy to carve off of whatever stateful or stateless > > prefix delegations the CE receives via its WAN connection. > >=20 > >> if ISATAP is enabled by default, how do we know that the user=20 > >> hasn't intended a topology separating host on different links=20 > >> and by building a single virtual link we are violating that=20 > >> policy? > >=20 > > Such a user would be in a more competent position to disable > > and/or reconfigure the on-by-default settings than a novice > > user would be to enable an off-by-default setting. Besides, > > the ISATAP virtual link would not magically bypass any IPv4 > > filtering gateways in the network. So, the ISATAP virtual > > link might be partitioned, but the IPv4 filtering policies > > would not be violated.=20 > >=20 > >> e.g. why were the extra routers there in the first place. > >=20 > > For the same reasons that any IPv4 site administrator > > would portion the site off into separate subnets separated > > by IPv4 routers. > >=20 > >> how is ISATAP provisioning supposed to work? so far the IPv6=20 > >> CE router work has focused on the profile of the router=20 > >> itself, and it has references standards track document for=20 > >> WAN side and LAN side behaviour. > >=20 > > There is a lot of documented operational guidance on how > > to provision an ISATAP site service outside of the IETF > > document series - some of it from your company. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >> cheers, > >> Ole >=20 > = From fred@cisco.com Thu Apr 7 07: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 44D9A28C13E for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keIHUqYSYV72 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8A19328C128 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=138; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=RCHh97SshyFqwwHVPlJurog9VM38FanVglHswvoX+CI=; b=mj3OELoXwOc615UvpP/iIH+pdf44vOUnrVHN0Tw2SB1E9uJ1Ss7R4FzV Co5RbalG3MH1dyb21uMEJ9IDZgRh0x4e2awlzaWAvHohBKEEVjsLvdNYJ /jLkdbqjkYYTzS2iDkem2ohSWpQDiL1dmGZQQQTfoAQfV9KOLu5+RMTYV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoJ/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301888" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQvU028434; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBPom025036; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBPKD025003; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBPKD025003@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-herbst-v6ops-cpeenhancements@tools.ietf.org Subject: [v6ops] new draft: draft-herbst-v6ops-cpeenhancements-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, 07 Apr 2011 14:09:46 -0000 A new draft has been posted, at http://tools.ietf.org/draft-herbst-v6ops-cpeenhancements-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07: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 555C828C128 for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8aahpPfeHLN for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 98F9628C12C for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=134; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=WxPED0n0l4rK1u7ooHwTqGWYS8CHkTSBIMbttuCcFDs=; b=bYdcAjkxmm7UIeHSlscYWgfSsJn9oth1CcTlLVwbIZO+bshQrfW7+daJ 1ua1/3eoPKtrwUqhz/N4qLQlj5vycym+Ou29w98DDL6AELM5I+4relgvw 8mGLU1cIMXJodaRD1SbaU9wpAX+hWZ8zmVYg6UKvabKcRwUGsT+35Wxe3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoG/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301889" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQPf029393; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQJ7025041; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBPal025016; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBPal025016@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-6to4-advisory@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-6to4-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, 07 Apr 2011 14:09:46 -0000 A new draft has been posted, at http://tools.ietf.org/draft-ietf-v6ops-6to4-advisory-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07: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 7282328C12D for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNBRJ7QpPtU6 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BEC3728C130 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=137; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=PMmogl3R46CJTHDBjTCLe59aFu5uvvk6RBgA1W2cGyY=; b=RuXtypOEWUdrJZ9AtHaDBr9ezCLgbw43fuV0Ts6fox+VoG2jpsgQjVHR vlNPel0p3nteQ1HXmaony9425Qte7Jcf5/i31XnVdfuUax4bJs58QlBEo tEM5/pZXBGhxlb/JI1KfIXk0ooNYIAPQD3l/rSlz4IJYVkP4PTzozRlFi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAFvFnU2rRDoJ/2dsb2JhbACYcQEBjRF3pFOcXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="332525343" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQiE028437; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQeL025073; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQRG025042; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQRG025042@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-tan-v6ops-nat64-experiences@tools.ietf.org Subject: [v6ops] new draft: draft-tan-v6ops-nat64-experiences-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, 07 Apr 2011 14:09:46 -0000 A new draft has been posted, at http://tools.ietf.org/draft-tan-v6ops-nat64-experiences-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07: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 669AB28C12C for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql8IXNnusoq1 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AE78A28C12D for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=137; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=dQul1YC+gckn6JgP9QBoaBeodhxRB78A+yfKl/yMG5M=; b=jsdJOovBswGZ085e89GsHOYoIhORKEVpgcYWgtSYkBwgA9XdrIja8BEF dylE2GoMHaabSfRNKt3Q5BxlMe/0ba6ns/mKNbPBdZbOb0ujglT3+oI1k gRTr52NYixqw3MICwKMm0GlY76CU/Od3dcAu7WXx+c5edjFl2lxKC6Q2o U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHACDFnU2rRDoI/2dsb2JhbACYcQEBjRF3pFScXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="425600093" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQa8020796; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQFF025043; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBPOh025019; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBPOh025019@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-6to4-to-historic@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-6to4-to-historic-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, 07 Apr 2011 14:09:46 -0000 A new draft has been posted, at http://tools.ietf.org/draft-ietf-v6ops-6to4-to-historic-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07: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 E7EE928C126 for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcI+QC2nh8w4 for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B969E28C12F for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=138; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=fD5Eb625d3oGoTEQ16YY8ZJDN4OEMyDiTM5G50ku4xM=; b=ev2baiMkDKgwBEbeIxYNQ4BgfnJoQcCuzp9IC6zaVCUaENddtqXXj2hL 3n16hCDD9IpONLN6wpHWim5bfTVPJueFDvES/QVRY6fFR3DcMdbewkrA6 HBo+zz2EjqUM7hHBFLsaTxhM2bnc06aiTLNi9PPHpSfN8aLV2pzUyDQnD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHACDFnU2rRDoH/2dsb2JhbACYcQEBjRF3pFScXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="425600096" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQ8K002898; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQ96025067; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQTQ025038; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQTQ025038@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-lee-v6ops-tran-cable-usecase@tools.ietf.org Subject: [v6ops] new draft: draft-lee-v6ops-tran-cable-usecase-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-lee-v6ops-tran-cable-usecase-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 12E5528C128 for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxxVRn1Uugh2 for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D4BD728C134 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=144; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=TXkfSGzOUI6jmxKlCWDO8l8TnwX36YfzwpRBMWRO5pY=; b=BbL94Rg3e1GXqDMTcaLV1xXCMW48nmx9peAuO6/vqU9UZxyunq8FgJwL 6EHfZYoCkqjwdvEteF3iEyjo5xLWXiZ49anQDeG63eaYnzZfkf02ZtPrI x9kUQoaFyQDIxIc7cc63vcWP0NqqFPYcY17SjdEmEzrG4GA3XeFhXwC8t U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAFvFnU2rRDoH/2dsb2JhbACYcQEBjRF3pFOcXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="332525344" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQh4002902; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQdY025072; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQXq025046; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQXq025046@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-tsou-v6ops-mobile-transition-guide@tools.ietf.org Subject: [v6ops] new draft: draft-tsou-v6ops-mobile-transition-guide-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-tsou-v6ops-mobile-transition-guide-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 1A04028C126 for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWkX7bn5Vy8Z for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C1A9F28C131 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=149; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=S8PB9RtA+T43g5CtNDFqE4Ra9bv+E1ImFIH5w4hT5r0=; b=hgrzl7eGFviF5kErURl9yTu9nyb/hciY8Zv8keAzsOL8ealqUOMZ+0CF wpWCnybGXKJO+vrCkzB0kkZbTywGBkVErtpLCUQ5dhsh+mZ38POD4wODV rQBvBM/NG6nkJw4q9oah0GgLXW+gVqgc43bBSbzP5DlFdnyOXc2ZQMCv3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoH/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301890" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQq9002897; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQNw025061; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQsC025034; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQsC025034@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-kanizsai-v6ops-anycast-data-aggregation@tools.ietf.org Subject: [v6ops] new draft: draft-kanizsai-v6ops-anycast-data-aggregation-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-kanizsai-v6ops-anycast-data-aggregation-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 2D6E728C12C for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OrDsw2pMQnI for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D5D9E28C135 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=153; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=StneRcAhWkme1vP5WSQZBiVqXibsNOvrOvGNDDEf0ho=; b=mVFMnRV0Fx/XnWlfRxjJjmogeGy3wfxRknoksJO60wa03mzY0oRoTcux VmICrTLDR2VMbRG9xizH12XXYf+ZdTM5rX/CxieaTT2MNOmvE+mbyJ54I 4o6416AcZmoVg8LTuffsV+8rC/gFoB517Nm8lanPHryjwra//4FcBFtQt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHACDFnU2rRDoI/2dsb2JhbACYcQEBjRF3pFScXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="425600098" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQMo020805; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQaL025074; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBP1Q025025; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBP1Q025025@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 9C45028C12C for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fktW0tNs2nsE for ; Thu, 7 Apr 2011 07:09:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D32D628C133 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=129; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=s1XzF0BgW8Fs+IvRIgx+REL8pdSNO7f3YdmT/MXTrL0=; b=fJYuJ0sV6VV4TU5M0d3NOvPw8l7vmh8DFXh22z1GGc/gqiKwF4tH7feC 6AHCG3VE07VLGal/btZ0o7TL3g2lWO20Jlcw2CwP6um9gkHEXsPlk8Ql9 p61dRB0+NuEVR2FDqGJdV0laLjoYrMl4i5v9xVbRgnoXXC9duY0pqxOpT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoI/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301893" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQiQ020804; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQMi025071; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBPTN025009; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBPTN025009@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-3gpp-eps@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-3gpp-eps-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-ietf-v6ops-3gpp-eps-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 BFC1728C131 for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxRC2Sv0ThYf for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D94D528C136 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=145; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=uqUhW1//vmaC3wYRgIcL9w0FPKiBIfmz4U1iLcrzo9I=; b=DCye8e5mnxcDfcIKcdfmqO2CATRCwiwgAe8HoGxyd6hrVUkvpB4FHUZ5 Edk2pIXuyzjTEuEHeX1aVrObNWjjc8PyYxwDp6QMitGjwQ45UN4zRwch/ poltX9DKdLNw8Yi2PbGcHzyGb2ZVUJFlXGSy8PueJ/RCyxiMW9J9mbU+c M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAJLFnU2rRDoH/2dsb2JhbACYcQEBjRF3pFycXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="677315762" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQMZ002903; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQkJ025064; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQQC025029; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQQC025029@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-jjmb-v6ops-comcast-ipv6-experiences@tools.ietf.org Subject: [v6ops] new draft: draft-jjmb-v6ops-comcast-ipv6-experiences-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-jjmb-v6ops-comcast-ipv6-experiences-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 B270528C12F for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZdQffgWDfOu for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E1C6628C137 for ; Thu, 7 Apr 2011 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=138; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=ARcniY4X1pUdqbhHHQmLsE6na7WQvBnKqnG+kyCRdvs=; b=nGma+pPqq21f5tTB2/7qohwrdyHJlwXcJLuZhdobNE0s1mdZrNliDgD3 g9lJI1Y9nChGKxw5E/KhK+ptLIibTwhWB4S52quRo+ow45mR1dy+amJTF bUMdsjRpbUpY9WSsyM8BjZfhjiYE3LE51yRx39UASF4Gf28CbRusoJgtL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoG/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301894" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQtC029396; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQZG025076; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQ5x025062; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQ5x025062@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-zhang-v6ops-cgn-source-trace@tools.ietf.org Subject: [v6ops] new draft: draft-zhang-v6ops-cgn-source-trace-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-zhang-v6ops-cgn-source-trace-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 CB20C28C12C for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoszK3k4FqWS for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 01E4828C138 for ; Thu, 7 Apr 2011 07:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=143; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=zfBjNLjlVABnLquN5Xez90zztRr/79mPbJrpjjPyVk8=; b=jH58c+AJbhF9rAJ/1vtq8MjC4GOyMhZx3cgLWUB9b9Qx2GdQRb7SbtE+ 4fdYVPRYjhzwms+D+3Q5zb5R3HtIv2ZaMvvAS9BKJhgkwYxfT4eqqs7yF YbcLjwJcIPYxe47ZtM1jtZ3vQ9rg7karvY1d2ajYzfb9uIvW8rPsSxTX2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoI/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301898" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQop020813; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQA5025078; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQ0K025058; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQ0K025058@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-v6ops-multihoming-without-ipv6nat@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-multihoming-without-ipv6nat-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, 07 Apr 2011 14:09:47 -0000 A new draft has been posted, at http://tools.ietf.org/draft-v6ops-multihoming-without-ipv6nat-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 7528628C135 for ; Thu, 7 Apr 2011 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL3n7NQvjrBJ for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0C20F28C139 for ; Thu, 7 Apr 2011 07:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=140; q=dns/txt; s=iport; t=1302185487; x=1303395087; h=date:from:message-id:to:subject:cc; bh=J9Y3u2ACeKeY+mnmc92nsjxTmBwNMdmxCXID8jKrdls=; b=UN/sBMibWo8FGPIVbmbRX1YLxVCgC1fDczxKsgT/RaFIFFDSpfJ7sx/N W5JmGAtgIXSIwIA/rnhljqQYK2bLlyIpqFXZ6ESj2lm4GuK+MfB85ciCQ MLdYaxzRk5a1hf2dWtp7l5zjCzWUI+UbIWm3YY61aXlNjBq4XWMS3JzVo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoI/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301897" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQtc020808; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQKb025082; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBPSX025022; Thu, 7 Apr 2011 07:11:25 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:25 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBPSX025022@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-ipv6-cpe-router-bis@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ipv6-cpe-router-bis-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, 07 Apr 2011 14:09:48 -0000 A new draft has been posted, at http://tools.ietf.org/draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 98E4028C137 for ; Thu, 7 Apr 2011 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNUtsA7Wq+1p for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1C67428C13B for ; Thu, 7 Apr 2011 07:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=136; q=dns/txt; s=iport; t=1302185487; x=1303395087; h=date:from:message-id:to:subject:cc; bh=eFsoFvSeox2DAT0Qd2JSqlkm9AVyFDYr1XXMjYN8X88=; b=AyG0TiMpGkVI8l3dvGTjImq2bPZ7HfucSN0rfHO0IGa+tW08Uzpa/qI+ t6pAs+EZZPmnmf/VnKAvjp1srGX3BA4o88KilJmXKrG1snimL6bS7xZjt ArLrwN5RS/NfbpuWHT2fBhnsitNLb5eiNklDQMF6GSNruMs2LNSPL0fXd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAK3EnU2rRDoJ/2dsb2JhbACYcQEBjRF3pEicXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="291301901" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQ5o028442; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQU1025084; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQfS025066; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQfS025066@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-zhou-v6ops-mobile-use-case@tools.ietf.org Subject: [v6ops] new draft: draft-zhou-v6ops-mobile-use-case-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, 07 Apr 2011 14:09:48 -0000 A new draft has been posted, at http://tools.ietf.org/draft-zhou-v6ops-mobile-use-case-00.txt. Please take a look at it and comment. From fred@cisco.com Thu Apr 7 07:09: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 BA23828C132 for ; Thu, 7 Apr 2011 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvWN+dwNgjSw for ; Thu, 7 Apr 2011 07:09:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 130A528C13A for ; Thu, 7 Apr 2011 07:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=135; q=dns/txt; s=iport; t=1302185486; x=1303395086; h=date:from:message-id:to:subject:cc; bh=6VevB6VIUNWy8E44ENj6bOj+7OyYJLJKjnvQxz++GJI=; b=bWMGjYuh/LOA7L91m8Uf+7gX+AkmSVJo2SCa/bDOSkQ2yKUTHjfFhY/1 ukbPRHemsbcSxTZJSrkFgmqW0a26wT8SnkQjIUGAqm8kW1QY123MyxwbX B/lZ9NuYJaxVypFFLy6m++MduNwemu0u4y2gDM3edHlDMUo65nU2Qwaev I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHACDFnU2rRDoH/2dsb2JhbACYcQEBjRF3pFScXIVtBIVQ X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="425600099" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 14:11:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37EBQsH002907; Thu, 7 Apr 2011 14:11:26 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p37EBQvf025075; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p37EBQSZ025050; Thu, 7 Apr 2011 07:11:26 -0700 (PDT) Date: Thu, 7 Apr 2011 07:11:26 -0700 (PDT) From: Fred Baker Message-Id: <201104071411.p37EBQSZ025050@irp-view13.cisco.com> To: v6ops@ietf.org Cc: draft-v6ops-ipv6-cpe-router-bis@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-ipv6-cpe-router-bis-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, 07 Apr 2011 14:09:48 -0000 A new draft has been posted, at http://tools.ietf.org/draft-v6ops-ipv6-cpe-router-bis-00.txt. Please take a look at it and comment. From martin@millnert.se Thu Apr 7 07:37: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 E20AF28C133 for ; Thu, 7 Apr 2011 07:37:50 -0700 (PDT) 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 tou5mXrEYDdv for ; Thu, 7 Apr 2011 07:37:50 -0700 (PDT) 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 0EF9528C129 for ; Thu, 7 Apr 2011 07:37:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 2EF1777A2; Thu, 7 Apr 2011 16:52:28 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvvWNaJnaz-U; Thu, 7 Apr 2011 16:52:28 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id 4F99376C5; Thu, 7 Apr 2011 16:52:24 +0200 (CEST) From: Martin Millnert To: Roman.Arcea@orange.md In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Apr 2011 10:36:17 -0400 Message-ID: <1302186977.3243.8.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Dmitry Anipko , Christopher Palmer Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 14:37:51 -0000 Brian, Roman, On Thu, 2011-04-07 at 10:50 +0300, Roman.Arcea@orange.md wrote: > > But how will that affect people who are happily using 6to4? Please > > don't forget > > that many 6to4 sessions are entirely successful. I really don't see how > > we could legitimately mess those people up to eliminate the cases that > don't > > work. It's either on by default or off by default. draft-ietf-v6ops-6to4-advisory-00 suggests that it is off by default, and user-enable:able. > +1 > Killing it entirely seems a bit too much. It is still a way to get > reasonably working IPv6 for some purposes. We're *not* discussing "killing it entirely". > I believe it will be good enough to disable the 6to4 and teredo by default > with a patch, but still leave it configurable from cli for whoever > understands why he is doing that. That is exactly what modifying the A-record of 6to4.ipv6.microsoft.com. will supposedly accomplish. Quoting my previous e-mail: "You can use the netsh interface ipv6 6to4 set relay command to specify which DNS name to query." Thus, anyone who wants to use 6to4 would only have to do the above, and my guess is that you can enter IPv4 literals ("192.88.99.1" ) as well as domain names there. Regards, Martin From fred@cisco.com Thu Apr 7 07:40: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 EEEEB3A6938 for ; Thu, 7 Apr 2011 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.171 X-Spam-Level: X-Spam-Status: No, score=-110.171 tagged_above=-999 required=5 tests=[AWL=-0.172, 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 dn01niEDnNrJ for ; Thu, 7 Apr 2011 07:40:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C056C3A68C4 for ; Thu, 7 Apr 2011 07:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=400; q=dns/txt; s=iport; t=1302187357; x=1303396957; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=ZC0wtAV+fgk7olE76r50rmQW5midvourV0x6cz2H6wo=; b=eFvPLyowF3o2t+Xl8Gn7lHxLDUGW0biQrO2xNSpjDU+q7oGJJAmT0Pup OQRvThkyrjFfsxgRdRiXfVoRRejl4d9z27Hwo4T7wbPkTzBHCsfpF0IVq NoeG30cLvmRCKsUKkj3dtaD/YNI58JRRFbEXkNqJxWvd1HlfJMM7gIi0J s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUEACfMnU2Q/khNgWdsb2JhbACmBBQBARYmJYh5my6cWYVtBI1Fg2g X-IronPort-AV: E=Sophos;i="4.63,316,1299456000"; d="scan'208";a="24847627" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Apr 2011 14:42:36 +0000 Received: from Freds-Computer.local (dhcp-10-55-85-64.cisco.com [10.55.85.64]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37EgPu2012388 for ; Thu, 7 Apr 2011 14:42:36 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 07 Apr 2011 16:42:36 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 07 Apr 2011 16:42:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <201104071411.p37EBPKD025003@irp-view13.cisco.com> Date: Thu, 7 Apr 2011 16:39:22 +0200 Message-Id: <44F7ED4D-30E8-4EC0-BDE7-AB6FEE9D7008@cisco.com> References: <201104071411.p37EBPKD025003@irp-view13.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] new draft: 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, 07 Apr 2011 14:40:54 -0000 My script obviously didn't work as expected. Please ignore. On Apr 7, 2011, at 4:11 PM, Fred Baker wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/draft-herbst-v6ops-cpeenhancements-00.txt. Please = take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From martin@millnert.se Thu Apr 7 07:52:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5AF28C13A for ; Thu, 7 Apr 2011 07:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66N84deUgC8P for ; Thu, 7 Apr 2011 07:52:50 -0700 (PDT) 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 B849628C135 for ; Thu, 7 Apr 2011 07:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id E1E0677A2; Thu, 7 Apr 2011 17:07:29 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTYE4YkmlSWU; Thu, 7 Apr 2011 17:07:29 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id CDC8476C5; Thu, 7 Apr 2011 17:07:28 +0200 (CEST) From: Martin Millnert To: Tore Anderson In-Reply-To: <4D9D6236.5000302@redpill-linpro.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D6236.5000302@redpill-linpro.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Apr 2011 10:51:21 -0400 Message-ID: <1302187881.3243.14.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Brian, "v6ops@ietf.org" , Dmitry Anipko , Christopher Palmer Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 14:52:51 -0000 Tore, On Thu, 2011-04-07 at 09:05 +0200, Tore Anderson wrote: > However, if it is possible to muck around with the > 6to4.ipv6.microsoft.com record in a way that prevents the 6to4 > interface from being enabled (and, by extension, RAs from ICS) - > please do share! That's where I saw the possibility of prudent forward-looking engineering, by for example using an A-record pointing to an address in 127/8, as a means of signaling "disable yourself" to the 6to4 adapter. We still haven't seen whether this is how it actually works or not, but it is certainly what Chris is alluding. Failing this, as you describe so well, new code is obviously required to ship to hosts. Regards, Martin From carlosm3011@gmail.com Thu Apr 7 08:06: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 EBF9D28C13C for ; Thu, 7 Apr 2011 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVKGIoq6p8WV for ; Thu, 7 Apr 2011 08:06:46 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 24A5328C112 for ; Thu, 7 Apr 2011 08:06:46 -0700 (PDT) Received: by yic13 with SMTP id 13so1266163yic.31 for ; Thu, 07 Apr 2011 08:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UG1BxdsX+GtN2msptgFUmSEbQIQ1cNKsrr7rTPRdJfY=; b=V0Z8jhOxSWfd/Z+nVChYtd2dV9MIOTgWG4/0R5VvIN8qlQJDX/MDJq+gN4hEOgLB+A o3GFpiY2YkWslu97TwJEhacJA5agFObTpNvZYvuvMMsncMTzNjEwyl1wOoB5ZeCcO9Fs O8QwasxBmWEzY2px6ooIkjokfyLggkHw6mePA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sGZM0SartIbra6+H+hi9nsh3laGlK5TucwF1/Ry2nNWcQPUxBrOaIEXqgr4pQWuzGi +qXgUq0c6CqqN/tPvJKUUq0QY3QQqB+FIWxz6Nik4yWvYcp5iKJc8nSrf1lg+asbBe6S /NwMy6DFJbjTS7QImjIfNGM5l9RFIio7Q8TDM= MIME-Version: 1.0 Received: by 10.43.58.208 with SMTP id wl16mr1619810icb.319.1302188712309; Thu, 07 Apr 2011 08:05:12 -0700 (PDT) Sender: carlosm3011@gmail.com Received: by 10.42.244.73 with HTTP; Thu, 7 Apr 2011 08:05:12 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 7 Apr 2011 12:05:12 -0300 X-Google-Sender-Auth: 51slx6b0JggPckPpcJh_J5yPUkc Message-ID: From: Carlos Martinez-Cagnazzo To: Erik Kline Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 15:06:47 -0000 Well put Erik, I agree with you. If we take out (most) of the automatic part it ceases to be 6to4. On Wed, Apr 6, 2011 at 8:29 PM, Erik Kline wrote: > I would refer specifically to the numbers for 6to4 customers where the > return path was directly on the server, i.e. the client-to-server relay w= as > not a problem (because the SYN packet reached the servers) and the > server-to-client relay was not a problem (because the server was > encapsulating directly). =A0Even in that scenario the connection completi= on > rate was abysmal, IIRC. > All of which reinforces the notion that it's not a valuable transition > mechanism. =A0It's a experimental thing, and plenty useful as such. =A0Bu= t it's > not production quality unless it's fully managed (i.e. it can be confirme= d > that no proto41 blocking is going on, etc). =A0In which case it's basical= ly > 6rd or static tunnels. > > On 6 April 2011 23:21, Carlos Martinez-Cagnazzo wrote= : >> >> I was there, but I'm not sure I follow what you mean. If you can be >> more specific, I would appreciate it. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From Wesley.E.George@sprint.com Thu Apr 7 08:17: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 052F228C0E1 for ; Thu, 7 Apr 2011 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.261 X-Spam-Level: X-Spam-Status: No, score=-5.261 tagged_above=-999 required=5 tests=[AWL=0.738, 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 5+taPFP0JV-q for ; Thu, 7 Apr 2011 08:17:32 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 857F728C0D7 for ; Thu, 7 Apr 2011 08:17:32 -0700 (PDT) Received: from mail32-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Thu, 7 Apr 2011 15:19:16 +0000 Received: from mail32-va3 (localhost.localdomain [127.0.0.1]) by mail32-va3-R.bigfish.com (Postfix) with ESMTP id D7A8712284EB; Thu, 7 Apr 2011 15:19:16 +0000 (UTC) X-SpamScore: -43 X-BigFish: VS-43(zz9371O103dK1432N98dK4015Lzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h34h61h) 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-va3 (localhost.localdomain [127.0.0.1]) by mail32-va3 (MessageSwitch) id 1302189556559648_19712; Thu, 7 Apr 2011 15:19:16 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.254]) by mail32-va3.bigfish.com (Postfix) with ESMTP id 7A0EE4B0056; Thu, 7 Apr 2011 15:19:16 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 7 Apr 2011 15:19:15 +0000 Received: from PDAWEH01.ad.sprint.com (PDAWEH01.corp.sprint.com [144.226.110.69]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p37FIv3d012207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2011 10:19:13 -0500 Received: from PLSWEH04.ad.sprint.com (144.226.251.22) by PDAWEH01.ad.sprint.com (144.226.110.69) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 7 Apr 2011 10:19:02 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH04.ad.sprint.com ([2002:90e2:fb16::90e2:fb16]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 10:19:01 -0500 From: "George, Wes E [NTK]" To: Nicolas Antoniello , Ole Troan Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: AQHL9SyMTp6kgz0IYkCjh9SyEC+Y+JRSdfGA Date: Thu, 7 Apr 2011 15:19:00 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6D604@PLSWM12A.ad.sprint.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0103_01CBF515.975B9130" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 15:17:34 -0000 ------=_NextPart_000_0103_01CBF515.975B9130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I fail to see the connection between leaving the prefixes alone but = deprecating the protocol. Either it's considered a supported protocol (including its defined well-known prefixes) or it=92s not. = Doing something with the prefixes later doesn=92t change that, because that=92s largely a record-keeping exercise on IANA=92s part. I think you=92re putting too much emphasis on the importance of the = prefixes themselves, and are making a bigger deal out of deprecation than is necessary. Deprecation !=3D unceremonious shutdown, = and there=92s no internet police that will show up if you choose to continue using it. We=92re simply saying that if it breaks, = especially in one of the ways that we already know that it=92s likely to do so, you=92re on your own. http://en.wikipedia.org/wiki/Deprecation In=A0computer software=A0or authoring programs standards and = documentation, the term=A0deprecation=A0is applied = to=A0software=A0features that are superseded and should be avoided. Although deprecated features = remain in the current version, their use may raise warning messages recommending alternative practices, and deprecation may = indicate that the feature will be removed in the future. Features are deprecated=97rather than being removed=97in order to = provide=A0backward compatibility=A0and give programmers who have used = the feature time to bring their code into compliance with the new standard. Also, we *are* saying in the draft to stop putting out new devices with = 6to4 support, and recommending a gradual wind-down of 6to4 relay support so that existing functional implementations are minimally = impacted. As I said at the mic, beyond Geoff=92s evidence as to how =93well=94 = 6to4 works, 6to4 is about to get broken in a whole series of new ways because of the prevalence of NAT + non-RFC1918 addresses. It=92s in our = best interest to try to get ahead of that and say that it is no longer a recommended method of IPv6 connectivity, or we=92ll waste a = lot of time trying to fix something that is increasingly looking unfixable at the expense of real IPv6 deployment.=20 Thanks,=20 Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Nicolas Antoniello Sent: Thursday, April 07, 2011 10:03 AM To: Ole Troan Cc: v6ops@ietf.org; Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Dear all, I believe this discussion has as technical as non-technical points to = consider... but just to clarify myself: Why setting the 2002::/16 as "deprecated" (whether this mean that it can = be re-assigned or not) when we are still selling PCs OSs and router OSs with 6to4 support; and no talking about the bunch of 6to4 = still working out there. Why don't (in case it could not be fixed) first stop supporting 6to4 (at = least put it at the bottom of the OS options for transition mechanisms), wait a relative prudent time, and then (just then) = "deprecate" the prefix? I have the sense we are putting the carriage in front of the horses here = (why the sudden hurry?). Opinion? Best, Nicolas On Thu, Apr 7, 2011 at 05:04, Ole Troan wrote: Chris, are you happy with the use of "deprecate" given the explanations = provided in this thread? not to forego matters, but I think we have managed to get a time slot in = the chair's busy WGLC schedule, so there would be another opportunity to discuss this before sending the document onwards. cheers, Ole > In =A0=93Request to move Connection of IPv6 Domains via IPv4 Clouds = (6to4) to Historic status=94 > > There is this recommendation: > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > =A0 =A0pointing to this document. =A0Reassignment of the prefix for = any usage > =A0 =A0requires justification via an IETF Standards Action [RFC5226]. > > It is not clear why this is necessary. > > If major vendors were to disable 6to4 by default, that would fix the = brokenness issue, while still allow for this prefix to be used in specialized or enthusiast scenarios. Isn=92t any other action = overkill? > > Thanks! > ---------------------------- > Christopher.Palmer@Microsoft.com > Program Manager > IPv6 @ Windows > > > > > _______________________________________________ > 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 ------=_NextPart_000_0103_01CBF515.975B9130 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDcxNTE4NTlaMCMGCSqGSIb3DQEJBDEWBBSVX0fKTxhu O0JvUhbyIz8rIQoj8DBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBil8rpoXRBqqyL/y1zSXsXKWufrzoU tgMvStAoeOnS4Et1U2sl8ChpDFcPdkzBhvl+2/qOc99jjqhABVqbW1KuJCNOZLXl9Xc0eTOwsxmV hsoE298TeQN2gFWAYB46y60n/yblaWX9gL7upRPA+xH1VCYmN3o7BLBYl4HzEulSOwAAAAAAAA== ------=_NextPart_000_0103_01CBF515.975B9130-- From jhw@apple.com Thu Apr 7 11:32: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 7EBFD28C0E4 for ; Thu, 7 Apr 2011 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 h+YFC-mroCY2 for ; Thu, 7 Apr 2011 11:32:07 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id EFC4C3A69CD for ; Thu, 7 Apr 2011 11:32:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJA0031UOSRBMN0@localhost.apple.com> for v6ops@ietf.org; Thu, 07 Apr 2011 11:33:51 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-8e-4d9e038f9cf2 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id CC.C7.29082.F830E9D4; Thu, 07 Apr 2011 11:33:51 -0700 (PDT) Received: from [17.193.13.64] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJA00BNIOWFHD40@elliott.apple.com> for v6ops@ietf.org; Thu, 07 Apr 2011 11:33:51 -0700 (PDT) From: james woodyatt In-reply-to: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 07 Apr 2011 11:33:51 -0700 Message-id: <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Christopher Palmer X-Mailer: Apple Mail (2.1214) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2011 18:32:07 -0000 On Apr 6, 2011, at 21:29 , Christopher Palmer wrote: > So, a 6to4 client will experience no change in their 6to4 experience. Relays will still be as available and routable (or not) as they are today? > > I'm very green in terms of IETF participation, so I apologize if my requests for clarity concerning this matter are entirely foolish. Christopher, this is a Standards Track draft, which means the very first thing you should do when reading it for content is look for all the capitalized normative keywords. Especially the phrases that use MUST and MUST NOT keywords. Its intended audience is plainly other IETF participants, and not the makers of Internet equipment, as it places no requirements on them whatsoever. It makes some non-normative recommendations to operators, that may be relevant, but it doesn't say anything that will show up in an IPv6 Ready certification test. When I briefed my managers about this draft, I told them that it currently requires us to do absolutely nothing in the foreseeable future, and it explicitly permits us to continue doing what we are doing today. My reading of the document suggests that you can safely ignore its current form as well. -- james woodyatt member of technical staff, core os networking From Jean-Francois.TremblayING@videotron.com Thu Apr 7 13:36: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 EF3383A6977; Thu, 7 Apr 2011 13:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 iQPY-HOdXW55; Thu, 7 Apr 2011 13:36:09 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by core3.amsl.com (Postfix) with ESMTP id 0D2253A68C3; Thu, 7 Apr 2011 13:36:09 -0700 (PDT) In-Reply-To: <00F8378B-279A-4F17-80D4-2F005A197FFF@cisco.com> To: fred@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 7 Apr 2011 16:37:39 -0400 X-MIMETrack: Serialize by Router on DOMMTL11/SRV/GVL(Release 7.0.2FP1|January 10, 2007) at 2011-04-07 16:37:39, Serialize complete at 2011-04-07 16:37:39 Content-Type: multipart/alternative; boundary="=_alternative 00714FD58525786B_=" Cc: 'IPv6 Ops WG' , v6ops-bounces@ietf.org Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 07 Apr 2011 20:36:10 -0000 Message en plusieurs parties au format MIME --=_alternative 00714FD58525786B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Fred Baker =20 Envoy=E9 par : v6ops-bounces@ietf.org 07/04/2011 02:19 AM A "Templin, Fred L" cc 'IPv6 Ops WG' , "'Tony Hain \(ahain\)'" Objet Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > Fred, it might be most appropriate for you to write a draft on the=20 configuration and use of ISATAP=20 > in a residential network. To my knowledge, it is rarely if ever used in=20 the absence of an IT=20 > department to support it, or in the presence of a native IPv6 network,=20 which is the topic of=20 > the CPE Router Draft. If you think it makes sense, maybe you can tell us = how in the usual manner. +1 Routed networks are rarely seen in a residential environment (outside of=20 Tony's house).=20 Besides, adding ISATAP in this draft would only add confusion to an=20 already confused CPE=20 vendor ecosystem, IMHO. From an ISP point of view, it's probably=20 preferable to have vendors=20 implement few feature correctly than many poorly. Let them focus on=20 DHCPv6-PD, PPPoE and 6RD first.=20 /JF --=_alternative 00714FD58525786B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
<below>



Fred Baker <fred@c= isco.com>
Envoy=E9 par : v6ops-bounces@ietf.or= g

07/04/2011 02:19 AM

A
"Templin, Fred L" <Fred= .L.Templin@boeing.com>
cc
'IPv6 Ops WG' <v6ops@ietf.org>, "'Tony Hain \(ahain\)'" <ahain@cisco.com>
Objet
Re: [v6ops]       &nb= sp;Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt




> Fred, it might be most appropriate for you to write a draft on the configuration and use of ISATAP
> in a residential network. To my knowledge, it is rarely if ever used in the absence of an IT
> department to support it, or in the presence of a native IPv6 network, which is the topic of
> the CPE Router Draft. If you think it makes sen= se, maybe you can tell us how in the usual manner.

+1

Routed networks are rarely seen in a residential env= ironment (outside of Tony's house).

Besides, adding ISATAP in this draft would only add confusion to an already confused CPE
vendor ecosystem, IMHO. From an ISP point of view, it's probably preferable to have vendors
implement few feature correctly than many poorly. Let them focus on DHCPv6-PD, PPPoE and 6RD first.

/JF

--=_alternative 00714FD58525786B_=-- From jason.weil@twcable.com Thu Apr 7 15:04: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 E08A93A69E1 for ; Thu, 7 Apr 2011 15:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv34Kk08yffm for ; Thu, 7 Apr 2011 15:04:26 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by core3.amsl.com (Postfix) with ESMTP id 6F5AE3A6943 for ; Thu, 7 Apr 2011 15:04:26 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.63,319,1299474000"; d="scan'208";a="211242780" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Apr 2011 18:30:44 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 7 Apr 2011 18:06:01 -0400 From: "Weil, Jason" To: "Templin, Fred L" , "Hemant Singh (shemant)" , "Fred Baker (fred)" Date: Thu, 7 Apr 2011 18:06:02 -0400 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvz4Q8n0FNPjHZLSOC0dAwAQxTsaQAAYSGAAACHRjAAAarCoAAAvcPqACHeDfAAPjCcwA== Message-ID: <34E4F50CAFA10349A41E0756550084FB049FF62F@PRVPEXVS04.corp.twcable.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om>< 5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9F E2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9- DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109. cisco.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.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 , "Tony Hain \(ahain\)" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 07 Apr 2011 22:04:28 -0000 Fred T., I completely agree that IPv4 links and IPv4 routers are reasonable and expe= cted in nearly limitless topologies in the residential network. But in orde= r to limit scope creep of this router-bis draft to something that could pu= blished in a reasonable amount of time, the arbitrarily complex home networ= k was not included. In fact it was narrowed down to just the topology depic= ted in the draft as it stands today. I think Fred Baker offers a good sugge= stion in requesting a separate document for how this would be configured an= d function in various network configurations if you feel that this would be= useful and implemented by CE router vendors. Thanks, Jason -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Wednesday, April 06, 2011 12:19 PM To: Weil, Jason; Hemant Singh (shemant); Fred Baker (fred) Cc: IPv6 Ops WG; Tony Hain (ahain) Subject: RE: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.t= xt Hi Jason, I'm not sure I understand that. We have no idea what varieties of topologies are set up in home/soho networks today, however it seems reasonable to assume that many have lots of IPv4 links and routers internally. That class of network would like to see IPv6 automatically turned on when their new CPE router is dropped in place the same as for simple home/soho networks with trivial internal topologies. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Weil, Jason [mailto:jason.weil@twcable.com] > Sent: Tuesday, April 05, 2011 5:15 PM > To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG; Tony Hain (ahain) > Subject: RE: > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > > If I recall correctly ISATAP was designed to support > duals-stack hosts through IPv4-only intermediate hops. The > use case that I tried hard not to ponder but is the only one > I could think of here is an intermediate hop IPv4-only CE > router connected between a dual-stack host and the dual-stack > on LAN CPE Router. While it is possibly and maybe even likely > this will happen, as Hemant alluded, the uses cases currently > being considered were assuming Dual-stack home network and > IPv4-only or IPv6-only WAN connection to the service > provider. I would say this belongs in the 3rd Phase draft for > complex multi-router home networks. > > Thanks, > > Jason > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On > Behalf Of Hemant Singh (shemant) [shemant@cisco.com] > Sent: Tuesday, April 05, 2011 7:57 PM > To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG; Tony Hain (ahain) > Subject: Re: [v6ops] > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > Fred T., > > Someone else pointed out to me use of ISATAP is in the home > LAN. Thus I > need not compare ISATAP to WAN 6to4 transition tech. > However, the use > case for ISATAP is not clear in the home LAN. Let's assume > the home has > multiple subnets. Why can't the home use dual-stack in the LAN with > private IPv4 addresses and ULA and global IPv6 addresses with routing > and instead use ISATAP? > > Thanks, > > Hemant > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Hemant Singh (shemant) > Sent: Tuesday, April 05, 2011 7:03 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: Re: > [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > Fred T., > > If the CE router gets a public IPv4 address the CE router > goes directly > to the public IPv4 Internet. If the CE router gets a "private" IPv4 > address where private is RFC 1918 address space + the specific subnet > defined in DS-Lite, the CE router uses DS-Lite. DS-Lite also > takes care > of shared IPv4 addresses between multiple homes. Can ISATAP take care > of shared IPv4 address between different homes? > > Hemant > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > This E-mail and any of its attachments may contain Time > Warner Cable proprietary information, which is privileged, > confidential, or subject to copyright belonging to Time > Warner Cable. This E-mail is intended solely for the use of > the individual or entity to which it is addressed. If you are > not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or > action taken in relation to the contents of and attachments > to this E-mail is strictly prohibited and may be unlawful. If > you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and > any copy of this E-mail and any printout. > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brian.e.carpenter@gmail.com Fri Apr 8 00:00: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 2ECB03A688A for ; Fri, 8 Apr 2011 00:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+uchUmyhJpQ for ; Fri, 8 Apr 2011 00:00:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 136053A6889 for ; Fri, 8 Apr 2011 00:00:44 -0700 (PDT) Received: by wwa36 with SMTP id 36so2730642wwa.13 for ; Fri, 08 Apr 2011 00:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8MJsv39Zs14WDHfjnJe9h633dficxfW2VxNfnUt7jWY=; b=Q2KSWI5pWXk7U7OJuYzVQVQv6DGxAd+2oYqbtTOMRmU/fZBeCv1SeHpJ66CAIykV+B vRTcFQ2CFyI2avqVveJFs8ghEd+2UObANCMoapXmQnAqyhLDftpycNyWzN+8bHnchsMB IrHwguVkMNV7uvbDXW/HxlUPCy4UoKcEJexho= 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=AHnVDgbFDpQJ2VGZogPLhgez4V2vMHC5R18iJPijeOHVnUIJeS+4jJ3i1jMF9nV2kv yopdx6I02xqH9vDtJGzcvMs4ri0FnJf2H4j0/vvVoR6g2MM0pN2FYsbPY++AECJ6n5PW 6hceYEvucuXrhRVjrBt7avj8IIqRmGnDpwGs4= Received: by 10.227.61.142 with SMTP id t14mr1799595wbh.84.1302246148353; Fri, 08 Apr 2011 00:02:28 -0700 (PDT) Received: from [192.168.1.65] (host86-166-116-170.range86-166.btcentralplus.com [86.166.116.170]) by mx.google.com with ESMTPS id g7sm1493554wby.48.2011.04.08.00.02.26 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 00:02:27 -0700 (PDT) Message-ID: <4D9EB2FF.2060900@gmail.com> Date: Fri, 08 Apr 2011 19:02:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> In-Reply-To: <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2011 07:00:46 -0000 James, All vendors can choose to ignore all RFCs , if they want to :-) However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that. netsh interface ipv6 6to4 set state state=disabled Regards Brian On 2011-04-08 06:33, james woodyatt wrote: > On Apr 6, 2011, at 21:29 , Christopher Palmer wrote: > >> So, a 6to4 client will experience no change in their 6to4 experience. Relays will still be as available and routable (or not) as they are today? >> >> I'm very green in terms of IETF participation, so I apologize if my requests for clarity concerning this matter are entirely foolish. > > Christopher, this is a Standards Track draft, which means the very first thing you should do when reading it for content is look for all the capitalized normative keywords. Especially the phrases that use MUST and MUST NOT keywords. Its intended audience is plainly other IETF participants, and not the makers of Internet equipment, as it places no requirements on them whatsoever. It makes some non-normative recommendations to operators, that may be relevant, but it doesn't say anything that will show up in an IPv6 Ready certification test. > > When I briefed my managers about this draft, I told them that it currently requires us to do absolutely nothing in the foreseeable future, and it explicitly permits us to continue doing what we are doing today. My reading of the document suggests that you can safely ignore its current form as well. > > > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Fri Apr 8 00:02: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 D363C3A6A45 for ; Fri, 8 Apr 2011 00:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 uqskQVPRRPJh for ; Fri, 8 Apr 2011 00:02:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 178C53A6889 for ; Fri, 8 Apr 2011 00:02:35 -0700 (PDT) Received: by wwa36 with SMTP id 36so2731663wwa.13 for ; Fri, 08 Apr 2011 00:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6HPIRal0EkF1ylOJ8fwfTqL2lo9Eo5l1gFH9Wy58xrw=; b=cUQN6Y/H43+0tJ15vh7QSr8EFrTI94ZQvhD7yOKhpsaTJuHiha8xj3RXWpRf1IYEBz ynMw8x09+FOdiRv3EJEdTlBoQ170X5LaFUU9eFC/eyS4vUusrBEgpJ4xBXh+GRR8C3vo rJ8e+olL3/q/7iqkQr9fjheWGrT3N+/lIZGlM= 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=pYXax4SsIQbp9EHmPhq0DlTd7Qe41zmKq5DWyBYGRpVQd8NqJnRGzCOkTWVaFlrJjX E6bD3GqavECCzjcLAOVmy4Y/VG/lRWXEJ9Ak5ToXobFkkjJ8Q0Pp5gPZ4jqwe8zsTrsE E8to0xTzDORnGMVYnw+ZcUKWaajNF2wqUL+00= Received: by 10.227.110.37 with SMTP id l37mr1837413wbp.114.1302246260679; Fri, 08 Apr 2011 00:04:20 -0700 (PDT) Received: from [192.168.1.65] (host86-166-116-170.range86-166.btcentralplus.com [86.166.116.170]) by mx.google.com with ESMTPS id b20sm1496286wbb.16.2011.04.08.00.04.18 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 00:04:19 -0700 (PDT) Message-ID: <4D9EB36F.5060702@gmail.com> Date: Fri, 08 Apr 2011 19:04:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "George, Wes E [NTK]" References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C6D604@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6D604@PLSWM12A.ad.sprint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Christopher Palmer , "v6ops@ietf.org" Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2011 07:02:38 -0000 Correct. Actually I don't care whether the prefixes are labelled 'deprecated' or simply 'reserved'. The purpose is to prevent IANA allocating them for a large number of years. Regards Brian On 2011-04-08 03:19, George, Wes E [NTK] wrote: > I fail to see the connection between leaving the prefixes alone but dep= recating the protocol. Either it's considered a supported > protocol (including its defined well-known prefixes) or it=E2=80=99s no= t. Doing something with the prefixes later doesn=E2=80=99t change that, > because that=E2=80=99s largely a record-keeping exercise on IANA=E2=80=99= s part. > I think you=E2=80=99re putting too much emphasis on the importance of t= he prefixes themselves, and are making a bigger deal out of > deprecation than is necessary. Deprecation !=3D unceremonious shutdown,= and there=E2=80=99s no internet police that will show up if you choose > to continue using it. We=E2=80=99re simply saying that if it breaks, es= pecially in one of the ways that we already know that it=E2=80=99s likely= to > do so, you=E2=80=99re on your own. >=20 > http://en.wikipedia.org/wiki/Deprecation > In computer software or authoring programs standards and documentation,= the term deprecation is applied to software features that > are superseded and should be avoided. Although deprecated features rema= in in the current version, their use may raise warning > messages recommending alternative practices, and deprecation may indica= te that the feature will be removed in the future. Features > are deprecated=E2=80=94rather than being removed=E2=80=94in order to pr= ovide backward compatibility and give programmers who have used the featu= re > time to bring their code into compliance with the new standard. >=20 > Also, we *are* saying in the draft to stop putting out new devices with= 6to4 support, and recommending a gradual wind-down of 6to4 > relay support so that existing functional implementations are minimally= impacted. >=20 > As I said at the mic, beyond Geoff=E2=80=99s evidence as to how =E2=80=9C= well=E2=80=9D 6to4 works, 6to4 is about to get broken in a whole series o= f new ways > because of the prevalence of NAT + non-RFC1918 addresses. It=E2=80=99s = in our best interest to try to get ahead of that and say that it is > no longer a recommended method of IPv6 connectivity, or we=E2=80=99ll w= aste a lot of time trying to fix something that is increasingly > looking unfixable at the expense of real IPv6 deployment.=20 >=20 > Thanks,=20 > Wes George >=20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Nicolas Antoniello > Sent: Thursday, April 07, 2011 10:03 AM > To: Ole Troan > Cc: v6ops@ietf.org; Christopher Palmer > Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status >=20 > Dear all, >=20 > I believe this discussion has as technical as non-technical points to c= onsider... but just to clarify myself: > Why setting the 2002::/16 as "deprecated" (whether this mean that it ca= n be re-assigned or not) when we are still selling PCs OSs > and router OSs with 6to4 support; and no talking about the bunch of 6to= 4 still working out there. >=20 > Why don't (in case it could not be fixed) first stop supporting 6to4 (a= t least put it at the bottom of the OS options for transition > mechanisms), wait a relative prudent time, and then (just then) "deprec= ate" the prefix? >=20 > I have the sense we are putting the carriage in front of the horses her= e (why the sudden hurry?). >=20 > Opinion? >=20 > Best, > Nicolas >=20 > On Thu, Apr 7, 2011 at 05:04, Ole Troan wrote: > Chris, >=20 > are you happy with the use of "deprecate" given the explanations provid= ed in this thread? >=20 > not to forego matters, but I think we have managed to get a time slot i= n the chair's busy WGLC schedule, so there would be another > opportunity to discuss this before sending the document onwards. >=20 > cheers, > Ole >=20 >=20 >=20 >> In =E2=80=9CRequest to move Connection of IPv6 Domains via IPv4 Cloud= s (6to4) to Historic status=E2=80=9D >> >> There is this recommendation: >> >> IANA is requested to mark the 2002::/16 prefix as "deprecated", >> pointing to this document. Reassignment of the prefix for any usag= e >> requires justification via an IETF Standards Action [RFC5226]. >> >> It is not clear why this is necessary. >> >> If major vendors were to disable 6to4 by default, that would fix the b= rokenness issue, while still allow for this prefix to be > used in specialized or enthusiast scenarios. Isn=E2=80=99t any other ac= tion overkill? >> Thanks! >> ---------------------------- >> Christopher.Palmer@Microsoft.com >> Program Manager >> IPv6 @ Windows >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nantoniello@gmail.com Fri Apr 8 05:10: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 2ECBD28C0E2 for ; Fri, 8 Apr 2011 05:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5GLBwjZSPPF for ; Fri, 8 Apr 2011 05:10:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id ECF8F28C0EC for ; Fri, 8 Apr 2011 05:10:55 -0700 (PDT) Received: by iye19 with SMTP id 19so4217586iye.31 for ; Fri, 08 Apr 2011 05:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oD0b76+1YDGPc/wGbSfXmqf+mJ3ovPNzCiOZzk1l7xk=; b=RqCghOr4o9Y1lMsJ8p3wMvurk7BGFe17ULDiEqt5dPHAZmUrbJTHYvcgdQw79TVit2 tWYmaGDZ17kggBeHVDt9NAq4pkuCgNpykRN8yzhaBs3OAlhTiDIQB367qaxDhmqCj5D1 Wt74ScIaSjwkleMbwU4mOR2NzY6I7mALeDv+Y= 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=dNEhl/6UsMWsRpEff2zkR401TWRE/WNMQI+4ff8vPhEkWEGWsTUcqsymiZff+6vlQI eaWuB0Dcfsg1jBOQZJk3LFpb7RlHvTdridDeYwg7W1ZsSXjUpuPnouFRakRGF7czzHlG 9cKcdgFJUgp7qs6bDuOrU6QW7ZfvfocZP+rug= Received: by 10.231.193.202 with SMTP id dv10mr2072861ibb.136.1302264761128; Fri, 08 Apr 2011 05:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.77 with HTTP; Fri, 8 Apr 2011 05:12:21 -0700 (PDT) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6D604@PLSWM12A.ad.sprint.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C6D604@PLSWM12A.ad.sprint.com> From: Nicolas Antoniello Date: Fri, 8 Apr 2011 09:12:21 -0300 Message-ID: To: "George, Wes E [NTK]" Content-Type: multipart/alternative; boundary=005045016d9e7d95dc04a06724cf Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2011 12:10:59 -0000 --005045016d9e7d95dc04a06724cf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Wes, Ok, I think I got your point. Thanks for the explanation. Also agree with Bryan: - "The purpose is to prevent IANA allocating them for a large number of years". Regards, Nicolas On Thu, Apr 7, 2011 at 12:19, George, Wes E [NTK] < Wesley.E.George@sprint.com> wrote: > I fail to see the connection between leaving the prefixes alone but > deprecating the protocol. Either it's considered a supported > protocol (including its defined well-known prefixes) or it=92s not. Doing > something with the prefixes later doesn=92t change that, > because that=92s largely a record-keeping exercise on IANA=92s part. > I think you=92re putting too much emphasis on the importance of the prefi= xes > themselves, and are making a bigger deal out of > deprecation than is necessary. Deprecation !=3D unceremonious shutdown, a= nd > there=92s no internet police that will show up if you choose > to continue using it. We=92re simply saying that if it breaks, especially= in > one of the ways that we already know that it=92s likely to > do so, you=92re on your own. > > http://en.wikipedia.org/wiki/Deprecation > In computer software or authoring programs standards and documentation, t= he > term deprecation is applied to software features that > are superseded and should be avoided. Although deprecated features remain > in the current version, their use may raise warning > messages recommending alternative practices, and deprecation may indicate > that the feature will be removed in the future. Features > are deprecated=97rather than being removed=97in order to provide backward > compatibility and give programmers who have used the feature > time to bring their code into compliance with the new standard. > > Also, we *are* saying in the draft to stop putting out new devices with > 6to4 support, and recommending a gradual wind-down of 6to4 > relay support so that existing functional implementations are minimally > impacted. > > As I said at the mic, beyond Geoff=92s evidence as to how =93well=94 6to4= works, > 6to4 is about to get broken in a whole series of new ways > because of the prevalence of NAT + non-RFC1918 addresses. It=92s in our b= est > interest to try to get ahead of that and say that it is > no longer a recommended method of IPv6 connectivity, or we=92ll waste a l= ot > of time trying to fix something that is increasingly > looking unfixable at the expense of real IPv6 deployment. > > Thanks, > Wes George > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Nicolas Antoniello > Sent: Thursday, April 07, 2011 10:03 AM > To: Ole Troan > Cc: v6ops@ietf.org; Christopher Palmer > Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status > > Dear all, > > I believe this discussion has as technical as non-technical points to > consider... but just to clarify myself: > Why setting the 2002::/16 as "deprecated" (whether this mean that it can = be > re-assigned or not) when we are still selling PCs OSs > and router OSs with 6to4 support; and no talking about the bunch of 6to4 > still working out there. > > Why don't (in case it could not be fixed) first stop supporting 6to4 (at > least put it at the bottom of the OS options for transition > mechanisms), wait a relative prudent time, and then (just then) "deprecat= e" > the prefix? > > I have the sense we are putting the carriage in front of the horses here > (why the sudden hurry?). > > Opinion? > > Best, > Nicolas > > On Thu, Apr 7, 2011 at 05:04, Ole Troan wrote: > Chris, > > are you happy with the use of "deprecate" given the explanations provided > in this thread? > > not to forego matters, but I think we have managed to get a time slot in > the chair's busy WGLC schedule, so there would be another > opportunity to discuss this before sending the document onwards. > > cheers, > Ole > > > > > In =93Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4= ) to > Historic status=94 > > > > There is this recommendation: > > > > IANA is requested to mark the 2002::/16 prefix as "deprecated", > > pointing to this document. Reassignment of the prefix for any usage > > requires justification via an IETF Standards Action [RFC5226]. > > > > It is not clear why this is necessary. > > > > If major vendors were to disable 6to4 by default, that would fix the > brokenness issue, while still allow for this prefix to be > used in specialized or enthusiast scenarios. Isn=92t any other action > overkill? > > > > Thanks! > > ---------------------------- > > Christopher.Palmer@Microsoft.com > > Program Manager > > IPv6 @ Windows > > > > > > > > > > _______________________________________________ > > 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 > > --005045016d9e7d95dc04a06724cf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Wes,

Ok, I think I got your point.
Thanks for the explanation.=

Also agree with Bryan: - "The purpose is to prevent
IANA allocating them for a large number of years".

Regards,
= Nicolas



On Thu, Apr 7, 2011 at 12= :19, George, Wes E [NTK] <Wesley.E.George@sprint.com> wrote:
I fail to see the= connection between leaving the prefixes alone but deprecating the protocol= . Either it's considered a supported
protocol (including its defined well-known prefixes) or it=92s not. Doing s= omething with the prefixes later doesn=92t change that,
because that=92s largely a record-keeping exercise on IANA=92s part.
I think you=92re putting too much emphasis on the importance of the prefixe= s themselves, and are making a bigger deal out of
deprecation than is necessary. Deprecation !=3D unceremonious shutdown, and= there=92s no internet police that will show up if you choose
to continue using it. We=92re simply saying that if it breaks, especially i= n one of the ways that we already know that it=92s likely to
do so, you=92re on your own.

http= ://en.wikipedia.org/wiki/Deprecation
In=A0computer software=A0or authoring programs standards and documentation,= the term=A0deprecation=A0is applied to=A0software=A0features that
are superseded and should be avoided. Although deprecated features remain i= n the current version, their use may raise warning
messages recommending alternative practices, and deprecation may indicate t= hat the feature will be removed in the future. Features
are deprecated=97rather than being removed=97in order to provide=A0backward= compatibility=A0and give programmers who have used the feature
time to bring their code into compliance with the new standard.

Also, we *are* saying in the draft to stop putting out new devices with 6to= 4 support, and recommending a gradual wind-down of 6to4
relay support so that existing functional implementations are minimally imp= acted.

As I said at the mic, beyond Geoff=92s evidence as to how =93well=94 6to4 w= orks, 6to4 is about to get broken in a whole series of new ways
because of the prevalence of NAT + non-RFC1918 addresses. It=92s in our bes= t interest to try to get ahead of that and say that it is
no longer a recommended method of IPv6 connectivity, or we=92ll waste a lot= of time trying to fix something that is increasingly
looking unfixable at the expense of real IPv6 deployment.

Thanks,
Wes George

From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Nicolas Antoniello
Sent: Thursday, April 07, 2011 10:03 AM
To: Ole Troan
Cc: v6ops@ietf.org; Christopher Palme= r
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

Dear all,

I believe this discussion has as technical as non-technical points to consi= der... but just to clarify myself:
Why setting the 2002::/16 as "deprecated" (whether this mean that= it can be re-assigned or not) when we are still selling PCs OSs
and router OSs with 6to4 support; and no talking about the bunch of 6to4 st= ill working out there.

Why don't (in case it could not be fixed) first stop supporting 6to4 (a= t least put it at the bottom of the OS options for transition
mechanisms), wait a relative prudent time, and then (just then) "depre= cate" the prefix?

I have the sense we are putting the carriage in front of the horses here (w= hy the sudden hurry?).

Opinion?

Best,
Nicolas

On Thu, Apr 7, 2011 at 05:04, Ole Troan <otroan@employees.org> wrote:
Chris,

are you happy with the use of "deprecate" given the explanations = provided in this thread?

not to forego matters, but I think we have managed to get a time slot in th= e chair's busy WGLC schedule, so there would be another
opportunity to discuss this before sending the document onwards.

cheers,
Ole



> In =A0=93Request to move Connection of IPv6 Domains via IPv4 Clouds (6= to4) to Historic status=94
>
> There is this recommendation:
>
> IANA is requested to mark the 2002::/16 prefix as "deprecated&quo= t;,
> =A0 =A0pointing to this document. =A0Reassignment of the prefix for an= y usage
> =A0 =A0requires justification via an IETF Standards Action [RFC5226].<= br> >
> It is not clear why this is necessary.
>
> If major vendors were to disable 6to4 by default, that would fix the b= rokenness issue, while still allow for this prefix to be
used in specialized or enthusiast scenarios. Isn=92t any other action overk= ill?
>
> Thanks!
> ----------------------------
> Christopher.Palmer@Microsoft.com
> Program Manager
> IPv6 @ Windows
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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


--005045016d9e7d95dc04a06724cf-- From fred@cisco.com Fri Apr 8 06:53: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 6A4F928C15D for ; Fri, 8 Apr 2011 06:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7nL2HCUSWmx for ; Fri, 8 Apr 2011 06:53:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7BAF93A690F for ; Fri, 8 Apr 2011 06:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=143; q=dns/txt; s=iport; t=1302270920; x=1303480520; h=date:from:message-id:to:subject:cc; bh=wddXQVVFMs2qYgJKxhOdQSE9Pur6wmGBBlr+hoA3JHI=; b=dAd9HVtdSlm0hoXhlrdkahhoDhfkCruTf0EZV0MDg6uxwVRIQYMt//wm II7DC44CDBEPrErn1F84OApX1PZZYLz/p7f385lvjyM1fwY0XxSig/936 tiMSr3n+T6mF7/TsLc6ARzAPNhx97UVDJDn+6DXFJN16UcE7UOVYjT/li 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4IAK4Tn02rRDoJ/2dsb2JhbACYfgEBjRR3pRGcLIVtBIVV X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="678016730" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2011 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p38Dt0CX003703; Fri, 8 Apr 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p38Dt0C04514; Fri, 8 Apr 2011 06:55:00 -0700 (PDT) Date: Fri, 8 Apr 2011 06:55:00 -0700 (PDT) From: Message-Id: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-fling-v6ops-hybrid-bridged-routed@tools.ietf.org Subject: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-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, 08 Apr 2011 13:53:35 -0000 A new draft has been posted, at http://tools.ietf.org/draft-fling-v6ops-hybrid-bridged-routed-00.txt. Please take a look at it and comment. From C.Donley@cablelabs.com Fri Apr 8 07:47:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD93D3A6820 for ; Fri, 8 Apr 2011 07:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPT2DxiPM5pY for ; Fri, 8 Apr 2011 07:47:31 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A1B033A6938 for ; Fri, 8 Apr 2011 07:47:31 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p38EnE73024123; Fri, 8 Apr 2011 08:49:14 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 8 Apr 2011 08:49:14 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 8 Apr 2011 08:49:14 -0600 From: Chris Donley To: "Templin, Fred L" , Fred Baker Date: Fri, 8 Apr 2011 08:49:13 -0600 Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acv067C8dJvlWe33TzCJZF9Y5nvpGgAP/BAgADPBzqA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D3541CC9D@srvxchg> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com> <14D633B3-6087-4303-8A84-0D84D11CCFA4@cisco.com> <8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com> <856E17EA-E3BA-47CE-A1D9-DD10F276991A@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com> <34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com> <009b01cbf3f1$4b22c970$e1685c50$@com> <34E4F50CAFA10349A41E0756550084FB049FEF81@!!PRVPEXVS04.corp.twcable.com> <6634030F-7E3D-439F-97D0-E6C85ACECA76@employees.org> <00F8378B-279A-4F17-80D4-2F005A197FFF@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 X-Approved: ondar Cc: 'IPv6 Ops WG' , "'Tony Hain \(ahain\)'" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 08 Apr 2011 14:47:33 -0000 Fred, =20 In our discussions with cable MSOs, we have identified support for the foll= owing transition/coexistence technologies on the access link (e.g. to the C= PE router): * Native Dual-Stack * NAT444 * DS-Lite * 6RD That's it.=20 =20 Specifically, there is no call for ISATAP, and we don't plan to support it = in CableLabs specs. Since the CPE router can advertise an IPv6 prefix on it= s LAN, I don't think ISATAP is needed for most deployments; I am therefore = opposed to including ISATAP support in this draft. If vendors want to inclu= de ISATAP support and have customers who will buy it, they're welcome to im= plement it. I would be willing to support someone publishing a separate dra= ft explaining how ISATAP could be deployed in a home network, but IMO this = isn't the right draft. =09 Chris -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= emplin, Fred L Sent: Thursday, April 07, 2011 8:08 AM To: Fred Baker Cc: 'IPv6 Ops WG'; 'Tony Hain (ahain)' Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.= txt Hi Fred, Until your message, this discussion has had traction with the working group= . I am not in a position to release a new draft without permission from my = company which can require a considerable internal review cycle, after which= this discussion thread will have grown stone cold. I wish you would have f= loated the idea to me off-list first. To your points, I believe this document needs to consider the case of a CPE= router deployed at the border of a predominantly IPv4 network. In that cas= e, ISATAP enables an automatic IPv6 capability for hosts in the end user ne= twork. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, April 06, 2011 11:19 PM > To: Templin, Fred L > Cc: Ole Troan; Weil, Jason; Tina Tsou; 'Hemant Singh (shemant)'; 'IPv6=20 > Ops WG'; 'Tony Hain (ahain)' > Subject: Re: [v6ops] > Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 > Fred, it might be most appropriate for you to write a draft on the=20 > configuration and use of ISATAP in a residential network. To my=20 > knowledge, it is rarely if ever used in the absence of an IT=20 > department to support it, or in the presence of a native IPv6 network,=20 > which is the topic of the CPE Router Draft. If you think it makes=20 > sense, maybe you can tell us how in the usual manner. >=20 > On Apr 7, 2011, at 1:36 AM, Templin, Fred L wrote: >=20 > > Hi Ole, > >=20 > >> -----Original Message----- > >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole=20 > >> Troan > >> Sent: Wednesday, April 06, 2011 12:44 PM > >> To: Weil, Jason > >> Cc: Tina Tsou; 'Hemant Singh (shemant)'; Templin, Fred L; 'Fred=20 > >> Baker (fred)'; 'IPv6 Ops WG'; 'Tony Hain (ahain)' > >> Subject: Re: [v6ops] > >> Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >>=20 > >>> I am not able clearly parse the data to the column > >> headings, but if it helps the diagram below is what I was > suggesting. > >>>=20 > >>> [DS HOST]--[v4 CE ROUTER]--[v6 BIS ROUTER]-->Service Provider > >>> | > >>> [DS HOST] > >>>=20 > >>> The issue in the topology depicted above is the IPv4-only > >> CE (interior) ROUTER is out of scope for the -bis draft today. The=20 > >> current scope covers transition technologies on the WAN (6rd and=20 > >> DS-LITE) and a simple two router setup with the interior router=20 > >> being an IPv6 CE router. > >>=20 > >> what is the proposal, that the IPv6 CE comes with ISATAP supported=20 > >> on by default or be capable of doing ISATAP tunneling? (remember we=20 > >> are trying to make these routers require no management). > >=20 > > At least capable of acting as an ISATAP router on the LAN side. On=20 > > by default would require some means of selecting one or more IPv6=20 > > prefixes to assign to the ISATAP link, but that should be easy to=20 > > carve off of whatever stateful or stateless prefix delegations the=20 > > CE receives via its WAN connection. > >=20 > >> if ISATAP is enabled by default, how do we know that the user=20 > >> hasn't intended a topology separating host on different links and=20 > >> by building a single virtual link we are violating that policy? > >=20 > > Such a user would be in a more competent position to disable and/or=20 > > reconfigure the on-by-default settings than a novice user would be=20 > > to enable an off-by-default setting. Besides, the ISATAP virtual=20 > > link would not magically bypass any IPv4 filtering gateways in the=20 > > network. So, the ISATAP virtual link might be partitioned, but the=20 > > IPv4 filtering policies would not be violated. > >=20 > >> e.g. why were the extra routers there in the first place. > >=20 > > For the same reasons that any IPv4 site administrator would portion=20 > > the site off into separate subnets separated by IPv4 routers. > >=20 > >> how is ISATAP provisioning supposed to work? so far the IPv6 CE=20 > >> router work has focused on the profile of the router itself, and it=20 > >> has references standards track document for WAN side and LAN side=20 > >> behaviour. > >=20 > > There is a lot of documented operational guidance on how to=20 > > provision an ISATAP site service outside of the IETF document series=20 > > - some of it from your company. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >> cheers, > >> Ole >=20 >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri Apr 8 09:04: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 981A23A6905 for ; Fri, 8 Apr 2011 09:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 7-n0S33Y9lBo for ; Fri, 8 Apr 2011 09:04:39 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 0CE683A680A for ; Fri, 8 Apr 2011 09:04:38 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p38G6GuD008832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2011 11:06:16 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p38G6Gbn024639; Fri, 8 Apr 2011 11:06:16 -0500 (CDT) 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 p38G6FOb024621 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 8 Apr 2011 11:06:15 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 8 Apr 2011 09:06:15 -0700 From: "Templin, Fred L" To: Fred Baker Date: Fri, 8 Apr 2011 09:06:14 -0700 Thread-Topic: [v6ops]Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acv067C8dJvlWe33TzCJZF9Y5nvpGgAP/BAgADPBzqAAAsDbUA== Message-ID: References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om>< 5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9F E2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9- DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109. cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com>< 34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com><009b0 1cbf3f1$4b22c970$e1685c50$@com><34E4F50CAFA10349A41E0756550084FB049FEF81@!! PRVPEXVS04.corp.twcable.com><6634030F-7E3D-439F-97D0-E6C85ACECA76@employees .org><00F8378B-279A-4F17-80D4-2F005A197FFF@cisco.com> <76AC5FEF83F1E64491446437EA81A61F7D3541CC9D@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D3541CC9D@srvxchg> 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' Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 08 Apr 2011 16:04:39 -0000 OK, I seem to be hearing from the majority of responders that there would be support for a separate draft explaining the use of ISATAP in home/soho networks. If that would not be the case I'd like to know now, since it would save me considerable trouble in preparing a new draft. Thanks - Fred fred.l.templin@boeing.com From jhw@apple.com Fri Apr 8 09:10: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 158283A69AC for ; Fri, 8 Apr 2011 09:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1BVX3faTQXM for ; Fri, 8 Apr 2011 09:10:39 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id 1F0D93A6945 for ; Fri, 8 Apr 2011 09:10:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJC005MRD0000O0@mail-out.apple.com> for v6ops@ietf.org; Fri, 08 Apr 2011 09:12:17 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-62-4d9f33e109af Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id AC.94.29082.1E33F9D4; Fri, 08 Apr 2011 09:12:17 -0700 (PDT) Received: from [66.109.105.84] by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJC00JBLD0BVN20@cardamom.apple.com> for v6ops@ietf.org; Fri, 08 Apr 2011 09:12:17 -0700 (PDT) From: james woodyatt In-reply-to: <4D9EB2FF.2060900@gmail.com> Date: Fri, 08 Apr 2011 09:12:10 -0700 Message-id: <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Apr 2011 16:10:40 -0000 On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote: > > However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that. An RFC is not required for that. This draft would send a much stronger signal to implementors if it were to contain language more like what you see in RFC 3701 for phasing out the 6bone. I draw your attention to this excerpt: Thus after the 6bone phaseout date June 6, 2006, it is the intent that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form. Network operators may filter 3FFE prefixes on their borders to ensure these prefixes are not misused. If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore. If we knew that network operators were given guidance by IETF to stop routing 2002::/16 in the default free zone after some future date, then that would help me convince certain product engineering people I know to consider patches for existing field deployments. Failing that however, I'm pretty sure this draft as it stands today will be too easily ignored. -- james woodyatt member of technical staff, core os networking From yiu_lee@cable.comcast.com Fri Apr 8 09:25:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1E73A68FD; Fri, 8 Apr 2011 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=-1.098, 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 lLHo1zrzuAOr; Fri, 8 Apr 2011 09:25:18 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 732443A6889; Fri, 8 Apr 2011 09:25:18 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.33018560; Fri, 08 Apr 2011 10:30:01 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Fri, 8 Apr 2011 12:26:59 -0400 From: "Lee, Yiu" To: "Jean-Francois.TremblayING@videotron.com" , "fred@cisco.com" Thread-Topic: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AQHL9gnHz9KGRPF8SPCoIpy5YfsW5g== Date: Fri, 8 Apr 2011 16:26:58 +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.13] Content-Type: multipart/alternative; boundary="_000_C9C4ADF4C657yiuleecablecomcastcom_" MIME-Version: 1.0 Cc: 'IPv6 Ops WG' , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 08 Apr 2011 16:25:19 -0000 --_000_C9C4ADF4C657yiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I second this. Let's focus on a smaller subset of features which are most i= mportant for the CPE vendors to build. Then people who are interested in mo= re advanced home networking can write a separate draft and explain how it s= hould work. If the WG decides this is important, then adopt it as WG item. = This won't delay the process and the CPE vendors (and customers) will be so= oner to have a v6 CPE. /Yiu From: > Date: Thu, 7 Apr 2011 16:37:39 -0400 To: > Cc: 'IPv6 Ops WG' >, > Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-00.= txt Routed networks are rarely seen in a residential environment (outside of To= ny's house). Besides, adding ISATAP in this draft would only add confusion to an already= confused CPE vendor ecosystem, IMHO. From an ISP point of view, it's probably preferable= to have vendors implement few feature correctly than many poorly. Let them focus on DHCPv6-= PD, PPPoE and 6RD first. --_000_C9C4ADF4C657yiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I second this. Let's focus on a smaller subset of features which are m= ost important for the CPE vendors to build. Then people who are interested = in more advanced home networking can write a separate draft and explain how= it should work. If the WG decides this is important, then adopt it as WG item. This won't delay the process = and the CPE vendors (and customers) will be sooner to have a v6 CPE.

/Yiu 

From: <Jean-Francois.TremblayING@videotron.com>
Date: Thu, 7 Apr 2011 16:37:39 -040= 0
To: <fred@cisco.com>
Cc: 'IPv6 Ops WG' <v6ops@ietf.org>, <v6ops-bounces@ietf.org>
Subject: Re: [v6ops] Fwd:I-DAction:= draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

Routed networks are rarely seen in a residential environment (outside of Tony's h= ouse). 

Besides, adding ISATAP in this draft would only add co= nfusion to an already confused CPE&nb= sp;
vendor ecosystem, IMHO. From an ISP point of view, it'= s probably preferable to have vendors=  
implement few feature correctly than many poorly. Let = them focus on DHCPv6-PD, PPPoE and 6RD first. --_000_C9C4ADF4C657yiuleecablecomcastcom_-- From fred@cisco.com Fri Apr 8 09:27: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 7876E3A6907 for ; Fri, 8 Apr 2011 09:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 66F3OsT1+kOo for ; Fri, 8 Apr 2011 09:27:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8A6C03A6889 for ; Fri, 8 Apr 2011 09:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=512; q=dns/txt; s=iport; t=1302280162; x=1303489762; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=eNwoqCnpdI/yKWziu4MxhowHtXtHzuPveRrcUUr1QoQ=; b=jPvg8XSXH9brtUqey2Du1CoTgct0+adphN7HkfAfCj5YE+uPnY4HgVsC J9MgrdbfVXsl1H15WSnTaUC7BoeSXAsvR9pKQR8+z50VLhcPpFDIpcSBh 7vjuWRoBtLTMTmOrfl5cANSg92agoACbRmOlw4LJderMXrbLG5Kji2SOH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDAMU2n02Q/khNgWdsb2JhbACmFRQBARYmJYh6mzScK4VtBI1Og2o X-IronPort-AV: E=Sophos;i="4.63,324,1299456000"; d="scan'208";a="82818104" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2011 16:29:21 +0000 Received: from Freds-Computer.local ([144.254.202.69]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p38GTGNn031626; Fri, 8 Apr 2011 16:29:21 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 08 Apr 2011 18:29:21 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 08 Apr 2011 18:29:21 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 8 Apr 2011 18:29:05 +0200 Message-Id: <88F536CA-4848-4464-8FB0-E639F19C854B@cisco.com> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om>< 5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9F E2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9- DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109. cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com>< 34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com><009b0 1cbf3f1$4b22c970$e1685c50$@com><34E4F50CAFA10349A41E0756550084FB049FEF81@!! P RVPEXVS04.corp.twcable.com><6634030F-7E3D-439F-97D0-E6C85ACECA76@employees .org><00F8378B-279A-4F17-80D4-2F005A197FFF@cisco.com> <76AC5FEF83F1E64491446437EA81A61F7D3541CC9D@srvxchg> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 08 Apr 2011 16:27:37 -0000 It's up to you. What I'm hearing from BBF and Cable Labs is that there = is no use case in their networks. On Apr 8, 2011, at 6:06 PM, Templin, Fred L wrote: > OK, I seem to be hearing from the majority of responders > that there would be support for a separate draft explaining > the use of ISATAP in home/soho networks. If that would not > be the case I'd like to know now, since it would save me > considerable trouble in preparing a new draft. >=20 > Thanks - Fred > fred.l.templin@boeing.com From jhw@apple.com Fri Apr 8 09:30: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 B28A93A68CF for ; Fri, 8 Apr 2011 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpUKl8X-nF14 for ; Fri, 8 Apr 2011 09:30:32 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by core3.amsl.com (Postfix) with ESMTP id 7BD333A6889 for ; Fri, 8 Apr 2011 09:30:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJC00K21DTAKU00@mail-out.apple.com> for v6ops@ietf.org; Fri, 08 Apr 2011 09:32:18 -0700 (PDT) X-AuditID: 11807137-b7c3cae0000010f5-e7-4d9f38916939 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 24.C2.04341.2983F9D4; Fri, 08 Apr 2011 09:32:18 -0700 (PDT) Received: from [66.109.105.84] by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJC00IRKDXNBL20@koseret.apple.com> for v6ops@ietf.org; Fri, 08 Apr 2011 09:32:17 -0700 (PDT) From: james woodyatt In-reply-to: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> Date: Fri, 08 Apr 2011 09:32:10 -0700 Message-id: References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-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, 08 Apr 2011 16:30:34 -0000 On Apr 8, 2011, at 6:55 AM, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/draft-fling-v6ops-hybrid-bridged-routed-00.txt. Please take a look at it and comment. I have reviewed this draft. My only comment is editorial. This draft only applies to CPE routers that have ATM interfaces. The title should be changed to reflect that, and I recommend prepending the phrase "In ATM networks," to the first sentence of the Introduction section. -- james woodyatt member of technical staff, core os networking From ichiroumakino@gmail.com Fri Apr 8 11: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 2BDDC3A696B for ; Fri, 8 Apr 2011 11:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 F4gFoMAe-bQK for ; Fri, 8 Apr 2011 11:48:59 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5BBC83A6962 for ; Fri, 8 Apr 2011 11:48:59 -0700 (PDT) Received: by eye13 with SMTP id 13so1387818eye.31 for ; Fri, 08 Apr 2011 11:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=L0gEBAVb8aUTz8DREx2XLUXP7uQh94VuOEI3kh8uRbs=; b=c9QCE84SZQXLTroHG/63GoFFCAeoyQyjX5JUIrWkQeI45ESmQ8n6ZFTsZ+IeOydA0m 4FPIrpRYncyTdI6mL8rPMuql6nTFrMcu2Zi8bIyMx9HeWTTv4n+6NY6DC2ifFxqfsbw5 k1NKBvnk5pvnEJTLMg9utUnMSfK2m/hnPcfsc= 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=oK4DF7srwklv9OhTIbs8fpFDsL6yKp1j5GipmY27LarQL8gLcW+pA6SHf3lS2SEbWT e/EEXdu2Odmkt8f7ITuMuNHs6YyaWhLmsE/+lEvX91ynW5uShDEeYvRA+EtomISWCUjT ei/g8Qhi+kjGY60vBusagMjfxXd2+JBDjtITs= Received: by 10.213.22.145 with SMTP id n17mr16004ebb.112.1302288643162; Fri, 08 Apr 2011 11:50:43 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id x54sm1883954eeh.26.2011.04.08.11.50.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 11:50:42 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Fri, 8 Apr 2011 20:50:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F259B1B-45AE-49AF-9798-0B4A75C8D338@employees.org> References: <959B73D2-A53C-4682-BB4B-ADFB71CA7906@cisco.com><14D633B3-6087-4 303-8A84-0D84D11CCFA4@cisco.com><8AD676EE-6C4D-4C7B-B5AD-4042476EB3DE@cisco.c om>< 5B6B2B64C9FE2A489045EEEADDAFF2C301391307@XMB-RCD-109.cisco.com><5B6B2B64C9F E2A489045EEEADDAFF2C301391380@XMB-RCD-109.cisco.com><856E17EA-E3BA-47CE-A1D9- DD10F276991A@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3013913FB@XMB-RCD-109. cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30139142B@XMB-RCD-109.cisco.com>< 34E4F50CAFA10349A41E0756550084FB03DDBF9E@PRVPEXVS04.corp.twcable.com><009b0 1cbf3f1$4b22c970$e1685c50$@com><34E4F50CAFA10349A41E0756550084FB049FEF81@!! P RVPEXVS04.corp.twcable.com><6634030F-7E3D-439F-97D0-E6C85ACECA76@employees .org><00F8378B-279A-4F17-80D4-2F005A197FFF@cisco.com> <76AC5FEF83F1E64491446437EA81A61F7D3541CC9D@srvxchg> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Fwd:I-DAction:draft-ietf-v6ops-ipv6-cpe-router-bis-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, 08 Apr 2011 18:49:00 -0000 Fred, > OK, I seem to be hearing from the majority of responders > that there would be support for a separate draft explaining > the use of ISATAP in home/soho networks. If that would not > be the case I'd like to know now, since it would save me > considerable trouble in preparing a new draft. I can conceptually imagine a network for where ISATAP could be useful in = the home. but I don't know if such a network exists in the real world. I am hoping = that we can manage to make the home network native IPv6. the main use = case for a routed home, the 802.15.4 folks are going to use ISATAP = anyway. perhaps if you are unsure of the reception a draft would get. could you = explore the most essential question. how could an ISATAP service be self = configured / unmanaged in a home network? can that be done without = changes to hosts stacks? if ISATAP can't be made to work unmanaged it is a non-starter. cheers, Ole= From tena@huawei.com Fri Apr 8 13:28: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 8664E3A6957; Fri, 8 Apr 2011 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft3TJl24cW9k; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5B0CC3A68CB; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJC00CCNOY7YV@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Received: from TingZousc1 ([10.212.246.132]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJC005F4OY58P@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Date: Fri, 08 Apr 2011 13:30:05 -0700 From: Tina Tsou To: 'MBONED WG' , pim@ietf.org, 'IPv6 Ops WG' , behave@ietf.org, softwires@ietf.org Message-id: <010001cbf62b$bfc24e40$3f46eac0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AQEvzYA9JGDJgObGWqAS/HlE5dNRbJWMr2vQgAAKSVA= Cc: multrans@ietf.org Subject: [v6ops] You are invited to subscribe to the multrans list X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:28:30 -0000 Hi all, You are invited to subscribe to the multrans list. https://www.ietf.org/mailman/listinfo/multrans You are invited to comment on https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ to the multrans list. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Steve Young [mailto:stevey@amsl.com] Sent: Friday, April 08, 2011 12:43 PM To: tena@huawei.com; tina.tsou.zouting@huawei.com Subject: Your new mailing list: multrans The mailing list `multrans' has just been created for you. The following is some basic information about your mailing list. Your mailing list password is: ... You need this password to configure your mailing list. You also need it to handle administrative requests, such as approving mail if you choose to run a moderated list. You can configure your mailing list at the following web page: https://www.ietf.org/mailman/admin/multrans The web page for users of your mailing list is: https://www.ietf.org/mailman/listinfo/multrans You can even customize these web pages from the list configuration page. However, you do need to know HTML to be able to do this. There is also an email-based interface for users (not administrators) of your list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: multrans-request@ietf.org To unsubscribe a user: from the mailing list 'listinfo' web page, click on or enter the user's email address as if you were that user. Where that user would put in their password to unsubscribe, put in your admin password. You can also use your password to change member's options, including digestification, delivery disabling, etc. Your mailing list is configured with a public archive which can be found at: http://www.ietf.org/mail-archive/web/multrans Please note: the archive will not be created until a message has been sent to the list and the archiving process has run (runs at 10, 30, 50 past each hour). Please address all questions to mailman-owner@ietf.org. From brian.e.carpenter@gmail.com Sat Apr 9 00:31: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 E79A63A69A9 for ; Sat, 9 Apr 2011 00:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTv-2egnXEtX for ; Sat, 9 Apr 2011 00:31:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BCCB73A6804 for ; Sat, 9 Apr 2011 00:31:48 -0700 (PDT) Received: by wyb29 with SMTP id 29so3995014wyb.31 for ; Sat, 09 Apr 2011 00:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hT+x8hf/pPZcWccZDRP/4ewUYNF+PhKKv3QSOqDx/9Y=; b=uuw+ikcs20W9J67AQ64CEj4wIIjcaFVW8sosdN8KWJyvL9ikkfMB8H8DdpxML+rEas u1qRgavxIiCFxWmTiSPl28wHifEiTsRaKIRKKn1b7IJcDW4ZOSiLlMvK1tsXZ5BijEtr 0Ui3JBBSA1af5MqpWVaLI9D77h+lKalHjuZAw= 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=cZuQMsmv2rdte8jpR3JqYuB9CBBRHWfmJg/nYbRV4j2alWwOo+NjaKpHo4VQqQbULf stVAk02/ifcsW7GS4NUKjoIV7f9xqAf0EH1t89C/93qs5thlmabqGkmysqm+vGOujFmC VBxge5Qeb6DjN0wHYQprCOEKqlZZVLfA5P6wM= Received: by 10.227.177.13 with SMTP id bg13mr2993191wbb.92.1302334413871; Sat, 09 Apr 2011 00:33:33 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id e13sm2129210wbi.23.2011.04.09.00.33.32 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 00:33:32 -0700 (PDT) Message-ID: <4DA00BC6.4090705@gmail.com> Date: Sat, 09 Apr 2011 19:33:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> In-Reply-To: <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 07:31:51 -0000 On 2011-04-09 04:12, james woodyatt wrote: > On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote: >> However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that. > > An RFC is not required for that. > > This draft would send a much stronger signal to implementors if it were to contain language more like what you see in RFC 3701 for phasing out the 6bone. I draw your attention to this excerpt: > > Thus after the 6bone phaseout date June 6, 2006, it is the intent > that no 6bone 3FFE prefixes, of any size/length, be used on the > Internet in any form. Network operators may filter 3FFE prefixes on > their borders to ensure these prefixes are not misused. > > If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore. If we knew that network operators were given guidance by IETF to stop routing 2002::/16 in the default free zone after some future date, then that would help me convince certain product engineering people I know to consider patches for existing field deployments. Failing that however, I'm pretty sure this draft as it stands today will be too easily ignored. IMHO that is exactly what we should not do. Breaking 6to4 worse than it is already broken is not in the interests of users or of service providers (whose help desks would incur the resulting costs). On the contrary, we need the 6to4 relays that exist to work impeccably, and that requires careful attention to routing both 2002::/16 and the anycast prefix. Brian From brian.e.carpenter@gmail.com Sat Apr 9 00:36: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 973273A6804 for ; Sat, 9 Apr 2011 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIumIYEHB89L for ; Sat, 9 Apr 2011 00:36:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 79ED63A69E0 for ; Sat, 9 Apr 2011 00:36:21 -0700 (PDT) Received: by wwa36 with SMTP id 36so3509902wwa.13 for ; Sat, 09 Apr 2011 00:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XBNb9xrsg92i9I4C1gHycQKXX+r3wZFwOzNIyBliAC0=; b=N41/mmPTzUPZsftsCRMew1XQ7N6FUKl2nX3XfFXQxmLCOa9jcz3CDysqJcUrQFk5TM 9ZmBgErv1MBtf2RhDaUUsOjIS6U2M264H6CHK+yx8mcnbeCxvrNL0oiv9pY68BFvh1Xh S3ENzFTB3f2IG5Ip9YLr4dAn8pV26xEnwG4yU= 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=vN+eN0P+Q1jEcnR8biqxaFpWihsZjIwAq2C6CZfONqEquj7yb9tMl+wIM57+JdsQUn tIAbs3vBPAgrRVmR5DMnZUBYqmCDlDvpyUyUUyunPkGCQLs7bQPxVXGqxs8FrlKmATOf ouMvHY182fioDXooPs/IRrANdvEj/DfeQ3RUI= Received: by 10.216.136.67 with SMTP id v45mr522330wei.106.1302334686615; Sat, 09 Apr 2011 00:38:06 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id bs4sm2128783wbb.52.2011.04.09.00.38.05 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 00:38:05 -0700 (PDT) Message-ID: <4DA00CDA.4030508@gmail.com> Date: Sat, 09 Apr 2011 19:38:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> In-Reply-To: <4DA00BC6.4090705@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 07:36:22 -0000 P.S. The phaseout plan is to wait until existing hosts and CPEs that do 6to4 by default go to landfill or e-cycling. So we need to operate relays for another ten years. Regards Brian On 2011-04-09 19:33, Brian E Carpenter wrote: > On 2011-04-09 04:12, james woodyatt wrote: >> On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote: >>> However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that. >> An RFC is not required for that. >> >> This draft would send a much stronger signal to implementors if it were to contain language more like what you see in RFC 3701 for phasing out the 6bone. I draw your attention to this excerpt: >> >> Thus after the 6bone phaseout date June 6, 2006, it is the intent >> that no 6bone 3FFE prefixes, of any size/length, be used on the >> Internet in any form. Network operators may filter 3FFE prefixes on >> their borders to ensure these prefixes are not misused. >> >> If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore. If we knew that network operators were given guidance by IETF to stop routing 2002::/16 in the default free zone after some future date, then that would help me convince certain product engineering people I know to consider patches for existing field deployments. Failing that however, I'm pretty sure this draft as it stands today will be too easily ignored. > > IMHO that is exactly what we should not do. Breaking 6to4 worse than > it is already broken is not in the interests of users or of > service providers (whose help desks would incur the resulting costs). > > On the contrary, we need the 6to4 relays that exist to work impeccably, > and that requires careful attention to routing both 2002::/16 and the > anycast prefix. > > Brian > From rogerj@gmail.com Sat Apr 9 00: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 1565D3A69EC for ; Sat, 9 Apr 2011 00:45:55 -0700 (PDT) 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.100, 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 fg1qYUTl7mU4 for ; Sat, 9 Apr 2011 00:45:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D94983A69A9 for ; Sat, 9 Apr 2011 00:45:53 -0700 (PDT) Received: by iye19 with SMTP id 19so5039884iye.31 for ; Sat, 09 Apr 2011 00:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=STErHSdz9HrkquTNreyEZ1wzrFZTxM4HgwGErVuGFmA=; b=fmedVCF8CUfbRu9PGyghJr4rgLjb4jNaNbEi7xt6C5KEZWn6p//mrrp63aSuVAkvpA 3k8CbP1Y1rHmaEdYIvD4ohGcpMykXLjg83wdRwzRHCNtpguJaclg0nKnBTxSRjJ1Etaa TT+qFEoyv7vXRsfORClZoHWIj5l4CHCqbcD8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FspZeSOa6bWpmjqp7hxtiSEz1gqLO3myZ1ehpcpOLs+3UaOpWMYuvEkR1HJaAY8qfl kJeiCHCyjPukR++VskPnRoTj9Lys2lGkbZLEgZNRCfnofJrrubpWRz5rtb2ny/qgc5iN 59ma01wo6EW6CV9D4qVzS1ChNj60Ws5fI2fJ0= MIME-Version: 1.0 Received: by 10.42.115.129 with SMTP id k1mr3818176icq.457.1302335259187; Sat, 09 Apr 2011 00:47:39 -0700 (PDT) Received: by 10.231.15.198 with HTTP; Sat, 9 Apr 2011 00:47:39 -0700 (PDT) Date: Sat, 9 Apr 2011 09:47:39 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: [v6ops] phaseout - Re: Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 07:45:55 -0000 On Sat, Apr 9, 2011 at 9:38 AM, Brian E Carpenter wrote: > P.S. The phaseout plan is to wait until existing hosts and CPEs that > do 6to4 by default go to landfill or e-cycling. So we need to operate > relays for another ten years. Since 6to4 will be (I assume) deprecated now, what about letting 16.June 2016 be the day to shut of 6to4? (I liked the number series, 16.06.2016 or 06.16.2016, 16.06.16...) --=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 cb.list6@gmail.com Sat Apr 9 07:58: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 AB8B53A6918 for ; Sat, 9 Apr 2011 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 KXfRC3U033PU for ; Sat, 9 Apr 2011 07:57:59 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 03DA73A690C for ; Sat, 9 Apr 2011 07:57:58 -0700 (PDT) Received: by ewy19 with SMTP id 19so1587597ewy.31 for ; Sat, 09 Apr 2011 07:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=de7E6oQFsDsMiJReBkz+CGYQp2elTqxKSitUF6JkurE=; b=mgp8ji9djCBcg5XMaXD/7H5E2zPNg6ir8ZXlxnv3kJpCfOQCCC8gkClg+G1+A+Pg2K sMlZ6X4jU4VlQnPc0gfqVdmimjWNNkb0eSXDwKDiQDSeNlH7F8EAVU1G2b/2GrpDlsrG Ewx/lk854j+HDbXoBqfAJ/XPZzGbCYxCAJofU= 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=REpfpM/8yOdvCPrCogzkj33WAOxlL67RDvKWCeU9DhOrvzSMOr4+fy2OO1VUJw4/vp GVAuFXtcyYYAz4DnILBPoPKHRJf5cFgdn2cA4sgCy3wP7QDCkGKLDKReMTR4GlErfv6R 9Vz2vAxuv02ZM7mVTLUnDFjN1mfCFwWrH99Ck= MIME-Version: 1.0 Received: by 10.213.27.22 with SMTP id g22mr356954ebc.120.1302361184203; Sat, 09 Apr 2011 07:59:44 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Sat, 9 Apr 2011 07:59:44 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Sat, 9 Apr 2011 07:59:44 -0700 (PDT) In-Reply-To: <4DA00BC6.4090705@gmail.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> Date: Sat, 9 Apr 2011 07:59:44 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=0015174c18d8c0f56804a07d9778 Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 14:58:00 -0000 --0015174c18d8c0f56804a07d9778 Content-Type: text/plain; charset=ISO-8859-1 On Apr 9, 2011 12:33 AM, "Brian E Carpenter" wrote: > > On 2011-04-09 04:12, james woodyatt wrote: > > On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote: > >> However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that. > > > > An RFC is not required for that. > > > > This draft would send a much stronger signal to implementors if it were to contain language more like what you see in RFC 3701 for phasing out the 6bone. I draw your attention to this excerpt: > > > > Thus after the 6bone phaseout date June 6, 2006, it is the intent > > that no 6bone 3FFE prefixes, of any size/length, be used on the > > Internet in any form. Network operators may filter 3FFE prefixes on > > their borders to ensure these prefixes are not misused. > > > > If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore. If we knew that network operators were given guidance by IETF to stop routing 2002::/16 in the default free zone after some future date, then that would help me convince certain product engineering people I know to consider patches for existing field deployments. Failing that however, I'm pretty sure this draft as it stands today will be too easily ignored. > > IMHO that is exactly what we should not do. Breaking 6to4 worse than > it is already broken is not in the interests of users or of > service providers (whose help desks would incur the resulting costs). > > On the contrary, we need the 6to4 relays that exist to work impeccably, > and that requires careful attention to routing both 2002::/16 and the > anycast prefix. Working impeccable is a lot to ask given that customers generally don't know or care about 6to4 and it does not and will not provide revenue Cb > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0015174c18d8c0f56804a07d9778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 9, 2011 12:33 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> On 2011-04-09 04:12, james woodyatt wrote:
> > On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote:
> >> However, I think we are suggesting that if MS can find a way = to patch existing hosts that will make it less likely that they use 6to4 an= ycast unintentionally, that would be a Good Thing. A MUST is not required f= or that.
> >
> > An RFC is not required for that.
> >
> > This draft would send a much stronger signal to implementors if i= t were to contain language more like what you see in RFC 3701 for phasing o= ut the 6bone. =A0I draw your attention to this excerpt:
> >
> > =A0 =A0Thus after the 6bone phaseout date June 6, 2006, it is the= intent
> > =A0 =A0that no 6bone 3FFE prefixes, of any size/length, be used o= n the
> > =A0 =A0Internet in any form. =A0Network operators may filter 3FFE= prefixes on
> > =A0 =A0their borders to ensure these prefixes are not misused. > >
> > If IETF were to publish a phaseout plan for 6to4, then it would b= e more difficult for vendors of host and home gateway operating systems to = ignore. =A0If we knew that network operators were given guidance by IETF to= stop routing 2002::/16 in the default free zone after some future date, th= en that would help me convince certain product engineering people I know to= consider patches for existing field deployments. =A0Failing that however, = I'm pretty sure this draft as it stands today will be too easily ignore= d.
>
> IMHO that is exactly what we should not do. Breaking 6to4 worse than > it is already broken is not in the interests of users or of
> service providers (whose help desks would incur the resulting costs).<= br> >
> On the contrary, we need the 6to4 relays that exist to work impeccably= ,
> and that requires careful attention to routing both 2002::/16 and the<= br> > anycast prefix.

Working impeccable is a lot to ask given that customers generally don= 9;t know or care about 6to4 and it does not and will not provide revenue

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

--0015174c18d8c0f56804a07d9778-- From cb.list6@gmail.com Sat Apr 9 08: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 C9E893A6A8E for ; Sat, 9 Apr 2011 08:03:47 -0700 (PDT) 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.225, 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 BL-RkXp-alnd for ; Sat, 9 Apr 2011 08:03:46 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 499543A690C for ; Sat, 9 Apr 2011 08:03:46 -0700 (PDT) Received: by ewy19 with SMTP id 19so1588547ewy.31 for ; Sat, 09 Apr 2011 08:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=67OKjpDK0XQbb8ytiSnht5BzUujH8cA2a24vpDXJljk=; b=nKZJSr6OiPgjwTj/NvShx0UGE7G4/JMgMj9qtbDtu/ODUc30wbtjbWCkTcVFBeiXc4 6kPH+UFK2sOECdSJibqkVCSBIrhnE3vJzvT4p0SoMxLNro7cqdi5E/+pACeQtNdMo35m Jts/NnwTfm3EFITp1DL5MDXPcyEoK4oQWWlY0= 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=fHapAaAowliU8Fj23nk6HOdbkOOkYLz4UiEyg+cWhupP63I/s5TxoQa1GSGRg/BVSJ z5QCnzaVeLNZ+H3TcgL7IxcClUI8ZyZG9NLPup2nDnHemTOyCVEK7xXH68GP05+9B6ED zfpMTlSj253LK3egPYpWJe4GtnoHDcUKzUELo= MIME-Version: 1.0 Received: by 10.213.15.82 with SMTP id j18mr367312eba.82.1302361530178; Sat, 09 Apr 2011 08:05:30 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Sat, 9 Apr 2011 08:05:29 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Sat, 9 Apr 2011 08:05:29 -0700 (PDT) In-Reply-To: <4DA00CDA.4030508@gmail.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> Date: Sat, 9 Apr 2011 08:05:29 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=0015174bdf06601ec504a07dac4a Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 15:03:48 -0000 --0015174bdf06601ec504a07dac4a Content-Type: text/plain; charset=ISO-8859-1 On Apr 9, 2011 12:38 AM, "Brian E Carpenter" wrote: > > P.S. The phaseout plan is to wait until existing hosts and CPEs that > do 6to4 by default go to landfill or e-cycling. So we need to operate > relays for another ten years. This is a tall ask from someone, with all due respect for your contributions, does not run a network or support desk. Do you happen to have a supporting business case or are we making proclamations that are not really intended for reality? I believe the sp consensus is turn 6to4 off by default asap. It's more trouble than it is worth and will get worse with cgn Cb > Regards > Brian > > On 2011-04-09 19:33, Brian E Carpenter wrote: > > On 2011-04-09 04:12, james woodyatt wrote: > >> On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote: > >>> However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that. > >> An RFC is not required for that. > >> > >> This draft would send a much stronger signal to implementors if it were to contain language more like what you see in RFC 3701 for phasing out the 6bone. I draw your attention to this excerpt: > >> > >> Thus after the 6bone phaseout date June 6, 2006, it is the intent > >> that no 6bone 3FFE prefixes, of any size/length, be used on the > >> Internet in any form. Network operators may filter 3FFE prefixes on > >> their borders to ensure these prefixes are not misused. > >> > >> If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore. If we knew that network operators were given guidance by IETF to stop routing 2002::/16 in the default free zone after some future date, then that would help me convince certain product engineering people I know to consider patches for existing field deployments. Failing that however, I'm pretty sure this draft as it stands today will be too easily ignored. > > > > IMHO that is exactly what we should not do. Breaking 6to4 worse than > > it is already broken is not in the interests of users or of > > service providers (whose help desks would incur the resulting costs). > > > > On the contrary, we need the 6to4 relays that exist to work impeccably, > > and that requires careful attention to routing both 2002::/16 and the > > anycast prefix. > > > > Brian > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0015174bdf06601ec504a07dac4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 9, 2011 12:38 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> P.S. The phaseout plan is to wait until existing hosts and CPEs that > do 6to4 by default go to landfill or e-cycling. So we need to operate<= br> > relays for another ten years.

This is a tall ask from someone, with all due respect for your contribut= ions, does not run a network or support desk.

Do you happen to have a supporting business case or are we making procla= mations that are not really intended for reality?

I believe the sp consensus is turn 6to4 off by default asap. It's mo= re trouble than it is worth and will get worse with cgn

Cb
> Regards
> =A0 Brian
>
> On 2011-04-09 19:33, Brian E Carpenter wrote:
> > On 2011-04-09 04:12, james woodyatt wrote:
> >> On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote:
> >>> However, I think we are suggesting that if MS can find a = way to patch existing hosts that will make it less likely that they use 6to= 4 anycast unintentionally, that would be a Good Thing. A MUST is not requir= ed for that.
> >> An RFC is not required for that.
> >>
> >> This draft would send a much stronger signal to implementors = if it were to contain language more like what you see in RFC 3701 for phasi= ng out the 6bone. =A0I draw your attention to this excerpt:
> >>
> >> =A0 =A0Thus after the 6bone phaseout date June 6, 2006, it is= the intent
> >> =A0 =A0that no 6bone 3FFE prefixes, of any size/length, be us= ed on the
> >> =A0 =A0Internet in any form. =A0Network operators may filter = 3FFE prefixes on
> >> =A0 =A0their borders to ensure these prefixes are not misused= .
> >>
> >> If IETF were to publish a phaseout plan for 6to4, then it wou= ld be more difficult for vendors of host and home gateway operating systems= to ignore. =A0If we knew that network operators were given guidance by IET= F to stop routing 2002::/16 in the default free zone after some future date= , then that would help me convince certain product engineering people I kno= w to consider patches for existing field deployments. =A0Failing that howev= er, I'm pretty sure this draft as it stands today will be too easily ig= nored.
> >
> > IMHO that is exactly what we should not do. Breaking 6to4 worse t= han
> > it is already broken is not in the interests of users or of
> > service providers (whose help desks would incur the resulting cos= ts).
> >
> > On the contrary, we need the 6to4 relays that exist to work impec= cably,
> > and that requires careful attention to routing both 2002::/16 and= the
> > anycast prefix.
> >
> > =A0 =A0Brian
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0015174bdf06601ec504a07dac4a-- From brian.e.carpenter@gmail.com Sat Apr 9 08: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 BBEE03A692A for ; Sat, 9 Apr 2011 08:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkYd6-F+F9KU for ; Sat, 9 Apr 2011 08:05:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id F0D493A690C for ; Sat, 9 Apr 2011 08:05:25 -0700 (PDT) Received: by wwa36 with SMTP id 36so3661903wwa.13 for ; Sat, 09 Apr 2011 08:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mcaXoB9sYKby6twyNyZDdZQy9LBhTm/MYr5jyQ0an5o=; b=K91Mda6JojC3C6zA5BUJPah+gH8jCrCaL0FOGYpfqM2405kBHi0Fk34hUd1wIE88mq GscgWAkGz2NE0yO6cx3IXCrZQL1cbnOjA5+zKcCq4ECAf1wv/oD3SlYoPjKeeLdCXhCW V4Obi5CxqmoV0FPernB18gl+oVJuhZ6n0XA04= 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=IWQShsas5Fe+bmxP5YtIXUTM8SuzFJ/8QRGfaKugUbdjKVtrtveQnYuqXqDjGstVGN 53WEfMSThCKH2Zczusm1u7AgdxDxTcn2pYFEu5rg27ODHw7M6biPgwywi8cu/FjnQhiY GYtQ33jwU0XuoYRIISTNP+UVF+aqboLKDpD3s= Received: by 10.216.29.134 with SMTP id i6mr3135755wea.11.1302361631475; Sat, 09 Apr 2011 08:07:11 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id l5sm1822617wej.8.2011.04.09.08.07.09 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 08:07:10 -0700 (PDT) Message-ID: <4DA07617.9030001@gmail.com> Date: Sun, 10 Apr 2011 03:07:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 15:05:26 -0000 On 2011-04-10 02:59, Cameron Byrne wrote: ... >> On the contrary, we need the 6to4 relays that exist to work impeccably, >> and that requires careful attention to routing both 2002::/16 and the >> anycast prefix. > > Working impeccable is a lot to ask given that customers generally don't know > or care about 6to4 and it does not and will not provide revenue Help desk calls cause negative revenue, and so do dissatisfied content providers. Also, careless configuration of routing for the 6to4 prefixes can offer a free ride to non-customers. I don't see any category of operator that will not get indirect OPEX benefits from making 6to4 relays work better. Brian From brian.e.carpenter@gmail.com Sat Apr 9 08:08: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 B3CF13A694D for ; Sat, 9 Apr 2011 08:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do-+sH5RF+PD for ; Sat, 9 Apr 2011 08:08:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D2F553A690C for ; Sat, 9 Apr 2011 08:08:17 -0700 (PDT) Received: by wyb29 with SMTP id 29so4176832wyb.31 for ; Sat, 09 Apr 2011 08:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wFmLHzSAIOUA4xqgIC0fTuutBfEJ2h6/1zqZU/uRZis=; b=YibWeC6ql0xAWN/0AKaVhIoAwLilATUyxdAs5Os7nTK+oPLl2DFVyx0slEzzQA5J36 EfTjLhUpEdymDhMKHZe3gU+pvHW6HPQUR2XVj7lA0vF6P5wG+CMa7Ic3SiiA99KW6ZHa Stma2eWhYOcmcZHdgV37eq8eCqTrgEuHRlgFU= 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=StEvOdDse3c+O9dS0csRNdfEODIWlivIO6BhTgAknhY1Y95onli4VfE5XFqlEb1Tzr yKLntKnfld/ox5Vcb0cPTJMg5ha456OXyMJM2MKxjNWIVBtNA3YBls2bRIz0X+yz4qLH 5bkngNUBa3z5HzVmpFRQHUM9ROUQkLhT5MamM= Received: by 10.216.241.197 with SMTP id g47mr893656wer.24.1302361801415; Sat, 09 Apr 2011 08:10:01 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id w12sm2314149wby.24.2011.04.09.08.09.59 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 08:10:00 -0700 (PDT) Message-ID: <4DA076C4.9010005@gmail.com> Date: Sun, 10 Apr 2011 03:09:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 15:08:19 -0000 On 2011-04-10 03:05, Cameron Byrne wrote: > On Apr 9, 2011 12:38 AM, "Brian E Carpenter" > wrote: >> P.S. The phaseout plan is to wait until existing hosts and CPEs that >> do 6to4 by default go to landfill or e-cycling. So we need to operate >> relays for another ten years. > > This is a tall ask from someone, with all due respect for your > contributions, does not run a network or support desk. > > Do you happen to have a supporting business case or are we making > proclamations that are not really intended for reality? > > I believe the sp consensus is turn 6to4 off by default asap. It's more > trouble than it is worth and will get worse with cgn My previous reply answers this too. Try to get it turned off by all means, but you can't turn off most of the legacy boxes. Everthing will get worse with CGN, but you are right and draft-ietf-v6ops-6to4-advisory calls this out. Brian > > Cb >> Regards >> Brian >> >> On 2011-04-09 19:33, Brian E Carpenter wrote: >>> On 2011-04-09 04:12, james woodyatt wrote: >>>> On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote: >>>>> However, I think we are suggesting that if MS can find a way to patch > existing hosts that will make it less likely that they use 6to4 anycast > unintentionally, that would be a Good Thing. A MUST is not required for > that. >>>> An RFC is not required for that. >>>> >>>> This draft would send a much stronger signal to implementors if it were > to contain language more like what you see in RFC 3701 for phasing out the > 6bone. I draw your attention to this excerpt: >>>> Thus after the 6bone phaseout date June 6, 2006, it is the intent >>>> that no 6bone 3FFE prefixes, of any size/length, be used on the >>>> Internet in any form. Network operators may filter 3FFE prefixes on >>>> their borders to ensure these prefixes are not misused. >>>> >>>> If IETF were to publish a phaseout plan for 6to4, then it would be more > difficult for vendors of host and home gateway operating systems to ignore. > If we knew that network operators were given guidance by IETF to stop > routing 2002::/16 in the default free zone after some future date, then that > would help me convince certain product engineering people I know to consider > patches for existing field deployments. Failing that however, I'm pretty > sure this draft as it stands today will be too easily ignored. >>> IMHO that is exactly what we should not do. Breaking 6to4 worse than >>> it is already broken is not in the interests of users or of >>> service providers (whose help desks would incur the resulting costs). >>> >>> On the contrary, we need the 6to4 relays that exist to work impeccably, >>> and that requires careful attention to routing both 2002::/16 and the >>> anycast prefix. >>> >>> Brian >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From jhw@apple.com Sat Apr 9 09:16:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFE93A68FD for ; Sat, 9 Apr 2011 09:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEaSpmg6l7N6 for ; Sat, 9 Apr 2011 09:16:05 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by core3.amsl.com (Postfix) with ESMTP id 86B363A6876 for ; Sat, 9 Apr 2011 09:16:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJE00AO37XJYJC0@mail-out.apple.com> for v6ops@ietf.org; Sat, 09 Apr 2011 09:17:51 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-74-4da086afe286 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with SMTP id B5.9F.20744.FA680AD4; Sat, 09 Apr 2011 09:17:51 -0700 (PDT) Received: from [172.16.1.2] ([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 <0LJE008027XRFV70@gertie.apple.com> for v6ops@ietf.org; Sat, 09 Apr 2011 09:17:51 -0700 (PDT) From: james woodyatt In-reply-to: <4DA00BC6.4090705@gmail.com> Date: Sat, 09 Apr 2011 09:17:50 -0700 Message-id: <780BE603-9C1F-4CF6-87A1-ED59AB2BEB64@apple.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Apr 2011 16:16:06 -0000 On Apr 9, 2011, at 12:33 AM, Brian E Carpenter wrote: > > IMHO that is exactly what we should not do. Breaking 6to4 worse than > it is already broken is not in the interests of users or of > service providers (whose help desks would incur the resulting costs). I agree, though I'm not sure the service and content providers pushing this move care about the help desk costs associated with this move. They probably know they'll be sharing the burden with equipment makers. However, the 6to4 To Historic draft is too easy for equipment makers to ignore because it sets no standard for equipment makers and it includes no phaseout plan for operators. That's why I opposed taking it up as a working group item. If we're going to deprecate 6to4 properly, then it needs a phaseout plan. We MUST break it worse than it is already broken, or it will only be phased out when IPv4 itself is phased out. > On the contrary, we need the 6to4 relays that exist to work impeccably, > and that requires careful attention to routing both 2002::/16 and the > anycast prefix. I'm an enthusiastic supporter of the 6to4/Teredo advisory draft. -- james woodyatt member of technical staff, core os networking From Dmitry.Anipko@microsoft.com Sat Apr 9 19:24: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 B92DC3A69BC for ; Sat, 9 Apr 2011 19:24:33 -0700 (PDT) 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 lVMP-Jev5NES for ; Sat, 9 Apr 2011 19:24:32 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 669D13A694D for ; Sat, 9 Apr 2011 19:24:32 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 9 Apr 2011 19:26:18 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 9 Apr 2011 19:26:18 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Sat, 9 Apr 2011 19:26:17 -0700 From: Dmitry Anipko To: Tore Anderson , Christopher Palmer Date: Sat, 9 Apr 2011 19:26:13 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: Acv08j3IW2nUZ2P5TaeVBPpNHnC8VQCMIdHA Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D6236.5000302@redpill-linpro.com> In-Reply-To: <4D9D6236.5000302@redpill-linpro.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] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2011 02:24:34 -0000 Hi Tore, >> Unfortunately, last I checked, it does not help to override the A record to resolve to nothing. The Default Gateway field in the ipconfig output shows an empty value (where it usually says 2002:c058:6301::). The 6to4 adapter is enabled, and ICS continues to annouce it with RAs. To clarify on this: when A record is absent, Windows 6to4 hosts do not conf= igure default route to 6to4 relay for themselves. It is correct that ICS, i= f configured on 6to4 host, will advertize default route irrespectively of w= hether 6to4 relay is configured or not. But for those hosts, which don't ha= ve ICS configured, modification of the A record for the relay name does hav= e effect. To verify that, I tested that today on a fresh Windows 7 install. >>It does *not* help *at* *all* against dual-stack brokenness, since the hosts that receive the RA will get an IPv6 address and an IPv6 default router, and will try to use that to get to the IPv6 internet. Which is guaranteed to not work, and you're guaranteed end-user brokenness. Are there data indicating that overwhelming majority of clients, which expe= rience IPv6 brokenness and have 6to4 addresses, are broken because they rec= eived ICS rogue 6to4 RAs, and that they are not 6to4 hosts, which try sendi= ng traffic through black-holed 6to4 relay due to the default route they hav= e to that relay? Thank you, Dmitry -----Original Message----- From: Tore Anderson [mailto:tore.anderson@redpill-linpro.com]=20 Sent: Thursday, April 07, 2011 12:05 AM To: Christopher Palmer Cc: Martin Millnert; Brian E Carpenter; v6ops@ietf.org; Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day questio= n Hi Chris, * Christopher Palmer > Yes - Windows clients currently "learn" the 6to4 anycast prefix by > resolving 6to4.ipv6.microsoft.com. >=20 > Modification of this A record could be used to modify Windows Vista/7 > behavior without requiring a Windows Update, and fix the perceived > issue semi-magically. Unfortunately, last I checked, it does not help to override the A record to resolve to nothing. The Default Gateway field in the ipconfig output shows an empty value (where it usually says 2002:c058:6301::). The 6to4 adapter is enabled, and ICS continues to annouce it with RAs. Doing this is equivalent to disabling anycast 6to4 (RFC 3068) but leaving router 6to4 (RFC 3056) functionality intact. It does *not* help *at* *all* against dual-stack brokenness, since the hosts that receive the RA will get an IPv6 address and an IPv6 default router, and will try to use that to get to the IPv6 internet. Which is guaranteed to not work, and you're guaranteed end-user brokenness. This problem is the biggest reason why I strongly feel that 3056 should be marked historic along with 3068. However, if it is possible to muck around with the 6to4.ipv6.microsoft.com record in a way that prevents the 6to4 interface from being enabled (and, by extension, RAs from ICS) - please do share! I know of several network operators who would be absolutely ecstatic about having a way to disable rogue RAs from 6to4/ICS for their entire user base in one fell swoop. Best regards, --=20 Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From tore@redpill-linpro.com Sat Apr 9 22:39: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 6C0E43A69D8 for ; Sat, 9 Apr 2011 22:39:19 -0700 (PDT) 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 WSSocM1ZDiXN for ; Sat, 9 Apr 2011 22:39:17 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 387B93A69D3 for ; Sat, 9 Apr 2011 22:39:17 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id EACA1CC100; Sun, 10 Apr 2011 07:40:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 WDdlD7zfrBhA; Sun, 10 Apr 2011 07:40:33 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Sun, 10 Apr 2011 07:40:33 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id A9854170C00B; Sun, 10 Apr 2011 07:40:32 +0200 (CEST) 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 d4nJUXumrKO8; Sun, 10 Apr 2011 07:40:30 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 361FE170C00A; Sun, 10 Apr 2011 07:40:30 +0200 (CEST) Date: Sun, 10 Apr 2011 07:40:30 +0200 (CEST) From: Tore Anderson To: Dmitry Anipko Message-ID: <1893570575.177029.1302414030186.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: v6ops@ietf.org, Christopher Palmer Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2011 05:39:20 -0000 Hi Dimitry, * Dmitry Anipko > Are there data indicating that overwhelming majority of clients, > which experience IPv6 brokenness and have 6to4 addresses, are broken > because they received ICS rogue 6to4 RAs, There's plenty of empirical evidence. After spending a few minutes with Google: https://ow.feide.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf http://malc.org.uk/6doom http://ripe61.ripe.net/presentations/162-ripe61.pdf http://www.rfc-editor.org/rfc/rfc6104.txt http://www.gossamer-threads.com/lists/nanog/users/139564#139564 http://www.getipv6.info/index.php/Customer_problems_that_could_occur#Internet_Connection_Sharing http://www.uknof.org.uk/uknof10/Chown-IPv6-campus.pdf http://www.gossamer-threads.com/lists/nsp/ipv6/28106#28106 http://www.ietf.org/mail-archive/web/72attendees/current/msg00478.html http://www.ipv6.leeds.ac.uk/Docs/IPv6issues.pdf http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf https://ow.feide.no/_media/geantcampus:2011-gn3-na3t4-ipv6-skjesol.pdf http://www.personal.psu.edu/dvm105/blogs/ipv6/2011/01/rogue-ra-while-shopping-for-sh.html http://www.apan.net/meetings/Sydney2010/Session/Slides/IPv6/10%20John_Mann_20100210.pdf I'll stop here, but you'll be able to find many more accounts of 6to4 rogue RAs from ICS causing major operational problems by using your favourite search engine. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From dwcarder@wisc.edu Sun Apr 10 13:56: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 249573A6989 for ; Sun, 10 Apr 2011 13:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9onsBN5FrnUO for ; Sun, 10 Apr 2011 13:56:32 -0700 (PDT) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by core3.amsl.com (Postfix) with ESMTP id 771193A697B for ; Sun, 10 Apr 2011 13:56:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LJG00B1KFI7DK00@smtpauth1.wiscmail.wisc.edu> for v6ops@ietf.org; Sun, 10 Apr 2011 15:56:31 -0500 (CDT) Received: from [192.168.0.5] (66-188-112-13.dhcp.mdsn.wi.charter.com [66.188.112.13]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LJG000N5FHZXK10@smtpauth1.wiscmail.wisc.edu>; Sun, 10 Apr 2011 15:56:24 -0500 (CDT) Date: Sun, 10 Apr 2011 15:56:23 -0500 From: "Dale W. Carder" In-reply-to: To: Dmitry Anipko Message-id: X-Mailer: Apple Mail (2.1084) X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.10.204815, SenderIP=192.168.0.5 References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D6236.5000302@redpill-linpro.com> Cc: "v6ops@ietf.org" , Christopher Palmer Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Apr 2011 20:56:33 -0000 Hi Dmitry, On Apr 9, 2011, at 9:26 PM, Dmitry Anipko wrote: > > Are there data indicating that overwhelming majority of clients, which experience IPv6 brokenness and have 6to4 addresses, are broken because they received ICS rogue 6to4 RAs This is the #1 cause of v6 brokenness on our campus network. Dale From Wesley.E.George@sprint.com Sun Apr 10 19: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 3C1D63A6A30 for ; Sun, 10 Apr 2011 19:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.499, 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 e5JCTTHI1uHl for ; Sun, 10 Apr 2011 19:22:10 -0700 (PDT) Received: from DB3EHSOBE004.bigfish.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by core3.amsl.com (Postfix) with ESMTP id C08433A6A43 for ; Sun, 10 Apr 2011 19:22:09 -0700 (PDT) Received: from mail12-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.8; Mon, 11 Apr 2011 02:22:09 +0000 Received: from mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3-R.bigfish.com (Postfix) with ESMTP id E92221A081E2; Mon, 11 Apr 2011 02:22:08 +0000 (UTC) X-SpamScore: -41 X-BigFish: VS-41(zz1803M9371O1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h34h61h) 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 mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3 (MessageSwitch) id 1302488528682262_14913; Mon, 11 Apr 2011 02:22:08 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.252]) by mail12-db3.bigfish.com (Postfix) with ESMTP id A30DE26004F; Mon, 11 Apr 2011 02:22:08 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 11 Apr 2011 02:22:06 +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 p3B2Lpvv002262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Apr 2011 21:21:51 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH03.ad.sprint.com ([fe80::a470:17cb:6a7f:3a52%15]) with mapi id 14.01.0270.001; Sun, 10 Apr 2011 21:21:50 -0500 From: "George, Wes E [NTK]" To: Cameron Byrne , Brian E Carpenter Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: AQHL9gfJvyX2eTdJUEGUkmjhJHG2bZRVeJUAgAABSQCAAH0EgIAB+UDA Date: Mon, 11 Apr 2011 02:21:49 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6E758@PLSWM12A.ad.sprint.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.114] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01CBF7CD.AEAA16D0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 02:22:11 -0000 ------=_NextPart_000_0019_01CBF7CD.AEAA16D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: Saturday, April 09, 2011 11:05 AM To: Brian E Carpenter Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status On Apr 9, 2011 12:38 AM, "Brian E Carpenter" wrote: > > P.S. The phaseout plan is to wait until existing hosts and CPEs that > do 6to4 by default go to landfill or e-cycling. So we need to operate > relays for another ten years. This is a tall ask from someone, with all due respect for your contributions, does not run a network or support desk. Do you happen to have a supporting business case or are we making proclamations that are not really intended for reality? I believe the sp consensus is turn 6to4 off by default asap. It's more trouble than it is worth and will get worse with cgn Cb [WEG] No matter what the behavior in new hosts may change to after this draft, Brian is right. For the same reason that we can't get more things to get software updates to support real IPv6, a software change to update the defaults on out-of-warranty consumer electronics is unlikely (both in availability and in getting people to apply it), and therefore the phaseout plan is accurate regardless of what SP consensus may be. No one is mandating that you support relays beyond when you think it makes sense in your network, whether that be a business case discussion, or a technical consideration, or both. That includes deciding to turn them off tomorrow, or never deploying relays at all, or doing things that you know will break it like using routable space as NAT space, etc. This is simply acknowledging that there is some set of folks that are successfully using 6to4, and we ought not unceremoniously break it if we can avoid doing so. I don't think that's such a tall order. Wes George ------=_NextPart_000_0019_01CBF7CD.AEAA16D0 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MTEwMjIxNDhaMCMGCSqGSIb3DQEJBDEWBBRx0ApBiqV3 ic0sdGyigtbKDSpTgTBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAGVTFYB2UMnZLTuqwjxf26MLVQjZwv ZNY8Tq7Wli9PfZ2yfyrpTDTKPV7CRWwl/cY7lphW9mlEQhJa9EbgtaI1yzM17k3c0QRjszEHxSst tnDjfFYi8O3RJvYAJp4GvPPYZ1lf2q5myGTBBqI9OxF2SDApoTyLQF89NG/cldtIpwAAAAAAAA== ------=_NextPart_000_0019_01CBF7CD.AEAA16D0-- From toasty@dragondata.com Sun Apr 10 19:50: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 570F43A6A47 for ; Sun, 10 Apr 2011 19:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OprtFHgZhQYj for ; Sun, 10 Apr 2011 19:50:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5176E3A6A43 for ; Sun, 10 Apr 2011 19:50:12 -0700 (PDT) Received: by iwn39 with SMTP id 39so6451968iwn.31 for ; Sun, 10 Apr 2011 19:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=2OhwqFmlY+WZ89+mTuzxtxTDLJ1SxHXdPts+ZhjXU3o=; b=HNhYukQRwtL61f0lchSP9TyQwzVSIU/+I83d9PNFbKLIjYffRTM4Bz/GN1oPvJ/tQv D3DdRYn+0S/T1YysISz+IrdBeZOCC1M8uJYpXWrcA0DynUsnLcvko8nVWJg/FRKkPYyt pQs4KCUWxBipfQtXXIyT2B6hulsXgfaGJzhuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dragondata.com; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=H/MN2i3/K5JbM0s6+GSZZc+Cgpk2p76vsDYJoiNu72/4RnJ3tusxEWrefckwVcDNfj PGuH9XSey/1K4ghd8J3hKktdlFf91u5k7EYyNHzoCvC++KGvt606sOYRBmmpySZZuJBR o5FqvR7dRXSJ5YVkCxz428cLMiS3cNNhfN3S4= Received: by 10.42.133.136 with SMTP id h8mr7081716ict.163.1302490211775; Sun, 10 Apr 2011 19:50:11 -0700 (PDT) Received: from vpn168.ord02.your.org (vpn168.ord02.your.org [204.9.55.168]) by mx.google.com with ESMTPS id 13sm3882057ibo.42.2011.04.10.19.50.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 19:50:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Kevin Day In-Reply-To: Date: Sun, 10 Apr 2011 21:50:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 02:50:16 -0000 On Apr 9, 2011, at 10:05 AM, Cameron Byrne wrote: >=20 > On Apr 9, 2011 12:38 AM, "Brian E Carpenter" = wrote: > > > > P.S. The phaseout plan is to wait until existing hosts and CPEs that > > do 6to4 by default go to landfill or e-cycling. So we need to = operate > > relays for another ten years. >=20 > This is a tall ask from someone, with all due respect for your = contributions, does not run a network or support desk. >=20 > Do you happen to have a supporting business case or are we making = proclamations that are not really intended for reality? >=20 > I believe the sp consensus is turn 6to4 off by default asap. It's more = trouble than it is worth and will get worse with cgn We run a public 6to4 relay announced to the world. Despite its problems, we're seeing overall usage on it go up, with an = overall trend of around a 5% increase each month. I don't know if this is because others are shutting their relays down, = more people are using 6to4, other providers are forcing a selection onto = our relay because we go through great pains to make sure it's actually = working, or there's just more v6 content out there. If the argument isn't "Even if 6to4 is your only option, you're better = off not having v6 at all", has anyone else looked at statistics on = public 6to4 relays to see what kind of usage growth/loss is happening = lately? I have no personal stake in what happens to 6to4, but if there = actually is a pattern of growth with it now, we probably should be = looking at why that's happening before discussions of pulling the plug = get too far. Another single-datapoint anecdote: We used to receive at least one = complaint a month about our 6to4 relay not working (which pretty much = always was traced down to the reverse path being broken, not us), but = those complaints have pretty much stopped entirely in the last year. I = don't know if this is because people are getting better at deploying = 6to4, or if people know enough to switch to another option if it's = broken. -- Kevin From victor.kuarsingh@gmail.com Sun Apr 10 20:03: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 552E43A6A43 for ; Sun, 10 Apr 2011 20:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 hOJY1+0vgcUs for ; Sun, 10 Apr 2011 20:03:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 1BECA3A69BC for ; Sun, 10 Apr 2011 20:03:53 -0700 (PDT) Received: by yxk30 with SMTP id 30so2472795yxk.31 for ; Sun, 10 Apr 2011 20:03:52 -0700 (PDT) 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=YYHdTpGZgRNapxpvmaWIkeUu3kaM7tHmpyiWra8ghdo=; b=YivPNrlyW1esBN18ZzALdkD/wi4YoxcGW52Yh1c8pbOwpzjhWFOeF98rn3lBAiTSt2 dr0maOI+E/DwmzduJLMoVh7trTdn1nJwN7PHYIgF3pXpx0ByXGKcIjK6xxOnrVSAn02U elHPG/mRLGFcRTrRPIE8m7bJUmAtIk68gqOaw= 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=OKQpkPLw/9Q+hzssRUxP3sd5LwpQDB6VdMtoE1c1605F5qKUkbcpVqs9remTBe5Amx sPas0Rz86ETgt+AZoInajBWIGRcU/p/pUgzgy5mlPXuvDNpOOIii+xizsYah8bGuOMzt LbcIQa22FenNRcMaq19w+ob+sRo478GNcTS0M= Received: by 10.236.27.69 with SMTP id d45mr5311883yha.229.1302491032617; Sun, 10 Apr 2011 20:03:52 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id n63sm2333477yhj.47.2011.04.10.20.03.50 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 20:03:51 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 10 Apr 2011 23:04:12 -0400 From: Victor Kuarsingh To: "George, Wes E [NTK]" , Cameron Byrne , Brian E Carpenter Message-ID: Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6E758@PLSWM12A.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 03:03:54 -0000 On 10/04/11 10:21 PM, "George, Wes E [NTK]" wrote: > >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >Cameron Byrne >Sent: Saturday, April 09, 2011 11:05 AM >To: Brian E Carpenter >Cc: IPv6 Ops WG >Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status > >On Apr 9, 2011 12:38 AM, "Brian E Carpenter" > wrote: >> >> P.S. The phaseout plan is to wait until existing hosts and CPEs that >> do 6to4 by default go to landfill or e-cycling. So we need to operate >> relays for another ten years. >This is a tall ask from someone, with all due respect for your >contributions, does not run a network or support desk. >Do you happen to have a supporting business case or are we making >proclamations that are not really intended for reality? >I believe the sp consensus is turn 6to4 off by default asap. It's more >trouble than it is worth and will get worse with cgn >Cb > >[WEG] No matter what the behavior in new hosts may change to after this >draft, Brian is right. For the same reason that we can't get >more things to get software updates to support real IPv6, a software >change to update the defaults on out-of-warranty consumer >electronics is unlikely (both in availability and in getting people to >apply it), and therefore the phaseout plan is accurate >regardless of what SP consensus may be. No one is mandating that you >support relays beyond when you think it makes sense in your >network, whether that be a business case discussion, or a technical >consideration, or both. That includes deciding to turn them off >tomorrow, or never deploying relays at all, or doing things that you know >will break it like using routable space as NAT space, etc. >This is simply acknowledging that there is some set of folks that are >successfully using 6to4, and we ought not unceremoniously >break it if we can avoid doing so. I don't think that's such a tall order. [Victor] Whereas I support the overall efforts to move 6to4 to historical, it's operation in the network will continue for a some time. Although device vendors "may" change the default behavior, the reality is that most customers don=B9t proactively update firmware, run updates etc, and many devices out there today (as noted by Wes) will not see firmware updates. Many of these devices will need to be turned off to stop their 6to4 operation. As an operator, I do not support the willful blocking or hinderance of valid traffic. As long as 6to4 traffic exists in the network, it's our job to make it work as best possible. I think the efforts to make it work are far more achievable in the near future then those efforts to kill it off. This is due based on the premise that killing it off requires the uncontrolled masses to take positive steps to upgrade/update [when those actually occur] - whereas making it work can be achieved by a controlled set of ISPs and knowledgeable staff). I guess over time 6to4 traffic will decline (not sure how long this will take) and then we can stop worrying about it. =20 I think Brian's draft (draft-ietf-v6ops-6to4-advisory) sums up what is needed to help 6to4 work as best possible while the realization of Ole's draft (draft-ietf-v6ops-6to4-to-historic) takes hold (over time). This would help my general populous of which some are using 6to4. As for the CGN use case (using non-RFC1918), there is an option here which works. For me, the reality is that 6to4 traffic exists for now so I will to deal with it; when it's gone all the better (Not just declared gone, but actually gone). Regards, Victor K > >Wes George >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From john.mann@monash.edu Sun Apr 10 21:37: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 B94F53A6A71 for ; Sun, 10 Apr 2011 21:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.776 X-Spam-Level: X-Spam-Status: No, score=-4.776 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 oVcapDrsrEBv for ; Sun, 10 Apr 2011 21:37:46 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with ESMTP id 32FB43A6A43 for ; Sun, 10 Apr 2011 21:37:46 -0700 (PDT) Received: from mail-vx0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTaKFl0Cp3jHhh9b7cj+JnG/aiYT3z3vm@postini.com; Sun, 10 Apr 2011 21:37:46 PDT Received: by mail-vx0-f178.google.com with SMTP id 11so5332620vxc.23 for ; Sun, 10 Apr 2011 21:37:43 -0700 (PDT) Received: by 10.52.0.110 with SMTP id 14mr7149110vdd.67.1302496662067; Sun, 10 Apr 2011 21:37:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.234 with HTTP; Sun, 10 Apr 2011 21:37:22 -0700 (PDT) In-Reply-To: <901586CA8F92D543BFFFD6E1122F5A36026BBDF61912@HE101453.emea1.cds.t-internal.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <0AB09EDBCD1C484EBE45978D62F3513C3CD899D4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD89B4B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <901586CA8F92D543BFFFD6E1122F5A36026BBDF61912@HE101453.emea1.cds.t-internal.com> From: "John Mann (ITS)" Date: Mon, 11 Apr 2011 14:37:22 +1000 Message-ID: To: HahnC@t-systems.com Content-Type: multipart/alternative; boundary=0023547c8ae5dd1c6f04a09d225e Cc: v6ops@ietf.org, Christopher.Palmer@microsoft.com Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 04:37:48 -0000 --0023547c8ae5dd1c6f04a09d225e Content-Type: text/plain; charset=ISO-8859-1 Hi, The problem that Windows 7 IPv6 addresses can't be un-deprecated is biting Fritz!Box users in Australia There is a discussion of this problem, along with a youtube demonstration at http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=5#r97 The discussion is scattered through several later pages at least as far as http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=15#r288 Also: http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/e1873459-5b9f-4c3e-b9e7-fdf778bae491/ Thanks, John On 7 April 2011 18:28, wrote: > > > >Yeah, we know about the rouge RAs (that's what I meant by ICS > >bugs that exacerbate the issue). > > > >Anything else? > > > Christopher, > > there is a bug still existing since 2009 which relates to state changes of > IPv6 addresses. > For history please see: > http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002718.html > Actual discussion: > http://lists.cluenet.de/pipermail/ipv6-ops/2011-April/005188.html > > How to reproduce? > > Case A: > 1) advertise IPv6 prefix to SLAAC enabled Vista/Win7 hosts > 2) withdraw this prefix by sending RA with PIO and PrefLT=0 > 3) re-advertise the same prefix with common timers > > Results in deprecated, unusable IPv6 addresses on the systems despite the > fact that timers are updated according to the recent PIO information. > > Case B (quoting myself from ipv6-ops list): > > You can reproduce this behavior without sending PIO with PrefLT=0 if you > send the Vista/Win7 system in standby and wake it up after time X. > Where X is defined as ValidLifetime > X > PreferredLifetime. > > > Same result as in case A. > > best regards, > Christian > > <><><><><><><><><><><><><><> > Christian Hahn > > T-Systems International GmbH > Systems Integration > IP Products, Services and Networks > Goslarer Ufer 35, 10589 Berlin > Tel +49 30 -3497 3164 > Fax +49 30 -3497 3165 > Mobil +49 170 7641791 > E-Mail: hahnc@t-systems.com > Internet: <> > > > >Best! > >Chris > > > >-----Original Message----- > >From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > >Sent: Wednesday, April 06, 2011 12:34 PM > >To: Christopher Palmer > >Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko > >Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and > >IPv6 day question > > > >Christopher, > > > > > >> From the perspective of Windows... > >> > >> Isn't it fair to say: > >> 6to4 is enabled by default on Windows Vista > >and Windows 7 > >> Windows Vista and Windows 7 implement RFC 3484 > >> > >> Thus, the only sources of "brokenness" - scoped to Windows: > >> Applications that sort addresses correctly > >(by not following Windows guidance) > >> Hosts that are behind Windows when it has > >been configured with Internet Connection Sharing, and do not > >have RFC 3484. > >> (we know about the ICS and 6to4 bugs > >> that exacerbate this issue) > >> > >> Are there other categories of brokenness from an experience > >perspective? Major applications that are broken? > > > >the ICS 'rouge RA' issue: > > - host A is on a dual stack link with native IPv6 support > >(IPv6 default router with native IPv6 connectivity) > > - host B on the same link, turns on ICS and advertises itself > >as a default router > > - host A picks host B as default router instead of the correct one > > > >cheers, > >Ole > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0023547c8ae5dd1c6f04a09d225e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

The problem that Windows 7 =A0IPv6 addresses can'= ;t be un-deprecated is biting Fritz!Box users in Australia

There is a discussion of this problem, along with a youtube demons= tration at
The discussion is scattered through= several later pages at least as far as

Also:

Thanks,
=A0 =A0 John

On 7 April 2011 18:28, <HahnC@t-systems.com> wrote:
>
>Yeah, we know about the rouge RAs (that's what I meant by ICS
>bugs that exacerbate the issue).
>
>Anything else?
>
Christopher,

there is a bug still existing since 2009 which relates to state changes of = IPv6 addresses.
For history please see: http://lists.cluenet.de/pip= ermail/ipv6-ops/2009-December/002718.html
Actual discussion: http://lists.cluenet.de/pipermail/i= pv6-ops/2011-April/005188.html

How to reproduce?

Case A:
1) advertise IPv6 prefix to SLAAC enabled Vista/Win7 hosts
2) withdraw this prefix by sending RA with PIO and PrefLT=3D0
3) re-advertise the same prefix with common timers

Results in deprecated, unusable IPv6 addresses on the systems despite the f= act that timers are updated according to the recent PIO information.

Case B (quoting myself from ipv6-ops list):
<quote>
You can reproduce this behavior without sending PIO with PrefLT=3D0 if you = send the Vista/Win7 system in standby and wake it up after time X.
Where X is defined as ValidLifetime > X > PreferredLifetime.
</quote>

Same result as in case A.

best regards,
Christian

<><><><><><><><><><= ;><><><><>
Christian Hahn

T-Systems International GmbH
Systems Integration
IP Products, Services and Networks
Goslarer Ufer 35, 10589 Berlin
Tel =A0 =A0 +49 30 -3497 3164
Fax =A0 =A0 +49 30 -3497 3165
Mobil =A0 +49 170 7641791
E-Mail: hahnc@t-systems.com
Internet: <<ht= tp://www.t-systems.com>>


>Best!
>Chris
>
>-----Original Message-----
>From: Ole Troan [mailto:ichi= roumakino@gmail.com] On Behalf Of Ole Troan
>Sent: Wednesday, April 06, 2011 12:34 PM
>To: Christopher Palmer
>Cc: Cameron Byrne; Sander Steffann; v= 6ops@ietf.org; Dmitry Anipko
>Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and
>IPv6 day question
>
>Christopher,
>
>
>> From the perspective of Windows...
>>
>> Isn't it fair to say:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6to4 is enabled by default on Wind= ows Vista
>and Windows 7
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Windows Vista and Windows 7 implem= ent RFC 3484
>>
>> Thus, the only sources of "brokenness" - scoped to Windo= ws:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Applications that sort addresses c= orrectly
>(by not following Windows guidance)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hosts that are behind Windows when= it has
>been configured with Internet Connection Sharing, and do not
>have RFC 3484.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (w= e know about the ICS and 6to4 bugs
>> that exacerbate this issue)
>>
>> Are there other categories of brokenness from an experience
>perspective? Major applications that are broken?
>
>the ICS 'rouge RA' issue:
> - host A is on a dual stack link with native IPv6 support
>(IPv6 default router with native IPv6 connectivity)
> - host B on the same link, turns on ICS and advertises itself
>as a default router
> - host A picks host B as default router instead of the correct one
>
>cheers,
>Ole
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--0023547c8ae5dd1c6f04a09d225e-- From john.mann@monash.edu Sun Apr 10 22:03: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 7C1DB3A6A43 for ; Sun, 10 Apr 2011 22:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjNILaycUg0H for ; Sun, 10 Apr 2011 22:03:08 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with ESMTP id 9AED53A69D2 for ; Sun, 10 Apr 2011 22:03:03 -0700 (PDT) Received: from mail-vw0-f46.google.com ([209.85.212.46]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTaKLh0dtlUmXxwO4utq7QLA9b5eRjHfc@postini.com; Sun, 10 Apr 2011 22:03:04 PDT Received: by mail-vw0-f46.google.com with SMTP id 1so5848171vws.33 for ; Sun, 10 Apr 2011 22:03:03 -0700 (PDT) Received: by 10.52.69.140 with SMTP id e12mr6953207vdu.187.1302498183007; Sun, 10 Apr 2011 22:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.234 with HTTP; Sun, 10 Apr 2011 22:02:37 -0700 (PDT) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D6236.5000302@redpill-linpro.com> From: "John Mann (ITS)" Date: Mon, 11 Apr 2011 15:02:37 +1000 Message-ID: To: "Dale W. Carder" Content-Type: multipart/alternative; boundary=20cf307f326a84cf5d04a09d7df5 Cc: "v6ops@ietf.org" , Christopher Palmer , Dmitry Anipko Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 05:03:11 -0000 --20cf307f326a84cf5d04a09d7df5 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 11 April 2011 06:56, Dale W. Carder wrote: > Hi Dmitry, > > On Apr 9, 2011, at 9:26 PM, Dmitry Anipko wrote: > > > > Are there data indicating that overwhelming majority of clients, which > experience IPv6 brokenness and have 6to4 addresses, are broken because they > received ICS rogue 6to4 RAs > > This is the #1 cause of v6 brokenness on our campus network. This _was_ the #1 cause of brokenness on our campus networks in 2009. Mostly Windows Vista personal laptops causing problems for OS X 10.4/5 Macs. Finding/fixing PCs one at a time couldn't keep up with the problem, especially for student PCs in residences who were only active in the evenings. We suppressed the rogue RAs (but didn't fix the problem by stopping the PCs from being 6to4 gateways) by applying this filter across 53,000+ user switch ports --- ipv6 access-list RA-FILTER deny icmp any any router-advertisement deny icmp any any router-renumbering permit ipv6 any any --- The graph of concurrently visible rogue 6to4 routers on our network can be seen decreasing from 11 to 0 http://ns0b.its.monash.edu/test/ipv6-rogue-routers-month.png Thanks, John --20cf307f326a84cf5d04a09d7df5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 11 April 2011 06:56, Dale W. Carde= r <dwcarder@wisc.= edu> wrote:
Hi Dmitry,

On Apr 9, 2011, at 9:26 PM, Dmitry Anipko wrote:
>
> Are there data indicating that overwhelming majority of clients, which= experience IPv6 brokenness and have 6to4 addresses, are broken because the= y received ICS rogue 6to4 RAs

This is the #1 cause of v6 brokenness on our campus network.

This _was_ the #1 cause of brokenness on our campus= networks in 2009.
Mostly Windows Vista personal laptops causing = problems for OS X 10.4/5 Macs.

Finding/fixing PCs one at a time couldn't keep up w= ith the problem, especially for student PCs in residences
who wer= e only active in the evenings.

We=A0suppressed the= rogue RAs (but didn't fix the problem by stopping the PCs from being 6= to4 gateways)=A0by applying this filter across 53,000+ user switch ports
---
ipv6 access-list RA-FILTER
=A0deny icmp a= ny any router-advertisement
=A0deny icmp any any router-renumberi= ng
=A0permit ipv6 any any
---

The graph of concurrently visible rogue 6to4 routers on our network can be = seen decreasing from 11 to 0

Thanks,
=A0 =A0 John
--20cf307f326a84cf5d04a09d7df5-- From joelja@bogus.com Sun Apr 10 23:38: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 B3E623A69D1 for ; Sun, 10 Apr 2011 23:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.451 X-Spam-Level: X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=0.548, 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 BABbM1q6zxeQ for ; Sun, 10 Apr 2011 23:38:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 9F6B13A6951 for ; Sun, 10 Apr 2011 23:38:13 -0700 (PDT) Received: from 23173jjaeggli.local ([64.9.242.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p3B6c8a3027937 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 11 Apr 2011 06:38:09 GMT (envelope-from joelja@bogus.com) Message-ID: <4DA2A1CB.6040609@bogus.com> Date: Sun, 10 Apr 2011 23:38:03 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Victor Kuarsingh References: 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, 11 Apr 2011 06:38:10 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 06:38:15 -0000 On 4/10/11 8:04 PM, Victor Kuarsingh wrote: > I think Brian's draft (draft-ietf-v6ops-6to4-advisory) sums up what is > needed to help 6to4 work as best possible while the realization of Ole's > draft (draft-ietf-v6ops-6to4-to-historic) takes hold (over time). This > would help my general populous of which some are using 6to4. As for the > CGN use case (using non-RFC1918), there is an option here which works. > > For me, the reality is that 6to4 traffic exists for now so I will to deal > with it; when it's gone all the better (Not just declared gone, but > actually gone). Right, this is my sense... We would prefer that hosts not do it. For now we support the hosts that do as best we can. The sooner they stop, the better. joel > Regards, > > Victor K > > > > > >> >> Wes George >> _______________________________________________ >> 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 mark@townsley.net Mon Apr 11 03:30: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 03EDC28C0F1 for ; Mon, 11 Apr 2011 03:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.106 X-Spam-Level: X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 lv-kwuoyJgd4 for ; Mon, 11 Apr 2011 03:30:44 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 916CE28C0E9 for ; Mon, 11 Apr 2011 03:30:43 -0700 (PDT) Received: by wwk4 with SMTP id 4so2471076wwk.1 for ; Mon, 11 Apr 2011 03:30:43 -0700 (PDT) Received: by 10.216.245.4 with SMTP id n4mr2587930wer.83.1302517843193; Mon, 11 Apr 2011 03:30:43 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id t5sm2573113wes.9.2011.04.11.03.30.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 03:30:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-11--59391485 From: Mark Townsley In-Reply-To: Date: Mon, 11 Apr 2011 12:30:39 +0200 Message-Id: <76A1027D-4F9E-49A6-9EA9-AE018C545B6A@townsley.net> References: To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-tunnel-loops 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, 11 Apr 2011 10:30:45 -0000 --Apple-Mail-11--59391485 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think we should have much stronger language here that filtering of = protocol 41 packets breaks 6to4, along with pointers to the relevant = documents discussed in v6ops as to why this causes problems. It's more = than "may not be suitable for scenarios where IPv4 connectivity is = essential on all interfaces" as this action can have real adverse = affects on unsuspecting users.=20 3.2.1.1. Filtering IPv4 Protocol-41 Packets In this measure a tunnel router may drop all IPv4 protocol-41 packets received or sent over interfaces that are attached to an untrusted IPv4 network. This will cut-off any IPv4 network as a shared link. This measure has the advantage of simplicity. However, such a measure may not always be suitable for scenarios where IPv4 connectivity is essential on all interfaces. Further, I believe we should be very clear in the abstract that this is = an attack vector for which there are (at the time of writing) no known = reports of any malicious attacks utilizing said vector. - Mark On Apr 6, 2011, at 7:59 AM, Fred Baker wrote: >=20 > On Mar 31, 2011, at 11:30 AM, Fred Baker wrote: >=20 >> This is to initiate a one week working group last call of = draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The = IESG reviewed the document and asked for changes; we need to be sure we = are comfortable with the changes. The diff from the version sent to the = IESG last November is at http://tinyurl.com/6dhowhf >>=20 >> 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. >=20 > WGLC closing Sunday. Any comments on the draft? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-11--59391485 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 


3.2.1.1.  Filtering IPv4 Protocol-41 Packets

   In this measure a tunnel router may drop all IPv4 protocol-41 packets
   received or sent over interfaces that are attached to an untrusted
   IPv4 network.  This will cut-off any IPv4 network as a shared link.
   This measure has the advantage of simplicity.  However, such a
   measure may not always be suitable for scenarios where IPv4
   connectivity is essential on all interfaces.


Further, I believe we should be = very clear in the abstract that this is an attack vector for which there = are (at the time of writing) no known reports of any malicious attacks =  utilizing said vector.

- = Mark


On Apr 6, 2011, at = 7:59 AM, Fred Baker wrote:


On = Mar 31, 2011, at 11:30 AM, Fred Baker wrote:

This is to initiate a one week working group last call of = draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The = IESG reviewed the document and asked for changes; we need to be sure we = are comfortable with the changes. The diff from the version sent to the = IESG last November is at http://tinyurl.com/6dhowhf

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.

WGLC closing Sunday. Any comments on = the draft?
_______________________________________________
v6ops = mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-11--59391485-- From kawashimam@vx.jp.nec.com Mon Apr 11 05:29: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 5780D3A6B10 for ; Mon, 11 Apr 2011 05:29:38 -0700 (PDT) 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 u768J8w-lKW5 for ; Mon, 11 Apr 2011 05:29:36 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 160A63A6B05 for ; Mon, 11 Apr 2011 05:29:35 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p3BCTZOv024501; Mon, 11 Apr 2011 21:29:35 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p3BCTZL29342; Mon, 11 Apr 2011 21:29:35 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id p3BCTY10023391; Mon, 11 Apr 2011 21:29:35 +0900 (JST) Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Mon, 11 Apr 2011 21:29:33 +0900 To: "John Mann (ITS)" In-reply-to: References: Message-Id: <20110411212926kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Mon, 11 Apr 2011 21:29:25 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Christopher.Palmer@microsoft.com Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 12:29:38 -0000 Hi John, I reported same problem to Japanese Microsoft engineers on March 11th. They've already finished to confirm this problem. They are considering how fix it. I might inform their decision one of these days. Sincerely, Masanobu >Hi, > >The problem that Windows 7 IPv6 addresses can't be un-deprecated is biting >Fritz!Box users in Australia > >There is a discussion of this problem, along with a youtube demonstration at > http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=5#r97 >The discussion is scattered through several later pages at least as far as > http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=15#r288 > >Also: > >http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/e1873459-5b9f-4c3e-b9e7-fdf778bae491/ > >Thanks, > John > >On 7 April 2011 18:28, wrote: > >> > >> >Yeah, we know about the rouge RAs (that's what I meant by ICS >> >bugs that exacerbate the issue). >> > >> >Anything else? >> > >> Christopher, >> >> there is a bug still existing since 2009 which relates to state changes of >> IPv6 addresses. >> For history please see: >> http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002718.html >> Actual discussion: >> http://lists.cluenet.de/pipermail/ipv6-ops/2011-April/005188.html >> >> How to reproduce? >> >> Case A: >> 1) advertise IPv6 prefix to SLAAC enabled Vista/Win7 hosts >> 2) withdraw this prefix by sending RA with PIO and PrefLT=0 >> 3) re-advertise the same prefix with common timers >> >> Results in deprecated, unusable IPv6 addresses on the systems despite the >> fact that timers are updated according to the recent PIO information. >> >> Case B (quoting myself from ipv6-ops list): >> >> You can reproduce this behavior without sending PIO with PrefLT=0 if you >> send the Vista/Win7 system in standby and wake it up after time X. >> Where X is defined as ValidLifetime > X > PreferredLifetime. >> >> >> Same result as in case A. >> >> best regards, >> Christian >> >> <><><><><><><><><><><><><><> >> Christian Hahn >> >> T-Systems International GmbH >> Systems Integration >> IP Products, Services and Networks >> Goslarer Ufer 35, 10589 Berlin >> Tel +49 30 -3497 3164 >> Fax +49 30 -3497 3165 >> Mobil +49 170 7641791 >> E-Mail: hahnc@t-systems.com >> Internet: <> >> >> >> >Best! >> >Chris >> > >> >-----Original Message----- >> >From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan >> >Sent: Wednesday, April 06, 2011 12:34 PM >> >To: Christopher Palmer >> >Cc: Cameron Byrne; Sander Steffann; v6ops@ietf.org; Dmitry Anipko >> >Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and >> >IPv6 day question >> > >> >Christopher, >> > >> > >> >> From the perspective of Windows... >> >> >> >> Isn't it fair to say: >> >> 6to4 is enabled by default on Windows Vista >> >and Windows 7 >> >> Windows Vista and Windows 7 implement RFC 3484 >> >> >> >> Thus, the only sources of "brokenness" - scoped to Windows: >> >> Applications that sort addresses correctly >> >(by not following Windows guidance) >> >> Hosts that are behind Windows when it has >> >been configured with Internet Connection Sharing, and do not >> >have RFC 3484. >> >> (we know about the ICS and 6to4 bugs >> >> that exacerbate this issue) >> >> >> >> Are there other categories of brokenness from an experience >> >perspective? Major applications that are broken? >> > >> >the ICS 'rouge RA' issue: >> > - host A is on a dual stack link with native IPv6 support >> >(IPv6 default router with native IPv6 connectivity) >> > - host B on the same link, turns on ICS and advertises itself >> >as a default router >> > - host A picks host B as default router instead of the correct one >> > >> >cheers, >> >Ole >> >_______________________________________________ >> >v6ops mailing list >> >v6ops@ietf.org >> >https://www.ietf.org/mailman/listinfo/v6ops >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > ======================================== NEC AccessTechnica, Ltd. Access Networks Engineering Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From fred@cisco.com Mon Apr 11 05:35: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 D1F6128C0F9 for ; Mon, 11 Apr 2011 05:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 vw3txpRFmC26 for ; Mon, 11 Apr 2011 05:35:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 03C4728C0F6 for ; Mon, 11 Apr 2011 05:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2471; q=dns/txt; s=iport; t=1302525330; x=1303734930; h=from:subject:date:message-id:cc:to:mime-version; bh=rwQLcj1MWpRgyxXB71/Ur2+WelLO312t4qLQ6ClQq4w=; b=Env8SqfpMxELQrndCAqz4odTQBOyfYRh+RVkSRlL2HDrrfpTlVTdBxQm Njqejcg4sd8dFvOfD2vcMfpINqRMoD8DbhztNLYtY3a549I6c6a1auU5m pOJYn1/ondLS2oTJm5CG0oFcqbxPYYORmdwoBiqMD4H6HDWtU89N75bN+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAGL0ok2rRDoJ/2dsb2JhbACCYJYfhguHD3eldZtXhW4EhVuHfYNq X-IronPort-AV: E=Sophos;i="4.63,338,1299456000"; d="scan'208,217";a="293631476" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 12:35:30 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BCZOCe018783; Mon, 11 Apr 2011 12:35:30 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 11 Apr 2011 05:35:30 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 11 Apr 2011 05:35:30 -0700 From: Fred Baker Date: Mon, 11 Apr 2011 05:35:14 -0700 Message-Id: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-82--51915896 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] WGLC draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 12:35:31 -0000 --Apple-Mail-82--51915896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a one week working group last call of = draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat; it will close a week = from today. We had a working group last call and got some comments; the = draft has since been updated. The diff from the February version is at = http://tinyurl.com/4rlzaln. If you commented on the previous document, = please advise the chairs and the authors of your view on the changes. 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.= --Apple-Mail-82--51915896 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a one week working = group last call of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat; it = will close a week from today. We had a working group last call and = got some comments; the draft has since been updated. The diff from = the February version is at http://tinyurl.com/4rlzaln. If = you commented on the previous document, please advise the chairs and the = authors of your view on the changes.
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.
=
= --Apple-Mail-82--51915896-- From brian.e.carpenter@gmail.com Mon Apr 11 09:06: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 37A3328C135 for ; Mon, 11 Apr 2011 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 XyyuDbf2wKeS for ; Mon, 11 Apr 2011 09:06:00 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F13A528C12F for ; Mon, 11 Apr 2011 09:05:59 -0700 (PDT) Received: by wyb29 with SMTP id 29so5444399wyb.31 for ; Mon, 11 Apr 2011 09:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sXnlXHK213HJYNoBTMnNv1zxfqGHYQuy+iBoR94XCbw=; b=cUZrkcELHTUCBAX+6/HwYFVUtHT2AIYyzfI+fQ2ivTrvtLYAA0VqcT66/syjg2V4Ye L+UEVXWivz1QOc0y7kw9DDUGTYNsvPEjp9Y45c9o93Q1zT9JZpPHUmhsmzO9rF5DjDIC JM9H4rfZuTWpIupiKwimAdImJ+jW+zD5TNgJ0= 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=QJ8kLtZpWC2FrbqWexZF9aCasYoLrFNUeFpxIbCE7KiaByAGDS6NJGIY4IqO7L+S2P GSUsG3DFbVizYmCtSoDxDn7PwjuFIaCTnnuwpKT2iQ9fyRC2aA+/VfZ1BBQaxleGB7cd w3wzlQa+fntP4LG/prBk8ti+j3MNv76tvFCE0= Received: by 10.216.254.39 with SMTP id g39mr2133449wes.108.1302537959677; Mon, 11 Apr 2011 09:05:59 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id g32sm2740874wej.27.2011.04.11.09.05.57 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 09:05:58 -0700 (PDT) Message-ID: <4DA326E0.3060808@gmail.com> Date: Tue, 12 Apr 2011 04:05:52 +1200 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: <76A1027D-4F9E-49A6-9EA9-AE018C545B6A@townsley.net> In-Reply-To: <76A1027D-4F9E-49A6-9EA9-AE018C545B6A@townsley.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-tunnel-loops 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, 11 Apr 2011 16:06:01 -0000 On 2011-04-11 22:30, Mark Townsley wrote: > > I think we should have much stronger language here that filtering of protocol 41 packets breaks 6to4, along with pointers to the relevant documents discussed in v6ops as to why this causes problems. It's more than "may not be suitable for scenarios where IPv4 connectivity is essential on all interfaces" as this action can have real adverse affects on unsuspecting users. > +1 In fact this issue is specifically mentioned in several places in draft-ietf-v6ops-6to4-advisory, and is summarized in the Security Considerations as: A blanket recommendation to block Protocol 41 is not compatible with mitigating the 6to4 problems described in this document. This is part of a balanced recommendation; elsewhere the draft says: The strategic solution is to deploy native IPv6, making Protocol 41 redundant. Brian > > 3.2.1.1. Filtering IPv4 Protocol-41 Packets > > In this measure a tunnel router may drop all IPv4 protocol-41 packets > received or sent over interfaces that are attached to an untrusted > IPv4 network. This will cut-off any IPv4 network as a shared link. > This measure has the advantage of simplicity. However, such a > measure may not always be suitable for scenarios where IPv4 > connectivity is essential on all interfaces. > > > Further, I believe we should be very clear in the abstract that this is an attack vector for which there are (at the time of writing) no known reports of any malicious attacks utilizing said vector. > > - Mark > > > On Apr 6, 2011, at 7:59 AM, Fred Baker wrote: > >> On Mar 31, 2011, at 11:30 AM, Fred Baker wrote: >> >>> This is to initiate a one week working group last call of draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The IESG reviewed the document and asked for changes; we need to be sure we are comfortable with the changes. The diff from the version sent to the IESG last November is at http://tinyurl.com/6dhowhf >>> >>> 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. >> WGLC closing Sunday. Any comments on the draft? >> _______________________________________________ >> 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.L.Templin@boeing.com Mon Apr 11 11:18: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 30E843A6A47 for ; Mon, 11 Apr 2011 11:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 soJEpbBNkR-Y for ; Mon, 11 Apr 2011 11:18:19 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 329E93A6A09 for ; Mon, 11 Apr 2011 11:18:19 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3BIIHA5026779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Apr 2011 13:18:17 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3BIIHCZ012593 for ; Mon, 11 Apr 2011 13:18:17 -0500 (CDT) 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 p3BIIFtW012546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 11 Apr 2011 13:18:16 -0500 (CDT) 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, 11 Apr 2011 11:18:15 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Date: Mon, 11 Apr 2011 11:18:14 -0700 Thread-Topic: Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv4RPaAwKW3FKbCS76FU3Oxx/og4QAGIvjA Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> In-Reply-To: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@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 Subject: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-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: Mon, 11 Apr 2011 18:18:20 -0000 Hello, The following should not be construed as a draft, but rather just a set of ideas that might be considered for inclusion in a new or existing draft. Any comments or suggestions? Thanks - Fred fred.l.templin@boeing.com --- cut here --- Introduction ************ Countless end user sites in the Internet today still have predominantly IPv4 infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services. As more and more IPv6-only services are deployed in the Internet, however, end user devices within the site will increasingly require at least basic IPv6 functionality for external access. This pre-draft provides operational guidance for predominantly IPv4 sites in making transitional IPv6 services available without disrupting existing IPv4 services. Characteristics of Existing IPv4 Sites ************************************** Existing end user sites use IPv4 routing and addressing internally for normal IT operations such as filesharing, network printing, e-mail, conferencing and numerous other critical site-internal networking services. Such sites typically have an abundance of public or private IPv4 addresses for internal networking, and are separated from the public Internet by firewalls, packet filtering gateways, proxies, address translators and other site border securing devices. To date, such sites have had little incentive to enable IPv6 services internally [RFC1687]. With the emergence of IPv6-only services within the public Internet, however, existing IPv4 sites will increasingly require a means for enabling client-side IPv6 services so that end user devices within the site can access IPv6 Internet services. Such services must be deployable with minimal configuration and in a fashion that will not cause disruptions to existing IPv4 services within the site. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to-use service that sites can deploy in the near term to meet these reqirements while a longer-term site-wide IPv6 deployment plan is conducted in parallel. Enabling Client-Side IPv6 Services with ISATAP ********************************************** Small sites typically arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP) in the same fashion as for home network users. When the ISP does not yet provide native IPv6 services, it can instead offer a transitional service with native-equivalent capabilities using 6RD [RFC5569][RFC5969]. Large sites typically obtain provider independent IPv6 prefixes from an Internet registry and advertise the prefixes into the IPv6 routing system on their own behalf, i.e., they act as an ISP unto themselves. In both cases, the site can automatically enable ISATAP based IPv6 services by configuring one or more site border routers as ISATAP routers. Each such ISATAP router is added to the Potential Router List (PRL) for the site so that hosts in the network can discover them for default route and prefix auto-configuration purposes. When there are multiple ISATAP site border routers, the routers can advertise the same IPv6 prefix or a different set of IPv6 prefixes of prefix length /64. For example, a first router may advertise 2001:db8:0:0::/64, a second may advertise 2001:db8:0:1::/64, etc. The routers can further be configured to advertise different prefixes to different sets of hosts within the site (e.g., as identified by the host's IPv4 prefix) for the purpose of site partitioning. In all cases, however, the site border routers must take operational measures to avoid routing loops [draft-ietf-v6ops-tunnel-loops]. As a simple mitigation, the site border router can drop any incoming packets that have an IPv4 source or outgoing packets that have an IPv4 destination address of another site border router, e.g., by checking for the address in the site's PRL. ISATAP hosts will automatically discover ISATAP site border routers and configure ISATAP addresses using Stateless Address AutoConfiguration (SLAAC) based on the advertised IPv6 prefixes. In order to provide a simple service that does not interact poorly with existing site topological arrangements, the site can enable client-side only operation so that hosts only use the ISATAP service for accessing IPv6 services on the public Internet, while continuing to use IPv4 services for intra-site communications. In order to maintain a client-side only service, the site should not configure any IPv6 addresses provided by ISATAP within site name service resource records. In this way, intra-site communications will continue to use existing IPv4 networking services instead of ISATAP-served IPv6 services. This arrangement prevents communication failure modes in which a pair of ISATAP hosts are separated by a packet filtering gateway which would prevent direct communications via the tunneled IPv6 service. To further disable host-to-host ISATAP communications within the site, the ISATAP site border routers should advertise their prefixes with the (A,L) flags set to (1,0) in their IPv6 Router Advertisements. In that way, each ISATAP host will autoconfigure an address from the advertised IPv6 prefix and assign it to their ISATAP interface, but they will not assign an IPv6 prefix to the ISATAP interface. Therefore, no two ISATAP hosts will see each other as on-link neighbors, and all IPv6 communications from the hosts will flow through an ISATAP site border router in order to access IPv6 services in the Internet. Migration to Native IPv6 Services ********************************* ISATAP hosts should be configured to prefer native IPv6 services instead of ISATAP whenever available. As the site transitions its internal routers and links to use IPv6 natively, hosts will naturally begin to receive native IPv6 router advertisments and will begin using the native IPv6 service instead of ISATAP. As more and more native IPv6 service is enabled in the site, IPv6 addresses can be entered into site name service resource records to enable intra-site IPv6 service discovery. In that way, predominantly IPv4 sites will begin to operate a parallel native IPv6 service, and legacy IPv4 services will gradually be phased out.= From yjchui@cht.com.tw Mon Apr 11 20:02:06 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AB2E8E0675 for ; Mon, 11 Apr 2011 20:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.836 X-Spam-Level: ** X-Spam-Status: No, score=2.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNeOr1jIExHU for ; Mon, 11 Apr 2011 20:02:06 -0700 (PDT) Received: from scan2.cht.com.tw (scan3.cht.com.tw [202.39.168.43]) by ietfc.amsl.com (Postfix) with ESMTP id 0682DE06B3 for ; Mon, 11 Apr 2011 20:02:05 -0700 (PDT) X-AuditID: 0aa00266-a7567ba000000b34-0e-4da3c0a630d7 Received: from cas1.corp.cht.com.tw (unknown [10.160.2.147]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id 90FF8156F71 for ; Tue, 12 Apr 2011 11:01:58 +0800 (CST) Received: from MAIL.corp.cht.com.tw ([10.160.1.132]) by cas1.corp.cht.com.tw ([10.160.2.147]) with mapi; Tue, 12 Apr 2011 11:00:35 +0800 From: =?big5?B?prar26Zw?= To: "v6ops@ietf.org" Date: Tue, 12 Apr 2011 11:02:24 +0800 Thread-Topic: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-00.txt Thread-Index: Acv19LCFpI9Xp6SAT82GsVFdP/FIyACyPCcg Message-ID: <6EF582646D1CBF4D987E88FD43A5ECF2B0D6C00686@MAIL.corp.cht.com.tw> References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> In-Reply-To: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> Accept-Language: zh-HK, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-HK, en-US Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: =?big5?B?reKq2rfsKEZhbmctWXUgTGluZyk=?= Subject: Re: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 03:02:06 -0000 VGhlIGxpbmsgZm9yIHRoZSBkcmFmdCBpcyBub3QgcmlnaHQuIFBsZWFzZSByZWZlciB0byA6DQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mbGluZy12Nm9wcy1oeWJyaWQtYnJpZGdl ZC1yb3V0ZWQtMDANCg0KWWFubi1KdQ0KQ2h1bmdId2EgVGVsZWNvbS4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9w cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZnJlZEBjaXNjby5jb20NClNlbnQ6IEZy aWRheSwgQXByaWwgMDgsIDIwMTEgOTo1NSBQTQ0KVG86IHY2b3BzQGlldGYub3JnDQpDYzogZHJh ZnQtZmxpbmctdjZvcHMtaHlicmlkLWJyaWRnZWQtcm91dGVkQHRvb2xzLmlldGYub3JnDQpTdWJq ZWN0OiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZmxpbmctdjZvcHMtaHlicmlkLWJyaWRnZWQt cm91dGVkLTAwLnR4dA0KDQoNCkEgbmV3IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwgYXQgaHR0cDov L3Rvb2xzLmlldGYub3JnL2RyYWZ0LWZsaW5nLXY2b3BzLWh5YnJpZC1icmlkZ2VkLXJvdXRlZC0w MC50eHQuIFBsZWFzZSB0YWtlIGEgbG9vayBhdCBpdCBhbmQgY29tbWVudC4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QN CnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo= From Dmitry.Anipko@microsoft.com Tue Apr 12 00:31:16 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6CD29E0793 for ; Tue, 12 Apr 2011 00:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QppwnvolqvE4 for ; Tue, 12 Apr 2011 00:31:14 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id E954EE0784 for ; Tue, 12 Apr 2011 00:31:13 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Apr 2011 00:31:13 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 12 Apr 2011 00:31:13 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Tue, 12 Apr 2011 00:30:42 -0700 From: Dmitry Anipko To: Tore Anderson Date: Tue, 12 Apr 2011 00:30:41 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: Acv3QeLkpukoR3a5Tze0sMAg0cyLpwBoNJtw Message-ID: References: <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no> In-Reply-To: <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:31:16 -0000 SGkgVG9yZSwNCg0KZGVmaW5pdGVseSA2dG80IFJBcyBzZW50IGJ5IElDUyBpcyBvbmUgb2YgdGhl IGJyb2tlbm5lc3Mgc291cmNlcy4gSG93ZXZlciBpdCBpcyBub3QgdGhlIG9ubHkgc291cmNlLCBh bmQgbXkgcXVlc3Rpb24gd2FzIGhvdyBtYW55IHVzZXJzIGFyZSB0aGVyZSwgc2l0dGluZyB3aXRo IDZ0bzQgZGVmYXVsdCByb3V0ZSBhbmQgZXhwZXJpZW5jaW5nIElQdjYgYnJva2VubmVzcywgd2hv IHdvdWxkIGJlIGZpeGVkIGJ5IGNoYW5naW5nIHJlbGF5IEEgcmVjb3JkLiANCg0KTm9uZSBvZiB0 aGUgc291cmNlcyB5b3UgcXVvdGVkIHNlZW1zIHRvIGRvIHN1Y2ggY29tcGFyaXNvbiAtIHRoZXkg YXJlIG1vc3RseSBmb2N1c2VkIG9uIElDUyBSQSBpc3N1ZSwgd2hpY2ggaXMgaGlnaGx5IHZpc2li bGUgdG8gbmV0d29yayBhZG1pbmlzdHJhdG9ycywgYnV0IGl0IGRvZXNuJ3QgYXV0b21hdGljYWxs eSBtZWFuIHRoYXQgaXNzdWVzIGluIG90aGVyIGNvbmZpZ3VyYXRpb25zIGRvbid0IGV4aXN0IG9y IGxlc3MgaW1wb3J0YW50LCBldmVuIGlmIHRoZXkgYXJlIGxlc3MgdmlzaWJsZSB0byBhZG1pbmlz dHJhdG9ycy4gDQoNCk9uZSBjb3VsZCBlc3RpbWF0ZSB0aGUgbnVtYmVyIG9mIHVzZXJzIGFmZmVj dGVkIGJ5IDZ0bzQgUkFzIChmb3IgZXhhbXBsZSwgb24gSVB2NCBvbmx5IG5ldHdvcmtzKSBhbmQg YnkgNnRvNCBvbiBob3N0cywgYmFzZWQgb24gbWFya2V0IHNoYXJlcyBvZiBPU2VzIGFuZCBicm93 c2VyczoNCg0KSWYgWCBpcyBhIG51bWJlciBvZiBob3N0cyB3b3JsZHdpZGUgd2l0aCBhc3NpZ25l ZCBwdWJsaWMgSVB2NCBhZGRyZXNzZXMsIGFuIGVzdGltYXRlIGZvciB0aGUgbnVtYmVyIG9mIGFm ZmVjdGVkIHVzZXJzIGZvciBXaW5kb3dzIDZ0bzQgaG9zdHMgY291bGQgYmUgLSBYICogMC4zNSAo V2luZG93cyA3ICsgVmlzdGEgc2hhcmUpICogMC4wMDUgKHVwcGVyIGVzdGltYXRlIG9mIHNoYXJl IG9mIG9sZGVyIGJyb3dzZXJzIG5vdCBmb2xsb3dpbmcgUkZDIDM0ODQpLiAgDQoNCkFuIGVzdGlt YXRlIGZvciB0aGUgbnVtYmVyIG9mIGFmZmVjdGVkIHVzZXJzIG9uIElQdjQgbmV0d29ya3MgYWZm ZWN0ZWQgYnkgNnRvNCBJQ1MgUkFzIC0gWCAqIDAuMzUgKFc3ICsgVmlzdGEgbWFya2V0IHNoYXJl KSAqIE1vYmlsZUlDU1NoYXJlICogQXZnTWFjaGluZXNQZXJMQU4gKiAoMC4wNiAodXBwZXIgZXN0 aW1hdGUgb2Ygc2hhcmUgb2Ygb2xkZXIgdmVyc2lvbnMgb2Ygc29tZSBPU2VzLCBub3QgZm9sbG93 aW5nIFJGQyAzNDg0KSArIDAuMzUgKFdpbmRvd3MgNyArIFZpc3RhIHNoYXJlKSAqIDAuMDA1ICkg d2hlcmUgTW9iaWxlSUNTU2hhcmUgc3RhbmRzIGZvciByZWxhdGl2ZSBzaGFyZSBvZiBXaW5kb3dz NytWaXN0YSB3aXRoIElDUyBlbmFibGVkIHdoaWNoIGFyZSBub3QgYWx3YXlzIGF0IG9uZSBsb2Nh dGlvbiwgYW5kIEF2Z01hY2hpbmVzUGVyTEFOIGlzIGhvdyBtYW55IG1hY2hpbmVzIGFyZSBpbiBh biBhdmVyYWdlIExBTi4NCg0KSW4gY29tcGFyaXNvbiB0aGUgY29tbW9uIGZhY3RvciBYKjAuMzUg Y2FuIGJlIGV4Y2x1ZGVkLCBhbmQgb25lIG5lZWRzIHRvIGNvbXBhcmUgfjAuMDA1IHdpdGggTW9i aWxlSUNTU2hhcmUgKiBBdmdNYWNoaW5lc1BlckxBTiAqIDAuMDYuIFRvIGVzdGltYXRlIE1vYmls ZUlDU1NoYXJlICogQXZnTWFjaGluZXNQZXJMQU4sIG15IGd1ZXNzIGZvciBBdmdNYWNoaW5lc1Bl ckxBTiBpcyAxMDAtMTAwMC4gV2l0aCBzdWNoIG51bWJlcnMsIGZvciBudW1iZXIgb2YgYWZmZWN0 ZWQgdXNlcnMgaW4gdGhlIHR3byBzY2VuYXJpb3MgdG8gYmUgb2YgdGhlIHNhbWUgb3JkZXIsIE1v YmlsZUlDU1NoYXJlIG5lZWRzIHRvIGJlIDEwXi00IC0gMTBeLTMuIA0KDQpJIGRvbid0IGhhdmUg Z29vZCBkYXRhIHNvdXJjZXMgdG8gZXN0aW1hdGUgYWN0dWFsIE1vYmlsZUlDU1NoYXJlIHZhbHVl LCBidXQgd29ybGR3aWRlIDEwXi00IC0gMTBeLTMgZG9lc24ndCBzZWVtIHRvIGJlIGNvbXBsZXRl bHkgdW5yZWFzb25hYmxlLCBhbmQgbnVtYmVyIG9mIHRoZSBhZmZlY3RlZCB1c2VycyBpbiB0aGUg dHdvIHNjZW5hcmlvcyBtYXkgYmUgb2YgdGhlIHNhbWUgb3JkZXIuIFNvIGlmIHRoZXJlIGlzIGFu eSB0cnV0aCBpbiBzdWNoIHJvdWdoIGVzdGltYXRlLCBkaXNhYmxpbmcgNnRvNCByZWxheSByZWNv cmQgbWF5IHJlZHVjZSBJUHY2IGJyb2tlbm5lc3MuIEhvdyBtdWNoIGV4YWN0bHkgLSBJIGd1ZXNz IG9ubHkgYSBtZWFzdXJlbWVudCBjb3VsZCBzaG93Lg0KDQpUaGFuayB5b3UsDQpEbWl0cnkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRvcmUgQW5kZXJzb24gW21haWx0bzp0 b3JlLmFuZGVyc29uQHJlZHBpbGwtbGlucHJvLmNvbV0gDQpTZW50OiBTYXR1cmRheSwgQXByaWwg MDksIDIwMTEgMTA6NDEgUE0NClRvOiBEbWl0cnkgQW5pcGtvDQpDYzogQ2hyaXN0b3BoZXIgUGFs bWVyOyBNYXJ0aW4gTWlsbG5lcnQ7IEJyaWFuIEUgQ2FycGVudGVyOyB2Nm9wc0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02dG80LWFkdmlzb3J5LTAwIGFu ZCBJUHY2IGRheSBxdWVzdGlvbg0KDQpIaSBEaW1pdHJ5LA0KDQoqIERtaXRyeSBBbmlwa28NCg0K PiBBcmUgdGhlcmUgZGF0YSBpbmRpY2F0aW5nIHRoYXQgb3ZlcndoZWxtaW5nIG1ham9yaXR5IG9m IGNsaWVudHMsDQo+IHdoaWNoIGV4cGVyaWVuY2UgSVB2NiBicm9rZW5uZXNzIGFuZCBoYXZlIDZ0 bzQgYWRkcmVzc2VzLCBhcmUgYnJva2VuDQo+IGJlY2F1c2UgdGhleSByZWNlaXZlZCBJQ1Mgcm9n dWUgNnRvNCBSQXMsDQoNClRoZXJlJ3MgcGxlbnR5IG9mIGVtcGlyaWNhbCBldmlkZW5jZS4gQWZ0 ZXIgc3BlbmRpbmcgYSBmZXcgbWludXRlcw0Kd2l0aCBHb29nbGU6DQoNCmh0dHBzOi8vb3cuZmVp ZGUubm8vX21lZGlhL2dlYW50Y2FtcHVzOjIwMTEtZ24zbmEzdDQtaXB2Ni1ncmVnci5wZGYNCmh0 dHA6Ly9tYWxjLm9yZy51ay82ZG9vbQ0KaHR0cDovL3JpcGU2MS5yaXBlLm5ldC9wcmVzZW50YXRp b25zLzE2Mi1yaXBlNjEucGRmDQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2MTA0 LnR4dA0KaHR0cDovL3d3dy5nb3NzYW1lci10aHJlYWRzLmNvbS9saXN0cy9uYW5vZy91c2Vycy8x Mzk1NjQjMTM5NTY0DQpodHRwOi8vd3d3LmdldGlwdjYuaW5mby9pbmRleC5waHAvQ3VzdG9tZXJf cHJvYmxlbXNfdGhhdF9jb3VsZF9vY2N1ciNJbnRlcm5ldF9Db25uZWN0aW9uX1NoYXJpbmcNCmh0 dHA6Ly93d3cudWtub2Yub3JnLnVrL3Vrbm9mMTAvQ2hvd24tSVB2Ni1jYW1wdXMucGRmDQpodHRw Oi8vd3d3Lmdvc3NhbWVyLXRocmVhZHMuY29tL2xpc3RzL25zcC9pcHY2LzI4MTA2IzI4MTA2DQpo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvNzJhdHRlbmRlZXMvY3VycmVudC9t c2cwMDQ3OC5odG1sDQpodHRwOi8vd3d3LmlwdjYubGVlZHMuYWMudWsvRG9jcy9JUHY2aXNzdWVz LnBkZg0KaHR0cDovL3d3dy5pcHY2Lm9yZy5hdS8xMGlwdjZzdW1taXQvdGFsa3MvUm9uX0Jyb2Vy c21hLnBkZg0KaHR0cHM6Ly9vdy5mZWlkZS5uby9fbWVkaWEvZ2VhbnRjYW1wdXM6MjAxMS1nbjMt bmEzdDQtaXB2Ni1za2plc29sLnBkZg0KaHR0cDovL3d3dy5wZXJzb25hbC5wc3UuZWR1L2R2bTEw NS9ibG9ncy9pcHY2LzIwMTEvMDEvcm9ndWUtcmEtd2hpbGUtc2hvcHBpbmctZm9yLXNoLmh0bWwN Cmh0dHA6Ly93d3cuYXBhbi5uZXQvbWVldGluZ3MvU3lkbmV5MjAxMC9TZXNzaW9uL1NsaWRlcy9J UHY2LzEwJTIwSm9obl9NYW5uXzIwMTAwMjEwLnBkZg0KDQpJJ2xsIHN0b3AgaGVyZSwgYnV0IHlv dSdsbCBiZSBhYmxlIHRvIGZpbmQgbWFueSBtb3JlIGFjY291bnRzIG9mDQo2dG80IHJvZ3VlIFJB cyBmcm9tIElDUyBjYXVzaW5nIG1ham9yIG9wZXJhdGlvbmFsIHByb2JsZW1zIGJ5DQp1c2luZyB5 b3VyIGZhdm91cml0ZSBzZWFyY2ggZW5naW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQotLSANClRvcmUg QW5kZXJzb24NClJlZHBpbGwgTGlucHJvIEFTIC0gaHR0cDovL3d3dy5yZWRwaWxsLWxpbnByby5j b20NClRlbDogKzQ3IDIxIDU0IDQxIDI3DQoNCg== From swmike@swm.pp.se Tue Apr 12 00:55:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5EAB9E0784 for ; Tue, 12 Apr 2011 00:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-PT9dXD4S4L for ; Tue, 12 Apr 2011 00:55:17 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id B62EEE078A for ; Tue, 12 Apr 2011 00:55:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0599B9E; Tue, 12 Apr 2011 09:55:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 034519A for ; Tue, 12 Apr 2011 09:55:16 +0200 (CEST) Date: Tue, 12 Apr 2011 09:55:15 +0200 (CEST) From: Mikael Abrahamsson To: "v6ops@ietf.org" In-Reply-To: Message-ID: References: <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:55:18 -0000 On Tue, 12 Apr 2011, Dmitry Anipko wrote: > So if there is any truth in such rough estimate, disabling 6to4 relay > record may reduce IPv6 brokenness. How much exactly - I guess only a > measurement could show. I am 100% sure that disabling 6to4 by default would seriously reduce IPv6 brokenness. It will also seriously reduce the number of people using IPv6 (over 6to4), but I think the consensus is that right now it's better to reduce use of IPv6 compared to having a significant share of added IPv6 brokenness. So in my opinion from reading this WG, a lot of people (majority) wants users to get IPv6 when it's done right and has a very high possibility of working, as opposed to having IPv6 that we know is breaking in a lot of cases but that reaches a higher number. 6to4 was great for testing, it's not great for production. -- Mikael Abrahamsson email: swmike@swm.pp.se From tore.anderson@redpill-linpro.com Tue Apr 12 01:15:57 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39C17E066F for ; Tue, 12 Apr 2011 01:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGrwzomkQRgl for ; Tue, 12 Apr 2011 01:15:56 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfc.amsl.com (Postfix) with ESMTP id 13DD3E0613 for ; Tue, 12 Apr 2011 01:15:55 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 7BCA9C3E02; Tue, 12 Apr 2011 10:15:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 PvAGq3kTsd82; Tue, 12 Apr 2011 10:15:54 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Tue, 12 Apr 2011 10:15:54 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 536E3170C00E; Tue, 12 Apr 2011 10:15:54 +0200 (CEST) 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 27Q9vm8vzx6m; Tue, 12 Apr 2011 10:15:53 +0200 (CEST) Received: from envy.fud.no (unknown [77.40.198.54]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 3190D170C00F; Tue, 12 Apr 2011 10:15:53 +0200 (CEST) Message-ID: <4DA40A38.80906@redpill-linpro.com> Date: Tue, 12 Apr 2011 10:15:52 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:15:57 -0000 Hi Dmitry, * Dmitry Anipko > definitely 6to4 RAs sent by ICS is one of the brokenness sources. > However it is not the only source, and my question was how many users > are there, sitting with 6to4 default route and experiencing IPv6 > brokenness, who would be fixed by changing relay A record. My guess? Almost none. Removing the relay A record will only help people that are: 1) Windows users (millions), and 2) Have a local 6to4 interface (millons), and 3) Prefer to use the 6to4 interface above IPv4 (almost none - pretty much only Opera users that haven't upgraded in more than a year). As you've confirmed yourself, removing the relay A record does nothing for users behind/besides a ICS host, as they will still have an default route and a 6to4 address. > None of the sources you quoted seems to do such comparison - they are > mostly focused on ICS RA issue, which is highly visible to network > administrators, but it doesn't automatically mean that issues in > other configurations don't exist or less important, even if they are > less visible to administrators. The ICS rogue RA issue is the way I see it *THE* problem with IPv6 in Windows. I'm happy to hear that you acknowledge it to be a problem. I'm looking at this from the content provider's perspective, not as network operator that has a RA problem on my own network: I see users being unable to access my dual-stacked sites, and when talking to the operators of the networks those end users are in, they tell me that they're tearing their hair out about rogue RAs and don't know what to do about them. The problem is not limited to 6to4 though, any rogue RA causes grief, including the site-local and prefix-less ones that ICS can generate. Especially on dual-stacked LANs, as the hosts get confused about which next-hop to use. (BTW: The University of Oslo ended up developing an intricate system that detects rogue RA, shoots them down with ramond and immediately moves the end-user's switch port into an quarantine VLAN where the only thing he can access is a captive portal that instructs him to first disable ICS, and then afterwards contact the help desk in order to have his network access restored.) > One could estimate the number of users affected by 6to4 RAs I fail to see why this is interesting, as it is beyond any doubt that rogue RAs from ICS are a huge problem. Can you please fix it ASAP? Just make ICS never send out any RAs unless it has native IPv6 connectivity to share, and push this patch out to your users in Windows Update. It would help *A LOT*. If we notice any further IPv6 problems caused by any Microsoft products we'll make sure to let you know so that you can have a look at those too. But until then - the ICS rogue RA problem has been known for a long time now and is very well understood; please don't delay fixing it just because you want to look for other issues too. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gvandeve@cisco.com Tue Apr 12 04:03:15 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39387E0704 for ; Tue, 12 Apr 2011 04:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.394 X-Spam-Level: X-Spam-Status: No, score=-8.394 tagged_above=-999 required=5 tests=[AWL=1.605, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuK6Qnn3me+Y for ; Tue, 12 Apr 2011 04:03:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 7F6A7E06B6 for ; Tue, 12 Apr 2011 04:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=7486; q=dns/txt; s=iport; t=1302606193; x=1303815793; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=yoFMWrKoBlSHKXE1QCDNTdRyLGtspfuILcaUkwH5wCc=; b=jsSSDV1mbVUBW6wPytlLdJ1WfJ3jfaNI0RH6u6SScXGi6JfPVVAg0KxJ E+9bgkhAQPrD11WKJJAk12fuMGWJbaYUbDR0HKHB+l5M4qAMdE07URBzT CrrS5siBuJzrqSIzxxDeiz+fszsEFzH8giHN7it0H0+bxmJ6JDYhDQfpk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJEwpE2Q/khR/2dsb2JhbACmLHekepx3hW4EkVc X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="83223284" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 11:03:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3CB3CPS011864; Tue, 12 Apr 2011 11:03:12 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); Tue, 12 Apr 2011 13:03:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 13:03:10 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv4RPaAwKW3FKbCS76FU3Oxx/og4QAGIvjAACipH5A= References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Templin, Fred L" , X-OriginalArrivalTime: 12 Apr 2011 11:03:12.0046 (UTC) FILETIME=[36D5DCE0:01CBF901] Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 11:03:15 -0000 Many thanks for sharing.=20 In some way I have a feeling that native-v6 should be promoted above ISATAP. ISATAP is tunneling and eventhough its not as bad as 6to4, it is way worse as native v6. Fact is that my affiliation company is using ISATAP right now, and it is part of the=20 migration strategy for implementing IPv6, but we do want to get away from it asap=20 due to a set of disadvantages it includes. My take is that when a new RFC like this would=20 be generated, it will be too late for actual usage because the world and the enterprises=20 have moved forward. All the best, G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: 11 April 2011 20:18 To: v6ops@ietf.org Subject: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Hello, The following should not be construed as a draft, but rather just a set of ideas that might be considered for inclusion in a new or existing draft. Any comments or suggestions? Thanks - Fred fred.l.templin@boeing.com --- cut here --- Introduction ************ Countless end user sites in the Internet today still have predominantly IPv4 infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services. As more and more IPv6-only services are deployed in the Internet, however, end user devices within the site will increasingly require at least basic IPv6 functionality for external access. This pre-draft provides operational guidance for predominantly IPv4 sites in making transitional IPv6 services available without disrupting existing IPv4 services. Characteristics of Existing IPv4 Sites ************************************** Existing end user sites use IPv4 routing and addressing internally for normal IT operations such as filesharing, network printing, e-mail, conferencing and numerous other critical site-internal networking services. Such sites typically have an abundance of public or private IPv4 addresses for internal networking, and are separated from the public Internet by firewalls, packet filtering gateways, proxies, address translators and other site border securing devices. To date, such sites have had little incentive to enable IPv6 services internally [RFC1687]. With the emergence of IPv6-only services within the public Internet, however, existing IPv4 sites will increasingly require a means for enabling client-side IPv6 services so that end user devices within the site can access IPv6 Internet services. Such services must be deployable with minimal configuration and in a fashion that will not cause disruptions to existing IPv4 services within the site. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to-use service that sites can deploy in the near term to meet these reqirements while a longer-term site-wide IPv6 deployment plan is conducted in parallel. Enabling Client-Side IPv6 Services with ISATAP ********************************************** Small sites typically arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP) in the same fashion as for home network users. When the ISP does not yet provide native IPv6 services, it can instead offer a transitional service with native-equivalent capabilities using 6RD [RFC5569][RFC5969]. Large sites typically obtain provider independent IPv6 prefixes from an Internet registry and advertise the prefixes into the IPv6 routing system on their own behalf, i.e., they act as an ISP unto themselves. In both cases, the site can automatically enable ISATAP based IPv6 services by configuring one or more site border routers as ISATAP routers. Each such ISATAP router is added to the Potential Router List (PRL) for the site so that hosts in the network can discover them for default route and prefix auto-configuration purposes. When there are multiple ISATAP site border routers, the routers can advertise the same IPv6 prefix or a different set of IPv6 prefixes of prefix length /64. For example, a first router may advertise 2001:db8:0:0::/64, a second may advertise 2001:db8:0:1::/64, etc. The routers can further be configured to advertise different prefixes to different sets of hosts within the site (e.g., as identified by the host's IPv4 prefix) for the purpose of site partitioning. In all cases, however, the site border routers must take operational measures to avoid routing loops [draft-ietf-v6ops-tunnel-loops]. As a simple mitigation, the site border router can drop any incoming packets that have an IPv4 source or outgoing packets that have an IPv4 destination address of another site border router, e.g., by checking for the address in the site's PRL. ISATAP hosts will automatically discover ISATAP site border routers and configure ISATAP addresses using Stateless Address AutoConfiguration (SLAAC) based on the advertised IPv6 prefixes. In order to provide a simple service that does not interact poorly with existing site topological arrangements, the site can enable client-side only operation so that hosts only use the ISATAP service for accessing IPv6 services on the public Internet, while continuing to use IPv4 services for intra-site communications. In order to maintain a client-side only service, the site should not configure any IPv6 addresses provided by ISATAP within site name service resource records. In this way, intra-site communications will continue to use existing IPv4 networking services instead of ISATAP-served IPv6 services. This arrangement prevents communication failure modes in which a pair of ISATAP hosts are separated by a packet filtering gateway which would prevent direct communications via the tunneled IPv6 service. To further disable host-to-host ISATAP communications within the site, the ISATAP site border routers should advertise their prefixes with the (A,L) flags set to (1,0) in their IPv6 Router Advertisements. In that way, each ISATAP host will autoconfigure an address from the advertised IPv6 prefix and assign it to their ISATAP interface, but they will not assign an IPv6 prefix to the ISATAP interface. Therefore, no two ISATAP hosts will see each other as on-link neighbors, and all IPv6 communications from the hosts will flow through an ISATAP site border router in order to access IPv6 services in the Internet. Migration to Native IPv6 Services ********************************* ISATAP hosts should be configured to prefer native IPv6 services instead of ISATAP whenever available. As the site transitions its internal routers and links to use IPv6 natively, hosts will naturally begin to receive native IPv6 router advertisments and will begin using the native IPv6 service instead of ISATAP. As more and more native IPv6 service is enabled in the site, IPv6 addresses can be entered into site name service resource records to enable intra-site IPv6 service discovery. In that way, predominantly IPv4 sites will begin to operate a parallel native IPv6 service, and legacy IPv4 services will gradually be phased out. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Apr 12 08:53:46 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F82FE07CB for ; Tue, 12 Apr 2011 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgP+p0uIHzB4 for ; Tue, 12 Apr 2011 08:53:45 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfc.amsl.com (Postfix) with ESMTP id 352CFE07AE for ; Tue, 12 Apr 2011 08:53:45 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3CFraai021031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 10:53:37 -0500 (CDT) 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 p3CFraPO005096; Tue, 12 Apr 2011 08:53:36 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3CFra2j005085 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 08:53:36 -0700 (PDT) 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, 12 Apr 2011 08:53:36 -0700 From: "Templin, Fred L" To: "Gunter Van de Velde (gvandeve)" , "v6ops@ietf.org" Date: Tue, 12 Apr 2011 08:53:35 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv4RPaAwKW3FKbCS76FU3Oxx/og4QAGIvjAACipH5AACXBnMA== Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.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 Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:53:46 -0000 Hi Gunter,=20 > -----Original Message----- > From: Gunter Van de Velde (gvandeve) [mailto:gvandeve@cisco.com]=20 > Sent: Tuesday, April 12, 2011 4:03 AM > To: Templin, Fred L; v6ops@ietf.org > Subject: RE: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft) >=20 > Many thanks for sharing.=20 >=20 > In some way I have a feeling that native-v6 should be promoted above > ISATAP. Yes, I said that - thanks for confirming. This is not the only proposed way of operating ISATAP, but within the framework of this specific proposal an automatic sunset of ISATAP is part of the long-term plan. > ISATAP is tunneling and eventhough its not as bad as 6to4, it is way > worse as native v6. In this proposal, ISATAP is a way to get out of an enterprise network in order to access IPv6 services in the public Internet. That sort of access is likely to go through deep packet inspection and firewalling anyway, so any performance gains for native IPv6 over tunneled IPv6 are likely to be lost at the site borders anyway. Also in this proposal, unless the enterprise IT staff wants to pull off the heroic effort of turning up native IPv6 on all links, routers, hosts, applications, etc., they are still good to go with IPv4 for continued support of enterprise-interior services. Can you make a good case that it is worth the investment of overhauling the entire IT infrastructure just to claim support of native IPv6 everywhere? For example, is it going to make the end user experience better in some way? =20 =20 > Fact is that my affiliation company is using ISATAP right=20 > now, and it is > part of the=20 > migration strategy for implementing IPv6, but we do want to get away > from it asap=20 > due to a set of disadvantages it includes. Well, if this proposal were implemented then any IPv6 communications would be for the purpose of accessing services outside of the site, and those would be going through a site border firewall/proxy/etc. "speed-bump" anyway. Do you think native is going to make things significantly better if the dominating factor in performance is the penalty for crossing the site border in the first place?=20 > My take is that when a new > RFC like this would=20 > be generated, it will be too late for actual usage because=20 > the world and > the enterprises=20 > have moved forward. That sounds like a good reason to have this text in a near-term document rather than a longer-term document. Especially since it would be nice to have this in place before World IPv6 Day. Thanks - Fred fred.l.templin@boeing.com =20 > All the best, > G/ >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Templin, Fred L > Sent: 11 April 2011 20:18 > To: v6ops@ietf.org > Subject: [v6ops] Operational Guidance for IPv6 Deployment in > Predominantly IPv4 Sites - (pre-draft) >=20 > Hello, >=20 > The following should not be construed as a draft, but > rather just a set of ideas that might be considered > for inclusion in a new or existing draft. Any > comments or suggestions? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > --- cut here --- >=20 > Introduction > ************ > Countless end user sites in the Internet today still have > predominantly IPv4 infrastructures. These sites range in > size from small home/office networks to large corporate > enterprise networks, but share the commonality that IPv4 > continues to provide satisfactory internal routing and > addressing services. As more and more IPv6-only services > are deployed in the Internet, however, end user devices > within the site will increasingly require at least basic > IPv6 functionality for external access. This pre-draft > provides operational guidance for predominantly IPv4 sites > in making transitional IPv6 services available without > disrupting existing IPv4 services. >=20 > Characteristics of Existing IPv4 Sites > ************************************** > Existing end user sites use IPv4 routing and addressing > internally for normal IT operations such as filesharing, > network printing, e-mail, conferencing and numerous other > critical site-internal networking services. Such sites > typically have an abundance of public or private IPv4 > addresses for internal networking, and are separated from > the public Internet by firewalls, packet filtering gateways, > proxies, address translators and other site border securing > devices. To date, such sites have had little incentive to > enable IPv6 services internally [RFC1687]. >=20 > With the emergence of IPv6-only services within the public > Internet, however, existing IPv4 sites will increasingly > require a means for enabling client-side IPv6 services so > that end user devices within the site can access IPv6 > Internet services. Such services must be deployable with > minimal configuration and in a fashion that will not cause > disruptions to existing IPv4 services within the site. The > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) > [RFC5214] provides a simple-to-use service that sites can > deploy in the near term to meet these reqirements while a > longer-term site-wide IPv6 deployment plan is conducted > in parallel. >=20 > Enabling Client-Side IPv6 Services with ISATAP > ********************************************** > Small sites typically arrange to obtain public IPv6 prefixes > from an Internet Service Provider (ISP) in the same fashion > as for home network users. When the ISP does not yet provide > native IPv6 services, it can instead offer a transitional > service with native-equivalent capabilities using 6RD > [RFC5569][RFC5969]. Large sites typically obtain provider > independent IPv6 prefixes from an Internet registry and > advertise the prefixes into the IPv6 routing system on their > own behalf, i.e., they act as an ISP unto themselves. >=20 > In both cases, the site can automatically enable ISATAP > based IPv6 services by configuring one or more site border > routers as ISATAP routers. Each such ISATAP router is added > to the Potential Router List (PRL) for the site so that > hosts in the network can discover them for default route > and prefix auto-configuration purposes. >=20 > When there are multiple ISATAP site border routers, the > routers can advertise the same IPv6 prefix or a different > set of IPv6 prefixes of prefix length /64. For example, > a first router may advertise 2001:db8:0:0::/64, a second > may advertise 2001:db8:0:1::/64, etc. The routers can > further be configured to advertise different prefixes > to different sets of hosts within the site (e.g., as > identified by the host's IPv4 prefix) for the purpose > of site partitioning. In all cases, however, the site > border routers must take operational measures to avoid > routing loops [draft-ietf-v6ops-tunnel-loops]. As a > simple mitigation, the site border router can drop any > incoming packets that have an IPv4 source or outgoing > packets that have an IPv4 destination address of another > site border router, e.g., by checking for the address > in the site's PRL. >=20 > ISATAP hosts will automatically discover ISATAP site border > routers and configure ISATAP addresses using Stateless > Address AutoConfiguration (SLAAC) based on the advertised > IPv6 prefixes. In order to provide a simple service that > does not interact poorly with existing site topological > arrangements, the site can enable client-side only operation > so that hosts only use the ISATAP service for accessing IPv6 > services on the public Internet, while continuing to use > IPv4 services for intra-site communications. >=20 > In order to maintain a client-side only service, the site > should not configure any IPv6 addresses provided by ISATAP > within site name service resource records. In this way, > intra-site communications will continue to use existing > IPv4 networking services instead of ISATAP-served IPv6 > services. This arrangement prevents communication failure > modes in which a pair of ISATAP hosts are separated by a > packet filtering gateway which would prevent direct > communications via the tunneled IPv6 service. >=20 > To further disable host-to-host ISATAP communications > within the site, the ISATAP site border routers should > advertise their prefixes with the (A,L) flags set to (1,0) > in their IPv6 Router Advertisements. In that way, each > ISATAP host will autoconfigure an address from the > advertised IPv6 prefix and assign it to their ISATAP > interface, but they will not assign an IPv6 prefix to > the ISATAP interface. Therefore, no two ISATAP hosts will > see each other as on-link neighbors, and all IPv6 > communications from the hosts will flow through an ISATAP > site border router in order to access IPv6 services in > the Internet. >=20 > Migration to Native IPv6 Services > ********************************* > ISATAP hosts should be configured to prefer native IPv6 > services instead of ISATAP whenever available. As the site > transitions its internal routers and links to use IPv6 > natively, hosts will naturally begin to receive native > IPv6 router advertisments and will begin using the > native IPv6 service instead of ISATAP. As more and > more native IPv6 service is enabled in the site, IPv6 > addresses can be entered into site name service resource > records to enable intra-site IPv6 service discovery. In > that way, predominantly IPv4 sites will begin to operate > a parallel native IPv6 service, and legacy IPv4 services > will gradually be phased out. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From fred@cisco.com Tue Apr 12 10:28:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 774DBE0886 for ; Tue, 12 Apr 2011 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.344 X-Spam-Level: X-Spam-Status: No, score=-109.344 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpBXAYFouILf for ; Tue, 12 Apr 2011 10:28:56 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id E2DBFE0881 for ; Tue, 12 Apr 2011 10:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=271; q=dns/txt; s=iport; t=1302629335; x=1303838935; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=ObxsjZgC58SpjZhwUKZqBVCA2yoJVBrQ4iM0H2IXuzQ=; b=gaVsAdu9GBZO2rXdJ9KD4E7ohvBnoomnTLRimf3HiJhXjqZGt0O5VTVS UCPnYdRscfRjpJVvCYJls4X+zawtFwGnBAUOs91f9a+XpSYy0lL6dEwKW Fi7GTIVPrR2pIzplidgVpAtAk7WwX2iceBxnWJv0cCOUugzHcym3gykxQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQHAMKKpE2rRDoG/2dsb2JhbACYVo0pd6VMnQSFbgSFW4gHg24 X-IronPort-AV: E=Sophos;i="4.64,197,1301875200"; d="scan'208";a="335603645" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 17:28:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3CHSYer020428; Tue, 12 Apr 2011 17:28:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 12 Apr 2011 10:28:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 12 Apr 2011 10:28:40 -0700 From: Fred Baker Date: Tue, 12 Apr 2011 10:28:21 -0700 Message-Id: <30C16CDC-9A24-460A-A2D3-54A2DB25202C@cisco.com> To: draft-fling-v6ops-hybrid-bridged-routed@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: [v6ops] draft-fling-v6ops-hybrid-bridged-routed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 17:28:56 -0000 We said at the recent IETF meeting that documents discussed f2f should = first achieve traction on the mailing list. You posted a new draft. May = I invite you to explain what you're interested in to the community, so = the community can decide how best to proceed?= From fred@cisco.com Tue Apr 12 11:32:44 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4A1F7E07E4 for ; Tue, 12 Apr 2011 11:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.012 X-Spam-Level: X-Spam-Status: No, score=-110.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7TwmPANcvOk for ; Tue, 12 Apr 2011 11:32:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 5E169E067F for ; Tue, 12 Apr 2011 11:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1485; q=dns/txt; s=iport; t=1302633163; x=1303842763; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=s5meiLdpKokq5UBY2AHZPJWpgfxUppNgrqI808QSB7M=; b=LCKHiRkRyIqKTCN7xeKslVqrAQNhwyvkF7ug31+KV/h6Y0lajR5VnSYU srduPiI3s+m1vMCd7cV4M/Y3HQhc1DG3IgrmCWzjxv85vB8SOtAxBAmdN ts06cQki95ENLhEQYLqob2SrfrNAQv99hsQ2Idk03QeatCDUgmzZBRXYe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIaZpE2rRDoH/2dsb2JhbACmAHeIep0knQSFbgSFW4gHg24 X-IronPort-AV: E=Sophos;i="4.64,197,1301875200"; d="scan'208";a="294766373" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 18:32:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3CIWBU4016123; Tue, 12 Apr 2011 18:32:17 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 12 Apr 2011 11:32:17 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 12 Apr 2011 11:32:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 12 Apr 2011 11:32:01 -0700 Message-Id: References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:32:44 -0000 On Apr 8, 2011, at 9:32 AM, james woodyatt wrote: > On Apr 8, 2011, at 6:55 AM, fred@cisco.com wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/draft-fling-v6ops-hybrid-bridged-routed-00.txt. = Please take a look at it and comment. >=20 > I have reviewed this draft. My only comment is editorial. >=20 > This draft only applies to CPE routers that have ATM interfaces. The = title should be changed to reflect that, and I recommend prepending the = phrase "In ATM networks," to the first sentence of the Introduction = section. The authors will correct me, but I think they're talking about DSL = networks, which have historically been ATM-based. They generally come = out to an Ethernet interface, and use the bridged mode to get traffic to = that interface. I do question the implication there - I have no problem with someone = implementing a residential CPE as a bridge, but it has direct meaning = upstream, and it's a different service for the user than we usually = suggest. The cpe-router drafts, both of them, have specifically looked = at the CPE as an IPv6 router. So - question for the assembled throngs - = what's your opinion of a CPE that runs as an Ethernet switch? > -- > 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 swmike@swm.pp.se Tue Apr 12 11:48:40 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A389DE084F for ; Tue, 12 Apr 2011 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNCJPb5ZzyZz for ; Tue, 12 Apr 2011 11:48:40 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id EDB11E084B for ; Tue, 12 Apr 2011 11:48:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AF8609E; Tue, 12 Apr 2011 20:48:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AD3429A; Tue, 12 Apr 2011 20:48:37 +0200 (CEST) Date: Tue, 12 Apr 2011 20:48:37 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker In-Reply-To: Message-ID: References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:48:40 -0000 On Tue, 12 Apr 2011, Fred Baker wrote: > I do question the implication there - I have no problem with someone > implementing a residential CPE as a bridge, but it has direct meaning > upstream, and it's a different service for the user than we usually > suggest. The cpe-router drafts, both of them, have specifically looked > at the CPE as an IPv6 router. So - question for the assembled throngs - > what's your opinion of a CPE that runs as an Ethernet switch? I've seen this in DSL deployments where rfc1483bridged is run over ATM, basically making the DSL transport pure L2 ethernet (ethernet uplinked DSLAM, ETHoATMoDSL on the access line, the modem is a media converter and has an ethernet downlink to the LAN which is bridged all the way to the uplink of the DSLAM. The CPE in this case wouldn't do much, and the DSLAM would be a SAVI-WG type device which would need to do SAVI-WG functionality. The CPE in this case wouldn't do much at all apart from bridging the packets. The hybrid problem might come in all the cases we've been looking into though, but I would really like to encourage ISPs to have a routed CPE anyway. Having your PE router participate in the home routing domain doing SLAAC has some serious scaling implications that can get ugly really quickly. The simple handoff with LL only (or single DHCPv6 /128 WAN address) for the CPE, and do DHCPv6-PD to it, seems a lot more clean and scalable. -- Mikael Abrahamsson email: swmike@swm.pp.se From dougb@dougbarton.us Tue Apr 12 12:20:33 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3F047E0887 for ; Tue, 12 Apr 2011 12:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7eLNwvn9a+w for ; Tue, 12 Apr 2011 12:20:32 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfc.amsl.com (Postfix) with ESMTP id 4D78EE0824 for ; Tue, 12 Apr 2011 12:20:32 -0700 (PDT) Received: (qmail 6387 invoked by uid 399); 12 Apr 2011 19:20:26 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 Apr 2011 19:20:26 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DA4A5FA.9000600@dougbarton.us> Date: Tue, 12 Apr 2011 12:20:26 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> In-Reply-To: <4D9D6B50.4020508@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:20:33 -0000 On 4/7/2011 12:44 AM, Brian E Carpenter wrote: > But how will that affect people who are happily using 6to4? Please don't forget > that many 6to4 sessions are entirely successful. I really don't see how > we could legitimately mess those people up to eliminate the cases that don't > work. The questions we need to be looking at are: 1. What benefits are gained from successful 6to4 connections? 2. What costs are associated with unsuccessful ones? For those who really legitimately care about IPv6 access and have a "need" to do it, there are other tunneling methods available that are at least as good, if not better. So disabling 6to4 would not seriously hamper people in the first category, although it would create some inconvenience for them in terms of having to switch. On the other hand, the unsuccessful 6to4 connections have a very high cost in that they are a major contributing factor causing content providers to be hesitant to deploy real IPv6. One could also argue that the presence of 6to4 has created a reduced incentive for ISPs as well, but I don't place a lot of weight on that argument. So, benefits, nearly zero; costs, huge. To me that's a pretty clear cut decision point. Stick a fork in it, it's done. 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 Jean-Francois.TremblayING@videotron.com Tue Apr 12 12:39:10 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7F359E0893; Tue, 12 Apr 2011 12:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgypRxEgY9zP; Tue, 12 Apr 2011 12:39:09 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfc.amsl.com (Postfix) with ESMTP id 6660CE0824; Tue, 12 Apr 2011 12:39:09 -0700 (PDT) In-Reply-To: To: fred@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Tue, 12 Apr 2011 15:38:58 -0400 X-MIMETrack: Serialize by Router on DOMMTL11/SRV/GVL(Release 7.0.2FP1|January 10, 2007) at 2011-04-12 15:38:59, Serialize complete at 2011-04-12 15:38:59 Content-Type: multipart/alternative; boundary="=_alternative 006BF03785257870_=" Cc: IPv6 Ops WG , v6ops-bounces@ietf.org Subject: Re: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:39:10 -0000 Message en plusieurs parties au format MIME --=_alternative 006BF03785257870_= Content-Type: text/plain; charset="US-ASCII" On Apr 8, 2011, at 9:32 AM, james woodyatt wrote: > On Apr 8, 2011, at 6:55 AM, fred@cisco.com wrote: >> A new draft has been posted, at http://tools.ietf.org/draft-fling-v6ops-hybrid-bridged-routed-00.txt. Please take a look at it and comment. > > I do question the implication there - I have no problem with someone implementing > a residential CPE as a bridge, but it has direct meaning upstream, and it's a different > service for the user than we usually suggest. The cpe-router drafts, both of them, > have specifically looked at the CPE as an IPv6 router. So - question for the assembled > throngs - what's your opinion of a CPE that runs as an Ethernet switch? IMHO, this seems to be more of a confusion about terminology than an actual debate about the architecture. In CableLabish, the cable modem (CM) acts as a bridge and the CPE is any ethernet device requesting an address behind that modem. Even if the cable modem implements an embedded router, it is still conceptually separated from the modem. As Fred points out, draft-ietf-v6ops-ipv6-cpe-router only considers a CPE from the routed device point of view. Reading draft hybrid-bridged-routed, the definition of the CPE is different here. The equipment described here as the CPE in "Bridged Mode" rather acts as a dsl modem, in a way similar to the cable modem in the CableLabs model. Correct me if I'm wrong here DSL people, but isn't the "Routed Mode" described in hybrid-bridged-routed actually a "Bridge Mode" device with a routed device in the same physical box? I believe there is some value, from a specification point of view, in splitting the bridging function from the routing function. Whether they are implemented in the same box or not then becomes an implementation detail. The important thing here is not to call them both "CPE". Is there a need for a new draft describing this terminology in details? /JF --=_alternative 006BF03785257870_= Content-Type: text/html; charset="US-ASCII"
<inline>



On Apr 8, 2011, at 9:32 AM, james woodyatt wrote:
> On Apr 8, 2011, at 6:55 AM, fred@cisco.com wrote:
>> A new draft has been posted, at http://tools.ietf.org/draft-fling-v6ops-hybrid-bridged-routed-00.txt. Please take a look at it and comment.
>
> I do question the implication there - I have no problem with someone implementing
> a residential CPE as a bridge, but it has direct meaning upstream, and it's a different
> service for the user than we usually suggest. The cpe-router drafts, both of them,
> have specifically looked at the CPE as an IPv6 router. So - question for the assembled
> throngs - what's your opinion of a CPE that runs as an Ethernet switch?
IMHO, this seems to be more of a confusion about terminology than an actual debate about
the architecture. In CableLabish, the cable modem (CM) acts as a bridge and the CPE is
any ethernet device requesting an address behind that modem. Even if the cable modem
implements an embedded router, it is still conceptually separated from the modem.
As Fred points out, draft-ietf-v6ops-ipv6-cpe-router only considers a CPE from the
routed device point of view.

Reading draft hybrid-bridged-routed, the definition of the CPE is different here. The
equipment described here as the CPE in "Bridged Mode" rather acts as a dsl modem,
in a way similar to the cable modem in the CableLabs model.

Correct me if I'm wrong here DSL people, but isn't the "Routed Mode" described in
hybrid-bridged-routed actually a "Bridge Mode" device with a routed device in the
same physical box?

I believe there is some value, from a specification point of view, in
splitting the bridging function from the routing function. Whether they are
implemented in the same box or not then becomes an implementation detail.
The important thing here is not to call them both "CPE". Is there a need for
a new draft describing this terminology in details?

/JF
--=_alternative 006BF03785257870_=-- From swmike@swm.pp.se Tue Apr 12 12:43:17 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63D4EE0824; Tue, 12 Apr 2011 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-qfqjZc2JE5; Tue, 12 Apr 2011 12:43:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id C2301E080C; Tue, 12 Apr 2011 12:43:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 01A079E; Tue, 12 Apr 2011 21:43:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F28B19A; Tue, 12 Apr 2011 21:43:15 +0200 (CEST) Date: Tue, 12 Apr 2011 21:43:15 +0200 (CEST) From: Mikael Abrahamsson To: Jean-Francois.TremblayING@videotron.com In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , v6ops-bounces@ietf.org Subject: Re: [v6ops] new draft: draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:43:17 -0000 On Tue, 12 Apr 2011, Jean-Francois.TremblayING@videotron.com wrote: > Correct me if I'm wrong here DSL people, but isn't the "Routed Mode" > described in hybrid-bridged-routed actually a "Bridge Mode" device with > a routed device in the same physical box? Yes, there are plenty of CPEs that'll do "rfc1483bridge" and into that bridge domain, have a IP interface. This is as you say, conceptually like a bridge (from ETHoATM to ETH) and then internally having a router connected to it. > The important thing here is not to call them both "CPE". Is there a need > for a new draft describing this terminology in details? I agree. For me the ATM bridge is a CPE media converter, not a CPE router. They are both CPEs though (Customer Premises Equipment). -- Mikael Abrahamsson email: swmike@swm.pp.se From randy@psg.com Tue Apr 12 12:52:04 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16F09E07E6 for ; Tue, 12 Apr 2011 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhFRQq9NB4aY for ; Tue, 12 Apr 2011 12:52:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 6488DE07C4 for ; Tue, 12 Apr 2011 12:52:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9jd3-0003pc-1l; Tue, 12 Apr 2011 19:52:02 +0000 Date: Tue, 12 Apr 2011 12:52:09 -0700 Message-ID: From: Randy Bush To: "Gunter Van de Velde (gvandeve)" In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.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 Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:52:04 -0000 > In some way I have a feeling that native-v6 should be promoted above > ISATAP. ISATAP is tunneling and eventhough its not as bad as 6to4, it > is way worse as native v6. +1 From bs7652@att.com Tue Apr 12 12:57:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D8DBE084A for ; Tue, 12 Apr 2011 12:57:12 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCfYneCmvFoQ for ; Tue, 12 Apr 2011 12:57:11 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfc.amsl.com (Postfix) with ESMTP id 1F3B4E07C4 for ; Tue, 12 Apr 2011 12:57:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1302638230!417339!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6288 invoked from network); 12 Apr 2011 19:57:10 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Apr 2011 19:57:10 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3CJu9TW005912; Tue, 12 Apr 2011 15:56:10 -0400 Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p3CJu5Lx005851; Tue, 12 Apr 2011 15:56:05 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:56:47 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:56:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 15:56:44 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1B5DBE3B@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt Thread-Index: Acv5QAF3iJ9vGUl7TZa0I23V9h6bqQAAmU+w References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> From: "STARK, BARBARA H (ATTSI)" To: "Fred Baker" , "james woodyatt" X-OriginalArrivalTime: 12 Apr 2011 19:56:47.0027 (UTC) FILETIME=[C1404830:01CBF94B] Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:57:12 -0000 I have to say that I'm a bit confused as to who the audience is for this draft, and whether there exist members of that audience who are asking for guidance in this area. It would appear that the draft may be targeted at "Provider Edge" providers (aka access providers). But I'm not aware of any such providers who are requesting guidance in this area. At least not from IETF. Is China Telecom asking for such guidance? Or are they wanting to give guidance to others (in which case, others need to be wanting such guidance for a draft to make sense)? It's true that there exist a great number of "bridge modems" for both DOCSIS and DSL. These bridge Ethernet MAC between DOCSIS or (ATM)/DSL and Ethernet PHY. They will continue to exist, and there's nothing wrong with them (unless your access provider changes the access PHY ;) ). They won't break in the presence of IPv6, because they truly don't care what's above the Ethernet MAC layer. In early years, people attached a single computer to the Ethernet PHY side of the bridge, and the computer got IPv4 connectivity to/through the access provider. When people got more computers, they put in a router (IPv4, with NAT), because many access providers (especially in the US) would only hand out a single IPv4 address, and the router solved that problem. Once the access provider supports IPv6, users can swap out the old IPv4-only router with a brand new "CE router" that does IPv4 and IPv6. The fact that a bridge exists in-between is irrelevant. The user with a single computer behind a bridge might be a little more challenged with IPv6, if the access provider is using the "unnumbered model" and expecting IA_PD to be used. But this is easily solved by putting in a router.=20 In Europe (I'm not familiar with Asia), due to some interesting regulations, some DSL access providers support bridged "residential gateways" (RGs). These devices acquire an IPv4 address for themselves (for management and host applications like maybe VoIP in the RG), but bridge traffic to the home network. The user could put in their own home network router, that could acquire an IPv4 address. Which is to say, bridging exists all over the world, with DSL and DOCSIS. But the existence of bridging doesn't necessarily cause the problem that this draft seems to be trying to address. At its root, this draft seems to be talking about an access network that wants to support both hosts and routers. This could occur for a variety of reasons. For example, it could be an LTE network that has many host devices, but where there are also many people who slap a PC card into a router and use LTE to connect their home network. Or it could be that the access provider does still want to support that single computer that I mentioned above, in addition to routers. Some access providers have also discussed this in conjunction with PPPoE service (for access networks that use PPPoE above Ethernet to access IPv6 or IPv6 and IPv4), where the device connecting with PPPoE might be a computer or game console, or it might be a CE router. The concern I've generally heard, is that access providers want to provide hosts with an address via SLAAC, but they want to give routers an address either through IA_NA or "unnumbered" from the IA_PD pool. And if a CE router sees a SLAAC prefix being advertised in the RA, it's likely to do SLAAC. That is what it is. If access providers want a single IPv6 access network to support both hosts and CE routers, then there are decisions they have to make about how to set it up.=20 The thing is, I haven't heard any providers asking someone (IETF or BBF) to tell them how to do this. Barbara > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred Baker > Sent: Tuesday, April 12, 2011 2:32 PM > To: james woodyatt > Cc: IPv6 Ops WG > Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed- > 00.txt >=20 >=20 > On Apr 8, 2011, at 9:32 AM, james woodyatt wrote: >=20 > > On Apr 8, 2011, at 6:55 AM, fred@cisco.com wrote: > >> > >> A new draft has been posted, at http://tools.ietf.org/draft-fling- > v6ops-hybrid-bridged-routed-00.txt. Please take a look at it and > comment. > > > > I have reviewed this draft. My only comment is editorial. > > > > This draft only applies to CPE routers that have ATM interfaces. The > title should be changed to reflect that, and I recommend prepending the > phrase "In ATM networks," to the first sentence of the Introduction > section. >=20 > The authors will correct me, but I think they're talking about DSL > networks, which have historically been ATM-based. They generally come > out to an Ethernet interface, and use the bridged mode to get traffic > to that interface. >=20 > I do question the implication there - I have no problem with someone > implementing a residential CPE as a bridge, but it has direct meaning > upstream, and it's a different service for the user than we usually > suggest. The cpe-router drafts, both of them, have specifically looked > at the CPE as an IPv6 router. So - question for the assembled throngs - > what's your opinion of a CPE that runs as an Ethernet switch? >=20 > > -- > > james woodyatt > > member of technical staff, core os networking > > > > > > > > _______________________________________________ > > 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 shemant@cisco.com Tue Apr 12 12:58:16 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E744E08C4 for ; Tue, 12 Apr 2011 12:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et7UKMwaqCHZ for ; Tue, 12 Apr 2011 12:58:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfc.amsl.com (Postfix) with ESMTP id AEA5DE07C4 for ; Tue, 12 Apr 2011 12:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=820; q=dns/txt; s=iport; t=1302638295; x=1303847895; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gpVtI+FpUr959xMSwSpDy+SEZp+VqlvbdRHWQj9A34U=; b=dVmEw57oWRZFCihHB9Yv0zPzDHCMfbzWZaQ3TDL4zXhXo1Ztu6VrXq7/ dlHCHq8JGJAAvtfNuq0NSbKPVnzMM/MJpf03mxsTeweFxfjR3e1WJWGlJ /Zeq8vf10IOCcAc0s8AoPpq642djQdeNxcTZvaMRBXd7o3xJpgyr35ulX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAJ6upE2tJXHA/2dsb2JhbACYGY1od4h6nV2cf4VuBIVbi3w X-IronPort-AV: E=Sophos;i="4.64,198,1301875200"; d="scan'208";a="282773740" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-4.cisco.com with ESMTP; 12 Apr 2011 19:58:13 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p3CJwDeD019379; Tue, 12 Apr 2011 19:58:13 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 14:58:13 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 14:58:12 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDBF5@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Operational Guidance for IPv6 Deploymentin Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5SyHUbfaAnZF0SoO6XiZ1OVEtVAAAKeIQ References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com><4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> From: "Hemant Singh (shemant)" To: "Randy Bush" , "Gunter Van de Velde (gvandeve)" X-OriginalArrivalTime: 12 Apr 2011 19:58:13.0680 (UTC) FILETIME=[F4E67B00:01CBF94B] Cc: v6ops@ietf.org Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymentin Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:58:16 -0000 +1. I already sent email to v6ops in the past week or two asking Fred T. a question that a home LAN can do native ipv4 and native ipv4 and thus why does the home need ISATAP. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, April 12, 2011 3:52 PM To: Gunter Van de Velde (gvandeve) Cc: v6ops@ietf.org Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymentin Predominantly IPv4 Sites - (pre-draft) > In some way I have a feeling that native-v6 should be promoted above > ISATAP. ISATAP is tunneling and eventhough its not as bad as 6to4, it > is way worse as native v6. +1 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Apr 12 13:18:43 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15423E091A for ; Tue, 12 Apr 2011 13:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyoFEgLlXq7H for ; Tue, 12 Apr 2011 13:18:42 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfc.amsl.com (Postfix) with ESMTP id 6CD89E090C for ; Tue, 12 Apr 2011 13:18:42 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3CKIcnE024603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 15:18:38 -0500 (CDT) 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 p3CKIb9l015611; Tue, 12 Apr 2011 13:18:37 -0700 (PDT) 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 p3CKIb2r015590 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 13:18:37 -0700 (PDT) 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, 12 Apr 2011 13:18:37 -0700 From: "Templin, Fred L" To: Randy Bush , "Gunter Van de Velde (gvandeve)" Date: Tue, 12 Apr 2011 13:18:35 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5SxiDqhRdm4YdRHC/plO1dKNWlQAAykkg Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com><4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:18:43 -0000 Randy, You are quoting out of context. Please go back and read the rest of Gunter's original message and my reply in their entirety. Then, if you are inclined, please make a case as to why major enterprise networks that have long been satisfied with IPv4 for enterprise-internal networking services should make the jump to ubiquitous native IPv6. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Tuesday, April 12, 2011 12:52 PM > To: Gunter Van de Velde (gvandeve) > Cc: Templin, Fred L; v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft) >=20 > > In some way I have a feeling that native-v6 should be promoted above > > ISATAP. ISATAP is tunneling and eventhough its not as bad=20 > as 6to4, it > > is way worse as native v6. >=20 > +1 > = From Fred.L.Templin@boeing.com Tue Apr 12 13:25:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D1A9AE091F for ; Tue, 12 Apr 2011 13:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh+8GH8rytPX for ; Tue, 12 Apr 2011 13:25:55 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id 0D8F4E090C for ; Tue, 12 Apr 2011 13:25:54 -0700 (PDT) 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 p3CKPow0012744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 13:25:51 -0700 (PDT) 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 p3CKPo7p008732; Tue, 12 Apr 2011 13:25:50 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3CKPn2M008714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 13:25:50 -0700 (PDT) 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, 12 Apr 2011 13:25:49 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , Randy Bush , "Gunter Van de Velde (gvandeve)" Date: Tue, 12 Apr 2011 13:25:49 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5SyHUbfaAnZF0SoO6XiZ1OVEtVAAAKeIQAADdHLA= Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com><4269EA985EACD2498 7D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDBF5@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDBF5@XMB-RCD-109.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" Subject: Re: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:25:56 -0000 Hemant,=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Hemant Singh (shemant) > Sent: Tuesday, April 12, 2011 12:58 PM > To: Randy Bush; Gunter Van de Velde (gvandeve) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for=20 > IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) >=20 > +1. I already sent email to v6ops in the past week or two asking Fred > T. a question that a home LAN can do native ipv4 and native ipv4 and > thus why does the home need ISATAP. You have taken Randy's out-of-context quote and spun it even further out of context. We have moved on to a different page now; please go back and re-read the latest posts to get proper context: http://www.ietf.org/mail-archive/web/v6ops/current/msg08276.html http://www.ietf.org/mail-archive/web/v6ops/current/msg08281.html http://www.ietf.org/mail-archive/web/v6ops/current/msg08282.html Thanks - Fred fred.l.templin@boeing.com > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Randy Bush > Sent: Tuesday, April 12, 2011 3:52 PM > To: Gunter Van de Velde (gvandeve) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymentin > Predominantly IPv4 Sites - (pre-draft) >=20 > > In some way I have a feeling that native-v6 should be promoted above > > ISATAP. ISATAP is tunneling and eventhough its not as bad=20 > as 6to4, it > > is way worse as native v6. >=20 > +1 > _______________________________________________ > 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 shemant@cisco.com Tue Apr 12 13:31:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C287E0936 for ; Tue, 12 Apr 2011 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu4FheCREd4X for ; Tue, 12 Apr 2011 13:31:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 5850AE0935 for ; Tue, 12 Apr 2011 13:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2489; q=dns/txt; s=iport; t=1302640266; x=1303849866; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Q9EP+wAnh/90WY4zEBnsNK+69pPTeJFHdIjQSdhlKp4=; b=Hdb1OpriLW9Dgnn1XGfxLEaimwkLmDkMj1Gpnu486n/YSp5IVWc4O3lB /BXIcljHaZY6sWhbmqkQ2qEPidp2m65UEV2TiSSaadHfh+AJIEf/6eLzW kefgrB7kvSBu329L8g/7VNj44aIzUCsRKzM2yR9ODuKU9fmcxHsf1iktd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAIu1pE2tJV2a/2dsb2JhbACYGY1od4h6nWqdB4VuBIVbi3w X-IronPort-AV: E=Sophos;i="4.64,199,1301875200"; d="scan'208";a="294860678" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 20:31:05 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CKV54Y020444; Tue, 12 Apr 2011 20:31:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:31:05 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 15:31:03 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDC32@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5SyHUbfaAnZF0SoO6XiZ1OVEtVAAAKeIQAADdHLAAADD3cA== References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com><4269EA985EACD24987D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDBF5@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "Randy Bush" , "Gunter Van de Velde (gvandeve)" X-OriginalArrivalTime: 12 Apr 2011 20:31:05.0096 (UTC) FILETIME=[8BF4B080:01CBF950] Cc: v6ops@ietf.org Subject: Re: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:31:07 -0000 Fred, Thanks for the pointers to the other messages. When I get a chance, will go thru the details in the URLs provided and get back to you. But I still reiterate my original point which was that is one has multiple IPv6 subnets in the home LAN why not use routing for native IPv6 and IPv4?=20 Hemant -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Tuesday, April 12, 2011 4:26 PM To: Hemant Singh (shemant); Randy Bush; Gunter Van de Velde (gvandeve) Cc: v6ops@ietf.org Subject: RE: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) Hemant,=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Hemant Singh (shemant) > Sent: Tuesday, April 12, 2011 12:58 PM > To: Randy Bush; Gunter Van de Velde (gvandeve) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for=20 > IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) >=20 > +1. I already sent email to v6ops in the past week or two asking Fred > T. a question that a home LAN can do native ipv4 and native ipv4 and > thus why does the home need ISATAP. You have taken Randy's out-of-context quote and spun it even further out of context. We have moved on to a different page now; please go back and re-read the latest posts to get proper context: http://www.ietf.org/mail-archive/web/v6ops/current/msg08276.html http://www.ietf.org/mail-archive/web/v6ops/current/msg08281.html http://www.ietf.org/mail-archive/web/v6ops/current/msg08282.html Thanks - Fred fred.l.templin@boeing.com > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Randy Bush > Sent: Tuesday, April 12, 2011 3:52 PM > To: Gunter Van de Velde (gvandeve) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymentin > Predominantly IPv4 Sites - (pre-draft) >=20 > > In some way I have a feeling that native-v6 should be promoted above > > ISATAP. ISATAP is tunneling and eventhough its not as bad=20 > as 6to4, it > > is way worse as native v6. >=20 > +1 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From ichiroumakino@gmail.com Tue Apr 12 13:34:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7FB9E093C for ; Tue, 12 Apr 2011 13:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN27Hru2XQsW for ; Tue, 12 Apr 2011 13:34:17 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 31BC9E091E for ; Tue, 12 Apr 2011 13:34:17 -0700 (PDT) Received: by ewy19 with SMTP id 19so2567155ewy.31 for ; Tue, 12 Apr 2011 13:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=LQ+FMclKFZ1XexrM0WAeKPwpc6ck/yO/no0fBwUTZf0=; b=T1+RjsKtiHD9lAuWTFQANT+8lfV6AsXaTv8BnDXPZOx4bKHb2ebiLP877ybhxcbWo7 ELJzuHOa4SZOx9DYY60I+uVjycNSgqCIfmNHESkdJ3CpLBgADxqpaL7TgccmR0Rl1xQM ZpsN4Qc9kkJWWeQOgwiOvNKiTzRrxKkNj7vf4= 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=hKNFqq+sLY16UbkBgyxlbMF32tHEyAYlsg+jRn1Eggv9wUSpxlJaA1ixlnpmAjWIAM ByACdSvMRQ/vUCf9rDICLDcFO39jQzfokpIwNNoKLKuJp9B+y53+KDuS+EviGgWHlrqJ 05DvUtGE9hI6lpt2nHddNxKJsXcd6rAsTk7tA= Received: by 10.213.9.14 with SMTP id j14mr2889791ebj.132.1302640456232; Tue, 12 Apr 2011 13:34:16 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id y7sm4709213eeh.14.2011.04.12.13.34.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 13:34:15 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 12 Apr 2011 22:34:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12CDF20F-16DA-488E-948B-CBB18989CE04@employees.org> References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:34:18 -0000 Fred, > The following should not be construed as a draft, but > rather just a set of ideas that might be considered > for inclusion in a new or existing draft. Any > comments or suggestions? thanks for writing this up. I'd still like to see. as this is an operations group, how this would = work in practice. I'm particularly curious about how the host discovers its default = router. e.g. would an IPv6 CE / ISATAP router be a DNS server for a = given domain or inject a well known host name into a certain domain for = ISATAP default router discovery to work? or would some other = provisioning mechanism be used? cheers, Ole >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > --- cut here --- >=20 > Introduction > ************ > Countless end user sites in the Internet today still have > predominantly IPv4 infrastructures. These sites range in > size from small home/office networks to large corporate > enterprise networks, but share the commonality that IPv4 > continues to provide satisfactory internal routing and > addressing services. As more and more IPv6-only services > are deployed in the Internet, however, end user devices > within the site will increasingly require at least basic > IPv6 functionality for external access. This pre-draft > provides operational guidance for predominantly IPv4 sites > in making transitional IPv6 services available without > disrupting existing IPv4 services. >=20 > Characteristics of Existing IPv4 Sites > ************************************** > Existing end user sites use IPv4 routing and addressing > internally for normal IT operations such as filesharing, > network printing, e-mail, conferencing and numerous other > critical site-internal networking services. Such sites > typically have an abundance of public or private IPv4 > addresses for internal networking, and are separated from > the public Internet by firewalls, packet filtering gateways, > proxies, address translators and other site border securing > devices. To date, such sites have had little incentive to > enable IPv6 services internally [RFC1687]. >=20 > With the emergence of IPv6-only services within the public > Internet, however, existing IPv4 sites will increasingly > require a means for enabling client-side IPv6 services so > that end user devices within the site can access IPv6 > Internet services. Such services must be deployable with > minimal configuration and in a fashion that will not cause > disruptions to existing IPv4 services within the site. The > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) > [RFC5214] provides a simple-to-use service that sites can > deploy in the near term to meet these reqirements while a > longer-term site-wide IPv6 deployment plan is conducted > in parallel. >=20 > Enabling Client-Side IPv6 Services with ISATAP > ********************************************** > Small sites typically arrange to obtain public IPv6 prefixes > from an Internet Service Provider (ISP) in the same fashion > as for home network users. When the ISP does not yet provide > native IPv6 services, it can instead offer a transitional > service with native-equivalent capabilities using 6RD > [RFC5569][RFC5969]. Large sites typically obtain provider > independent IPv6 prefixes from an Internet registry and > advertise the prefixes into the IPv6 routing system on their > own behalf, i.e., they act as an ISP unto themselves. >=20 > In both cases, the site can automatically enable ISATAP > based IPv6 services by configuring one or more site border > routers as ISATAP routers. Each such ISATAP router is added > to the Potential Router List (PRL) for the site so that > hosts in the network can discover them for default route > and prefix auto-configuration purposes. >=20 > When there are multiple ISATAP site border routers, the > routers can advertise the same IPv6 prefix or a different > set of IPv6 prefixes of prefix length /64. For example, > a first router may advertise 2001:db8:0:0::/64, a second > may advertise 2001:db8:0:1::/64, etc. The routers can > further be configured to advertise different prefixes > to different sets of hosts within the site (e.g., as > identified by the host's IPv4 prefix) for the purpose > of site partitioning. In all cases, however, the site > border routers must take operational measures to avoid > routing loops [draft-ietf-v6ops-tunnel-loops]. As a > simple mitigation, the site border router can drop any > incoming packets that have an IPv4 source or outgoing > packets that have an IPv4 destination address of another > site border router, e.g., by checking for the address > in the site's PRL. >=20 > ISATAP hosts will automatically discover ISATAP site border > routers and configure ISATAP addresses using Stateless > Address AutoConfiguration (SLAAC) based on the advertised > IPv6 prefixes. In order to provide a simple service that > does not interact poorly with existing site topological > arrangements, the site can enable client-side only operation > so that hosts only use the ISATAP service for accessing IPv6 > services on the public Internet, while continuing to use > IPv4 services for intra-site communications. >=20 > In order to maintain a client-side only service, the site > should not configure any IPv6 addresses provided by ISATAP > within site name service resource records. In this way, > intra-site communications will continue to use existing > IPv4 networking services instead of ISATAP-served IPv6 > services. This arrangement prevents communication failure > modes in which a pair of ISATAP hosts are separated by a > packet filtering gateway which would prevent direct > communications via the tunneled IPv6 service. >=20 > To further disable host-to-host ISATAP communications > within the site, the ISATAP site border routers should > advertise their prefixes with the (A,L) flags set to (1,0) > in their IPv6 Router Advertisements. In that way, each > ISATAP host will autoconfigure an address from the > advertised IPv6 prefix and assign it to their ISATAP > interface, but they will not assign an IPv6 prefix to > the ISATAP interface. Therefore, no two ISATAP hosts will > see each other as on-link neighbors, and all IPv6 > communications from the hosts will flow through an ISATAP > site border router in order to access IPv6 services in > the Internet. >=20 > Migration to Native IPv6 Services > ********************************* > ISATAP hosts should be configured to prefer native IPv6 > services instead of ISATAP whenever available. As the site > transitions its internal routers and links to use IPv6 > natively, hosts will naturally begin to receive native > IPv6 router advertisments and will begin using the > native IPv6 service instead of ISATAP. As more and > more native IPv6 service is enabled in the site, IPv6 > addresses can be entered into site name service resource > records to enable intra-site IPv6 service discovery. In > that way, predominantly IPv4 sites will begin to operate > a parallel native IPv6 service, and legacy IPv4 services > will gradually be phased out. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Apr 12 13:44:30 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 41065E08B8 for ; Tue, 12 Apr 2011 13:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvk+bLMZ6k2v for ; Tue, 12 Apr 2011 13:44:29 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id 5849BE0858 for ; Tue, 12 Apr 2011 13:44:29 -0700 (PDT) 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 p3CKiRHF026089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 13:44:28 -0700 (PDT) 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 p3CKiR7x017314; Tue, 12 Apr 2011 13:44:27 -0700 (PDT) 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 p3CKiQme017290 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 13:44:26 -0700 (PDT) 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, 12 Apr 2011 13:44:26 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , Randy Bush , "Gunter Van de Velde (gvandeve)" Date: Tue, 12 Apr 2011 13:44:25 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5SyHUbfaAnZF0SoO6XiZ1OVEtVAAAKeIQAADdHLAAADD3cAAAWpqw Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com><4269EA985EACD2498 7D82DAE2FEC62E503764E39@XMB-AMS-101.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDBF5@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDC32@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDC32@XMB-RCD-109.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" Subject: Re: [v6ops] Operational Guidance for IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:44:30 -0000 Hemant,=20 > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: Tuesday, April 12, 2011 1:31 PM > To: Templin, Fred L; Randy Bush; Gunter Van de Velde (gvandeve) > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Operational Guidance for=20 > IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) >=20 > Fred, >=20 > Thanks for the pointers to the other messages. When I get a chance, > will go thru the details in the URLs provided and get back to=20 > you. But > I still reiterate my original point which was that is one has multiple > IPv6 subnets in the home LAN why not use routing for native IPv6 and > IPv4? I'm afraid I don't really understand your questions. The point I am making is about provisioning of transitional IPv6 services within predominantly IPv4 end user sites. These "sites" may be of various shapes and sizes - some quite small (e.g., the soho network of a local retailer), and others quite large (e.g., a multi-national corporate enterprise network). This discussion has therefore transitioned to focus on site-internal considerations. Thanks - Fred fred.l.templin@boeing.com > Hemant >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Tuesday, April 12, 2011 4:26 PM > To: Hemant Singh (shemant); Randy Bush; Gunter Van de Velde (gvandeve) > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Operational Guidance for IPv6Deploymentin > Predominantly IPv4 Sites - (pre-draft) >=20 > Hemant,=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > > On Behalf Of Hemant Singh (shemant) > > Sent: Tuesday, April 12, 2011 12:58 PM > > To: Randy Bush; Gunter Van de Velde (gvandeve) > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] Operational Guidance for=20 > > IPv6Deploymentin Predominantly IPv4 Sites - (pre-draft) > >=20 > > +1. I already sent email to v6ops in the past week or two=20 > asking Fred > > T. a question that a home LAN can do native ipv4 and native ipv4 and > > thus why does the home need ISATAP. >=20 > You have taken Randy's out-of-context quote and spun > it even further out of context. We have moved on to > a different page now; please go back and re-read the > latest posts to get proper context: >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg08276.html > http://www.ietf.org/mail-archive/web/v6ops/current/msg08281.html > http://www.ietf.org/mail-archive/web/v6ops/current/msg08282.html >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Hemant > >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Randy Bush > > Sent: Tuesday, April 12, 2011 3:52 PM > > To: Gunter Van de Velde (gvandeve) > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymentin > > Predominantly IPv4 Sites - (pre-draft) > >=20 > > > In some way I have a feeling that native-v6 should be=20 > promoted above > > > ISATAP. ISATAP is tunneling and eventhough its not as bad=20 > > as 6to4, it > > > is way worse as native v6. > >=20 > > +1 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > = From shemant@cisco.com Tue Apr 12 13:50:03 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08331E08B9 for ; Tue, 12 Apr 2011 13:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnh9z1WYEKog for ; Tue, 12 Apr 2011 13:50:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 2E671E0852 for ; Tue, 12 Apr 2011 13:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1213; q=dns/txt; s=iport; t=1302641402; x=1303851002; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=izBzBBBfx4FxMPeVpgCL3e+ytQFic87YtFRfSEAuk04=; b=G6lILRcFXuEXIvZilSSsYXGSWi47Q669FyGKE1KAFTit4dmK+PIAmt1W 0a8371EZA3bzThfhH8WIzTrF+fasYrx9yCiVqAXW4WL7Dn9cnqgr+o8BC 0olNjXY5o26vxany8fDpcvadqcbek4rL0WaxsUMl6SNEhJs1hDPd2YT6S 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOK5pE2tJXG8/2dsb2JhbACmBHeIep15nQ2FbgSFW4t8 X-IronPort-AV: E=Sophos;i="4.64,199,1301875200"; d="scan'208";a="294873751" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 20:50:00 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3CKo0Pk012324; Tue, 12 Apr 2011 20:50:00 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:49:59 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 15:49:58 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDC64@XMB-RCD-109.cisco.com> In-Reply-To: <12CDF20F-16DA-488E-948B-CBB18989CE04@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5UQsc0Za8T76SSQy1gQYXQ3iEuAAAPBFQ References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <12CDF20F-16DA-488E-948B-CBB18989CE04@employees.org> From: "Hemant Singh (shemant)" To: "Ole Troan" , "Templin, Fred L" X-OriginalArrivalTime: 12 Apr 2011 20:49:59.0904 (UTC) FILETIME=[305AA600:01CBF953] Cc: v6ops@ietf.org Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:50:03 -0000 > the (A,L) flags set to (1,0) in their IPv6 Router Advertisements. IPv6 ND (RFC 4861) has no means to specify a prefix as off-link. The statement above from Fred T. has recommended to set the L-bit in the RA as cleared to signal the prefix as off-link. The on/off-link behavior in ND is per destination address not a prefix. Many folks have a misconception that by merely clearing the L-bit in the RA, one has signaled an IPv6 prefix off-link is not correct. The only means to specify (via the ND RA) a destination for off-link is to send an RA with no PIO (Prefix Information Option). One reason I can think of as to why ND has no means to specify a prefix as off-link is because of the A-bit in the RA. The A-bit asks the hosts to perform SLAAC and thus the host has other destinations as on-link within a /64 of the prefix doled out in the PIO. Thus how can the L-bit for A-bit =3D=3D 1 be cleared to = signal the prefix as off-link? Anyway, I do need to spend some time to read of all of Fred T.'s documentation and get back to the mailer. I will need at least a week or two to read all of ISATAP emails and related blurbs. Thus I will reply back in such timeframe. Hemant=20 From Fred.L.Templin@boeing.com Tue Apr 12 13:53:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 433B6E0858 for ; Tue, 12 Apr 2011 13:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6943xw1+lun for ; Tue, 12 Apr 2011 13:53:37 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id C879DE0688 for ; Tue, 12 Apr 2011 13:53:37 -0700 (PDT) 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 p3CKrYYY003714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 13:53:34 -0700 (PDT) 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 p3CKrYDV005678; Tue, 12 Apr 2011 13:53:34 -0700 (PDT) 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 p3CKrXpG005655 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 13:53:33 -0700 (PDT) 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, 12 Apr 2011 13:53:33 -0700 From: "Templin, Fred L" To: Ole Troan Date: Tue, 12 Apr 2011 13:53:32 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5UQAPwvQPZTBrQNqh4k99bLaY0gAAZxQA Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <12CDF20F-16DA-488E-948B-CBB18989CE04@employees.org> In-Reply-To: <12CDF20F-16DA-488E-948B-CBB18989CE04@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: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:53:39 -0000 Hi Ole,=20 > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of=20 > Ole Troan > Sent: Tuesday, April 12, 2011 1:34 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft) >=20 > Fred, >=20 > > The following should not be construed as a draft, but > > rather just a set of ideas that might be considered > > for inclusion in a new or existing draft. Any > > comments or suggestions? >=20 > thanks for writing this up. >=20 > I'd still like to see. as this is an operations group, how=20 > this would work in practice. > I'm particularly curious about how the host discovers its=20 > default router. e.g. would an IPv6 CE / ISATAP router be a=20 > DNS server for a given domain or inject a well known host=20 > name into a certain domain for ISATAP default router=20 > discovery to work? The ISATAP router typically arranges to have its IPv4 address added to the Potential Route List (PRL) within the name service for the site. That does not necessarily mean the DNS - it could be some other site-internal naming service. But, by and large, hosts should be able to resolve the name "isatap.domainname" for the "domainname" suffix associated with their attached link. > or would some other provisioning mechanism be used? We could have done it via a DHCP option as you and Mark did for 6RD. There is in fact an expired draft from me asking for a DHCP option, but after some initial interest the idea just didn't seem to catch on. The lowest common denominator as always is manual configuration, which some hosts might choose over the name resolution method. Fred fred.l.templin@boeing.com > cheers, > Ole >=20 >=20 > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > --- cut here --- > >=20 > > Introduction > > ************ > > Countless end user sites in the Internet today still have > > predominantly IPv4 infrastructures. These sites range in > > size from small home/office networks to large corporate > > enterprise networks, but share the commonality that IPv4 > > continues to provide satisfactory internal routing and > > addressing services. As more and more IPv6-only services > > are deployed in the Internet, however, end user devices > > within the site will increasingly require at least basic > > IPv6 functionality for external access. This pre-draft > > provides operational guidance for predominantly IPv4 sites > > in making transitional IPv6 services available without > > disrupting existing IPv4 services. > >=20 > > Characteristics of Existing IPv4 Sites > > ************************************** > > Existing end user sites use IPv4 routing and addressing > > internally for normal IT operations such as filesharing, > > network printing, e-mail, conferencing and numerous other > > critical site-internal networking services. Such sites > > typically have an abundance of public or private IPv4 > > addresses for internal networking, and are separated from > > the public Internet by firewalls, packet filtering gateways, > > proxies, address translators and other site border securing > > devices. To date, such sites have had little incentive to > > enable IPv6 services internally [RFC1687]. > >=20 > > With the emergence of IPv6-only services within the public > > Internet, however, existing IPv4 sites will increasingly > > require a means for enabling client-side IPv6 services so > > that end user devices within the site can access IPv6 > > Internet services. Such services must be deployable with > > minimal configuration and in a fashion that will not cause > > disruptions to existing IPv4 services within the site. The > > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) > > [RFC5214] provides a simple-to-use service that sites can > > deploy in the near term to meet these reqirements while a > > longer-term site-wide IPv6 deployment plan is conducted > > in parallel. > >=20 > > Enabling Client-Side IPv6 Services with ISATAP > > ********************************************** > > Small sites typically arrange to obtain public IPv6 prefixes > > from an Internet Service Provider (ISP) in the same fashion > > as for home network users. When the ISP does not yet provide > > native IPv6 services, it can instead offer a transitional > > service with native-equivalent capabilities using 6RD > > [RFC5569][RFC5969]. Large sites typically obtain provider > > independent IPv6 prefixes from an Internet registry and > > advertise the prefixes into the IPv6 routing system on their > > own behalf, i.e., they act as an ISP unto themselves. > >=20 > > In both cases, the site can automatically enable ISATAP > > based IPv6 services by configuring one or more site border > > routers as ISATAP routers. Each such ISATAP router is added > > to the Potential Router List (PRL) for the site so that > > hosts in the network can discover them for default route > > and prefix auto-configuration purposes. > >=20 > > When there are multiple ISATAP site border routers, the > > routers can advertise the same IPv6 prefix or a different > > set of IPv6 prefixes of prefix length /64. For example, > > a first router may advertise 2001:db8:0:0::/64, a second > > may advertise 2001:db8:0:1::/64, etc. The routers can > > further be configured to advertise different prefixes > > to different sets of hosts within the site (e.g., as > > identified by the host's IPv4 prefix) for the purpose > > of site partitioning. In all cases, however, the site > > border routers must take operational measures to avoid > > routing loops [draft-ietf-v6ops-tunnel-loops]. As a > > simple mitigation, the site border router can drop any > > incoming packets that have an IPv4 source or outgoing > > packets that have an IPv4 destination address of another > > site border router, e.g., by checking for the address > > in the site's PRL. > >=20 > > ISATAP hosts will automatically discover ISATAP site border > > routers and configure ISATAP addresses using Stateless > > Address AutoConfiguration (SLAAC) based on the advertised > > IPv6 prefixes. In order to provide a simple service that > > does not interact poorly with existing site topological > > arrangements, the site can enable client-side only operation > > so that hosts only use the ISATAP service for accessing IPv6 > > services on the public Internet, while continuing to use > > IPv4 services for intra-site communications. > >=20 > > In order to maintain a client-side only service, the site > > should not configure any IPv6 addresses provided by ISATAP > > within site name service resource records. In this way, > > intra-site communications will continue to use existing > > IPv4 networking services instead of ISATAP-served IPv6 > > services. This arrangement prevents communication failure > > modes in which a pair of ISATAP hosts are separated by a > > packet filtering gateway which would prevent direct > > communications via the tunneled IPv6 service. > >=20 > > To further disable host-to-host ISATAP communications > > within the site, the ISATAP site border routers should > > advertise their prefixes with the (A,L) flags set to (1,0) > > in their IPv6 Router Advertisements. In that way, each > > ISATAP host will autoconfigure an address from the > > advertised IPv6 prefix and assign it to their ISATAP > > interface, but they will not assign an IPv6 prefix to > > the ISATAP interface. Therefore, no two ISATAP hosts will > > see each other as on-link neighbors, and all IPv6 > > communications from the hosts will flow through an ISATAP > > site border router in order to access IPv6 services in > > the Internet. > >=20 > > Migration to Native IPv6 Services > > ********************************* > > ISATAP hosts should be configured to prefer native IPv6 > > services instead of ISATAP whenever available. As the site > > transitions its internal routers and links to use IPv6 > > natively, hosts will naturally begin to receive native > > IPv6 router advertisments and will begin using the > > native IPv6 service instead of ISATAP. As more and > > more native IPv6 service is enabled in the site, IPv6 > > addresses can be entered into site name service resource > > records to enable intra-site IPv6 service discovery. In > > that way, predominantly IPv4 sites will begin to operate > > a parallel native IPv6 service, and legacy IPv4 services > > will gradually be phased out. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = From Fred.L.Templin@boeing.com Tue Apr 12 14:14:05 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 017A8E0961 for ; Tue, 12 Apr 2011 14:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwEO1vv9KtsL for ; Tue, 12 Apr 2011 14:14:04 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 2B90EE0960 for ; Tue, 12 Apr 2011 14:14:03 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3CLE2Vx016658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 14:14:02 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3CLE13O007162; Tue, 12 Apr 2011 14:14:01 -0700 (PDT) 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 p3CLE1kh007155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 14:14:01 -0700 (PDT) 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, 12 Apr 2011 14:14:01 -0700 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , Ole Troan Date: Tue, 12 Apr 2011 14:14:00 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5UQsc0Za8T76SSQy1gQYXQ3iEuAAAPBFQAAB23YA= Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <12CDF20F-16DA-488E-948B-CBB18989CE04@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDC64@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3014FDC64@XMB-RCD-109.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" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:14:05 -0000 Hemant, What would a reasonable host implementation do with a PIO in which the (A,L) flags are (1,0)? It would: 1) use SLAAC to configure an IPv6 address from the advertised prefix, and 2) assign the address to the interface over which the RA was received. That's it! The host has no reasonable guidance whereby=20 it can conceivable assign the IPv6 prefix to the link. Remember that, unlike with IPv4, address and prefix assignment in IPv6 are separate functions. Also, the method of operating ISATAP I am describing does not depend on strict adherence to any on-link vs off-link determinations. The only thing is that hosts that ignore the L bit may not be able to ping6 other hosts via ISATAP within a partitioned site. But, unless AAAA records for ISATAP IPv6 addresses are entered in the site name service there is no reason for the host to be ping6'ing within the site anyway. And, the sceanrio I am describing is one in which no AAAA records for ISATAP IPv6 addresses are entered in the site name service. I am sorry to hear that it may take you weeks and weeks to catch up on this thread. If you try for the three messages I cited, you would have all of the context you need: http://www.ietf.org/mail-archive/web/v6ops/current/msg08276.html http://www.ietf.org/mail-archive/web/v6ops/current/msg08281.html http://www.ietf.org/mail-archive/web/v6ops/current/msg08282.html Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: Tuesday, April 12, 2011 1:50 PM > To: Ole Troan; Templin, Fred L > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Operational Guidance for IPv6 Deployment=20 > inPredominantly IPv4 Sites - (pre-draft) >=20 > > the (A,L) flags set to (1,0) in their IPv6 Router Advertisements. >=20 > IPv6 ND (RFC 4861) has no means to specify a prefix as off-link. The > statement above from Fred T. has recommended to set the L-bit=20 > in the RA > as cleared to signal the prefix as off-link. The on/off-link behavior > in ND is per destination address not a prefix. Many folks have a > misconception that by merely clearing the L-bit in the RA, one has > signaled an IPv6 prefix off-link is not correct. The only means to > specify (via the ND RA) a destination for off-link is to send=20 > an RA with > no PIO (Prefix Information Option). One reason I can think=20 > of as to why > ND has no means to specify a prefix as off-link is because of=20 > the A-bit > in the RA. The A-bit asks the hosts to perform SLAAC and=20 > thus the host > has other destinations as on-link within a /64 of the prefix doled out > in the PIO. Thus how can the L-bit for A-bit =3D=3D 1 be cleared=20 > to signal > the prefix as off-link? Anyway, I do need to spend some time=20 > to read of > all of Fred T.'s documentation and get back to the mailer. I=20 > will need > at least a week or two to read all of ISATAP emails and=20 > related blurbs. > Thus I will reply back in such timeframe. >=20 > Hemant=20 >=20 > = From jhw@apple.com Tue Apr 12 14:25:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80B4DE091C for ; Tue, 12 Apr 2011 14:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EEr4ftWv90v for ; Tue, 12 Apr 2011 14:25:00 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id C2743E0976 for ; Tue, 12 Apr 2011 14:25:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJK008FC60P1WC0@mail-out.apple.com> for v6ops@ietf.org; Tue, 12 Apr 2011 14:24:59 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-14-4da4c32ba0c5 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id E9.2B.18996.B23C4AD4; Tue, 12 Apr 2011 14:24:59 -0700 (PDT) Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJK00HR365N4V00@et.apple.com> for v6ops@ietf.org; Tue, 12 Apr 2011 14:24:59 -0700 (PDT) From: james woodyatt In-reply-to: <4DA4A5FA.9000600@dougbarton.us> Date: Tue, 12 Apr 2011 14:24:58 -0700 Message-id: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:25:01 -0000 On Apr 12, 2011, at 12:20 , Doug Barton wrote: > > On the other hand, the unsuccessful 6to4 connections have a very high cost in that they are a major contributing factor causing content providers to be hesitant to deploy real IPv6. One could also argue that the presence of 6to4 has created a reduced incentive for ISPs as well, but I don't place a lot of weight on that argument. I don't believe this claim of high costs associated with failed 6to4 is supported by evidence. Furthermore, I fail to see how deprecating 6to4 will do anything to increase the incentives for either content providers or Internet service providers to deploy native IPv6 applications and service. The content providers can identify plenty of other sources of IPv6 brokenness with which to excuse dragging their heels to effect the transition. Those source mainly revolve around buggy CPE router implementations that have nothing to do with 6to4 or its anycast relay service. Moreover, the incumbent service providers have little incentive to deploy native IPv6 while content providers are still available over IPv4 and they are protected from competition because NAT444 offers better customer lock-in mechanisms than DS and DS-lite. I therefore contend that deprecating 6to4 now is a waste of IETF time. The utility of 6to4 will wither away naturally over time. Attempting to hurry it along by publishing an RFC will help no one. -- james woodyatt member of technical staff, core os networking From oskar@acm.org Tue Apr 12 14:41:03 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15BBFE097F for ; Tue, 12 Apr 2011 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwe3rZqDMkTi for ; Tue, 12 Apr 2011 14:41:02 -0700 (PDT) Received: from smtp1.dokom.net (smtp1.dokom.net [85.22.54.10]) by ietfc.amsl.com (Postfix) with ESMTP id 788D7E0809 for ; Tue, 12 Apr 2011 14:41:02 -0700 (PDT) Received: from tmo-100-248.customers.d1-online.com ([80.187.100.248] helo=[192.168.9.100]) by smtp1.dokom.net with esmtpa (Exim 4.66) (envelope-from ) id 1Q9lKW-0000ox-DZ; Tue, 12 Apr 2011 23:41:00 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan-Hinrich Fessel In-Reply-To: Date: Tue, 12 Apr 2011 23:40:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7AEFF548-7EDE-4DDF-929B-ABF5F1322941@acm.org> References: <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:41:03 -0000 Am 12.04.2011 um 09:55 schrieb Mikael Abrahamsson: > On Tue, 12 Apr 2011, Dmitry Anipko wrote: >=20 >> So if there is any truth in such rough estimate, disabling 6to4 relay = record may reduce IPv6 brokenness. How much exactly - I guess only a = measurement could show. >=20 > I am 100% sure that disabling 6to4 by default would seriously reduce = IPv6 brokenness. It will also seriously reduce the number of people = using IPv6 (over 6to4), but I think the consensus is that right now it's = better to reduce use of IPv6 compared to having a significant share of = added IPv6 brokenness. >=20 > So in my opinion from reading this WG, a lot of people (majority) = wants users to get IPv6 when it's done right and has a very high = possibility of working, as opposed to having IPv6 that we know is = breaking in a lot of cases but that reaches a higher number. >=20 > 6to4 was great for testing, it's not great for production. +1 --=20 Jan-Hinrich Fessel= From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Apr 12 14:43:03 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33446E0939 for ; Tue, 12 Apr 2011 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7rTkWUIkzSx for ; Tue, 12 Apr 2011 14:43:02 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfc.amsl.com (Postfix) with ESMTP id E0FF3E08A8 for ; Tue, 12 Apr 2011 14:42:53 -0700 (PDT) Received: from 182-239-169-88.ip.adam.com.au ([182.239.169.88] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Q9lMG-0001PM-HC; Wed, 13 Apr 2011 07:12:48 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 096F73B337; Wed, 13 Apr 2011 07:12:48 +0930 (CST) Date: Wed, 13 Apr 2011 07:12:47 +0930 From: Mark Smith To: "Templin, Fred L" Message-ID: <20110413071247.2befa661@opy.nosense.org> In-Reply-To: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:43:03 -0000 Hi Fred, On Mon, 11 Apr 2011 11:18:14 -0700 "Templin, Fred L" wrote: > Hello, > > The following should not be construed as a draft, but > rather just a set of ideas that might be considered > for inclusion in a new or existing draft. Any > comments or suggestions? > I don't know if it has been though of before, however one alternative use of ISATAP I've thought of is to facilitate IPv6 topology hiding. The underlying IPv4 addresses probably would expose the network typology, however if they're RFC1918 ones, they'd be unreachable externally. Possibly this could be resolved by having only the ISATAP domain link-local addresses use IPv4 addresses, and then have global -> link local IPv6 translation tables which are then used to resolve a global IPv6 ISATAP host address which doesn't include an interior IPv4 host address into a ISATAP link local and then interior IPv4 address. As external parties would only use externally visible IPv6 addresses, the IPv4 topology would then be hidden as well. Regards, Mark. > Thanks - Fred > fred.l.templin@boeing.com > > --- cut here --- > > Introduction > ************ > Countless end user sites in the Internet today still have > predominantly IPv4 infrastructures. These sites range in > size from small home/office networks to large corporate > enterprise networks, but share the commonality that IPv4 > continues to provide satisfactory internal routing and > addressing services. As more and more IPv6-only services > are deployed in the Internet, however, end user devices > within the site will increasingly require at least basic > IPv6 functionality for external access. This pre-draft > provides operational guidance for predominantly IPv4 sites > in making transitional IPv6 services available without > disrupting existing IPv4 services. > > Characteristics of Existing IPv4 Sites > ************************************** > Existing end user sites use IPv4 routing and addressing > internally for normal IT operations such as filesharing, > network printing, e-mail, conferencing and numerous other > critical site-internal networking services. Such sites > typically have an abundance of public or private IPv4 > addresses for internal networking, and are separated from > the public Internet by firewalls, packet filtering gateways, > proxies, address translators and other site border securing > devices. To date, such sites have had little incentive to > enable IPv6 services internally [RFC1687]. > > With the emergence of IPv6-only services within the public > Internet, however, existing IPv4 sites will increasingly > require a means for enabling client-side IPv6 services so > that end user devices within the site can access IPv6 > Internet services. Such services must be deployable with > minimal configuration and in a fashion that will not cause > disruptions to existing IPv4 services within the site. The > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) > [RFC5214] provides a simple-to-use service that sites can > deploy in the near term to meet these reqirements while a > longer-term site-wide IPv6 deployment plan is conducted > in parallel. > > Enabling Client-Side IPv6 Services with ISATAP > ********************************************** > Small sites typically arrange to obtain public IPv6 prefixes > from an Internet Service Provider (ISP) in the same fashion > as for home network users. When the ISP does not yet provide > native IPv6 services, it can instead offer a transitional > service with native-equivalent capabilities using 6RD > [RFC5569][RFC5969]. Large sites typically obtain provider > independent IPv6 prefixes from an Internet registry and > advertise the prefixes into the IPv6 routing system on their > own behalf, i.e., they act as an ISP unto themselves. > > In both cases, the site can automatically enable ISATAP > based IPv6 services by configuring one or more site border > routers as ISATAP routers. Each such ISATAP router is added > to the Potential Router List (PRL) for the site so that > hosts in the network can discover them for default route > and prefix auto-configuration purposes. > > When there are multiple ISATAP site border routers, the > routers can advertise the same IPv6 prefix or a different > set of IPv6 prefixes of prefix length /64. For example, > a first router may advertise 2001:db8:0:0::/64, a second > may advertise 2001:db8:0:1::/64, etc. The routers can > further be configured to advertise different prefixes > to different sets of hosts within the site (e.g., as > identified by the host's IPv4 prefix) for the purpose > of site partitioning. In all cases, however, the site > border routers must take operational measures to avoid > routing loops [draft-ietf-v6ops-tunnel-loops]. As a > simple mitigation, the site border router can drop any > incoming packets that have an IPv4 source or outgoing > packets that have an IPv4 destination address of another > site border router, e.g., by checking for the address > in the site's PRL. > > ISATAP hosts will automatically discover ISATAP site border > routers and configure ISATAP addresses using Stateless > Address AutoConfiguration (SLAAC) based on the advertised > IPv6 prefixes. In order to provide a simple service that > does not interact poorly with existing site topological > arrangements, the site can enable client-side only operation > so that hosts only use the ISATAP service for accessing IPv6 > services on the public Internet, while continuing to use > IPv4 services for intra-site communications. > > In order to maintain a client-side only service, the site > should not configure any IPv6 addresses provided by ISATAP > within site name service resource records. In this way, > intra-site communications will continue to use existing > IPv4 networking services instead of ISATAP-served IPv6 > services. This arrangement prevents communication failure > modes in which a pair of ISATAP hosts are separated by a > packet filtering gateway which would prevent direct > communications via the tunneled IPv6 service. > > To further disable host-to-host ISATAP communications > within the site, the ISATAP site border routers should > advertise their prefixes with the (A,L) flags set to (1,0) > in their IPv6 Router Advertisements. In that way, each > ISATAP host will autoconfigure an address from the > advertised IPv6 prefix and assign it to their ISATAP > interface, but they will not assign an IPv6 prefix to > the ISATAP interface. Therefore, no two ISATAP hosts will > see each other as on-link neighbors, and all IPv6 > communications from the hosts will flow through an ISATAP > site border router in order to access IPv6 services in > the Internet. > > Migration to Native IPv6 Services > ********************************* > ISATAP hosts should be configured to prefer native IPv6 > services instead of ISATAP whenever available. As the site > transitions its internal routers and links to use IPv6 > natively, hosts will naturally begin to receive native > IPv6 router advertisments and will begin using the > native IPv6 service instead of ISATAP. As more and > more native IPv6 service is enabled in the site, IPv6 > addresses can be entered into site name service resource > records to enable intra-site IPv6 service discovery. In > that way, predominantly IPv4 sites will begin to operate > a parallel native IPv6 service, and legacy IPv4 services > will gradually be phased out. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Apr 12 15:07:37 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B49D5E079B for ; Tue, 12 Apr 2011 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVPQXQr7Zsyz for ; Tue, 12 Apr 2011 15:07:36 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfc.amsl.com (Postfix) with ESMTP id 4C6D8E07BE for ; Tue, 12 Apr 2011 15:07:36 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3CM7Qab003974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 17:07:26 -0500 (CDT) 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 p3CM7PG4016756; Tue, 12 Apr 2011 15:07:25 -0700 (PDT) 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 p3CM7Pxs016753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 15:07:25 -0700 (PDT) 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; Tue, 12 Apr 2011 15:07:25 -0700 From: "Templin, Fred L" To: Mark Smith Date: Tue, 12 Apr 2011 15:07:24 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5WpX0SXRY8m3ASDWV8OcR8pq4UgAAajJw Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <20110413071247.2befa661@opy.nosense.org> In-Reply-To: <20110413071247.2befa661@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 22:07:37 -0000 Hi Mark,=20 > -----Original Message----- > From: Mark Smith=20 > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > Sent: Tuesday, April 12, 2011 2:43 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > inPredominantly IPv4 Sites - (pre-draft) >=20 > Hi Fred, >=20 > On Mon, 11 Apr 2011 11:18:14 -0700 > "Templin, Fred L" wrote: >=20 > > Hello, > >=20 > > The following should not be construed as a draft, but > > rather just a set of ideas that might be considered > > for inclusion in a new or existing draft. Any > > comments or suggestions? > >=20 >=20 > I don't know if it has been though of before, however one alternative > use of ISATAP I've thought of is to facilitate IPv6 topology > hiding. The underlying IPv4 addresses probably would expose=20 > the network > typology, however if they're RFC1918 ones, they'd be unreachable > externally. There is probably a discussion point here, but I'll note that other IPv4-embedding mechanisms like 6to4 and 6rd are not shy about exposing IPv4 addresses externally. Especially with 6rd, the IPv4 addresses may be from the private internal IPv4 addressing realm of the ISP, so there would seem to be precendence for just letting the IPv4 addresses leak out. > Possibly this could be resolved by having only the ISATAP > domain link-local addresses use IPv4 addresses, and then have=20 > global -> > link local IPv6 translation tables which are then used to resolve a > global IPv6 ISATAP host address which doesn't include an interior IPv4 > host address into a ISATAP link local and then interior IPv4=20 > address. As > external parties would only use externally visible IPv6 addresses, the > IPv4 topology would then be hidden as well. I'm almost on-board with this, however I would not want to see the site number all of its ISATAP host interfaces with only link-local IPv6 addresses. Or, maybe that's not what you were saying? What I *could* see happening is for the ISATAP router to maintain a translation table whereby it translates the IPv6 address 2001:db8::[ISATAP] coming from a host within the site to the IPv6 address 2001:db8::[EUI64] for communications with hosts outside the site. Even moreso, ISATAP hosts inside an enterprise network are likely to need to go through an enterprise-border proxy in order to talk to IPv6 servers out on the Internet, so the proxy itself could do the translation as I suspect many IPv4 proxies currently do today. Is that what you had in mind? Thanks - Fred fred.l.templin@boeing.com =20 > Regards, > Mark. >=20 >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > --- cut here --- > >=20 > > Introduction > > ************ > > Countless end user sites in the Internet today still have > > predominantly IPv4 infrastructures. These sites range in > > size from small home/office networks to large corporate > > enterprise networks, but share the commonality that IPv4 > > continues to provide satisfactory internal routing and > > addressing services. As more and more IPv6-only services > > are deployed in the Internet, however, end user devices > > within the site will increasingly require at least basic > > IPv6 functionality for external access. This pre-draft > > provides operational guidance for predominantly IPv4 sites > > in making transitional IPv6 services available without > > disrupting existing IPv4 services. > >=20 > > Characteristics of Existing IPv4 Sites > > ************************************** > > Existing end user sites use IPv4 routing and addressing > > internally for normal IT operations such as filesharing, > > network printing, e-mail, conferencing and numerous other > > critical site-internal networking services. Such sites > > typically have an abundance of public or private IPv4 > > addresses for internal networking, and are separated from > > the public Internet by firewalls, packet filtering gateways, > > proxies, address translators and other site border securing > > devices. To date, such sites have had little incentive to > > enable IPv6 services internally [RFC1687]. > >=20 > > With the emergence of IPv6-only services within the public > > Internet, however, existing IPv4 sites will increasingly > > require a means for enabling client-side IPv6 services so > > that end user devices within the site can access IPv6 > > Internet services. Such services must be deployable with > > minimal configuration and in a fashion that will not cause > > disruptions to existing IPv4 services within the site. The > > Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) > > [RFC5214] provides a simple-to-use service that sites can > > deploy in the near term to meet these reqirements while a > > longer-term site-wide IPv6 deployment plan is conducted > > in parallel. > >=20 > > Enabling Client-Side IPv6 Services with ISATAP > > ********************************************** > > Small sites typically arrange to obtain public IPv6 prefixes > > from an Internet Service Provider (ISP) in the same fashion > > as for home network users. When the ISP does not yet provide > > native IPv6 services, it can instead offer a transitional > > service with native-equivalent capabilities using 6RD > > [RFC5569][RFC5969]. Large sites typically obtain provider > > independent IPv6 prefixes from an Internet registry and > > advertise the prefixes into the IPv6 routing system on their > > own behalf, i.e., they act as an ISP unto themselves. > >=20 > > In both cases, the site can automatically enable ISATAP > > based IPv6 services by configuring one or more site border > > routers as ISATAP routers. Each such ISATAP router is added > > to the Potential Router List (PRL) for the site so that > > hosts in the network can discover them for default route > > and prefix auto-configuration purposes. > >=20 > > When there are multiple ISATAP site border routers, the > > routers can advertise the same IPv6 prefix or a different > > set of IPv6 prefixes of prefix length /64. For example, > > a first router may advertise 2001:db8:0:0::/64, a second > > may advertise 2001:db8:0:1::/64, etc. The routers can > > further be configured to advertise different prefixes > > to different sets of hosts within the site (e.g., as > > identified by the host's IPv4 prefix) for the purpose > > of site partitioning. In all cases, however, the site > > border routers must take operational measures to avoid > > routing loops [draft-ietf-v6ops-tunnel-loops]. As a > > simple mitigation, the site border router can drop any > > incoming packets that have an IPv4 source or outgoing > > packets that have an IPv4 destination address of another > > site border router, e.g., by checking for the address > > in the site's PRL. > >=20 > > ISATAP hosts will automatically discover ISATAP site border > > routers and configure ISATAP addresses using Stateless > > Address AutoConfiguration (SLAAC) based on the advertised > > IPv6 prefixes. In order to provide a simple service that > > does not interact poorly with existing site topological > > arrangements, the site can enable client-side only operation > > so that hosts only use the ISATAP service for accessing IPv6 > > services on the public Internet, while continuing to use > > IPv4 services for intra-site communications. > >=20 > > In order to maintain a client-side only service, the site > > should not configure any IPv6 addresses provided by ISATAP > > within site name service resource records. In this way, > > intra-site communications will continue to use existing > > IPv4 networking services instead of ISATAP-served IPv6 > > services. This arrangement prevents communication failure > > modes in which a pair of ISATAP hosts are separated by a > > packet filtering gateway which would prevent direct > > communications via the tunneled IPv6 service. > >=20 > > To further disable host-to-host ISATAP communications > > within the site, the ISATAP site border routers should > > advertise their prefixes with the (A,L) flags set to (1,0) > > in their IPv6 Router Advertisements. In that way, each > > ISATAP host will autoconfigure an address from the > > advertised IPv6 prefix and assign it to their ISATAP > > interface, but they will not assign an IPv6 prefix to > > the ISATAP interface. Therefore, no two ISATAP hosts will > > see each other as on-link neighbors, and all IPv6 > > communications from the hosts will flow through an ISATAP > > site border router in order to access IPv6 services in > > the Internet. > >=20 > > Migration to Native IPv6 Services > > ********************************* > > ISATAP hosts should be configured to prefer native IPv6 > > services instead of ISATAP whenever available. As the site > > transitions its internal routers and links to use IPv6 > > natively, hosts will naturally begin to receive native > > IPv6 router advertisments and will begin using the > > native IPv6 service instead of ISATAP. As more and > > more native IPv6 service is enabled in the site, IPv6 > > addresses can be entered into site name service resource > > records to enable intra-site IPv6 service discovery. In > > that way, predominantly IPv4 sites will begin to operate > > a parallel native IPv6 service, and legacy IPv4 services > > will gradually be phased out. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > = From frnkblk@iname.com Tue Apr 12 15:39:04 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB109E07F5 for ; Tue, 12 Apr 2011 15:39:04 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VZkZoBUHe6l for ; Tue, 12 Apr 2011 15:39:04 -0700 (PDT) Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfc.amsl.com (Postfix) with ESMTP id C7FAAE07F4 for ; Tue, 12 Apr 2011 15:39:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.27; Received: from bulklaptop (unverified [199.120.69.27]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 24819980-1729245 for multiple; Tue, 12 Apr 2011 17:38:59 -0500 From: "Frank Bulk - iName.com" To: "'james woodyatt'" , "Doug Barton" References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> In-Reply-To: Date: Tue, 12 Apr 2011 17:38:59 -0500 Message-ID: X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acv5WCYEyOhGmrvQS8O6USeY7VCh+gACWnpQ 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=8 Friend=755 Surbl=0 Catch=0 r=0 ip=199.120.69.27 X-IP-stats: Incoming Outgoing Last 0, First 766, in=10581802, out=53337, spam=0 Known=true ip=199.120.69.27 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 12 Apr 2011 22:39:05 -0000 There are several known items of brokenness. If all we can do is take small steps to address them, that's better than taking no steps at all. As someone else said earlier in this thread, we'd rather have a little less IPv6 traffic (collateral damage) because 6to4 is disabled in the OS or router than have the measured levels brokenness. My current top concern for my end users on World IPv6 day? Routers that support 6to4 and end-users who plug their PC directly into our cable modem or ONT and use 6to4 that way. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, April 12, 2011 4:25 PM To: Doug Barton Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question On Apr 12, 2011, at 12:20 , Doug Barton wrote: > > On the other hand, the unsuccessful 6to4 connections have a very high cost in that they are a major contributing factor causing content providers to be hesitant to deploy real IPv6. One could also argue that the presence of 6to4 has created a reduced incentive for ISPs as well, but I don't place a lot of weight on that argument. I don't believe this claim of high costs associated with failed 6to4 is supported by evidence. Furthermore, I fail to see how deprecating 6to4 will do anything to increase the incentives for either content providers or Internet service providers to deploy native IPv6 applications and service. The content providers can identify plenty of other sources of IPv6 brokenness with which to excuse dragging their heels to effect the transition. Those source mainly revolve around buggy CPE router implementations that have nothing to do with 6to4 or its anycast relay service. Moreover, the incumbent service providers have little incentive to deploy native IPv6 while content providers are still available over IPv4 and they are protected from competition because NAT444 offers better customer lock-in mechanisms than DS and DS-lite. I therefore contend that deprecating 6to4 now is a waste of IETF time. The utility of 6to4 will wither away naturally over time. Attempting to hurry it along by publishing an RFC will help no one. -- james woodyatt member of technical staff, core os networking _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Apr 12 16:01:49 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 23D47E079B for ; Tue, 12 Apr 2011 16:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1elckTEte-Os for ; Tue, 12 Apr 2011 16:01:48 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfc.amsl.com (Postfix) with ESMTP id DD0AEE06A5 for ; Tue, 12 Apr 2011 16:01:47 -0700 (PDT) Received: from 182-239-169-88.ip.adam.com.au ([182.239.169.88] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Q9mad-0004q2-6W; Wed, 13 Apr 2011 08:31:43 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id CD09A3B337; Wed, 13 Apr 2011 08:31:42 +0930 (CST) Date: Wed, 13 Apr 2011 08:31:42 +0930 From: Mark Smith To: "Templin, Fred L" Message-ID: <20110413083142.1400c381@opy.nosense.org> In-Reply-To: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <20110413071247.2befa661@opy.nosense.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 23:01:49 -0000 Hi Fred, On Tue, 12 Apr 2011 15:07:24 -0700 "Templin, Fred L" wrote: > Hi Mark, > > > -----Original Message----- > > From: Mark Smith > > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > > Sent: Tuesday, April 12, 2011 2:43 PM > > To: Templin, Fred L > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment > > inPredominantly IPv4 Sites - (pre-draft) > > > > Hi Fred, > > > > On Mon, 11 Apr 2011 11:18:14 -0700 > > "Templin, Fred L" wrote: > > > > > Hello, > > > > > > The following should not be construed as a draft, but > > > rather just a set of ideas that might be considered > > > for inclusion in a new or existing draft. Any > > > comments or suggestions? > > > > > > > I don't know if it has been though of before, however one alternative > > use of ISATAP I've thought of is to facilitate IPv6 topology > > hiding. The underlying IPv4 addresses probably would expose > > the network > > typology, however if they're RFC1918 ones, they'd be unreachable > > externally. > > There is probably a discussion point here, but I'll > note that other IPv4-embedding mechanisms like 6to4 > and 6rd are not shy about exposing IPv4 addresses > externally. Especially with 6rd, the IPv4 addresses > may be from the private internal IPv4 addressing realm > of the ISP, so there would seem to be precendence for > just letting the IPv4 addresses leak out. > I think people who're using those sorts of mechanisms probably aren't concerned about using topology hiding so much, or are aware that only one or a small number of public IPv4 addresses are exposed. I'm imagining a conversation with people who like the topology hiding that IPv4 NAPT provides, and think they need IPv6 NAPT for the same reason. I think you could rebut that by saying that ISATAP could be used to make all IPv6 hosts appear to be attached to a single /64, also pointing out that ISATAP implementations are commonly available. However, when they find out that underlying IPv4 addresses are embedded in the ISATAP addresses, they'll then say that thats still exposing IPv4 topology information that isn't exposed with IPv4 NAPT, and therefore ISATAP isn't adequate, and therefore they need IPv6 NAPT. So I think ISATAP is nearly capable of providing IPv6 and underlying IPv4 topology hiding, as long as the exterior devices don't see the underlying IPv4 addresses. It has just occurred to me that ISATAP + stateful DHCPv6 addressing might achieve that. Do you know if that would work or has been implemented anywhere? > > Possibly this could be resolved by having only the ISATAP > > domain link-local addresses use IPv4 addresses, and then have > > global -> > > link local IPv6 translation tables which are then used to resolve a > > global IPv6 ISATAP host address which doesn't include an interior IPv4 > > host address into a ISATAP link local and then interior IPv4 > > address. As > > external parties would only use externally visible IPv6 addresses, the > > IPv4 topology would then be hidden as well. > > I'm almost on-board with this, however I would not > want to see the site number all of its ISATAP host > interfaces with only link-local IPv6 addresses. Or, > maybe that's not what you were saying? > No, it was that the underlying IPv4 addresses were only embedded in the link local addresses used within the ISATAP domain, and the global IPv6 addresses used within the ISATAP domain were generic (non-IPv4 embedded) IPv6 addresses (e.g. SLAAC using some other non-IPv4 IID, or privacy addresses, or stateful DHCPv6 addresses). To resolve the underlying IPv4 address for inbound packets, with these generic global IPv6 addresses, the look up mechanism would be - 1. Match up the global IPv6 address to an ISATAP domain link-local address with the embedded IPv4 address. 2. Extract the IPv4 address from the link local address and use that for the encapsulating packet IPv4 destination. > What I *could* see happening is for the ISATAP > router to maintain a translation table whereby > it translates the IPv6 address 2001:db8::[ISATAP] > coming from a host within the site to the IPv6 > address 2001:db8::[EUI64] for communications with > hosts outside the site. I think the drawback of that is that it is IPv6-to-IPv6 address translation with all the related issues of NAT. > > Even moreso, ISATAP hosts inside an enterprise > network are likely to need to go through an > enterprise-border proxy in order to talk to IPv6 > servers out on the Internet, so the proxy itself > could do the translation as I suspect many IPv4 > proxies currently do today. > > Is that what you had in mind? > > Thanks - Fred > fred.l.templin@boeing.com > (got to rush off to catch my train!) Regards, Mark. From Fred.L.Templin@boeing.com Tue Apr 12 17:07:06 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F555E0708 for ; Tue, 12 Apr 2011 17:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX-p1gce41W5 for ; Tue, 12 Apr 2011 17:07:05 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id 581F3E096C for ; Tue, 12 Apr 2011 17:07:02 -0700 (PDT) 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 p3D06qOU029982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 17:06:53 -0700 (PDT) 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 p3D06q2X009332; Tue, 12 Apr 2011 17:06:52 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3D06p79009321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Apr 2011 17:06:52 -0700 (PDT) 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; Tue, 12 Apr 2011 17:06:51 -0700 From: "Templin, Fred L" To: Mark Smith Date: Tue, 12 Apr 2011 17:06:49 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) Thread-Index: Acv5ZZs8gsZF0yjcS9qrbW1HJxN2mgACBkUw Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com><20110413071247.2b efa661@opy.nosense.org> <20110413083142.1400c381@opy.nosense.org> In-Reply-To: <20110413083142.1400c381@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment inPredominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 00:07:06 -0000 Hi Mark, It sounds like what you'd prefer would be DHCPv6 over ISATAP interfaces. In that case, the routing system matches up the (non-ISATAP) DHCPv6-delegated IPv6 addresses with an ISATAP link-local address of the host to which the address has been delegated. We talk about how to do exactly that in Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops'. So, this has come down to a DHCPv6 vs SLAAC bakeoff on ISATAP links, I guess? I was told by an employee of a major host implementation vendor that their ISATAP host implementation does not do DHCPv6. But, you list a number of reasons why DHCPv6 would be beneficial. This sounds like a recipe for a food-fight. Can I run off to catch that train with you?? Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Mark Smith=20 > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > Sent: Tuesday, April 12, 2011 4:02 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > inPredominantly IPv4 Sites - (pre-draft) >=20 > Hi Fred, >=20 > On Tue, 12 Apr 2011 15:07:24 -0700 > "Templin, Fred L" wrote: >=20 > > Hi Mark,=20 > >=20 > > > -----Original Message----- > > > From: Mark Smith=20 > > > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > > > Sent: Tuesday, April 12, 2011 2:43 PM > > > To: Templin, Fred L > > > Cc: v6ops@ietf.org > > > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > > > inPredominantly IPv4 Sites - (pre-draft) > > >=20 > > > Hi Fred, > > >=20 > > > On Mon, 11 Apr 2011 11:18:14 -0700 > > > "Templin, Fred L" wrote: > > >=20 > > > > Hello, > > > >=20 > > > > The following should not be construed as a draft, but > > > > rather just a set of ideas that might be considered > > > > for inclusion in a new or existing draft. Any > > > > comments or suggestions? > > > >=20 > > >=20 > > > I don't know if it has been though of before, however one=20 > alternative > > > use of ISATAP I've thought of is to facilitate IPv6 topology > > > hiding. The underlying IPv4 addresses probably would expose=20 > > > the network > > > typology, however if they're RFC1918 ones, they'd be unreachable > > > externally. > >=20 > > There is probably a discussion point here, but I'll > > note that other IPv4-embedding mechanisms like 6to4 > > and 6rd are not shy about exposing IPv4 addresses > > externally. Especially with 6rd, the IPv4 addresses > > may be from the private internal IPv4 addressing realm > > of the ISP, so there would seem to be precendence for > > just letting the IPv4 addresses leak out. > >=20 >=20 > I think people who're using those sorts of mechanisms probably aren't > concerned about using topology hiding so much, or are aware that only > one or a small number of public IPv4 addresses are exposed. >=20 > I'm imagining a conversation with people who like the topology > hiding that IPv4 NAPT provides, and think they need IPv6 NAPT for the > same reason. I think you could rebut that by saying that ISATAP could > be used to make all IPv6 hosts appear to be attached to a single /64, > also pointing out that ISATAP implementations are commonly available. > However, when they find out that underlying IPv4 addresses=20 > are embedded > in the ISATAP addresses, they'll then say that thats still exposing > IPv4 topology information that isn't exposed with IPv4 NAPT, and > therefore ISATAP isn't adequate, and therefore they need IPv6 NAPT. >=20 > So I think ISATAP is nearly capable of providing IPv6 and underlying > IPv4 topology hiding, as long as the exterior devices don't see the > underlying IPv4 addresses. It has just occurred to me that ISATAP + > stateful DHCPv6 addressing might achieve that. Do you know if that > would work or has been implemented anywhere? >=20 >=20 > > > Possibly this could be resolved by having only the ISATAP > > > domain link-local addresses use IPv4 addresses, and then have=20 > > > global -> > > > link local IPv6 translation tables which are then used to=20 > resolve a > > > global IPv6 ISATAP host address which doesn't include an=20 > interior IPv4 > > > host address into a ISATAP link local and then interior IPv4=20 > > > address. As > > > external parties would only use externally visible IPv6=20 > addresses, the > > > IPv4 topology would then be hidden as well. > >=20 > > I'm almost on-board with this, however I would not > > want to see the site number all of its ISATAP host > > interfaces with only link-local IPv6 addresses. Or, > > maybe that's not what you were saying? > >=20 >=20 > No, it was that the underlying IPv4 addresses were only=20 > embedded in the > link local addresses used within the ISATAP domain, and the=20 > global IPv6 > addresses used within the ISATAP domain were generic (non-IPv4 > embedded) IPv6 addresses (e.g. SLAAC using some other non-IPv4 IID, or > privacy addresses, or stateful DHCPv6 addresses). >=20 > To resolve the underlying IPv4 address for inbound packets, with these > generic global IPv6 addresses, the look up mechanism would be - >=20 > 1. Match up the global IPv6 address to an ISATAP domain link-local > address with the embedded IPv4 address. > 2. Extract the IPv4 address from the link local address and use that > for the encapsulating packet IPv4 destination. >=20 > > What I *could* see happening is for the ISATAP > > router to maintain a translation table whereby > > it translates the IPv6 address 2001:db8::[ISATAP] > > coming from a host within the site to the IPv6 > > address 2001:db8::[EUI64] for communications with > > hosts outside the site. >=20 > I think the drawback of that is that it is IPv6-to-IPv6 address > translation with all the related issues of NAT. >=20 > >=20 > > Even moreso, ISATAP hosts inside an enterprise > > network are likely to need to go through an > > enterprise-border proxy in order to talk to IPv6 > > servers out on the Internet, so the proxy itself > > could do the translation as I suspect many IPv4 > > proxies currently do today. > >=20 > > Is that what you had in mind? > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 >=20 > (got to rush off to catch my train!) >=20 > Regards, > Mark. > = From newbery@gmail.com Tue Apr 12 20:57:05 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFF1DE069D for ; Tue, 12 Apr 2011 20:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JarjnRS757bS for ; Tue, 12 Apr 2011 20:57:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 93346E0670 for ; Tue, 12 Apr 2011 20:56:51 -0700 (PDT) Received: by iye19 with SMTP id 19so270399iye.31 for ; Tue, 12 Apr 2011 20:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=aAaXrzGa84HX8jRy6xTLK+VBFk2o7OsVgman7MmstQ4=; b=kSAY//0nQbkQ8FHMWk4icp9GDttCF//BRxXCPWvE8yFxCCOpoRmCqH/23MPYbJGb8o 7rW+JiCX/dFEXt8b+A6nYy9z3KU7yOnqiCsSKHo1aKkyIFMAVXMVYMaDFitY1bgbz5Wk N31epDMDRi7twnwle8WqJQOOfqKpFIfk0Vdq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=lU3+wdXG5lNUCuT/jSqiawT7rvaV3mb6i/BEhs93f4yoeirpvG1Q3UGpghy6qF9HMq DsnAO/yrMEh+voOL0VAucGRKM8kmMAGfWbIwKlPSBlieItK+YBOAvUG5AffILzKxK+Mq 8//RtQ/4B3umntpIM3ttwpMgwxSD71yG8Q1xQ= Received: by 10.43.69.197 with SMTP id yd5mr2997841icb.362.1302667010726; Tue, 12 Apr 2011 20:56:50 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id vw9sm107519icb.11.2011.04.12.20.56.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 20:56:49 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1-89773782; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 13 Apr 2011 15:56:39 +1200 In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1B5DBE3B@crexc50p> To: IPv6 Ops WG References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F1B5DBE3B@crexc50p> Message-Id: <9A6F4032-B172-4BF8-82D4-B91D60F27A95@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 03:57:05 -0000 --Apple-Mail-1-89773782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13/04/2011, at 7:56 AM, STARK, BARBARA H (ATTSI) wrote: > It's true that there exist a great number of "bridge modems" for both > DOCSIS and DSL. These bridge Ethernet MAC between DOCSIS or (ATM)/DSL > and Ethernet PHY. They will continue to exist, and there's nothing = wrong > with them (unless your access provider changes the access PHY ;) ). = They > won't break in the presence of IPv6, because they truly don't care > what's above the Ethernet MAC layer.=20 Not quite. DOCSIS modems are indeed bridges, but they are IP aware = bridges. In particular they have extensive filters in place, based on = Ethertype, IP address and netmask. Furthermore, they can snoop the = traffic for DHCP. That's why DOCSIS 3.0 needed to add IPv6 support. All = of the IP filters and DHCP support are IPv4 only with DOCSIS = 1.0/1.1/2.0, which reduces the filter options to Ethertype, which means = you can allow or deny IPv6, but not filter it. Those filters are there for a reason. Actually, many reasons, which I = don't think I need to go into here. Suffice it to say that without them, = many service providers are forced to deny IPv6 carriage, which means = that DOCSIS 1.0/1.1/2.0 networks may be layer 2, but they nevertheless = don't support IPv6. DOCSIS 3.0 does, and the IPv6 filters have been = backported to DOCOS 2.0 and are available if your cable modem can = support the firmware upgrade (not all have the necessary hardware = capability). Note that this is probably not strictly relevant to the document in = question.= --Apple-Mail-1-89773782 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNDEzMDM1NjQ0 WjAjBgkqhkiG9w0BCQQxFgQUWHc8A/Ma7GazUV1znss2WdIjGqYwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBAAl3gCqXloA7wSeG6gd/GfGBGI3Oc1j4nG6aN2ghELp4WKuy5gMwLE1YtoKs m0WZhxHzGrUm8phZjUBkoIoMnkAm/D5wPrto1zcfqw9IwcFEzMG7+QtX6XK2F+GPdyTQSN6UyPB5 2MZAlBIYlrTHMO1xcTFRKLjAYJQBLy4PyC7iMM5m3OaM6/6NDGFPdsyMYZaB7PgFDHliCB9YrIdI OGzm3JT1j4yTeS71soDh2JmjNMEUih+cIzmw+BgcKHFhld/Em0ipKtvOWfESZpbKUazgCJPbC/Wx F2pAtANbBT8vFNTQ5Sz1KGYcpCJNPufM/I95GYWz6WlBiQV/yPrMShkAAAAAAAA= --Apple-Mail-1-89773782-- From brian.e.carpenter@gmail.com Tue Apr 12 23:50:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D64DFE06E3 for ; Tue, 12 Apr 2011 23:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzombJHwviVE for ; Tue, 12 Apr 2011 23:50:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3A5DBE06D1 for ; Tue, 12 Apr 2011 23:50:28 -0700 (PDT) Received: by wyb29 with SMTP id 29so250833wyb.31 for ; Tue, 12 Apr 2011 23:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CY7MrffSGl1ZDw1JKe0aUJibmNIyVJdCilD22gaYoSY=; b=REcEApaq0Ti4OKDMKc+VKwVjNu+GLtc5PlCF4vjHYcihdNXSOCfteOWr2J3nDx9fjx v/YJDUtghLBbhx41dQvW0Z3VLZVxqwZKcUuoUoljK/GRwX9RmzSgSgQk91rh5RGWd8WL 4dskAlZbunIoz7AAER814KjqyuA6s5AHGbC8g= 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=E4le3q6y946M/DCl4wTWb6v+zpy1Qusd28y+80hxneB51DPQaVroWsg++alWIobrK4 mcYxRE2JBHKLi5pHmxS8k3uRHvcmlq4goXsPRyzgDD75RnReHs+5SIdE8xdpntAfjSGn HvbBVkpraUETOa88tHuLPHydrMTdtcGdOGQGU= Received: by 10.216.173.12 with SMTP id u12mr5386491wel.18.1302677427522; Tue, 12 Apr 2011 23:50:27 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id g22sm83394wes.36.2011.04.12.23.50.25 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 23:50:26 -0700 (PDT) Message-ID: <4DA547B0.9080304@gmail.com> Date: Wed, 13 Apr 2011 18:50:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 06:50:30 -0000 On 2011-04-13 09:24, james woodyatt wrote: > On Apr 12, 2011, at 12:20 , Doug Barton wrote: >> On the other hand, the unsuccessful 6to4 connections have a very high cost in that they are a major contributing factor causing content providers to be hesitant to deploy real IPv6. One could also argue that the presence of 6to4 has created a reduced incentive for ISPs as well, but I don't place a lot of weight on that argument. > > I don't believe this claim of high costs associated with failed 6to4 is supported by evidence. Furthermore, I fail to see how deprecating 6to4 will do anything to increase the incentives for either content providers or Internet service providers to deploy native IPv6 applications and service. > > The content providers can identify plenty of other sources of IPv6 brokenness with which to excuse dragging their heels to effect the transition. Those source mainly revolve around buggy CPE router implementations that have nothing to do with 6to4 or its anycast relay service. Moreover, the incumbent service providers have little incentive to deploy native IPv6 while content providers are still available over IPv4 and they are protected from competition because NAT444 offers better customer lock-in mechanisms than DS and DS-lite. > > I therefore contend that deprecating 6to4 now is a waste of IETF time. The utility of 6to4 will wither away naturally over time. Attempting to hurry it along by publishing an RFC will help no one. I fully agree with James, and unlike Doug I believe that it would be totally wrong for us to intentionally break working connectivity (via 6to4 or any other mechanism). Specifically, some people use 6to4 because it works; it's considerably more bother to find a tunnel broker. I'm not fighting against draft-ietf-v6ops-6to4-to-historic, because it's harmless to existing users and may reduce future problems. But if ISPs do what is suggested in draft-ietf-v6ops-6to4-advisory, things will be better *for their customers and for their OPEX* before, during and after IPv6 day. Brian From gvandeve@cisco.com Wed Apr 13 01:25:15 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53303E06B0 for ; Wed, 13 Apr 2011 01:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.962 X-Spam-Level: X-Spam-Status: No, score=-8.962 tagged_above=-999 required=5 tests=[AWL=1.637, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSgiW+ksrlYo for ; Wed, 13 Apr 2011 01:25:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id D10C8E065F for ; Wed, 13 Apr 2011 01:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=568; q=dns/txt; s=iport; t=1302683114; x=1303892714; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mmqXxNEtLTjd0Av4NDHs1CTKR115cl3VnnMSOQm5JZ0=; b=Zj7Rtrei4aeknKsAOYCZ7xXSv5ayVlbQHSudKVoMe3/3qpn9kgwZVXAg vYMLoZGw9AAyJv4jx5jilhgrdmP8mdMd1WY6eSg4wWH85FVWjKfGrAPlk thzcwniSVY3JHXwluo4bnSA/eE9szXaQmi41LuFUlq7saZm6iumwghw4C U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8EAIldpU2Q/khNgWdsb2JhbACmBxQBARYmJaZUnHiFbgSRYg X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25511987" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 08:25:11 +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 p3D8P9eg008937; Wed, 13 Apr 2011 08:25:09 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 10:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 10:25:06 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> In-Reply-To: <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv38zfMLRF/cXU7QJKEPkuOcscreABwOiYw References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com><0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4D9D2D50.4040801@dougbarton.us><0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com><4D9EB2FF.2060900@gmail.com><3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com><4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> From: "Gunter Van de Velde (gvandeve)" To: "Kevin Day" , "Cameron Byrne" X-OriginalArrivalTime: 13 Apr 2011 08:25:09.0233 (UTC) FILETIME=[4D0D2E10:01CBF9B4] Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:25:15 -0000 Another single-datapoint anecdote: We used to receive at least one complaint a month about our 6to4 relay not working (which pretty much always was traced down to the reverse path being broken, not us), but those complaints have pretty much stopped entirely in the last year. I don't know if this is because people are getting better at deploying 6to4, or if people know enough to switch to another option if it's broken. GV> They probably did an internet-searched and discovered that they have the problem go away with disabling IPv6 on their device :-) From fancy@cht.com.tw Wed Apr 13 01:28:35 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B55EE066A for ; Wed, 13 Apr 2011 01:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.236 X-Spam-Level: ** X-Spam-Status: No, score=2.236 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmAsQoiE+5zt for ; Wed, 13 Apr 2011 01:28:33 -0700 (PDT) Received: from scan2.cht.com.tw (scan2.cht.com.tw [202.39.168.16]) by ietfc.amsl.com (Postfix) with ESMTP id D1A7FE065F for ; Wed, 13 Apr 2011 01:28:32 -0700 (PDT) X-AuditID: 0aa00267-a44c6ba000000b34-19-4da55ead4e75 Received: from cas1.corp.cht.com.tw (unknown [10.160.2.147]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id 569111545B5 for ; Wed, 13 Apr 2011 16:28:29 +0800 (CST) Received: from MAIL.corp.cht.com.tw ([10.160.1.132]) by cas1.corp.cht.com.tw ([10.160.2.147]) with mapi; Wed, 13 Apr 2011 16:28:29 +0800 From: =?big5?B?reKq2rfsKEZhbmctWXUgTGluZyk=?= To: IPv6 Ops WG Date: Wed, 13 Apr 2011 16:28:32 +0800 Thread-Topic: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt Thread-Index: Acv5jvCgLfs6vCa2TqGDrbX4LhqgvAAJbUvQ Message-ID: <19614F693882ED4DA4481CBE85DDE4B3011BA3C0A92C@MAIL.corp.cht.com.tw> References: <201104081355.p38Dt0C04514@ftpeng-update.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F1B5DBE3B@crexc50p> <9A6F4032-B172-4BF8-82D4-B91D60F27A95@gmail.com> In-Reply-To: <9A6F4032-B172-4BF8-82D4-B91D60F27A95@gmail.com> Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-TW, en-US Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:28:35 -0000 SGkgQWxsLCANCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpPdXIgY29tcGFueSBpcyBh biBJU1AgaW4gVGFpd2FuLiBXZSBkbyBlbmNvdW50ZXIgdGhlIGNvZXhpc3QgcHJvYmxlbXMgb2Yg YnJpZGdlZCBhbmQgcm91dGVkIG1vZGUuDQpXZSBoYXZlIGRlcGxveWVkIHRoZSBtb2RlbCB3aGlj aCBpcyBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBpbiBhIHRyaWFsIGVudmlyb25tZW50IHdpdGgg aHVuZHJlZHMgY3VzdG9tZXJzLg0KV2UgZG8gdGhpbmsgaXQgaXMgYSBzdWNjZXNzZnVsIG1vZGVs IGFmdGVyIG9uZSB5ZWFyIGV4cGVyaW1lbnQuDQpXZSBob3BlIHRvIHNoYXJlIHRoaXMgZXhwZXJp ZW5jZSB0byBvdGhlciBJU1BzIHdobyBoYXZlIHRoZSBzYW1lIHJlcXVpcmVtZW50Lg0KDQpTb21l dGhpbmcgd2UgbmVlZCB0byBjbGFyaWZ5Og0KMS4gV2UgcHJvdmlkZSBWRFNMIGFjY2VzcyBzZXJ2 aWNlIGluIG91ciBjb21wYW55LiBCdXQgb3VyIG1vZGVsIGNhbiBiZSB1c2VkIGZvciBhbnkgb3Ro ZXIgcGh5c2ljYWwgbmV0d29yaywgbm90IG9ubHkgZm9yIEFUTS4NCg0KMi4gSW4gb3VyIGRyYWZ0 LCB0aGUgImJyaWRnZWQgbW9kZSIgQ1BFIGNhbiBiZSBhICJEU0wgTW9kZW0iLCBvbmx5IGhhcyBi cmlkZ2UgZnVuY3Rpb24uIFN1YnNjcmliZXIgY29ubmVjdHMgYSByb3V0ZXIgYmVoaW5kIHRoaXMg Q1BFIGlzIG91dCBvZiB0aGUgc2NvcGUuIEFuZCB0aGUgInJvdXRlZCBtb2RlIiBDUEUgaXMgYSBy b3V0ZXIgd2hpY2ggaXMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1jcGUtcm91 dGVyLTA5IChCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJz KSBvciB5b3UgY2FuIHNheSBpdCBpcyBhIEhvbWUgR2F0ZXdheS4NCg0KMy4gVGhlIHByb2JsZW0g d2UnZCBsaWtlIHRvIHNvbHZlIGlzIHRvIHNpbXBsaWZ5IHRoZSBjb25maWd1cmF0aW9uIG9mIFBF LiBCZWZvcmUgdGhpcyBtb2RlbCwgUEUncyBvcGVyYXRvciBoYXMgdG8ga25vdyB0aGUgc3Vic2Ny aWJlciBpcyBpbiBicmlkZ2Ugb3Igcm91dGVkIG1vZGUuIFRoZSBvcGVyYXRvciBjb25maWd1cmVz IGEgSVB2NiBhZGRyZXNzIGZvciBSQSBpZiB0aGUgc3Vic2NyaWJlciBpcyBpbiBicmlkZ2VkIG1v ZGUuIFRoZSBvcGVyYXRvciBjb25maWd1cmVzIGEgSVB2NiBwcmVmaXggZm9yIERIQ1AtUEQgaWYg dGhlIHN1YnNjcmliZXIgaXMgaW4gcm91dGVkIG1vZGUuIEJ1dCBpbiBvdXIgbW9kZWwsIG9wZXJh dG9yIGNvbmZpZ3VyZXMgYm90aCBmb3IgZWFjaCBubyBtYXR0ZXIgdGhlIHN1YnNjcmliZXIgaXMg aW4gd2hpY2ggbW9kZS4gSXQgaXMgdG8gc2ltcGxpZnkgdGhlIGNvbmZpZ3VyYXRpb24uDQoNClJl Z2FyZHMsDQpGYW5nDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpGYW5nLVl1IExpbmcNCkNodW5naHdhIFRlbGVjb20gTGFib3JhdG9yaWVzDQptYWlsdG86ZmFu Y3lAY2h0LmNvbS50dw0KVEVMOiArODg2LTMtNDI0LTU2MzENCkZBWDogKzg4Ni0zLTQyNC00ODg4 DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNo YWVsIE5ld2JlcnkNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMsIDIwMTEgMTE6NTcgQU0NClRv OiBJUHY2IE9wcyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OmRyYWZ0LWZsaW5n LXY2b3BzLWh5YnJpZC1icmlkZ2VkLXJvdXRlZC0wMC50eHQNCg0KDQpPbiAxMy8wNC8yMDExLCBh dCA3OjU2IEFNLCBTVEFSSywgQkFSQkFSQSBIIChBVFRTSSkgd3JvdGU6DQoNCj4gSXQncyB0cnVl IHRoYXQgdGhlcmUgZXhpc3QgYSBncmVhdCBudW1iZXIgb2YgImJyaWRnZSBtb2RlbXMiIGZvciBi b3RoIA0KPiBET0NTSVMgYW5kIERTTC4gVGhlc2UgYnJpZGdlIEV0aGVybmV0IE1BQyBiZXR3ZWVu IERPQ1NJUyBvciAoQVRNKS9EU0wgDQo+IGFuZCBFdGhlcm5ldCBQSFkuIFRoZXkgd2lsbCBjb250 aW51ZSB0byBleGlzdCwgYW5kIHRoZXJlJ3Mgbm90aGluZyANCj4gd3Jvbmcgd2l0aCB0aGVtICh1 bmxlc3MgeW91ciBhY2Nlc3MgcHJvdmlkZXIgY2hhbmdlcyB0aGUgYWNjZXNzIFBIWSA7KSANCj4g KS4gVGhleSB3b24ndCBicmVhayBpbiB0aGUgcHJlc2VuY2Ugb2YgSVB2NiwgYmVjYXVzZSB0aGV5 IHRydWx5IGRvbid0IA0KPiBjYXJlIHdoYXQncyBhYm92ZSB0aGUgRXRoZXJuZXQgTUFDIGxheWVy Lg0KDQpOb3QgcXVpdGUuIERPQ1NJUyBtb2RlbXMgYXJlIGluZGVlZCBicmlkZ2VzLCBidXQgdGhl eSBhcmUgSVAgYXdhcmUgYnJpZGdlcy4gSW4gcGFydGljdWxhciB0aGV5IGhhdmUgZXh0ZW5zaXZl IGZpbHRlcnMgaW4gcGxhY2UsIGJhc2VkIG9uIEV0aGVydHlwZSwgSVAgYWRkcmVzcyBhbmQgbmV0 bWFzay4gRnVydGhlcm1vcmUsIHRoZXkgY2FuIHNub29wIHRoZSB0cmFmZmljIGZvciBESENQLiBU aGF0J3Mgd2h5IERPQ1NJUyAzLjAgbmVlZGVkIHRvIGFkZCBJUHY2IHN1cHBvcnQuIEFsbCBvZiB0 aGUgSVAgZmlsdGVycyBhbmQgREhDUCBzdXBwb3J0IGFyZSBJUHY0IG9ubHkgd2l0aCBET0NTSVMg MS4wLzEuMS8yLjAsIHdoaWNoIHJlZHVjZXMgdGhlIGZpbHRlciBvcHRpb25zIHRvIEV0aGVydHlw ZSwgd2hpY2ggbWVhbnMgeW91IGNhbiBhbGxvdyBvciBkZW55IElQdjYsIGJ1dCBub3QgZmlsdGVy IGl0Lg0KDQpUaG9zZSBmaWx0ZXJzIGFyZSB0aGVyZSBmb3IgYSByZWFzb24uIEFjdHVhbGx5LCBt YW55IHJlYXNvbnMsIHdoaWNoIEkgZG9uJ3QgdGhpbmsgSSBuZWVkIHRvIGdvIGludG8gaGVyZS4g U3VmZmljZSBpdCB0byBzYXkgdGhhdCB3aXRob3V0IHRoZW0sIG1hbnkgc2VydmljZSBwcm92aWRl cnMgYXJlIGZvcmNlZCB0byBkZW55IElQdjYgY2FycmlhZ2UsIHdoaWNoIG1lYW5zIHRoYXQgRE9D U0lTIDEuMC8xLjEvMi4wIG5ldHdvcmtzIG1heSBiZSBsYXllciAyLCBidXQgdGhleSBuZXZlcnRo ZWxlc3MgZG9uJ3Qgc3VwcG9ydCBJUHY2LiBET0NTSVMgMy4wIGRvZXMsIGFuZCB0aGUgSVB2NiBm aWx0ZXJzIGhhdmUgYmVlbiBiYWNrcG9ydGVkIHRvIERPQ09TIDIuMCBhbmQgYXJlIGF2YWlsYWJs ZSBpZiB5b3VyIGNhYmxlIG1vZGVtIGNhbiBzdXBwb3J0IHRoZSBmaXJtd2FyZSB1cGdyYWRlIChu b3QgYWxsIGhhdmUgdGhlIG5lY2Vzc2FyeSBoYXJkd2FyZSBjYXBhYmlsaXR5KS4NCg0KTm90ZSB0 aGF0IHRoaXMgaXMgcHJvYmFibHkgbm90IHN0cmljdGx5IHJlbGV2YW50IHRvIHRoZSBkb2N1bWVu dCBpbiBxdWVzdGlvbi4NCg== From john.mann@monash.edu Wed Apr 13 02:23:19 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 919E2E06ED for ; Wed, 13 Apr 2011 02:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nORY0AqPW2YH for ; Wed, 13 Apr 2011 02:23:18 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfc.amsl.com (Postfix) with ESMTP id 04C9DE06A9 for ; Wed, 13 Apr 2011 02:23:17 -0700 (PDT) Received: from mail-vx0-f176.google.com ([209.85.220.176]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTaVrhUEXIQC01Yl4jy+3EfMv7oiciI1Q@postini.com; Wed, 13 Apr 2011 02:23:18 PDT Received: by mail-vx0-f176.google.com with SMTP id 37so442660vxa.21 for ; Wed, 13 Apr 2011 02:23:17 -0700 (PDT) Received: by 10.52.173.38 with SMTP id bh6mr5929122vdc.296.1302686597074; Wed, 13 Apr 2011 02:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.182.226 with HTTP; Wed, 13 Apr 2011 02:22:57 -0700 (PDT) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> From: "John Mann (ITS)" Date: Wed, 13 Apr 2011 19:22:57 +1000 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=bcaec517c4fcdf4f6404a0c95b4a Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:23:19 -0000 --bcaec517c4fcdf4f6404a0c95b4a Content-Type: text/plain; charset=ISO-8859-1 Hi, On 13 April 2011 07:24, james woodyatt wrote: > On Apr 12, 2011, at 12:20 , Doug Barton wrote: > > > > On the other hand, the unsuccessful 6to4 connections have a very high > cost in that they are a major contributing factor causing content providers > to be hesitant to deploy real IPv6. One could also argue that the presence > of 6to4 has created a reduced incentive for ISPs as well, but I don't place > a lot of weight on that argument. > > I don't believe this claim of high costs associated with failed 6to4 is > supported by evidence. ... I can't provide overall numbers, but I can provide anecdotal evidence. As I remember it ... in November 2008, I enabled IPv6 on http://www.monash.edu.au (that's Monash acting as content provider). IPv6 was only enabled on a few user subnets. Everything went well over the Christmas break. Then, with the start of the academic year in 2009, users started reporting problems (that's Monash acting as an access provider). Users starting reporting slowness or complete inability to get to www.monash.edu.au Often Macs ... and it was often tracked down to nearby Windows Vista laptops. By tracking down and disabling IPv6 on that laptop and/or disabling IPv6 on all the Macs we were kept busy, but were keeping the problem manageable. Student machines are harder to track down ... In parallel, we were trying other solutions, such as enabling real IPv6 dual-stack on the affected subnets. This helped, but sometimes Macs would align themselves with the rogue 6to4 RAs rather than to our Cisco router RAs. And then some Professors had troubles. Not only was accessing Monash web sites slow, but late every afternoon, they became unusable. Professors don't call ITS Helpdesk -- they complain to the Dean that their ability to do important research and apply for grants is compromised !! Deans don't call ITS Helpdesk -- they complain at University IT Steering committee meetings !! Eventually, the problem filters down the chain of command to us. We were quickly able to identify the problem and solve it, and spent the next 2 days in their building smoothing things over. It was a laptop tunneling all IPv6 traffic out to a 6to4 relay and then back into Monash - slow access. And at 4:30pm each day the user took the laptop home, but the Macs still had a default IPv6 route and continued sending IPv6 traffic to the PC's Ethernet address until the route expired -- blackholing all IPv6 traffic. We did *not* tell the users that the problem was triggered by turning on IPv6 on the main web site. But we did turn off IPv6 on the main web site for a couple of days. But I promised that after we got over _this_ problem, all would be well with IPv6. And we turned IPv6 back on for the main web site. Next I did a large amount of work to enable RA filtering on every user-facing Catalyst 3750 switch port. So, yes, unsuccessful 6to4 connections did almost stop/reverse Monash's IPv6 content-provider rollout. And it cost a lot of effort to make Monash's access-provider network safe against 6to4 rogue routers. John --bcaec517c4fcdf4f6404a0c95b4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 13 April 2011 07:24, james woodyat= t <jhw@apple.com&= gt; wrote:
On Apr 12, 2011, at 12:20 , Doug Barton wrote:
>
> On the other hand, the unsuccessful 6to4 connections have a very high = cost in that they are a major contributing factor causing content providers= to be hesitant to deploy real IPv6. One could also argue that the presence= of 6to4 has created a reduced incentive for ISPs as well, but I don't = place a lot of weight on that argument.

I don't believe this claim of high costs associated with failed 6= to4 is supported by evidence. ...

I can'= ;t provide overall numbers, but I can provide anecdotal evidence.

As I remember it ... in November 2008, I enabled IPv6 o= n http://www.monash.edu.au (that&#= 39;s Monash acting as content provider).
IPv6 was only enabled on= a few user subnets.
Everything went well over the Christmas break.

Then, with the start of the academic year in 2009, users started reportin= g problems (that's Monash acting as an access provider).
Users starting reporting slowness or complete inability to get to=A0www.monash.edu.au
Often Macs ..= . and it was often tracked down to nearby Windows Vista laptops.
By tracking down and disabling IPv6 on that laptop and/or disabling IPv6 on= all the Macs we were kept busy, but were keeping the problem=A0manageable.=
Student machines are harder to track down ...

In parallel, we were trying other solutions, such as enabling real IPv= 6 dual-stack on the affected subnets.
This helped, but sometimes = Macs would align themselves with the rogue 6to4 RAs rather than to our Cisc= o router RAs.

And then some Professors had troubles. =A0Not only was = accessing Monash web sites slow, but late every afternoon, they became unus= able.
Professors don't call ITS Helpdesk -- they complain to = the Dean that their ability to do important research and apply for grants i= s compromised !!
Deans don't call ITS Helpdesk -- they complain at University IT St= eering committee meetings !!

Eventually, the probl= em filters down the chain of command to us.
We were quickly able = to identify the problem and solve it, and spent the next 2 days in their bu= ilding smoothing things over.
It was a laptop tunneling all IPv6 traffic out to a 6to4 relay and the= n back into Monash - slow access.
And at 4:30pm each day the user= took the laptop home, but the Macs still had a default IPv6 route and cont= inued sending IPv6 traffic to the PC's Ethernet address until the route= expired -- blackholing all IPv6 traffic.

We did *not* tell the users that the problem was trigge= red by turning on IPv6 on the main web site.
But we did turn off = IPv6 on the main web site for a couple of days.

But I promised that after we got over _this_ problem, all would be well wit= h IPv6.
And we turned IPv6 back on for=A0the main web site.
=
Next I did a large amount of work to enable RA filtering on every user= -facing Catalyst 3750 switch port.

So, yes, unsuccessful 6to4 connections did almost stop/= reverse Monash's IPv6 content-provider rollout.
And it cost a= lot of effort to make Monash's access-provider network safe against 6t= o4 rogue routers.

=A0 =A0 John
--bcaec517c4fcdf4f6404a0c95b4a-- From swmike@swm.pp.se Wed Apr 13 02:45:20 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 379BBE0613 for ; Wed, 13 Apr 2011 02:45:20 -0700 (PDT) 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.058, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQE2r1zcuG7W for ; Wed, 13 Apr 2011 02:45:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 12318E0684 for ; Wed, 13 Apr 2011 02:45:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5D7E29E; Wed, 13 Apr 2011 11:45:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5A2E69A; Wed, 13 Apr 2011 11:45:15 +0200 (CEST) Date: Wed, 13 Apr 2011 11:45:15 +0200 (CEST) From: Mikael Abrahamsson To: "John Mann (ITS)" In-Reply-To: Message-ID: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:45:20 -0000 On Wed, 13 Apr 2011, John Mann (ITS) wrote: > And it cost a lot of effort to make Monash's access-provider network > safe against 6to4 rogue routers. Were you able to motivate and get buy-in from higher management that implementing proper filtering (SAVI) in the network is important after all these problems? -- Mikael Abrahamsson email: swmike@swm.pp.se From pch-b6B5344D9@u-1.phicoh.com Wed Apr 13 02:51:43 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8576EE0692 for ; Wed, 13 Apr 2011 02:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxumc8-KXsuJ for ; Wed, 13 Apr 2011 02:51:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 4A3F3E0613 for ; Wed, 13 Apr 2011 02:51:41 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1Q9wjc-0001ffC; Wed, 13 Apr 2011 11:51 +0200 Message-Id: To: "John Mann (ITS)" From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> In-reply-to: Your message of "Wed, 13 Apr 2011 19:22:57 +1000 ." Date: Wed, 13 Apr 2011 11:51:36 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:51:43 -0000 In your letter dated Wed, 13 Apr 2011 19:22:57 +1000 you wrote: >And at 4:30pm each day the user took the laptop home, but the Macs still had >a default IPv6 route and continued sending IPv6 traffic to the PC's Ethernet >address until the route expired -- blackholing all IPv6 traffic. I wonder wonder what went wrong there. According to the neighbor discovery RFC, reachable time is 30 seconds. After that, a couple of probes once a second and the rogue router is declared unreachable. And at that point the host should switch over to a router that is actually reachable. From gert@space.net Wed Apr 13 02:57:02 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2A29E06A2 for ; Wed, 13 Apr 2011 02:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcSrGJfbYf06 for ; Wed, 13 Apr 2011 02:57:02 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfc.amsl.com (Postfix) with ESMTP id 65E96E0678 for ; Wed, 13 Apr 2011 02:56:59 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D0104F820C for ; Wed, 13 Apr 2011 11:56:58 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BE3FDF81F8 for ; Wed, 13 Apr 2011 11:56:58 +0200 (CEST) Received: (qmail 3992 invoked by uid 1007); 13 Apr 2011 11:56:58 +0200 Date: Wed, 13 Apr 2011 11:56:58 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20110413095658.GR30227@Space.Net> References: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:57:03 -0000 Hi, On Wed, Apr 13, 2011 at 11:51:36AM +0200, Philip Homburg wrote: > In your letter dated Wed, 13 Apr 2011 19:22:57 +1000 you wrote: > >And at 4:30pm each day the user took the laptop home, but the Macs still had > >a default IPv6 route and continued sending IPv6 traffic to the PC's Ethernet > >address until the route expired -- blackholing all IPv6 traffic. > > I wonder wonder what went wrong there. According to the neighbor discovery > RFC, reachable time is 30 seconds. After that, a couple of probes once a second > and the rogue router is declared unreachable. And at that point the host > should switch over to a router that is actually reachable. Possibly it switched to the "proper router" but continued to use the no-longer-working source address (6to4-based)... That's at least what I've observed on my Linux systems at home - if a "rogue RA" is seen, the Linux will eventually stop using that router, but the rogue IPv6 address will stick, and will continue sabotaging IPv6 for a long time. (Same scope as the "working" address, so source address selection doesn't help) 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 brian.e.carpenter@gmail.com Wed Apr 13 03:07:00 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53641E06C0 for ; Wed, 13 Apr 2011 03:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3iklBRzDdHT for ; Wed, 13 Apr 2011 03:06:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 43686E06BB for ; Wed, 13 Apr 2011 03:06:59 -0700 (PDT) Received: by wwa36 with SMTP id 36so329563wwa.13 for ; Wed, 13 Apr 2011 03:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tUYV969xKYQCqJvA0sXKUdgRQoRFrdw0qQPtRqo+Vow=; b=Oc5Q83y+3GpZJq5MuF2STVAJJI1rb8YRnJPN3wyVNBgXwP2f/rNxeJxp1fqatU9IZS FkOyZTFK72NCBRRkFNY48oKQKKwBfYtgQNeLTnNtrlfZA54/RJVrwdvdz6TlsfFFpKXj y9DHSZiyK60Ev8/O9diO7c2GGlzsYWMq1E0O0= 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=hJ+aEQkTLKlHb2/+mCnQf3m3d4PuoarV0/AlZ6y47kaCTJtuA1fPJaeKE4VhhH4S+M 14mz0g+8n29kClvJCzA9nDcFT/LwfKLAmpg+U0W8GteQxH4mRHp3+QK7U85U52fRCtB7 XSp0z9P1lTmLka15twDxzQ2DmegZRu6IpH4tI= Received: by 10.227.110.147 with SMTP id n19mr7451917wbp.51.1302689218593; Wed, 13 Apr 2011 03:06:58 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id bd8sm230704wbb.14.2011.04.13.03.06.57 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 03:06:57 -0700 (PDT) Message-ID: <4DA575C1.9060304@gmail.com> Date: Wed, 13 Apr 2011 22:06:57 +1200 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: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com><0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4D9D2D50.4040801@dougbarton.us><0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com><4D9EB2FF.2060900@gmail.com><3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com><4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:07:00 -0000 On 2011-04-13 20:25, Gunter Van de Velde (gvandeve) wrote: > Another single-datapoint anecdote: We used to receive at least one > complaint a month about our 6to4 relay not working (which pretty much > always was traced down to the reverse path being broken, not us), but > those complaints have pretty much stopped entirely in the last year. I > don't know if this is because people are getting better at deploying > 6to4, or if people know enough to switch to another option if it's > broken. > > GV> They probably did an internet-searched and discovered that they have > the problem go away with disabling IPv6 on their device :-) This is not very scientific as an analysis. We need data, as in the excellent example below, to get some idea of the total usage as well as the problem cases: http://stats.ottix.net/ipv6/ Brian From brian.e.carpenter@gmail.com Wed Apr 13 03:13:05 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCC19E0663 for ; Wed, 13 Apr 2011 03:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J41xXofZuq5w for ; Wed, 13 Apr 2011 03:12:55 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id E5D34E06CD for ; Wed, 13 Apr 2011 03:12:54 -0700 (PDT) Received: by fxm15 with SMTP id 15so390969fxm.31 for ; Wed, 13 Apr 2011 03:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kXGpUVSTXRELPzPzJEkjsjl8VZmD51J/rPgOeX7u68E=; b=MBminCdA/g8mjPLRdJJAQ6s9m5q3YamEDg2Jdy9ck51JBjC3RKd+QCcS2Lald6+2d9 3JsnTUKxrGUY4deStdHzUTNs2oRuXQP60HlevFeDmlCE7n7Pb9TvTb5ifs0bgDCjkPXJ Ga49/4j70MkwXIeu/Wpo9hErsbA9v5C9XDNeg= 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=H0cnnR8wmdspKctn7bxGcsaG8s5Yvnz8ET9hYB7BmIXw8goRXyEkvOe75QPRwyRX9O d6UkwGG7AU8zipDrjD+YF1M8Tew6cXVAGPChI+gojtKzZh1ewFAA2bjwcnRBDR2NYOx4 lkOU/+BfZj+5f3vKjKs9TqL+ptRJrK8PF67S8= Received: by 10.223.14.137 with SMTP id g9mr710923faa.1.1302689574010; Wed, 13 Apr 2011 03:12:54 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id f15sm127097fax.34.2011.04.13.03.12.52 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 03:12:53 -0700 (PDT) Message-ID: <4DA57724.9030408@gmail.com> Date: Wed, 13 Apr 2011 22:12:52 +1200 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: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> In-Reply-To: <20110413095658.GR30227@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:13:06 -0000 Could you look at the advice re Rogue RA in draft-ietf-v6ops-6to4-advisory-00 and suggest how it can be made more complete? Section 4.1 bullet 5, the end of Section 4.2, and Section 4.3 mention this issue. Thanks Brian On 2011-04-13 21:56, Gert Doering wrote: > Hi, > > On Wed, Apr 13, 2011 at 11:51:36AM +0200, Philip Homburg wrote: >> In your letter dated Wed, 13 Apr 2011 19:22:57 +1000 you wrote: >>> And at 4:30pm each day the user took the laptop home, but the Macs still had >>> a default IPv6 route and continued sending IPv6 traffic to the PC's Ethernet >>> address until the route expired -- blackholing all IPv6 traffic. >> I wonder wonder what went wrong there. According to the neighbor discovery >> RFC, reachable time is 30 seconds. After that, a couple of probes once a second >> and the rogue router is declared unreachable. And at that point the host >> should switch over to a router that is actually reachable. > > Possibly it switched to the "proper router" but continued to use the > no-longer-working source address (6to4-based)... > > That's at least what I've observed on my Linux systems at home - if a > "rogue RA" is seen, the Linux will eventually stop using that router, but > the rogue IPv6 address will stick, and will continue sabotaging IPv6 for > a long time. (Same scope as the "working" address, so source address > selection doesn't help) > > Gert Doering > -- NetMaster From mark@townsley.net Wed Apr 13 03:20:33 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3846E06B2 for ; Wed, 13 Apr 2011 03:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFK5ducohEjh for ; Wed, 13 Apr 2011 03:20:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0C057E0613 for ; Wed, 13 Apr 2011 03:20:32 -0700 (PDT) Received: by wwa36 with SMTP id 36so337829wwa.13 for ; Wed, 13 Apr 2011 03:20:32 -0700 (PDT) Received: by 10.227.149.11 with SMTP id r11mr5133773wbv.165.1302690032315; Wed, 13 Apr 2011 03:20:32 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id b20sm235148wbb.67.2011.04.13.03.20.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 03:20:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4DA575C1.9060304@gmail.com> Date: Wed, 13 Apr 2011 12:20:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21CA8579-04BB-4F07-8B81-2EF7210B05E8@townsley.net> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com><0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4D9D2D50.4040801@dougbarton.us><0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com><4D9EB2FF.2060900@gmail.com><3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com><4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> <4DA575C1.9060304@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:20:34 -0000 On Apr 13, 2011, at 12:06 PM, Brian E Carpenter wrote: > On 2011-04-13 20:25, Gunter Van de Velde (gvandeve) wrote: >> Another single-datapoint anecdote: We used to receive at least one >> complaint a month about our 6to4 relay not working (which pretty much >> always was traced down to the reverse path being broken, not us), but >> those complaints have pretty much stopped entirely in the last year. = I >> don't know if this is because people are getting better at deploying >> 6to4, or if people know enough to switch to another option if it's >> broken. >>=20 >> GV> They probably did an internet-searched and discovered that they = have >> the problem go away with disabling IPv6 on their device :-) >=20 > This is not very scientific as an analysis. We need data, as in the = excellent > example below, to get some idea of the total usage as well as the = problem cases: >=20 > http://stats.ottix.net/ipv6/ Nice data. How are you discerning problem cases from this though? >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Wed Apr 13 03:20:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA1DFE0713 for ; Wed, 13 Apr 2011 03:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.195 X-Spam-Level: X-Spam-Status: No, score=-9.195 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UjSLv4xNm1a for ; Wed, 13 Apr 2011 03:20:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 51139E06F8 for ; Wed, 13 Apr 2011 03:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1040; q=dns/txt; s=iport; t=1302690037; x=1303899637; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0jcNJtH+2X0r+rEGmW/CACAYGzc9/TGNVj/4Vdms4KI=; b=Y/G021amhQhXPHO4Odvc6gRDeDhRlwm/cmdviR7FRaIrRkxfwluqLhtA vQcnKGfjyPVPDfxG+WZF2awlgsE4K8L2tR/Chuy5rWlO4KC+eGXyLvW+B RslGFZm/4nzWg/whs3iTMt1qO1OFozpUr9g18I+Y5+8ZV1IKl252blMnH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEEAMB3pU2Q/khMgWdsb2JhbACES6BGeRQBARYmJYh6nXWLUJEzgSmDTXgEkWI X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="83381481" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2011 10:20:35 +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 p3DAKWdp012078; Wed, 13 Apr 2011 10:20:35 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 12:20:33 +0200 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: Wed, 13 Apr 2011 12:20:31 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E50376511A@XMB-AMS-101.cisco.com> In-Reply-To: <4DA575C1.9060304@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv5wokv6kVF/o6RSIya52ohmHGhiwAAELCQ References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com><0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4D9D2D50.4040801@dougbarton.us><0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com><4D9EB2FF.2060900@gmail.com><3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com><4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> <4DA575C1.9060304@gmail.com> From: "Gunter Van de Velde (gvandeve)" To: "Brian E Carpenter" X-OriginalArrivalTime: 13 Apr 2011 10:20:33.0153 (UTC) FILETIME=[6C078710:01CBF9C4] Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:20:39 -0000 DQo+IA0KPiBHVj4gVGhleSBwcm9iYWJseSBkaWQgYW4gaW50ZXJuZXQtc2VhcmNoZWQgYW5kIGRp c2NvdmVyZWQgdGhhdCB0aGV5IGhhdmUNCj4gdGhlIHByb2JsZW0gZ28gYXdheSB3aXRoIGRpc2Fi bGluZyBJUHY2IG9uIHRoZWlyIGRldmljZSA6LSkNCg0KVGhpcyBpcyBub3QgdmVyeSBzY2llbnRp ZmljIGFzIGFuIGFuYWx5c2lzLiBXZSBuZWVkIGRhdGEsIGFzIGluIHRoZSBleGNlbGxlbnQNCmV4 YW1wbGUgYmVsb3csIHRvIGdldCBzb21lIGlkZWEgb2YgdGhlIHRvdGFsIHVzYWdlIGFzIHdlbGwg YXMgdGhlIHByb2JsZW0gY2FzZXM6DQoNCmh0dHA6Ly9zdGF0cy5vdHRpeC5uZXQvaXB2Ni8NCg0K R1Y+IEkgYWdyZWUgb24gdGhhdCBzdGF0ZW1lbnQgYWJvdXQgYmVpbmcgbm9uLXNjaWVudGlmaWMu IEdvb2QgbGluayBidHcuIE15IGNvbW1lbnQgd2FzIHBhcnRpYWxseSBtZW50aW9uZWQgDQp3aXRo IG15IHRvbmd1ZS1pbi1jaGVlaywgYmVjYXVzZSB0aGF0IGlzIHdoYXQgSSB3b3VsZCBoYXZlIGRv bmUgdG8gcmVzb2x2ZSB0aGUgaXNzdWUuDQooYW5kIHllcywgdGhlcmUgYXJlIHN0YXRzIG91dCB0 aGVyZSB0ZWxsaW5nIHRoYXQgcGVvcGxlIGxvb2sgMTAgdGltZXMgbW9yZSB0byBkaXNhYmxlIElQ djYgaW4gY29tcGFyaXNvbiB0byBlbmFibGUgSVB2NjoNCmh0dHA6Ly93d3cuZ29vZ2xlLmNvbS90 cmVuZHM/cT1kaXNhYmxlK2lwdjYlMkMrZW5hYmxlK2lwdjYmY3RhYj0wJmdlbz1hbGwmZGF0ZT1h bGwmc29ydD0wKQ0KDQpHLw0K From swmike@swm.pp.se Wed Apr 13 03:45:46 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8BC2E06FC for ; Wed, 13 Apr 2011 03:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCm7tR49YczB for ; Wed, 13 Apr 2011 03:45:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 09065E0714 for ; Wed, 13 Apr 2011 03:45:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1822F9E; Wed, 13 Apr 2011 12:45:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 16D0E9A; Wed, 13 Apr 2011 12:45:44 +0200 (CEST) Date: Wed, 13 Apr 2011 12:45:44 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4DA57724.9030408@gmail.com> Message-ID: References: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> <4DA57724.9030408@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:45:46 -0000 On Wed, 13 Apr 2011, Brian E Carpenter wrote: > Could you look at the advice re Rogue RA in > draft-ietf-v6ops-6to4-advisory-00 and suggest how it can > be made more complete? > > Section 4.1 bullet 5, the end of Section 4.2, and Section > 4.3 mention this issue. Doing a text search for "SAVI" yields 0 hits in the document. I believe it would be very valuable to have that included. They have a lot of functionality that makes "Rogue RA" a non-problem. If a port isn't supposted to have a router, RAs are suppressed. -- Mikael Abrahamsson email: swmike@swm.pp.se From gvandeve@cisco.com Wed Apr 13 04:03:13 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 97F9DE06CD for ; Wed, 13 Apr 2011 04:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.921 X-Spam-Level: X-Spam-Status: No, score=-8.921 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJc9t7HQehI1 for ; Wed, 13 Apr 2011 04:03:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 2168EE0682 for ; Wed, 13 Apr 2011 04:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1088; q=dns/txt; s=iport; t=1302692588; x=1303902188; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZcoxqLPuMJWZLDqQ0yldUAvu9cpMvI2BB9DWMbObWXk=; b=X4/VnETDH38Oo+y5/n8vTGq5JiZEHwbszzIyVFtp9NuraMrAdCSV+gf3 bmzVAzocG+RtzZoOtY62GxVP6j4qPigETxDvAOQ0Xyxi7UNT+xc6u63GZ XeaYXSEPypAmkKe7owxLN7I2fOz1Dp2r0kVMhnXWxPS1JJPcCcQZe1t+s s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYEALaApU2Q/khLgWdsb2JhbACmEhQBARYmJaZGnQeFbgSRXoM+ X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25536898" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 11:03:07 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3DB37cs017970; Wed, 13 Apr 2011 11:03:07 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); Wed, 13 Apr 2011 13:03:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 13:03:05 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503765149@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] phaseout - Re: Deprecating 2002::/16 - 6to4 Historic Status Thread-Index: Acv2inSqsPGbViYYSt2HiuKAR7Tx1gDP8xMA References: From: "Gunter Van de Velde (gvandeve)" To: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "Brian E Carpenter" X-OriginalArrivalTime: 13 Apr 2011 11:03:07.0056 (UTC) FILETIME=[5E463300:01CBF9CA] Cc: IPv6 Ops WG Subject: Re: [v6ops] phaseout - Re: Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:03:13 -0000 What about 6-4-2064 ... maybe a long time down the road though. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Roger J=F8rgensen Sent: 09 April 2011 09:48 To: Brian E Carpenter Cc: IPv6 Ops WG Subject: [v6ops] phaseout - Re: Deprecating 2002::/16 - 6to4 Historic = Status On Sat, Apr 9, 2011 at 9:38 AM, Brian E Carpenter wrote: > P.S. The phaseout plan is to wait until existing hosts and CPEs that > do 6to4 by default go to landfill or e-cycling. So we need to operate > relays for another ten years. Since 6to4 will be (I assume) deprecated now, what about letting 16.June 2016 be the day to shut of 6to4? (I liked the number series, 16.06.2016 or 06.16.2016, 16.06.16...) --=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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From pch-b6B5344D9@u-1.phicoh.com Wed Apr 13 04:22:37 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D01CE068E for ; Wed, 13 Apr 2011 04:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMWLw+Sil7iF for ; Wed, 13 Apr 2011 04:22:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 515FEE0682 for ; Wed, 13 Apr 2011 04:22:35 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1Q9y9a-0001h1C; Wed, 13 Apr 2011 13:22 +0200 Message-Id: To: Gert Doering From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> In-reply-to: Your message of "Wed, 13 Apr 2011 11:56:58 +0200 ." <20110413095658.GR30227@Space.Net> Date: Wed, 13 Apr 2011 13:22:25 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:22:37 -0000 In your letter dated Wed, 13 Apr 2011 11:56:58 +0200 you wrote: >(Same scope as the "working" address, so source address >selection doesn't help) Isn't that where you get into longest match. In this case I would guess that an address from a Monash prefix would be a better match for the Monash website than a 6to4 address. From pch-b6B5344D9@u-1.phicoh.com Wed Apr 13 04:32:34 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C9A0E06FA for ; Wed, 13 Apr 2011 04:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiWsA0WiGaLQ for ; Wed, 13 Apr 2011 04:32:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 90763E06CB for ; Wed, 13 Apr 2011 04:32:33 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1Q9yJB-0001gNC; Wed, 13 Apr 2011 13:32 +0200 Message-Id: To: Brian E Carpenter From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> <4DA57724.9030408@gmail.com> In-reply-to: Your message of "Wed, 13 Apr 2011 22:12:52 +1200 ." <4DA57724.9030408@gmail.com> Date: Wed, 13 Apr 2011 13:32:29 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:32:34 -0000 In your letter dated Wed, 13 Apr 2011 22:12:52 +1200 you wrote: >Could you look at the advice re Rogue RA in >draft-ietf-v6ops-6to4-advisory-00 and suggest how it can >be made more complete? > >Section 4.1 bullet 5, the end of Section 4.2, and Section >4.3 mention this issue. What about advising people running official routers to have at least one router on each lan with the priority set to high? From Jean-Francois.TremblayING@videotron.com Wed Apr 13 07:24:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A167E06C6; Wed, 13 Apr 2011 07:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRVzA5xT3xEh; Wed, 13 Apr 2011 07:24:17 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfc.amsl.com (Postfix) with ESMTP id A6968E06C5; Wed, 13 Apr 2011 07:24:17 -0700 (PDT) In-Reply-To: <19614F693882ED4DA4481CBE85DDE4B3011BA3C0A92C@MAIL.corp.cht.com.tw> To: Fang-Yu Ling MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 13 Apr 2011 10:24:05 -0400 X-MIMETrack: Serialize by Router on DOMMTL11/SRV/GVL(Release 7.0.2FP1|January 10, 2007) at 2011-04-13 10:24:06, Serialize complete at 2011-04-13 10:24:06 Content-Type: multipart/alternative; boundary="=_alternative 004F1C8585257871_=" Cc: IPv6 Ops WG , v6ops-bounces@ietf.org Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:24:18 -0000 Message en plusieurs parties au format MIME --=_alternative 004F1C8585257871_= Content-Type: text/plain; charset="US-ASCII" > (Fang-Yu Ling) wrote > 3. The problem we'd like to solve is to simplify the configuration of PE. > Before this model, PE's operator has to know the subscriber is in bridge > or routed mode. The operator configures a IPv6 address for RA if the subscriber > is in bridged mode. The operator configures a IPv6 prefix for DHCP-PD if the > subscriber is in routed mode. But in our model, operator configures both for > each no matter the subscriber is in which mode. It is to simplify the configuration. Thank you for clarifying your need here. My humble opinion: - You need to send RAs anyway in both cases, so there's no difference in configuration here. - It's impossible to differentiate in advance between a user with an embedded routed CPE and a user with a bridged CPE with a standalone routed CPE behind it (for example what happens if a user adds a router later?). The bottom line is that you have to provision PD prefixes for all of your users anyway. No matter what, you shouldn't be worried about running out of IPv6 address space. If you don't have enough space for all of your users, ask your RIR for more space. Some RIRs will ask for justification of the previous block, but that's an issue with your local RIR policies and better discussed on the related mailing list. /JF > Regards, > Fang > ------------------------------------------- > Fang-Yu Ling > Chunghwa Telecom Laboratories > mailto:fancy@cht.com.tw > TEL: +886-3-424-5631 > FAX: +886-3-424-4888 --=_alternative 004F1C8585257871_= Content-Type: text/html; charset="US-ASCII"


> (Fang-Yu Ling) <fancy@cht.com.tw> wrote
> 3. The problem we'd like to solve is to simplify the configuration of PE.
> Before this model, PE's operator has to know the subscriber is in bridge
> or routed mode. The operator configures a IPv6 address for RA if the subscriber
> is in bridged mode. The operator configures a IPv6 prefix for DHCP-PD if the
> subscriber is in routed mode. But in our model, operator configures both for
> each no matter the subscriber is in which mode. It is to simplify the configuration.

Thank you for clarifying your need here.

My humble opinion:
- You need to send RAs anyway in both cases, so there's no difference in configuration here.
- It's impossible to differentiate in advance between a user with an embedded routed CPE
and a user with a bridged CPE with a standalone routed CPE behind it (for example what happens
if a user adds a router later?). The bottom line is that you have to provision PD prefixes
for all of your users anyway.

No matter what, you shouldn't be worried about running out of IPv6 address space.
If you don't have enough space for all of your users, ask your RIR for more space.
Some RIRs will ask for justification of the previous block, but that's an issue
with your local RIR policies and better discussed on the related mailing list.

/JF

> Regards,
> Fang
> -------------------------------------------
> Fang-Yu Ling
> Chunghwa Telecom Laboratories
> mailto:fancy@cht.com.tw
> TEL: +886-3-424-5631
> FAX: +886-3-424-4888
--=_alternative 004F1C8585257871_=-- From cb.list6@gmail.com Wed Apr 13 08:16:30 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57838E0704 for ; Wed, 13 Apr 2011 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQCfrvgylJui for ; Wed, 13 Apr 2011 08:16:29 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id D9FF4E0798 for ; Wed, 13 Apr 2011 08:16:28 -0700 (PDT) Received: by eye13 with SMTP id 13so251262eye.31 for ; Wed, 13 Apr 2011 08:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=935AoBd/rDG4igI7DmxU+niw+OQqNgmcwCo1qhFiiSw=; b=lsj7b3ScCW5/p0+IgXG8qqLyFfu/BTKNCbGc0Y6+9PW1/aZ3c27L2SpEmXQt91LV73 9m86QVajQxgoC8Yoo5fDjpV32XwlnjkIxOp0AdqxpJiEbikvDYp4PDtjRR6LAgb7fHFP 37IfDPeUqbZvPnfHJeLG+sx6HLoDFEHjuzGzA= 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=fnnm3ZQq/NTay7D+hr/nofoEgrZT2rsi2n6uhAXejT8wdMrFzrM6hUbBNY4EsRhrwq dGERm0w55TbA9paxydDRnit0LnvrWYKXcjUru3v6ixlmvKLNzH76T9EdKeCbSH1pWxxV HeXG0iWUG/pzYjFUAv4X9am1s5tDufXWFM5/s= MIME-Version: 1.0 Received: by 10.213.27.22 with SMTP id g22mr2111077ebc.120.1302707786313; Wed, 13 Apr 2011 08:16:26 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Wed, 13 Apr 2011 08:16:25 -0700 (PDT) Received: by 10.213.113.194 with HTTP; Wed, 13 Apr 2011 08:16:25 -0700 (PDT) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> Date: Wed, 13 Apr 2011 08:16:25 -0700 Message-ID: From: Cameron Byrne To: "John Mann (ITS)" Content-Type: multipart/alternative; boundary=0015174c18d8d96f1b04a0ce4a58 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:16:30 -0000 --0015174c18d8d96f1b04a0ce4a58 Content-Type: text/plain; charset=ISO-8859-1 On Apr 13, 2011 2:23 AM, "John Mann (ITS)" wrote: > > Hi, > > On 13 April 2011 07:24, james woodyatt wrote: >> >> On Apr 12, 2011, at 12:20 , Doug Barton wrote: >> > >> > On the other hand, the unsuccessful 6to4 connections have a very high cost in that they are a major contributing factor causing content providers to be hesitant to deploy real IPv6. One could also argue that the presence of 6to4 has created a reduced incentive for ISPs as well, but I don't place a lot of weight on that argument. >> >> I don't believe this claim of high costs associated with failed 6to4 is supported by evidence. ... > > > I can't provide overall numbers, but I can provide anecdotal evidence. > > As I remember it ... in November 2008, I enabled IPv6 on http://www.monash.edu.au (that's Monash acting as content provider). > IPv6 was only enabled on a few user subnets. > Everything went well over the Christmas break. > > Then, with the start of the academic year in 2009, users started reporting problems (that's Monash acting as an access provider). > Users starting reporting slowness or complete inability to get to www.monash.edu.au > Often Macs ... and it was often tracked down to nearby Windows Vista laptops. > By tracking down and disabling IPv6 on that laptop and/or disabling IPv6 on all the Macs we were kept busy, but were keeping the problem manageable. > Student machines are harder to track down ... > > In parallel, we were trying other solutions, such as enabling real IPv6 dual-stack on the affected subnets. > This helped, but sometimes Macs would align themselves with the rogue 6to4 RAs rather than to our Cisco router RAs. > > And then some Professors had troubles. Not only was accessing Monash web sites slow, but late every afternoon, they became unusable. > Professors don't call ITS Helpdesk -- they complain to the Dean that their ability to do important research and apply for grants is compromised !! > Deans don't call ITS Helpdesk -- they complain at University IT Steering committee meetings !! > > Eventually, the problem filters down the chain of command to us. > We were quickly able to identify the problem and solve it, and spent the next 2 days in their building smoothing things over. > It was a laptop tunneling all IPv6 traffic out to a 6to4 relay and then back into Monash - slow access. > And at 4:30pm each day the user took the laptop home, but the Macs still had a default IPv6 route and continued sending IPv6 traffic to the PC's Ethernet address until the route expired -- blackholing all IPv6 traffic. > > We did *not* tell the users that the problem was triggered by turning on IPv6 on the main web site. > But we did turn off IPv6 on the main web site for a couple of days. > > But I promised that after we got over _this_ problem, all would be well with IPv6. > And we turned IPv6 back on for the main web site. > Next I did a large amount of work to enable RA filtering on every user-facing Catalyst 3750 switch port. > > So, yes, unsuccessful 6to4 connections did almost stop/reverse Monash's IPv6 content-provider rollout. > And it cost a lot of effort to make Monash's access-provider network safe against 6to4 rogue routers. > Thanks. Real lessons from a real network. Cb > John > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0015174c18d8d96f1b04a0ce4a58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 13, 2011 2:23 AM, "John Mann (ITS)" <john.mann@monash.edu> wrote:
>
> Hi,
>
> On 13 April 2011 07:24, james woodyatt <jhw@apple.com> wrote:
>>
>> On Apr 12, 2011, at 12:20 , Doug Barton wrote:
>> >
>> > On the other hand, the unsuccessful 6to4 connections have a v= ery high cost in that they are a major contributing factor causing content = providers to be hesitant to deploy real IPv6. One could also argue that the= presence of 6to4 has created a reduced incentive for ISPs as well, but I d= on't place a lot of weight on that argument.
>>
>> I don't believe this claim of high costs associated with faile= d 6to4 is supported by evidence. ...
>
>
> I can't provide overall numbers, but I can provide anecdotal evide= nce.
>
> As I remember it ... in November 2008, I enabled IPv6 on http://www.monash.edu.au (that's Monash act= ing as content provider).
> IPv6 was only enabled on a few user subnets.
> Everything went well over the Christmas break.
>
> Then, with the start of the academic year in 2009, users started repor= ting problems (that's Monash acting as an access provider).
> Users starting reporting slowness or complete inability to get to=A0www.monash.edu.au
> Often Macs ... and it was often tracked down to nearby Windows Vista l= aptops.
> By tracking down and disabling IPv6 on that laptop and/or disabling IP= v6 on all the Macs we were kept busy, but were keeping the problem=A0manage= able.
> Student machines are harder to track down ...
>
> In parallel, we were trying other solutions, such as enabling real IPv= 6 dual-stack on the affected subnets.
> This helped, but sometimes Macs would align themselves with the rogue = 6to4 RAs rather than to our Cisco router RAs.
>
> And then some Professors had troubles. =A0Not only was accessing Monas= h web sites slow, but late every afternoon, they became unusable.
> Professors don't call ITS Helpdesk -- they complain to the Dean th= at their ability to do important research and apply for grants is compromis= ed !!
> Deans don't call ITS Helpdesk -- they complain at University IT St= eering committee meetings !!
>
> Eventually, the problem filters down the chain of command to us.
> We were quickly able to identify the problem and solve it, and spent t= he next 2 days in their building smoothing things over.
> It was a laptop tunneling all IPv6 traffic out to a 6to4 relay and the= n back into Monash - slow access.
> And at 4:30pm each day the user took the laptop home, but the Macs sti= ll had a default IPv6 route and continued sending IPv6 traffic to the PC= 9;s Ethernet address until the route expired -- blackholing all IPv6 traffi= c.
>
> We did *not* tell the users that the problem was triggered by turning = on IPv6 on the main web site.
> But we did turn off IPv6 on the main web site for a couple of days. >
> But I promised that after we got over _this_ problem, all would be wel= l with IPv6.
> And we turned IPv6 back on for=A0the main web site.
> Next I did a large amount of work to enable RA filtering on every user= -facing Catalyst 3750 switch port.
>
> So, yes, unsuccessful 6to4 connections did almost stop/reverse Monash&= #39;s IPv6 content-provider rollout.
> And it cost a lot of effort to make Monash's access-provider netwo= rk safe against 6to4 rogue routers.
>

Thanks.=A0 Real lessons from a real network.

Cb

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

--0015174c18d8d96f1b04a0ce4a58-- From brian.e.carpenter@gmail.com Wed Apr 13 08:26:21 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1493E07C3 for ; Wed, 13 Apr 2011 08:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJBmjnjo+6IR for ; Wed, 13 Apr 2011 08:26:20 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 5B32CE07BC for ; Wed, 13 Apr 2011 08:26:20 -0700 (PDT) Received: by wwa36 with SMTP id 36so575591wwa.13 for ; Wed, 13 Apr 2011 08:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5GUcUG8ON92V/KaDvoUOlRv8LLLytz8Rz4Cd30d/RZc=; b=IFZVgb0zDjjwcudUzF6tDVP66QfZ4kWf07AaEy9W1Oge1odPEMCvBkQNe585PsAKaJ 3JeyzFaAJ3tN40K0MMipp4KUpZ1Ce8S1ljc1/sj7fLno1JDOuJaBrQsv8E5GfIqGBTgG TWr9juY0bIfRRl7VO0j9tH2XAgIij5V60FVzM= 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=RMuhdYPhEcKe2Yt/2A0oQKuV3b/ZH2G5p9NvJCrOHbDomEr5Vuzl0c7sY/LU5DWhcd jg2IQs8m9nrX/dbfXd6kQP4tFMcXIV8ePoygzRD4WoISv8aCOrDahxyUoev8jf23gmbs UOertQWAM4zmF1ZJOWvwHVtrulDdL/3UjO0kM= Received: by 10.217.7.4 with SMTP id z4mr5259046wes.89.1302708379670; Wed, 13 Apr 2011 08:26:19 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id t11sm329288wes.41.2011.04.13.08.26.17 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 08:26:18 -0700 (PDT) Message-ID: <4DA5C098.1070302@gmail.com> Date: Thu, 14 Apr 2011 03:26:16 +1200 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: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com><0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4D9D2D50.4040801@dougbarton.us><0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com><4D9EB2FF.2060900@gmail.com><3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com><4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> <4DA575C1.9060304@gmail.com> <21CA8579-04BB-4F07-8B81-2EF7210B05E8@townsley.net> In-Reply-To: <21CA8579-04BB-4F07-8B81-2EF7210B05E8@townsley.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:26:21 -0000 On 2011-04-13 22:20, Mark Townsley wrote: > On Apr 13, 2011, at 12:06 PM, Brian E Carpenter wrote: > >> On 2011-04-13 20:25, Gunter Van de Velde (gvandeve) wrote: >>> Another single-datapoint anecdote: We used to receive at least one >>> complaint a month about our 6to4 relay not working (which pretty much >>> always was traced down to the reverse path being broken, not us), but >>> those complaints have pretty much stopped entirely in the last year. I >>> don't know if this is because people are getting better at deploying >>> 6to4, or if people know enough to switch to another option if it's >>> broken. >>> >>> GV> They probably did an internet-searched and discovered that they have >>> the problem go away with disabling IPv6 on their device :-) >> This is not very scientific as an analysis. We need data, as in the excellent >> example below, to get some idea of the total usage as well as the problem cases: > >> http://stats.ottix.net/ipv6/ > > Nice data. How are you discerning problem cases from this though? You can't, but the person who runs that site is aware of Geoff Huston and Emile Aben's work on counting failed sessions, and may be integrating that sort of analysis too. At the moment you'd have to assume that the failure rates Geoff and Emile have reported would apply everywhere. Brian From brian.e.carpenter@gmail.com Wed Apr 13 08:30:51 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C85C2E0783 for ; Wed, 13 Apr 2011 08:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.724 X-Spam-Level: X-Spam-Status: No, score=-103.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps8WhI9snpst for ; Wed, 13 Apr 2011 08:30:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7AA4AE07E2 for ; Wed, 13 Apr 2011 08:30:47 -0700 (PDT) Received: by wyb29 with SMTP id 29so678894wyb.31 for ; Wed, 13 Apr 2011 08:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6eFA9ZGx6Q6K/g1hEyKb40UpjBOxEkLnO9x2jnIcL2k=; b=Oln+jpnhDSMlMln44mbJeuJ8KdYO6+qfBngmuuDpfGQCbfm2xRRoQGOvXpGP/IGrjK 7JwBewKAiyh/bvXYya8OeieU8yxV2z8HXP+H9vs9TkLzr9IHYC8nMt2WeXKg40LgDZQg Vv7tesZiGdA3ut25hqYezNHcNNKpJTomKAiAE= 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=pbayD03jCrEcye4BckkCrG33jostR7/0YYs7lh8vNQZl5aN/dYn76Y1vlwVX819BNx 0B+YgroP2hVw/HWN8wwztqhMhb/Q848cDfxDfTZeIBCMww7JBqwKMjrHUcza/FWVa2Mn 0PxXpqyoZD0NYCZCAnqQZ0HZknFrbY6TjD238= Received: by 10.227.10.149 with SMTP id p21mr7905209wbp.195.1302708646624; Wed, 13 Apr 2011 08:30:46 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id y12sm411254wby.42.2011.04.13.08.30.44 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 08:30:45 -0700 (PDT) Message-ID: <4DA5C1A3.3000904@gmail.com> Date: Thu, 14 Apr 2011 03:30:43 +1200 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: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> <4DA57724.9030408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:30:51 -0000 On 2011-04-13 22:45, Mikael Abrahamsson wrote: > On Wed, 13 Apr 2011, Brian E Carpenter wrote: > >> Could you look at the advice re Rogue RA in >> draft-ietf-v6ops-6to4-advisory-00 and suggest how it can >> be made more complete? >> >> Section 4.1 bullet 5, the end of Section 4.2, and Section >> 4.3 mention this issue. > > Doing a text search for "SAVI" yields 0 hits in the document. I believe > it would be very valuable to have that included. > > > > They have a lot of functionality that makes "Rogue RA" a non-problem. If > a port isn't supposted to have a router, RAs are suppressed. Right, but is there anything an ISP can install before IPv6 Day? Brian From swmike@swm.pp.se Wed Apr 13 08:43:41 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E627E079C for ; Wed, 13 Apr 2011 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5pn4psJE+xL for ; Wed, 13 Apr 2011 08:43:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 0FF86E078B for ; Wed, 13 Apr 2011 08:43:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B33F89E; Wed, 13 Apr 2011 17:43:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B01769A; Wed, 13 Apr 2011 17:43:39 +0200 (CEST) Date: Wed, 13 Apr 2011 17:43:39 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <4DA5C1A3.3000904@gmail.com> Message-ID: References: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> <4DA57724.9030408@gmail.com> <4DA5C1A3.3000904@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:43:41 -0000 On Thu, 14 Apr 2011, Brian E Carpenter wrote: > Right, but is there anything an ISP can install before IPv6 Day? Well, one strong recommendation is to filter everything that is not ARP or IP ethertypes in the access equipment. This is very important if you don't have any IPv6 SAVI functionality. It completely removes the rogue RA problem. It's of course a problem if you're delivering native IPv6 (without SAVI type security features), but if you do, then I guess the better way is to make sure your RAs are sent with higher priority than I guess Windows would use by default? -- Mikael Abrahamsson email: swmike@swm.pp.se From jhw@apple.com Wed Apr 13 10:05:47 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6367E079F for ; Wed, 13 Apr 2011 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbXDfcQ9lyrk for ; Wed, 13 Apr 2011 10:05:46 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id 67FCFE075D for ; Wed, 13 Apr 2011 10:05:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJL000GBOMOL120@mail-out.apple.com> for v6ops@ietf.org; Wed, 13 Apr 2011 10:05:45 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-4f-4da5d7e9e5f4 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id E9.09.18996.9E7D5AD4; Wed, 13 Apr 2011 10:05:45 -0700 (PDT) Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJL00A5LOTLTX30@et.apple.com> for v6ops@ietf.org; Wed, 13 Apr 2011 10:05:45 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 13 Apr 2011 10:05:45 -0700 Message-id: <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:05:48 -0000 On Apr 13, 2011, at 02:22 , John Mann (ITS) wrote: > > As I remember it ... in November 2008, I enabled IPv6 on http://www.monash.edu.au... I think current data would be more useful in this discussion than outdated anecdotes. When I review the data at , what I see is that a lot of academic networks are numbering their local area networks with public IPv4 addresses and that a fair number of hosts on those networks are successfully getting workable IPv6 service over 6to4 through the Ottowa IX anycast relay. One imagines that many of those hosts might get better Internet service overall if were stop using 6to4, but the data at OttIX is inconclusive on that question. It seems to me that I-D.ietf-v6ops-6to4-advisory needs to be nailed to the doors of the IT departments at every single one of those universities and colleges that you see listed in that page. If you're going to number your networks with public realm IPv4 addresses, then you really need to think about how you're going to handle 6to4 traffic. Some of the hosts on your network will be expecting to use it, and you should figure out how you're going to make it work as well as possible, so long as you continue to number out IPv4 public realm space. Having IETF move RFC 3056 and RFC 3068 to Historic status won't solve any of your problems. -- james woodyatt member of technical staff, core os networking From mark@townsley.net Wed Apr 13 10:22:20 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B60DAE0736 for ; Wed, 13 Apr 2011 10:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gbvpsNsY8ZA for ; Wed, 13 Apr 2011 10:22:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id AFBF0E0690 for ; Wed, 13 Apr 2011 10:22:19 -0700 (PDT) Received: by wyb29 with SMTP id 29so777378wyb.31 for ; Wed, 13 Apr 2011 10:22:19 -0700 (PDT) Received: by 10.227.150.90 with SMTP id x26mr2515160wbv.17.1302715338808; Wed, 13 Apr 2011 10:22:18 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id y12sm473567wby.8.2011.04.13.10.22.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 10:22:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> Date: Wed, 13 Apr 2011 19:22:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:22:20 -0000 On Apr 13, 2011, at 7:05 PM, james woodyatt wrote: > On Apr 13, 2011, at 02:22 , John Mann (ITS) wrote: >>=20 >> As I remember it ... in November 2008, I enabled IPv6 on = http://www.monash.edu.au... >=20 > I think current data would be more useful in this discussion than = outdated anecdotes. >=20 > When I review the data at , what I see = is that a lot of academic networks are numbering their local area = networks with public IPv4 addresses and that a fair number of hosts on = those networks are successfully getting workable IPv6 service over 6to4 = through the Ottowa IX anycast relay. One imagines that many of those = hosts might get better Internet service overall if were stop using 6to4, = but the data at OttIX is inconclusive on that question. >=20 > It seems to me that I-D.ietf-v6ops-6to4-advisory needs to be nailed to = the doors of the IT departments at every single one of those = universities and colleges that you see listed in that page. If you're = going to number your networks with public realm IPv4 addresses, then you = really need to think about how you're going to handle 6to4 traffic. = Some of the hosts on your network will be expecting to use it, and you = should figure out how you're going to make it work as well as possible, = so long as you continue to number out IPv4 public realm space. Ironic. The picture you paint is that an IPv6 transition technology = could be providing an incentive for operators to move networks numbered = with global IPv4 addresses to private IPv4 addresses. - Mark >=20 > Having IETF move RFC 3056 and RFC 3068 to Historic status won't solve = any of your problems. >=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 dwing@cisco.com Wed Apr 13 10:44:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09FB3E079E for ; Wed, 13 Apr 2011 10:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.122 X-Spam-Level: X-Spam-Status: No, score=-110.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdJHnwMzhPeG for ; Wed, 13 Apr 2011 10:44:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 9D191E0705 for ; Wed, 13 Apr 2011 10:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5092; q=dns/txt; s=iport; t=1302716645; x=1303926245; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0rcsY/8cnVM8EH6+BJUwlDi5K/TYjYsbLsK++ECD2U4=; b=BVZwxN2lCrtTPJEXCBlH8FrafMSaPKT2tb+eR4TCbZKW1DZkkosEVDor 1qg5zXqFClmX+AFJEJX3JYUXf7gDZOg+fzzrM1QX5Y6J/vEvdyiJyjNmY qtplcD/THJ9LOVMAllolsu6/fDChz/7vuOXndGDKJx/a0JZfO7X4uDqbT A=; X-IronPort-AV: E=Sophos;i="4.64,205,1301875200"; d="scan'208";a="336412342" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2011 17:44:00 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3DHi0JI030704; Wed, 13 Apr 2011 17:44:00 GMT From: "Dan Wing" To: , References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> In-Reply-To: <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> Date: Wed, 13 Apr 2011 10:43:59 -0700 Message-ID: <2f0101cbfa02$5f014b30$1d03e190$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvwOKIU3PxUKp/sRVqjQu5EAATqXwABK6nwAm3/ofA= Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:44:07 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Olaf.Bonness@telekom.de > Sent: Friday, April 01, 2011 12:35 AM > To: scott.brim@gmail.com > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? >=20 > Thx Scott, for this clarification. Unfortunately I havn't found a > recommendation for the default P value in the I-D. Would it make sense > to also think about a general method how this default P value can be > adjusted over time refelecting the increase of unbroken IPv6 > connectivity? > I don't think that the standard user can/will do this adjustement and > fine triggering. We will add a discussion of this to the I-D. My thought is to add a new variable, "offset", which would default to = 200ms. This would be a user-configurable value (e.g., "about:config" or = similar). Offset is always added to P. This would give IPv6 a 200ms head-start = over IPv4. A good value of "offset" would be the round-trip time to = communicate to a server on this network, so a value of NNN milliseconds (20ms?) = might be reasonable for a wired connection with a typical home Internet = connection, whereas a hundred milliseconds might be reasonable for a 3G connection = or a slow Internet connection (dialup, satellite without a TCP spoofing = device, etc.). Automatically tuning offset, based on connection times, might be useful as well, or getting the P value from the network (via DHCP or RA, = as Ted suggested). Today, we have an offset (or "P" value) of effectively 21-75 seconds, = based on Teemu's slide 3 at = http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf This 'offset' value would also reduce the worry of doubling traffic when initially visiting a server, giving a preference to IPv6. Obviously if 'offset' is too large, the user notices a delay -- which is exactly what Happy Eyeballs is trying to avoid so that IPv6 does not get = a black eye. -d > Kind regards > Olaf >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Scott Brim [mailto:scott.brim@gmail.com] > > Gesendet: Freitag, 1. April 2011 08:47 > > An: Bonne=DF, Olaf > > Cc: hagen@jauu.net; v6ops@ietf.org > > Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? > > > > Happy eyeballs is eminently configurable. For IPv4/v6, you could > > initialize the P value so that it never tries IPv4 unless there are > > extreme delays in getting an IPv6 connection. You could also > > parameterize P adjustment behavior. > > > > Scott > > > > On Thu, Mar 31, 2011 at 19:47, wrote: > > > Hi Hagen, > > > > > > as I tried to explain: If the HE approach remains in the > > network without a dedicated exit strategy than all the > > clients outthere will go on trying to connect via IPv4 (see > > "flashing the destination P value every 10 min") also in the > > case when there is already a better IPv6 connectivity is available. > > > > > > According to Gerds proposal this will end when there is no > > A record for the destination is available anymore or the > > client is IPv6-only. Gerd is of course right but the problem > > with this approach is, that it simply relies on the > > assumption that all the people are accordingly updating there > > DNS records. > > > > > > Besides that, one of the IETF standardization basics is to > > also think about exit strategies for mechanisms and protocols > > they standardize. > > > I hope that I could make my position a bit more clear. > > > > > > Regards > > > =A0 =A0 =A0 =A0Olaf > > > > > > PS: IMHO, HE is a very useful and needed mechanism (that > > may perhaps have some room for improvement), and thats why I > > definitely don't share your classification of this mechanism. > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: Hagen Paul Pfeifer [mailto:hagen@jauu.net] > > >> Gesendet: Donnerstag, 31. M=E4rz 2011 19:26 > > >> An: Bonne=DF, Olaf > > >> Cc: gert@space.net; v6ops@ietf.org > > >> Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? > > >> > > >> * Olaf.Bonness@telekom.de | 2011-03-31 11:32:36 [+0200]: > > >> > > >> >Hmm I've made the experience that DNS records are very often > > >> not at such an > > >> >actualized status as they should be. > > >> > > >> >Besides that this (sit back and wait) seems not be an an > > >> acceptable exit > > >> >strategy from a provider point of view. (The same applies > > >> also to the "wait > > >> >until the last IPv4 user died" approach.) > > >> > > >> What are these drawbacks that makes Happy Eyeball approach > > >> somewhat stinking? > > >> Why is Gert's reply not adequate from a provider point of view? > > >> > > >> Hagen > > >> > > > _______________________________________________ > > > 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 simon.perreault@viagenie.ca Wed Apr 13 10:54:17 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03E2EE0880 for ; Wed, 13 Apr 2011 10:54:17 -0700 (PDT) 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.139, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Omq6X83abpB for ; Wed, 13 Apr 2011 10:54:16 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id 4E3FDE087F for ; Wed, 13 Apr 2011 10:54:16 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A182721EBE for ; Wed, 13 Apr 2011 13:54:15 -0400 (EDT) Message-ID: <4DA5E347.5040303@viagenie.ca> Date: Wed, 13 Apr 2011 13:54:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: v6ops@ietf.org References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> <2f0101cbfa02$5f014b30$1d03e190$@com> In-Reply-To: <2f0101cbfa02$5f014b30$1d03e190$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:54:17 -0000 On 2011-04-13 13:43, Dan Wing wrote: > My thought is to add a new variable, "offset", which would default to 200ms. > This would be a user-configurable value (e.g., "about:config" or similar). > Offset is always added to P. This would give IPv6 a 200ms head-start over > IPv4. +1 In my implementation I ended up using 100ms. 200ms is also fine. 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 jhw@apple.com Wed Apr 13 11:35:34 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00BD6E0739 for ; Wed, 13 Apr 2011 11:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFQdmW0NWGtH for ; Wed, 13 Apr 2011 11:35:33 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 68EBEE06AC for ; Wed, 13 Apr 2011 11:35:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJL0068ZSUB5760@mail-out.apple.com> for v6ops@ietf.org; Wed, 13 Apr 2011 11:35:32 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-f9-4da5ecf458f2 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 77.C8.29082.4FCE5AD4; Wed, 13 Apr 2011 11:35:32 -0700 (PDT) Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJL00CMZSZ8VB70@gertie.apple.com> for v6ops@ietf.org; Wed, 13 Apr 2011 11:35:32 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 13 Apr 2011 11:35:32 -0700 Message-id: <9D0ACF10-E248-4544-902F-986EC02441E8@apple.com> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> To: Mark Townsley X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:35:34 -0000 On Apr 13, 2011, at 10:22 , Mark Townsley wrote: > > Ironic. The picture you paint is that an IPv6 transition technology could be providing an incentive for operators to move networks numbered with global IPv4 addresses to private IPv4 addresses. ...and/or roll out native IPv6 service. Standing athwart the path to progress with a stop sign in hand isn't going to work for anyone. -- james woodyatt member of technical staff, core os networking From nick@inex.ie Wed Apr 13 12:36:15 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9B67E0796 for ; Wed, 13 Apr 2011 12:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syF7pvF2Tk6I for ; Wed, 13 Apr 2011 12:36:15 -0700 (PDT) Received: from mail.acquirer.com (unknown [IPv6:2001:1bb8:2004:150::2]) by ietfc.amsl.com (Postfix) with ESMTP id DB049E0785 for ; Wed, 13 Apr 2011 12:36:14 -0700 (PDT) X-Envelope-To: Received: from crumpet.foobar.org (crumpet.foobar.org [10.230.100.34]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id p3DJa0oW009962 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 13 Apr 2011 20:36:07 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DA5FB20.9030001@inex.ie> Date: Wed, 13 Apr 2011 20:36:00 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: v6ops@ietf.org References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> <9D0ACF10-E248-4544-902F-986EC02441E8@apple.com> In-Reply-To: <9D0ACF10-E248-4544-902F-986EC02441E8@apple.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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:36:15 -0000 On 13/04/2011 19:35, james woodyatt wrote: > ...and/or roll out native IPv6 service. Standing athwart the path to > progress with a stop sign in hand isn't going to work for anyone. No, but as a medium-term objective, removing automatic 6to4 tunnel creation (e.g. the Linksys WRT610N) and then later, the ability to manually create 6to4 tunnels in operating systems and other software would probably be considered useful by the operator community at least. I can't say how end-users or prod-dev people would feel about this. As a long term objective, removing 6to4 support is probably good for everyone. How do we get to these positions from where we are right now? Nick From martin@millnert.se Wed Apr 13 13:48:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D57BE0744 for ; Wed, 13 Apr 2011 13:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf5kNBi1j8O6 for ; Wed, 13 Apr 2011 13:48:18 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfc.amsl.com (Postfix) with ESMTP id B72B0E05F5 for ; Wed, 13 Apr 2011 13:48:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 35D2E7788; Wed, 13 Apr 2011 23:02:03 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NPN5hW6ZTi1; Wed, 13 Apr 2011 23:02:03 +0200 (CEST) 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 8782576C2; Wed, 13 Apr 2011 23:02:01 +0200 (CEST) From: Martin Millnert To: Nick Hilliard In-Reply-To: <4DA5FB20.9030001@inex.ie> References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> <9D0ACF10-E248-4544-902F-986EC02441E8@apple.com> <4DA5FB20.9030001@inex.ie> Content-Type: text/plain; charset="UTF-8" Date: Wed, 13 Apr 2011 16:48:13 -0400 Message-ID: <1302727693.4385.195.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] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:48:18 -0000 On Wed, 2011-04-13 at 20:36 +0100, Nick Hilliard wrote: > On 13/04/2011 19:35, james woodyatt wrote: > > ...and/or roll out native IPv6 service. Standing athwart the path to > > progress with a stop sign in hand isn't going to work for anyone. > > No, but as a medium-term objective, removing automatic 6to4 tunnel creation > (e.g. the Linksys WRT610N) and then later, the ability to manually create > 6to4 tunnels in operating systems and other software would probably be > considered useful by the operator community at least. I can't say how > end-users or prod-dev people would feel about this. > > As a long term objective, removing 6to4 support is probably good for everyone. Yes, so the question is when the appropriate time to describe the phase-out plan is. A real phase-out plan would probably include one date where anycast relays began sending ICMP-please-uninstall-yourself back to hosts' 6to4 adapters (and stop routing them). > How do we get to these positions from where we are right now? 1. ISPs rolling out native v6 is a decent 6to4-mitigation technique which will go a long way to mitigate the problem. (How many residential users get public IPv4 behind their home gateway?) 2. Vendors cleaning up broken 6to4 code (various internet sharing schemes that are broken comes to mind) and shipping updates will be a massive win, at worst it will start reversing a bad trend. And the role I see for the IETF here is to point out what's broken and give appropriate recommendations on fixes (in a wording that convinces product managers that they should actually do something about it...) 3. Disabling automatic 6to4-enabling on hosts would be good, too, like you say (virtually everyone seems to agree about this?). #2 begs me to question: Brian, 4.1 in draft-ietf-v6ops-6to4-advisory-00: "This is bad practice - it should always be a conscious decision by a user to enable 6to4." Would you have a comment on increasing the usage of 2119-wording in the draft? Is a change of the above "should" to "MUST" inappropriate, the draft being a advisory text, and all? Regards, Martin > Nick > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From john.mann@monash.edu Wed Apr 13 14:52:43 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF5C8E0809 for ; Wed, 13 Apr 2011 14:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiC7tT5uMywk for ; Wed, 13 Apr 2011 14:52:43 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfc.amsl.com (Postfix) with ESMTP id BDBECE07D4 for ; Wed, 13 Apr 2011 14:52:42 -0700 (PDT) Received: from mail-vx0-f169.google.com ([209.85.220.169]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTaYbKacnidQDgspEtqoRXeCrpWePo2nf@postini.com; Wed, 13 Apr 2011 14:52:42 PDT Received: by mail-vx0-f169.google.com with SMTP id 20so1123660vxk.0 for ; Wed, 13 Apr 2011 14:52:41 -0700 (PDT) Received: by 10.52.72.167 with SMTP id e7mr2250712vdv.136.1302731561057; Wed, 13 Apr 2011 14:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.182.226 with HTTP; Wed, 13 Apr 2011 14:52:21 -0700 (PDT) In-Reply-To: References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> From: "John Mann (ITS)" Date: Thu, 14 Apr 2011 07:52:21 +1000 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec501645fef3cce04a0d3d356 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:52:43 -0000 --bcaec501645fef3cce04a0d3d356 Content-Type: text/plain; charset=ISO-8859-1 Mikael On 13 April 2011 19:45, Mikael Abrahamsson wrote: > On Wed, 13 Apr 2011, John Mann (ITS) wrote: > > And it cost a lot of effort to make Monash's access-provider network safe >> against 6to4 rogue routers. >> > > Were you able to motivate and get buy-in from higher management that > implementing proper filtering (SAVI) in the network is important after all > these problems? > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > We were/are doing as much ingress filtering as we can. We use mostly Cisco Catalyst 3750G switches in the edge network, and do "dhcp snooping" "bpdu guard" "switchport port-security ..." "storm-control broadcast" etc. to sanitise L2 and IPv4. At the time, there were limited options for sanitising IPv6 traffic. Not sure about now. Doesn't SLAAC and "privacy addresses" would make it hard to tie down which IPv6 client addresses should be on which user port, compared to "dhcp snooping" being able to create a 1:1 mapping between Ethernet address and IPv4 address. I hadn't heard of "SAVI" in Cisco switches. Do they call it something else? Thanks, John --bcaec501645fef3cce04a0d3d356 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mikael

On 13 April 2011 19:45, Mikael Abr= ahamsson <swmike@s= wm.pp.se> wrote:
On Wed, 13 Apr 2011, John Mann (ITS) wrote:

And it cost a lot of effort to make Monash's access-provider network sa= fe against 6to4 rogue routers.

Were you able to motivate and get buy-in from higher management that implem= enting proper filtering (SAVI) in the network is important after all these = problems?


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se

We were/are doing as much ingress f= iltering as we can.
We use mostly Cisco Catalyst 3750G switches i= n the edge network, and do "dhcp snooping" "bpdu guard"= "switchport port-security ..."=A0"storm-control broadcast&q= uot;=A0etc. to sanitise L2 and IPv4.
At the time, there were limited options for sanitising IPv6 traffic. N= ot sure about now.

Doesn't SLAAC and "pri= vacy addresses" would make it hard to tie down which IPv6 client addre= sses should be on which user port, compared to "dhcp snooping" be= ing able to create a 1:1 mapping between Ethernet address and IPv4 address.=

I hadn't heard of "SAVI" in Cisco switches.= =A0Do they call it something else?

Thanks,
<= div> =A0=A0 =A0John
--bcaec501645fef3cce04a0d3d356-- From john.mann@monash.edu Wed Apr 13 15:11:24 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BDB36E0696 for ; Wed, 13 Apr 2011 15:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTZ5dKxmfu5o for ; Wed, 13 Apr 2011 15:11:24 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfc.amsl.com (Postfix) with ESMTP id BA78DE05F5 for ; Wed, 13 Apr 2011 15:11:23 -0700 (PDT) Received: from mail-vx0-f171.google.com ([209.85.220.171]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTaYfizix7mPu0fqoNVLePB3jEzsL77jZ@postini.com; Wed, 13 Apr 2011 15:11:23 PDT Received: by mail-vx0-f171.google.com with SMTP id 40so1379151vxc.16 for ; Wed, 13 Apr 2011 15:11:23 -0700 (PDT) Received: by 10.52.173.38 with SMTP id bh6mr7054475vdc.296.1302732683130; Wed, 13 Apr 2011 15:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.182.226 with HTTP; Wed, 13 Apr 2011 15:11:03 -0700 (PDT) In-Reply-To: References: <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <20110413095658.GR30227@Space.Net> <4DA57724.9030408@gmail.com> <4DA5C1A3.3000904@gmail.com> From: "John Mann (ITS)" Date: Thu, 14 Apr 2011 08:11:03 +1000 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec517c4fcd0b90104a0d416e7 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 22:11:24 -0000 --bcaec517c4fcd0b90104a0d416e7 Content-Type: text/plain; charset=ISO-8859-1 Mikael On 14 April 2011 01:43, Mikael Abrahamsson wrote: > ,,, > It's of course a problem if you're delivering native IPv6 (without SAVI > type security features), but if you do, then I guess the better way is to > make sure your RAs are sent with higher priority than I guess Windows would > use by default? More "outdated anecdotes" ... My testing did *not* show that setting ipv6 nd router-preference High on Cisco routers was enough to _reliably_ get (Mac OS X 10.4 / 10.5) hosts to ignore rogue Windows 6to4 routers. It seemed like those Macs would use the first RA they saw ... And, not implementing RFC 3484 led to other faulty behavior like trying to connect to a Global IPv6 address, when the Mac only had link-local IPv6 addresses. John --bcaec517c4fcd0b90104a0d416e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mikael

On 14 April 2011 01:43, Mikael Abr= ahamsson <swmike@s= wm.pp.se> wrote:
,,,
It's of course a problem if you're delivering native IPv6 (without = SAVI type security features), but if you do, then I guess the better way is= to make sure your RAs are sent with higher priority than I guess Windows w= ould use by default?

More "outdated anecdotes" ...

<= /div>
My testing did *not* show that setting
=A0=A0=A0ipv6 nd= router-preference High
on Cisco routers was enough to _reliably_= get (Mac=A0OS X 10.4 / 10.5) hosts to ignore rogue Windows 6to4 routers.

It seemed like those Macs would use the first RA they s= aw ...

And, not implementing RFC 3484 led to other= faulty=A0behavior=A0like trying to connect to a Global IPv6 address, when = the Mac only had link-local IPv6 addresses.=A0

=A0=A0 =A0John
--bcaec517c4fcd0b90104a0d416e7-- From lightning.pengjun@huawei.com Wed Apr 13 18:33:22 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 135B5E0681; Wed, 13 Apr 2011 18:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.246 X-Spam-Level: X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrhZvLYjFMkW; Wed, 13 Apr 2011 18:33:21 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id A3329E05F5; Wed, 13 Apr 2011 18:33:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM001MACBIS1@szxga03-in.huawei.com>; Thu, 14 Apr 2011 09:33:18 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00G74CBIW6@szxga03-in.huawei.com>; Thu, 14 Apr 2011 09:33:18 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 09:31:31 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 09:33:13 +0800 Date: Thu, 14 Apr 2011 01:33:12 +0000 From: "Lightning Peng(Jun)" X-Originating-IP: [10.70.39.142] To: "v6ops@ietf.org" Message-id: <468BD06827570248BA4B70E2D7D00512D59CF6@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_A0QhTCxJ6mb3Zq5pU59v8Q)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [multrans] Comments on draft-jaclee-behave-v4v6-mcast-ps-01 Thread-index: AQHL+PAFWfr1eUUN3U6Yy/fdvCob4JRbAmzQgAGRvjA= X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "multrans@ietf.org" Subject: [v6ops] FW: [multrans] Comments on draft-jaclee-behave-v4v6-mcast-ps-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 01:33:22 -0000 --Boundary_(ID_A0QhTCxJ6mb3Zq5pU59v8Q) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SnVzdCBzaGFyZSBhbmQgZm9yd2FyZCBpdCB0byBWNm9wcyBXRy4NCg0KQmVzdCBSZWdhcmRzIQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuW9reWGmyBMaWdodG5pbmcgUGVuZw0K UGhvbmU6ICs4NiA3NTUgMjg5Nzg4NTENCk1vYmlsZTogKzg2IDE1OTg5MzYyNDEwDQoNCkZyb206 IExpZ2h0bmluZyBQZW5nKEp1bikNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMsIDIwMTEgOToz NCBBTQ0KVG86ICdKYWNuaSBRaW4nDQpDYzogdG9tMTExLnRheWxvckBiZWxsLm5ldDsgbXVsdHJh bnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXVsdHJhbnNdIENvbW1lbnRzIG9uIGRyYWZ0LWph Y2xlZS1iZWhhdmUtdjR2Ni1tY2FzdC1wcy0wMQ0KDQpQbGVhc2UgcmVhZCB0aGUgcGFyYWdyYXBo IOKAnDMuICBUcmFuc2l0aW9uIFN0ZXBz4oCdIGluIGRyYWZ0LXRzb3UtdjZvcHMtbXVsdGljYXN0 LXRyYW5zaXRpb24tdjZvbmx5LTAxLg0KDQpCZXN0IFJlZ2FyZHMhDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0K5b2t5YabIExpZ2h0bmluZyBQZW5nDQpQaG9uZTogKzg2IDc1NSAy ODk3ODg1MQ0KTW9iaWxlOiArODYgMTU5ODkzNjI0MTANCg0KRnJvbTogSmFjbmkgUWluIFttYWls dG86amFjbmlxQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDExIDQ6NTcg UE0NClRvOiBMaWdodG5pbmcgUGVuZyhKdW4pDQpDYzogdG9tMTExLnRheWxvckBiZWxsLm5ldDsg bXVsdHJhbnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXVsdHJhbnNdIENvbW1lbnRzIG9uIGRy YWZ0LWphY2xlZS1iZWhhdmUtdjR2Ni1tY2FzdC1wcy0wMQ0KDQpoaSBQZW5nLA0KDQpUaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMsDQpPbiBUdWUsIEFwciAxMiwgMjAxMSBhdCAzOjQxIFBNLCDlva3l hpsgTGlnaHRuaW5nIFBlbmcgPExpZ2h0bmluZy1QZW5nQGh1YXdlaS5jb208bWFpbHRvOkxpZ2h0 bmluZy1QZW5nQGh1YXdlaS5jb20+PiB3cm90ZToNClRoZSB1c2UgY2FzZXMgaW4gMy40LiAgTW9u by1TdGFjayBNdWx0aWNhc3QgRGVsaXZlcnkgSW5mcmFzdHJ1Y3R1cmUganVzdA0KaW52b2x2ZSBU cmFuc2xhdGlvbiBDYXNlcyBhbmQgVHJhdmVyc2FsIENhc2VzLCBidXQgSSB0aGluayBhbm90aGVy IGNhc2UgaW4NCmRyYWZ0LXRzb3UtdjZvcHMtbXVsdGljYXN0LXRyYW5zaXRpb24tdjZvbmx5LTAx IHNob3VsZCBiZSBpbmNsdWRlZC4NCg0KSmFjbmk+OiBTb3JyeSwgSSBkb24ndCBmb2xsb3cgaGVy ZSwgd2hpY2ggdXNlIGNhc2UgZG8geW91IG1lYW4/DQoNCg0KQ2hlZXJzLA0KSmFjbmkNCg0KSW4g b3JkZXINCnRvIGhhdmUgZ29vZCBwZXJmb3JtYW5jZSBvZiA0LjEgRmFzdCBaYXBwaW5nLCBlaXRo ZXIgVHJhbnNsYXRpb24gZnVuY3Rpb24gb3INClRyYXZlcnNhbCBmdW5jdGlvbiBpcyBhdm9pZGVk IGluDQpkcmFmdC10c291LXY2b3BzLW11bHRpY2FzdC10cmFuc2l0aW9uLXY2b25seS0wMS4NCg0K QmVzdCBSZWdhcmRzIQ0KDQpMaWdodG5pbmcgUGVuZw0KUGhvbmU6ICs4NiA3NTUgMjg5Nzg4NTEN Ck1vYmlsZTogKzg2IDE1OTg5MzYyNDEwDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBUb20gVGF5bG9yIFttYWlsdG86dG9tMTExLnRheWxvckBiZWxsLm5ldDxtYWlsdG86dG9t MTExLnRheWxvckBiZWxsLm5ldD5dDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDExIDY6 NTUgUE0NClRvOiBMZWUsIFlpdQ0KQ2M6IGNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLWZ0Z3Jv dXAuY29tPG1haWx0bzpjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS1mdGdyb3VwLmNvbT47IEJP VUNBREFJUiBNb2hhbWVkIE9MTkMvTkFEL1RJUDsNCkphY25pIFFpbjsgVGluYSBUU09VDQpTdWJq ZWN0OiBSZTogQ29tbWVudHMgb24gZHJhZnQtamFjbGVlLWJlaGF2ZS12NHY2LW1jYXN0LXBzLTAx DQoNCg== --Boundary_(ID_A0QhTCxJ6mb3Zq5pU59v8Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5KdXN0IHNoYXJlIGFuZCBmb3J3YXJkIGl0IHRvIFY2b3BzIFdHLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPGhyIHNpemU9 IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPuW9reWGmzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrljY7mlofnu4bpu5E7Y29sb3I6YmxhY2siPiBM aWdodG5pbmcgUGVuZzxicj4NClBob25lOiAmIzQzOzg2IDc1NSAyODk3ODg1MTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGJyPg0KTW9iaWxlOiAmIzQz Ozg2IDE1OTg5MzYyNDEwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMaWdodG5pbmcgUGVu ZyhKdW4pDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxMSA5OjM0 IEFNPGJyPg0KPGI+VG86PC9iPiAnSmFjbmkgUWluJzxicj4NCjxiPkNjOjwvYj4gdG9tMTExLnRh eWxvckBiZWxsLm5ldDsgbXVsdHJhbnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFttdWx0cmFuc10gQ29tbWVudHMgb24gZHJhZnQtamFjbGVlLWJlaGF2ZS12NHY2LW1jYXN0LXBz LTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSByZWFkIHRoZSBwYXJh Z3JhcGgg4oCcMy4mbmJzcDsgVHJhbnNpdGlvbiBTdGVwc+KAnSBpbiBkcmFmdC10c291LXY2b3Bz LW11bHRpY2FzdC10cmFuc2l0aW9uLXY2b25seS0wMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVy Ij4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2si PuW9reWGmzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrl jY7mlofnu4bpu5E7Y29sb3I6YmxhY2siPiBMaWdodG5pbmcgUGVuZzxicj4NClBob25lOiAmIzQz Ozg2IDc1NSAyODk3ODg1MTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PGJyPg0KTW9iaWxlOiAmIzQzOzg2IDE1OTg5MzYyNDEwPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBK YWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEFwcmlsIDEyLCAyMDExIDQ6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IExpZ2h0bmluZyBQ ZW5nKEp1bik8YnI+DQo8Yj5DYzo8L2I+IHRvbTExMS50YXlsb3JAYmVsbC5uZXQ7IG11bHRyYW5z QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXVsdHJhbnNdIENvbW1lbnRzIG9u IGRyYWZ0LWphY2xlZS1iZWhhdmUtdjR2Ni1tY2FzdC1wcy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmhpIFBlbmcsPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEFwciAx MiwgMjAxMSBhdCAzOjQxIFBNLCA8c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OuWui+S9kyI+DQrlva3lhps8L3NwYW4+IExpZ2h0bmluZyBQZW5nICZsdDs8YSBocmVmPSJtYWls dG86TGlnaHRuaW5nLVBlbmdAaHVhd2VpLmNvbSI+TGlnaHRuaW5nLVBlbmdAaHVhd2VpLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHVz ZSBjYXNlcyBpbiAzLjQuICZuYnNwO01vbm8tU3RhY2sgTXVsdGljYXN0IERlbGl2ZXJ5IEluZnJh c3RydWN0dXJlIGp1c3Q8YnI+DQppbnZvbHZlIFRyYW5zbGF0aW9uIENhc2VzIGFuZCBUcmF2ZXJz YWwgQ2FzZXMsIGJ1dCBJIHRoaW5rIGFub3RoZXIgY2FzZSBpbjxicj4NCmRyYWZ0LXRzb3UtdjZv cHMtbXVsdGljYXN0LXRyYW5zaXRpb24tdjZvbmx5LTAxIHNob3VsZCBiZSBpbmNsdWRlZC4gPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SmFjbmkmZ3Q7OiBTb3JyeSwgSSBkb24ndCBmb2xsb3cgaGVyZSwgd2hpY2ggdXNlIGNhc2Ug ZG8geW91IG1lYW4/PGJyPg0KPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCkphY25pPGJyPg0KPC9z cGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SW4gb3JkZXI8YnI+DQp0byBoYXZlIGdvb2QgcGVyZm9ybWFu Y2Ugb2YgNC4xIEZhc3QgWmFwcGluZywgZWl0aGVyIFRyYW5zbGF0aW9uIGZ1bmN0aW9uIG9yPGJy Pg0KVHJhdmVyc2FsIGZ1bmN0aW9uIGlzIGF2b2lkZWQgaW48YnI+DQpkcmFmdC10c291LXY2b3Bz LW11bHRpY2FzdC10cmFuc2l0aW9uLXY2b25seS0wMS48YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHMh PGJyPg0KPGJyPg0KTGlnaHRuaW5nIFBlbmc8YnI+DQpQaG9uZTogJiM0Mzs4NiA3NTUgMjg5Nzg4 NTE8YnI+DQpNb2JpbGU6ICYjNDM7ODYgMTU5ODkzNjI0MTA8YnI+DQo8YnI+DQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFRvbSBUYXlsb3IgW21haWx0bzo8YSBocmVmPSJt YWlsdG86dG9tMTExLnRheWxvckBiZWxsLm5ldCI+dG9tMTExLnRheWxvckBiZWxsLm5ldDwvYT5d PGJyPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNiwgMjAxMSA2OjU1IFBNPGJyPg0KVG86IExl ZSwgWWl1PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5n ZS1mdGdyb3VwLmNvbSI+Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UtZnRncm91cC5jb208L2E+ OyBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL05BRC9USVA7PGJyPg0KSmFjbmkgUWluOyBUaW5hIFRT T1U8YnI+DQpTdWJqZWN0OiBSZTogQ29tbWVudHMgb24gZHJhZnQtamFjbGVlLWJlaGF2ZS12NHY2 LW1jYXN0LXBzLTAxPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --Boundary_(ID_A0QhTCxJ6mb3Zq5pU59v8Q)-- From yiu_lee@cable.comcast.com Wed Apr 13 20:49:35 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3DBE4E07E4; Wed, 13 Apr 2011 20:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba5+urEvS2-7; Wed, 13 Apr 2011 20:49:34 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfc.amsl.com (Postfix) with ESMTP id 169C8E0707; Wed, 13 Apr 2011 20:49:33 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.33838239; Wed, 13 Apr 2011 21:52:38 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Wed, 13 Apr 2011 23:49:26 -0400 From: "Lee, Yiu" To: "Jean-Francois.TremblayING@videotron.com" , Fang-Yu Ling Thread-Topic: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt Thread-Index: AQHL+lbyCv8nrIt6mUa2h3CS4t4L8Q== Date: Thu, 14 Apr 2011 03:49:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: multipart/alternative; boundary="_000_C9CBE475CA43yiuleecablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:49:35 -0000 --_000_C9CBE475CA43yiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fang, I agree with Jeff that you should prepare to provide PD to even the bridged= host. Like Barbara said in another reply, even air-card today can be conne= cted to a small CPE to provider routed service. I am not 100% clear what the draft suggests. Do you suggest that the PE se= nds out RA for both host and CPE? If CPE wants a PD, it would send out a DH= CP-PD request to ask for PD from the PE (assuming dhcp server is collated w= ith the PE)? /Yiu From: > Date: Wed, 13 Apr 2011 10:24:05 -0400 To: Fang-Yu Ling > Cc: IPv6 Ops WG >, > Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.t= xt > (Fang-Yu Ling) > wrote > 3. The problem we'd like to solve is to simplify the configuration of PE. > Before this model, PE's operator has to know the subscriber is in bridge > or routed mode. The operator configures a IPv6 address for RA if the subs= criber > is in bridged mode. The operator configures a IPv6 prefix for DHCP-PD if = the > subscriber is in routed mode. But in our model, operator configures both = for > each no matter the subscriber is in which mode. It is to simplify the con= figuration. Thank you for clarifying your need here. My humble opinion: - You need to send RAs anyway in both cases, so there's no difference in co= nfiguration here. - It's impossible to differentiate in advance between a user with an embedd= ed routed CPE and a user with a bridged CPE with a standalone routed CPE behind it (for e= xample what happens if a user adds a router later?). The bottom line is that you have to provis= ion PD prefixes for all of your users anyway. No matter what, you shouldn't be worried about running out of IPv6 address = space. If you don't have enough space for all of your users, ask your RIR for more= space. Some RIRs will ask for justification of the previous block, but that's an i= ssue with your local RIR policies and better discussed on the related mailing li= st. /JF > Regards, > Fang > ------------------------------------------- > Fang-Yu Ling > Chunghwa Telecom Laboratories > mailto:fancy@cht.com.tw > TEL: +886-3-424-5631 > FAX: +886-3-424-4888 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_C9CBE475CA43yiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2829E3D01B5C914AB93754448E539614@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi Fang,

I agree with Jeff that you should prepare to provide PD to even the br= idged host. Like Barbara said in another reply, even air-card today can be = connected to a small CPE to provider routed service.

I am not 100% clear what the draft suggests.  Do you suggest that= the PE sends out RA for both host and CPE? If CPE wants a PD, it would sen= d out a DHCP-PD request to ask for PD from the PE (assuming dhcp server is = collated with the PE)? 

/Yiu

From: <Jean-Francois.TremblayING@videotron.com>
Date: Wed, 13 Apr 2011 10:24:05 -04= 00
To: Fang-Yu Ling <fancy@cht.com.tw>
Cc: IPv6 Ops WG <v6ops@ietf.org>, <v6ops-bounces@ietf.org>
Subject: Re: [v6ops] new draft:draf= t-fling-v6ops-hybrid-bridged-routed-00.txt




> (Fang-Yu Ling) <fancy@cht.com.t= w> wrote
> 3. The problem we'd like to solve is to simplify the configuration of = PE.
> Before this model, PE's operator has to know the = subscriber is in bridge
> or routed mode. The operator configures a IPv6 ad= dress for RA if the subscriber
> is in bridged mode. The operator configures a IPv= 6 prefix for DHCP-PD if the
> subscriber is in routed mode. But in our model, o= perator configures both for
> each no matter the subscriber is in which mode. I= t is to simplify the configuration.

Thank you for clarifying your need here. <= br>
My humble opinion:
- You need to send RAs anyway in both cases, so there'= s no difference in configuration here.
- It's impossible to differentiate in advance between = a user with an embedded routed CPE
and a user with a bridged CPE with a standalone routed= CPE behind it (for example what happens
if a user adds a router later?). The bottom line is th= at you have to provision PD prefixes
for all of your users anyway.

No matter what, you shouldn't be worried about running= out of IPv6 address space.
If you don't have enough space for all of your users, = ask your RIR for more space.
Some RIRs will ask for justification of the previous b= lock, but that's an issue
with your local RIR policies and better discussed on t= he related mailing list.

/JF

> Regards,
> Fang
> -------------------------------------------
> Fang-Yu Ling
> Chunghwa Telecom Laboratories
> mailto:fancy@cht.com.tw
> TEL: +886-3-424-5631
> FAX: +886-3-424-4888




_______________________________________________ v6ops mailing list v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops --_000_C9CBE475CA43yiuleecablecomcastcom_-- From fancy@cht.com.tw Thu Apr 14 00:05:27 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 97BB6E0675 for ; Thu, 14 Apr 2011 00:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.761 X-Spam-Level: *** X-Spam-Status: No, score=3.761 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqpnsqqiUChv for ; Thu, 14 Apr 2011 00:05:26 -0700 (PDT) Received: from scan2.cht.com.tw (scan3.cht.com.tw [202.39.168.43]) by ietfc.amsl.com (Postfix) with ESMTP id D4D35E0687 for ; Thu, 14 Apr 2011 00:05:25 -0700 (PDT) X-AuditID: 0aa00266-a9d6bba000000b34-3b-4da69cb36697 Received: from cas2.corp.cht.com.tw (unknown [10.160.2.148]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id F2BCC1574A9 for ; Thu, 14 Apr 2011 15:05:22 +0800 (CST) Received: from MAIL.corp.cht.com.tw ([10.160.1.132]) by cas2.corp.cht.com.tw ([10.160.2.148]) with mapi; Thu, 14 Apr 2011 15:05:22 +0800 From: =?big5?B?reKq2rfsKEZhbmctWXUgTGluZyk=?= To: IPv6 Ops WG Date: Thu, 14 Apr 2011 15:05:25 +0800 Thread-Topic: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt Thread-Index: AQHL+lbyCv8nrIt6mUa2h3CS4t4L8ZRc7XLQ Message-ID: <19614F693882ED4DA4481CBE85DDE4B3011BA3C0AA1F@MAIL.corp.cht.com.tw> References: In-Reply-To: Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-TW, en-US Content-Type: multipart/alternative; boundary="_000_19614F693882ED4DA4481CBE85DDE4B3011BA3C0AA1FMAILcorpcht_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] new draft:draft-fling-v6ops-hybrid-bridged-routed-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:05:27 -0000 --_000_19614F693882ED4DA4481CBE85DDE4B3011BA3C0AA1FMAILcorpcht_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 VGhhbmtzIGFsbCwgd2Ugd2lsbCB1cGxvYWQgYSByZXZpc2VkIHZlcnNpb24gdG8gZXhwbGFpbiBj bGVhcmVyIGFib3V0IG91ciBpZGVhLg0KDQpGYW5nDQoNCkZyb206IExlZSwgWWl1IFttYWlsdG86 WWl1X0xlZUBDYWJsZS5Db21jYXN0LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAx MSAxMTo0OSBBTQ0KVG86IEplYW4tRnJhbmNvaXMuVHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbTsg reKq2rfsKEZhbmctWXUgTGluZykNCkNjOiBJUHY2IE9wcyBXRzsgdjZvcHMtYm91bmNlc0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OmRyYWZ0LWZsaW5nLXY2b3BzLWh5 YnJpZC1icmlkZ2VkLXJvdXRlZC0wMC50eHQNCg0KSGkgRmFuZywNCg0KSSBhZ3JlZSB3aXRoIEpl ZmYgdGhhdCB5b3Ugc2hvdWxkIHByZXBhcmUgdG8gcHJvdmlkZSBQRCB0byBldmVuIHRoZSBicmlk Z2VkIGhvc3QuIExpa2UgQmFyYmFyYSBzYWlkIGluIGFub3RoZXIgcmVwbHksIGV2ZW4gYWlyLWNh cmQgdG9kYXkgY2FuIGJlIGNvbm5lY3RlZCB0byBhIHNtYWxsIENQRSB0byBwcm92aWRlciByb3V0 ZWQgc2VydmljZS4NCg0KSSBhbSBub3QgMTAwJSBjbGVhciB3aGF0IHRoZSBkcmFmdCBzdWdnZXN0 cy4gIERvIHlvdSBzdWdnZXN0IHRoYXQgdGhlIFBFIHNlbmRzIG91dCBSQSBmb3IgYm90aCBob3N0 IGFuZCBDUEU/IElmIENQRSB3YW50cyBhIFBELCBpdCB3b3VsZCBzZW5kIG91dCBhIERIQ1AtUEQg cmVxdWVzdCB0byBhc2sgZm9yIFBEIGZyb20gdGhlIFBFIChhc3N1bWluZyBkaGNwIHNlcnZlciBp cyBjb2xsYXRlZCB3aXRoIHRoZSBQRSk/DQoNCi9ZaXUNCg0KRnJvbTogPEplYW4tRnJhbmNvaXMu VHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbTxtYWlsdG86SmVhbi1GcmFuY29pcy5UcmVtYmxheUlO R0B2aWRlb3Ryb24uY29tPj4NCkRhdGU6IFdlZCwgMTMgQXByIDIwMTEgMTA6MjQ6MDUgLTA0MDAN ClRvOiBGYW5nLVl1IExpbmcgPGZhbmN5QGNodC5jb20udHc8bWFpbHRvOmZhbmN5QGNodC5jb20u dHc+Pg0KQ2M6IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+PiwgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OmRyYWZ0LWZsaW5nLXY2b3BzLWh5 YnJpZC1icmlkZ2VkLXJvdXRlZC0wMC50eHQNCg0KDQoNCg0KPiAoRmFuZy1ZdSBMaW5nKSA8ZmFu Y3lAY2h0LmNvbS50dzxtYWlsdG86ZmFuY3lAY2h0LmNvbS50dz4+IHdyb3RlDQo+IDMuIFRoZSBw cm9ibGVtIHdlJ2QgbGlrZSB0byBzb2x2ZSBpcyB0byBzaW1wbGlmeSB0aGUgY29uZmlndXJhdGlv biBvZiBQRS4NCj4gQmVmb3JlIHRoaXMgbW9kZWwsIFBFJ3Mgb3BlcmF0b3IgaGFzIHRvIGtub3cg dGhlIHN1YnNjcmliZXIgaXMgaW4gYnJpZGdlDQo+IG9yIHJvdXRlZCBtb2RlLiBUaGUgb3BlcmF0 b3IgY29uZmlndXJlcyBhIElQdjYgYWRkcmVzcyBmb3IgUkEgaWYgdGhlIHN1YnNjcmliZXINCj4g aXMgaW4gYnJpZGdlZCBtb2RlLiBUaGUgb3BlcmF0b3IgY29uZmlndXJlcyBhIElQdjYgcHJlZml4 IGZvciBESENQLVBEIGlmIHRoZQ0KPiBzdWJzY3JpYmVyIGlzIGluIHJvdXRlZCBtb2RlLiBCdXQg aW4gb3VyIG1vZGVsLCBvcGVyYXRvciBjb25maWd1cmVzIGJvdGggZm9yDQo+IGVhY2ggbm8gbWF0 dGVyIHRoZSBzdWJzY3JpYmVyIGlzIGluIHdoaWNoIG1vZGUuIEl0IGlzIHRvIHNpbXBsaWZ5IHRo ZSBjb25maWd1cmF0aW9uLg0KDQpUaGFuayB5b3UgZm9yIGNsYXJpZnlpbmcgeW91ciBuZWVkIGhl cmUuDQoNCk15IGh1bWJsZSBvcGluaW9uOg0KLSBZb3UgbmVlZCB0byBzZW5kIFJBcyBhbnl3YXkg aW4gYm90aCBjYXNlcywgc28gdGhlcmUncyBubyBkaWZmZXJlbmNlIGluIGNvbmZpZ3VyYXRpb24g aGVyZS4NCi0gSXQncyBpbXBvc3NpYmxlIHRvIGRpZmZlcmVudGlhdGUgaW4gYWR2YW5jZSBiZXR3 ZWVuIGEgdXNlciB3aXRoIGFuIGVtYmVkZGVkIHJvdXRlZCBDUEUNCmFuZCBhIHVzZXIgd2l0aCBh IGJyaWRnZWQgQ1BFIHdpdGggYSBzdGFuZGFsb25lIHJvdXRlZCBDUEUgYmVoaW5kIGl0IChmb3Ig ZXhhbXBsZSB3aGF0IGhhcHBlbnMNCmlmIGEgdXNlciBhZGRzIGEgcm91dGVyIGxhdGVyPykuIFRo ZSBib3R0b20gbGluZSBpcyB0aGF0IHlvdSBoYXZlIHRvIHByb3Zpc2lvbiBQRCBwcmVmaXhlcw0K Zm9yIGFsbCBvZiB5b3VyIHVzZXJzIGFueXdheS4NCg0KTm8gbWF0dGVyIHdoYXQsIHlvdSBzaG91 bGRuJ3QgYmUgd29ycmllZCBhYm91dCBydW5uaW5nIG91dCBvZiBJUHY2IGFkZHJlc3Mgc3BhY2Uu DQpJZiB5b3UgZG9uJ3QgaGF2ZSBlbm91Z2ggc3BhY2UgZm9yIGFsbCBvZiB5b3VyIHVzZXJzLCBh c2sgeW91ciBSSVIgZm9yIG1vcmUgc3BhY2UuDQpTb21lIFJJUnMgd2lsbCBhc2sgZm9yIGp1c3Rp ZmljYXRpb24gb2YgdGhlIHByZXZpb3VzIGJsb2NrLCBidXQgdGhhdCdzIGFuIGlzc3VlDQp3aXRo IHlvdXIgbG9jYWwgUklSIHBvbGljaWVzIGFuZCBiZXR0ZXIgZGlzY3Vzc2VkIG9uIHRoZSByZWxh dGVkIG1haWxpbmcgbGlzdC4NCg0KL0pGDQoNCj4gUmVnYXJkcywNCj4gRmFuZw0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEZhbmctWXUgTGluZw0KPiBD aHVuZ2h3YSBUZWxlY29tIExhYm9yYXRvcmllcw0KPiBtYWlsdG86ZmFuY3lAY2h0LmNvbS50dw0K PiBURUw6ICs4ODYtMy00MjQtNTYzMQ0KPiBGQVg6ICs4ODYtMy00MjQtNDg4OA0KDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWls aW5nIGxpc3QgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= --_000_19614F693882ED4DA4481CBE85DDE4B3011BA3C0AA1FMAILcorpcht_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Thanks all, we will upload a revised version to explain clearer abou= t our idea.

 <= /span>

Fang

 

= From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]
= Sent: Thursday, April 14, 2011 11:49 AM
To: Jean-Francois.= TremblayING@videotron.com; =AD=E2= =AA=DA=B7=EC(Fang-Yu Ling)
Cc: IPv6 Ops WG; v6ops-bou= nces@ietf.org
Subject: Re: [v6ops] new draft:draft-fling-v6ops-hy= brid-bridged-routed-00.txt

 

Hi Fang,

 

I agree with Jeff that you should prepare to= provide PD to even the bridged host. Like Barbara said in another reply, e= ven air-card today can be connected to a small CPE to provider routed servi= ce.

=  

I am not 100% clear what the draft suggests.  Do you suggest that t= he PE sends out RA for both host and CPE? If CPE wants a PD, it would send = out a DHCP-PD request to ask for PD from the PE (assuming dhcp server is co= llated with the PE)? 

 

/Yiu

 

From: <= ;Jean-Francois.T= remblayING@videotron.com>
Date: Wed, 13 Apr 2011 10:24:05 = -0400
To: Fang-Yu Ling <fa= ncy@cht.com.tw>
Cc: IPv6 Ops WG <v6ops@ietf.org>, <v6ops-bounces@ietf.org>
Subject: Re: [v6ops] new dr= aft:draft-fling-v6ops-hybrid-bridged-routed-00.txt

 

=



<= br>> (Fang-Yu Ling) <fancy@ch= t.com.tw> wrote
> 3. The problem we'd like to solve i= s to simplify the configuration of PE.
> Bef= ore this model, PE's operator has to know the subscriber is in bridge
> or routed mode. The operator configures a IPv6 = address for RA if the subscriber
<= tt>> is in bri= dged mode. The operator configures a IPv6 prefix for DHCP-PD if the =
> subscriber is in routed mode. But in our model, o= perator configures both for
> each no matter= the subscriber is in which mode. It is to simplify the configuration.

Thank you for clarifying your need here. =

My humble opinion: <= br>- Y= ou need to send RAs anyway in both cases, so there's no difference in confi= guration here.
- It's impossible to differentia= te in advance between a user with an embedded routed CPE
and a user with a bridged CPE with a standalone routed CPE behind= it (for example what happens
= if a user adds a = router later?). The bottom line is that you have to provision PD prefixes <= /span>
for all of your users anyway.

No matter what, you shouldn't be worried about running out of= IPv6 address space.
If you don't have enough s= pace for all of your users, ask your RIR for more space.
Some RIRs will ask for justification of the previous block, but t= hat's an issue
with your local RIR policies and= better discussed on the related mailing list.

/JF

> Regards,
>= Fang
> -------------------------------------------
= > Fang-Yu Ling
> Chunghwa Telecom Laboratories> mailto:fancy@cht.com.tw<= /tt>
> TEL: +886-3-424-5631
> FAX: +886-3-424-4888=




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

= --_000_19614F693882ED4DA4481CBE85DDE4B3011BA3C0AA1FMAILcorpcht_-- From brian.e.carpenter@gmail.com Thu Apr 14 00:30:10 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 84273E085F for ; Thu, 14 Apr 2011 00:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dgy0emVMdkE for ; Thu, 14 Apr 2011 00:30:06 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id BD81EE065A for ; Thu, 14 Apr 2011 00:30:05 -0700 (PDT) Received: by wwk4 with SMTP id 4so5686634wwk.1 for ; Thu, 14 Apr 2011 00:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NHs4TnxFqRjTKDJBm8wuNcPe24yXYTf4N23+Q0JWABE=; b=n0gSm7SxYAsJG1WY7/nt/+OVZZKwe6kuYEKEovRUOJGQwZEzPE4mFmtfxeF1giR6Tc up9gCqLrFyARzQefXH1fRb78RYednG/cK/PzfbgCfqGJPr1E1jAiOeEym/HxkAWP0806 qs+j1DmnrHU+bXGaM3iA5vlajqGLeRG6SO9Ns= 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=grFvl5BIfpHSmm3sPIe+q0hVUPvM0WL3cm55PK/eZstHi7XjyuZixgLqbmvGYAPuCV RFensiDyrQ/K7p4zWyY0XesecNoPBTHX7cKIswXbbQlyJKbTTWEqcl0w4lR0yjjH38uV 2Ripi5Nm0BH5s0SDNCSpO6E5gGOfidZ76kqig= Received: by 10.216.15.137 with SMTP id f9mr420807wef.62.1302766205043; Thu, 14 Apr 2011 00:30:05 -0700 (PDT) Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id d54sm639278wej.10.2011.04.14.00.30.02 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 00:30:03 -0700 (PDT) Message-ID: <4DA6A279.7080701@gmail.com> Date: Thu, 14 Apr 2011 19:30:01 +1200 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: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.com> <6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net> <4D9CB156.308@gmail.com> <1302122512.4072.38.camel@shakira.millnert.se> <0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1302130763.4072.94.camel@shakira.millnert.se> <4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> <9D0ACF10-E248-4544-902F-986EC02441E8@apple.com> <4DA5FB20.9030001@inex.ie> <1302727693.4385.195.camel@shakira.millnert.se> In-Reply-To: <1302727693.4385.195.camel@shakira.millnert.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:30:10 -0000 On 2011-04-14 08:48, Martin Millnert wrote: > 3. Disabling automatic 6to4-enabling on hosts would be good, too, like > you say (virtually everyone seems to agree about this?). > > #2 begs me to question: > Brian, 4.1 in draft-ietf-v6ops-6to4-advisory-00: "This is bad practice > - it should always be a conscious decision by a user to enable 6to4." > Would you have a comment on increasing the usage of 2119-wording in the > draft? Is a change of the above "should" to "MUST" inappropriate, the > draft being a advisory text, and all? Well, it will get published a lot quicker if it is kept as an Informational draft without formal language. I think you should raise this comment against draft-ietf-v6ops-6to4-to-historic-00.txt, which says: "2. Implementations capable of acting as 6to4 routers SHOULD NOT enable 6to4 without explicit user configuration. ... 3. If implemented in future products 6to4 SHOULD be disabled by default" Brian From gvandeve@cisco.com Thu Apr 14 00:54:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 21BA1E0867 for ; Thu, 14 Apr 2011 00:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.457 X-Spam-Level: X-Spam-Status: No, score=-9.457 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o85jdGqTPqQg for ; Thu, 14 Apr 2011 00:54:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id BD31EE0872 for ; Thu, 14 Apr 2011 00:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=408; q=dns/txt; s=iport; t=1302767677; x=1303977277; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=MgTxRFCpIwwIjW/jS5c24dYNQ3zOL9QvrVEv9h/1afo=; b=H26Gfd1NSXYRpEfm3vsiINlEAipt/8gipUjby4ed1vP2HsfI8tPUKnTB gWFygjKledcuPZ1HkgcBPpB6wTv+Avefsuju0yDz0qKqfx1gUdpoUR1vE Z1encrazJITgoUrWeGmWTjAJdxKO2nIaGoCYt+bAtqte7IWFXQthJtIJX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAAOopk2Q/khRgWdsb2JhbAClfRQBARYmJaQ8nHSFbgSRaQ X-IronPort-AV: E=Sophos;i="4.64,210,1301875200"; d="scan'208";a="25660804" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2011 07:54:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3E7sahI006248; Thu, 14 Apr 2011 07:54:36 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 09:54:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 09:54:33 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503765413@XMB-AMS-101.cisco.com> In-Reply-To: <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question Thread-Index: Acv5/RS4ixqCkMckSzC2iH0KxBXoVgAe7rOA References: <20110405123002.20640.18877.idtracker@localhost><4D9B2DED.3060608@redpill-linpro.com><6A532D6F-9EFD-40D0-9859-8568412C291E@townsley.net><4D9CB156.308@gmail.com><1302122512.4072.38.camel@shakira.millnert.se><0AB09EDBCD1C484EBE45978D62F3513C3CD8A378@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1302130763.4072.94.camel@shakira.millnert.se><4D9D6B50.4020508@gmail.com> <4DA4A5FA.9000600@dougbarton.us> <7DD41DF0-7C10-41DC-84F3-396E640537DE@apple.com> From: "Gunter Van de Velde (gvandeve)" To: "james woodyatt" , X-OriginalArrivalTime: 14 Apr 2011 07:54:36.0745 (UTC) FILETIME=[33377390:01CBFA79] Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:54:39 -0000 Having IETF move RFC 3056 and RFC 3068 to Historic status won't solve any of your problems. GV> it doesn't solve the problem at this current moment, however as 6to4 should popup less in the future, it will avoid the problem becoming an incremental problem. The advisory document from Brian is good help users get a better 6to4 experience then when these advisory rules would not of existed. G/ From scott.brim@gmail.com Thu Apr 14 06:10:57 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 751CCE077E for ; Thu, 14 Apr 2011 06:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nALpzOUCX3BA for ; Thu, 14 Apr 2011 06:10:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 6B20DE0780 for ; Thu, 14 Apr 2011 06:10:56 -0700 (PDT) Received: by iye19 with SMTP id 19so1882800iye.31 for ; Thu, 14 Apr 2011 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FIszmwjnLrG67+WvULxrdj98ksWLIknkirRoGbWuS+w=; b=IgIuno8gQc62L0l+sYajwDAIOqZdxiQbfs8KlpN3iBWhSKh06VZyoN0bCQVgkLaO4j LwpebpE1C3Y9GzOisKbMqkNdt7U1weMutK9iQiTxIyydXpQpsCUPN3e5H5oE3+b7+GM2 kvTm6Vc+7BhLf4m79UXJYTD/CdcLXjiWuTEGE= 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=WfE7pjF4a1V62XBhFWVpA46R1HjqE6O52YaCm7n36cXH3hVvjS7KONylkJX98bzplw 8DISeUd/67xYqLjuKG3ERKi2NBfBK7DqpYOvczGEMJCPZsNQt9slmfUC6Uc4q0shIXRD LBJwaHDjqt438ATyybW6OfSW3/Qlau25S9hf0= Received: by 10.231.199.77 with SMTP id er13mr648167ibb.52.1302786656067; Thu, 14 Apr 2011 06:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.140 with HTTP; Thu, 14 Apr 2011 06:10:36 -0700 (PDT) In-Reply-To: <2f0101cbfa02$5f014b30$1d03e190$@com> References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> <2f0101cbfa02$5f014b30$1d03e190$@com> From: Scott Brim Date: Thu, 14 Apr 2011 09:10:36 -0400 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=90e6ba47682bda62b304a0e0a746 Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:10:57 -0000 --90e6ba47682bda62b304a0e0a746 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 13, 2011 at 13:43, Dan Wing wrote: > My thought is to add a new variable, "offset", which would default to > 200ms. > This would be a user-configurable value (e.g., "about:config" or similar). > Offset is always added to P. This would give IPv6 a 200ms head-start over > IPv4. A good value of "offset" would be the round-trip time to communicate > to a server on this network, so a value of NNN milliseconds (20ms?) might > be > reasonable for a wired connection with a typical home Internet connection, > whereas a hundred milliseconds might be reasonable for a 3G connection or a > slow Internet connection (dialup, satellite without a TCP spoofing device, > etc.). Automatically tuning offset, based on connection times, might be > useful as well, or getting the P value from the network (via DHCP or RA, as > Ted suggested). > > Today, we have an offset (or "P" value) of effectively 21-75 seconds, based > on Teemu's slide 3 at > http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf > > This 'offset' value would also reduce the worry of doubling traffic when > initially visiting a server, giving a preference to IPv6. > > Obviously if 'offset' is too large, the user notices a delay -- which is > exactly what Happy Eyeballs is trying to avoid so that IPv6 does not get a > black eye. > > Sure but I wonder why it's a separate parameter. Why not just set an initial value for P? The initial offset should be overridden by what is learned, so the distinction between P and offset vanishes after one or two learning events. Scott --90e6ba47682bda62b304a0e0a746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 13, 2011 at 13:43, Dan Wing <dwing@cisco.com> wrote:
My thought is to add a new variable, "offset", = which would default to 200ms.
This would be a user-configurable value (e.g., "about:config" or = similar).
Offset is always added to P. =A0This would give IPv6 a 200ms head-start ove= r
IPv4. =A0A good value of "offset" would be the round-trip time to= communicate
to a server on this network, so a value of NNN milliseconds (20ms?) might b= e
reasonable for a wired connection with a typical home Internet connection,<= br> whereas a hundred milliseconds might be reasonable for a 3G connection or a=
slow Internet connection (dialup, satellite without a TCP spoofing device,<= br> etc.). =A0Automatically tuning offset, based on connection times, might be<= br> useful as well, or getting the P value from the network (via DHCP or RA, as=
Ted suggested).

Today, we have an offset (or "P" value) of effectively 21-75 seco= nds, based
on Teemu's slide 3 at http://www.ietf.org/proceedings/80/slid= es/v6ops-12.pdf

This 'offset' value would also reduce the worry of doubling traffic= when
initially visiting a server, giving a preference to IPv6.

Obviously if 'offset' is too large, the user notices a delay -- whi= ch is
exactly what Happy Eyeballs is trying to avoid so that IPv6 does not get a<= br> black eye.

Sure but I wonder why it's a separate parameter. =A0= Why not just set an initial value for P? =A0 The initial offset should be o= verridden by what is learned, so the distinction between P and offset vanis= hes after one or two learning events.

Scott
--90e6ba47682bda62b304a0e0a746-- From Olaf.Bonness@telekom.de Thu Apr 14 07:23:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4291FE075F for ; Thu, 14 Apr 2011 07:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dooJn7nuY-9m for ; Thu, 14 Apr 2011 07:23:55 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfc.amsl.com (Postfix) with ESMTP id C8A2BE070B for ; Thu, 14 Apr 2011 07:23:54 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail71.telekom.de with ESMTP; 14 Apr 2011 16:21:08 +0200 Received: from S4DE9JSAAMU.ost.t-com.de ([10.125.177.112]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 16:21:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBFAAF.31B921B1" Date: Thu, 14 Apr 2011 16:21:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Happy Eyeballs - Exit strategies? Thread-Index: Acv6pZwHTBcybWQfT5mTnBrZdpZHtAACR6sQ References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> <2f0101cbfa02$5f014b30$1d03e190$@com> From: To: , X-OriginalArrivalTime: 14 Apr 2011 14:21:07.0569 (UTC) FILETIME=[32065E10:01CBFAAF] Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:23:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFAAF.31B921B1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another thing that isn't really clear to me, is how the Application-wide = P value and the P value per Destination are combined and used to = generate a new delay value that is really used at the end. Perhaps it would also make sense to have different notations / names for = these two values in the I-D. Olaf _____ =20 Von: Scott Brim [mailto:scott.brim@gmail.com]=20 Gesendet: Donnerstag, 14. April 2011 15:11 An: Dan Wing Cc: Bonne=DF, Olaf; v6ops@ietf.org; Andrew Yourtchenko Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? On Wed, Apr 13, 2011 at 13:43, Dan Wing wrote: My thought is to add a new variable, "offset", which would default to = 200ms. This would be a user-configurable value (e.g., "about:config" or = similar). Offset is always added to P. This would give IPv6 a 200ms head-start = over IPv4. A good value of "offset" would be the round-trip time to = communicate to a server on this network, so a value of NNN milliseconds (20ms?) = might be reasonable for a wired connection with a typical home Internet = connection, whereas a hundred milliseconds might be reasonable for a 3G connection = or a slow Internet connection (dialup, satellite without a TCP spoofing = device, etc.). Automatically tuning offset, based on connection times, might be useful as well, or getting the P value from the network (via DHCP or RA, = as Ted suggested). Today, we have an offset (or "P" value) of effectively 21-75 seconds, = based on Teemu's slide 3 at = http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf This 'offset' value would also reduce the worry of doubling traffic when initially visiting a server, giving a preference to IPv6. Obviously if 'offset' is too large, the user notices a delay -- which is exactly what Happy Eyeballs is trying to avoid so that IPv6 does not get = a black eye. Sure but I wonder why it's a separate parameter. Why not just set an = initial value for P? The initial offset should be overridden by what = is learned, so the distinction between P and offset vanishes after one = or two learning events. Scott ------_=_NextPart_001_01CBFAAF.31B921B1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another thing that isn't really clear&= nbsp;to me, is=20 how the Application-wide P value and = ;the P value per Destination are combined&n= bsp;and used to generate a new delay v= alue that is really used at the = end.
Perhaps it would also make = sense to have=20 different notations / names for these two values in  the=20 I-D.
Olaf
  Von:=20 Scott Brim [mailto:scott.brim@gmail.com]
Gesendet: = Donnerstag, 14.=20 April 2011 15:11
An: Dan Wing
Cc: Bonne=DF, Olaf;=20 v6ops@ietf.org; Andrew Yourtchenko
Betreff: Re: [v6ops] = Happy=20 Eyeballs - Exit strategies?

On Wed, Apr 13, 2011 at 13:43, Dan Wing <dwing@cisco.com>=20 wrote:
My thought is to add a new variable, "offset", which = would=20 default to 200ms.
This would be a user-configurable value = (e.g.,=20 "about:config" or similar).
Offset is always added to P. =  This would=20 give IPv6 a 200ms head-start over
IPv4.  A good value of = "offset"=20 would be the round-trip time to communicate
to a server on this = network,=20 so a value of NNN milliseconds (20ms?) might be
reasonable for a = wired=20 connection with a typical home Internet connection,
whereas a = hundred=20 milliseconds might be reasonable for a 3G connection or a
slow = Internet=20 connection (dialup, satellite without a TCP spoofing = device,
etc.).=20  Automatically tuning offset, based on connection times, might=20 be
useful as well, or getting the P value from the network (via = DHCP or=20 RA, as
Ted suggested).

Today, we have an offset (or "P" = value) of=20 effectively 21-75 seconds, based
on Teemu's slide 3 at http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf

This=20 'offset' value would also reduce the worry of doubling traffic=20 when
initially visiting a server, giving a preference to=20 IPv6.

Obviously if 'offset' is too large, the user notices a = delay --=20 which is
exactly what Happy Eyeballs is trying to avoid so that = IPv6 does=20 not get a
black eye.

Sure but I wonder why it's a separate parameter.  Why not = just set=20 an initial value for P?   The initial offset should be overridden = by what=20 is learned, so the distinction between P and offset vanishes after one = or two=20 learning events.

Scott
------_=_NextPart_001_01CBFAAF.31B921B1-- From dwing@cisco.com Thu Apr 14 07:40:47 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC552E077E for ; Thu, 14 Apr 2011 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.407 X-Spam-Level: X-Spam-Status: No, score=-110.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0omFPQAXCrvD for ; Thu, 14 Apr 2011 07:40:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 73A4DE0765 for ; Thu, 14 Apr 2011 07:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2890; q=dns/txt; s=iport; t=1302792046; x=1304001646; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=YEi6tR+PBR2ZB02M823tnJ+wGygOdPch7AaIudWjwyg=; b=it7jZhzZGPAWG03CUCRnYHxh21UZ6vO6m4JiL6CwW9HKZZdqFrXxRb46 CMqxX9zYPrYOtBWGsrx3zwFKpuvwiPPV4TQOg2DDBNSJtVqIamk8T89lN C95FLkypSUkgEktdQCFgLd4Ze1R+/lCJeBHalvoxqA8yFQulT9jJuzDG5 E=; X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="337303106" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 14:40:45 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EEei0g022021; Thu, 14 Apr 2011 14:40:45 GMT From: "Dan Wing" To: , References: <4D9433B3.9040206@kit.edu> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FA9B@S4DE9JSAACX.ost.t-com.de> <20110331090626.GA30227@Space.Net> <8A34913DF3402341B6E0AF5FD0E8BBA708B1FADF@S4DE9JSAACX.ost.t-com.de> <20110331172618.GA3100@nuttenaction> <8A34913DF3402341B6E0AF5FD0E8BBA708B75D3E@S4DE9JSAACX.ost.t-com.de> <8A34913DF3402341B6E0AF5FD0E8BBA708B75E5F@S4DE9JSAACX.ost.t-com.de> <2f0101cbfa02$5f014b30$1d03e190$@com> In-Reply-To: Date: Thu, 14 Apr 2011 07:40:44 -0700 Message-ID: <000301cbfab1$f02c1f90$d0845eb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv6pZwHTBcybWQfT5mTnBrZdpZHtAACR6sQAABe+2A= Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs - Exit strategies? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:40:47 -0000 > -----Original Message----- > From: Olaf.Bonness@telekom.de [mailto:Olaf.Bonness@telekom.de] > Sent: Thursday, April 14, 2011 7:21 AM > To: scott.brim@gmail.com; dwing@cisco.com > Cc: v6ops@ietf.org; ayourtch@cisco.com > Subject: AW: [v6ops] Happy Eyeballs - Exit strategies? >=20 > Another thing that isn't really clear to me, is how the Application- > wide P value and the P value per Destination are combined and used to > generate a new delay value that is really used at the end. > Perhaps it would also make sense to have different notations / names > for these two values in the I-D. Agreed. We will probably be renaming "P", too -- it was a placeholder because I couldn't think of a better name. Andrew is on PTO at the = moment and when he gets back we will start crafting an update and run it by the working group. -d > Olaf >=20 > ________________________________ >=20 > Von: Scott Brim [mailto:scott.brim@gmail.com] > Gesendet: Donnerstag, 14. April 2011 15:11 > An: Dan Wing > Cc: Bonne=DF, Olaf; v6ops@ietf.org; Andrew Yourtchenko > Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies? >=20 >=20 > On Wed, Apr 13, 2011 at 13:43, Dan Wing wrote: >=20 >=20 > My thought is to add a new variable, "offset", which would > default to 200ms. > This would be a user-configurable value (e.g., > "about:config" or similar). > Offset is always added to P. This would give IPv6 a 200ms > head-start over > IPv4. A good value of "offset" would be the round-trip > time to communicate > to a server on this network, so a value of NNN milliseconds > (20ms?) might be > reasonable for a wired connection with a typical home > Internet connection, > whereas a hundred milliseconds might be reasonable for a 3G > connection or a > slow Internet connection (dialup, satellite without a TCP > spoofing device, > etc.). Automatically tuning offset, based on connection > times, might be > useful as well, or getting the P value from the network > (via DHCP or RA, as > Ted suggested). >=20 > Today, we have an offset (or "P" value) of effectively 21- > 75 seconds, based > on Teemu's slide 3 at > http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf >=20 > This 'offset' value would also reduce the worry of doubling > traffic when > initially visiting a server, giving a preference to IPv6. >=20 > Obviously if 'offset' is too large, the user notices a > delay -- which is > exactly what Happy Eyeballs is trying to avoid so that IPv6 > does not get a > black eye. >=20 >=20 >=20 > Sure but I wonder why it's a separate parameter. Why not just > set an initial value for P? The initial offset should be overridden > by what is learned, so the distinction between P and offset vanishes > after one or two learning events. >=20 > Scott From Fred.L.Templin@boeing.com Thu Apr 14 13:44:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8591E0836; Thu, 14 Apr 2011 13:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNfIIRU0uGtE; Thu, 14 Apr 2011 13:44:38 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id A0262E07AB; Thu, 14 Apr 2011 13:44:32 -0700 (PDT) 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 p3EKiVHO016027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2011 13:44:32 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3EKiVKC009122; Thu, 14 Apr 2011 15:44:31 -0500 (CDT) 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 p3EKiTRT009074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Apr 2011 15:44:30 -0500 (CDT) 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; Thu, 14 Apr 2011 13:44:29 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" , "renum@ietf.org" Date: Thu, 14 Apr 2011 13:44:28 -0700 Thread-Topic: Simplified Automatic IPv6 Renumbering within ISATAP Sites (non-draft) Thread-Index: Acv4RPaAwKW3FKbCS76FU3Oxx/og4QAGIvjAAJ/PblA= Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@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 Subject: [v6ops] Simplified Automatic IPv6 Renumbering within ISATAP Sites (non-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:44:40 -0000 The following is not a draft, but rather just a set of ideas. Any comments or suggestions? Thanks - Fred fred.l.templin@boeing.com --- cut here --- Introduction ************ Countless end user sites in the Internet today still have predominantly IPv4 infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services. As more and more IPv6-only services are deployed in the Internet, however, hosts within the site will increasingly require IPv6 functionality for external access. Such IPv4 sites can use ISATAP [RFC5214] to provide IPv6 services to hosts within the site. Advertising ISATAP routers distribute IPv6 prefixes obtained from an ISP to hosts within the site via DHCPv6 or SLAAC for address autoconfiguration purposes. If the site subsequently reconnects to a different ISP, however, the site must renumber to use addresses derived from the new IPv6 prefixes [RFC1900][RFC4192][RFC5887]. This non-draft provides operational guidance for accommodating simplified automatic renumbering within ISATAP sites. Characteristics of Existing IPv4 Sites ************************************** Existing end user sites use IPv4 routing and addressing internally for normal IT operations such as filesharing, network printing, e-mail, conferencing and numerous other critical site-internal networking services. Such sites typically have an abundance of public or private IPv4 addresses for internal networking, and are separated from the public Internet by firewalls, packet filtering gateways, proxies, address translators and other site border securing devices. To date, such sites have had little incentive to enable IPv6 services internally [RFC1687]. With the emergence of IPv6-only services within the public Internet, however, existing IPv4 sites will increasingly require a means for enabling IPv6 services so that hosts within the site can communicate with IPv6 correspondents in the Internet. Such services must be deployable with minimal configuration and in a fashion that will not cause disruptions to existing IPv4 services within the site. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to-use service that sites can deploy in the near term to meet these reqirements. Enabling Client-Side IPv6 Services with ISATAP ********************************************** Small sites typically arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP) in the same fashion as for home network users. When the ISP does not yet provide native IPv6 services, it can instead offer a transitional service with native-equivalent capabilities using 6RD [RFC5569][RFC5969]. Large sites typically obtain provider independent IPv6 prefixes from an Internet registry and advertise the prefixes into the IPv6 routing system on their own behalf, i.e., they act as an ISP unto themselves. (Such large sites need never incur a site-wide IPv6 renumbering.) After obtaining IPv6 prefixes, the site can automatically enable ISATAP based IPv6 services by configuring one or more site border routers as advertising ISATAP routers. Each such ISATAP router is added to the Potential Router List (PRL) for the site so that hosts can discover them for default route and address auto-configuration purposes. ISATAP hosts will automatically discover ISATAP site border routers and configure ISATAP addresses using either Stateless Address AutoConfiguration (SLAAC) or the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). In order to provide a simple service that does not interact poorly with existing site topological arrangements, the site should limit IPv6 operation for external access only so that hosts only use the ISATAP service for communicating with IPv6 correspondents on the public Internet, while continuing to use IPv4 services for intra-site communications. In order to maintain an external-only service, the site should not publish any IPv6 addresses provided by ISATAP within the site name service. The site should further not write down any IPv6 literal addresses within configuration files, documentation, packet filter rules, etc. An exception to this rule is that literal addresses may be used within packet filtering rules as long as they can be automatically rewritten during a site renumbering event. In this way, intra-site communications will continue to use existing IPv4 networking services instead of ISATAP served IPv6 services. Simplified Automatic Renumbering within ISATAP Sites **************************************************** When the site is configured in the manner described above, site renumbering in the event of a change in an ISP-served IPv6 prefix entails only the renumbering of IPv6 addresses and/or prefixes that are assigned to the ISATAP interfaces of hosts within the site. In some cases, filtering rules (e.g., within site border firewall filtering tables) may also require renumbering, but this operation can be automated and limited to only one or a few "touch points" at the site border. In order to renumber the ISATAP interfaces of hosts within the site, however, the ISATAP routers need only schedule the services offered by the old ISP for deprecation while beginning to advertise the IPv6 prefixes provided by the new ISP. ISATAP host interface address lifetimes will eventually expire, and the host will renumber its interfaces with addresses derived from the new prefixes. If the site has published the IPv6 addresses of any site- internal nodes within the public Internet DNS system, then the corresponding resource records will need to be updated during the renumbering operation. This can be accomplished via secure dynamic updates to the DNS. = From iesg-secretary@ietf.org Fri Apr 15 13:51:15 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFDD4E0747; Fri, 15 Apr 2011 13:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz2OMIfW5e2l; Fri, 15 Apr 2011 13:51:13 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0383EE0674; Fri, 15 Apr 2011 13:51:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415205113.13704.48681.idtracker@ietfc.amsl.com> Date: Fri, 15 Apr 2011 13:51:13 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:51:16 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 AAAA DNS Whitelisting Implications' 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-04-29. 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-aaaa-whitelisting-implications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/ No IPR declarations have been submitted directly on this I-D. From lee@asgard.org Fri Apr 15 15:14:57 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3645E06AD for ; Fri, 15 Apr 2011 15:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa-GEeE-+zL0 for ; Fri, 15 Apr 2011 15:14:57 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfc.amsl.com (Postfix) with ESMTP id 3ECC3E0688 for ; Fri, 15 Apr 2011 15:14:57 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p3FMEudW022491 for ; Fri, 15 Apr 2011 18:14:56 -0400 Authentication-Results: cm-omr7 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.164] ([204.235.115.164:40496] helo=HDC00027112) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D7/3F-19066-063C8AD4; Fri, 15 Apr 2011 18:14:56 -0400 From: "Lee Howard" To: "'Templin, Fred L'" , References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> In-Reply-To: Date: Fri, 15 Apr 2011 18:14:55 -0400 Message-ID: <001201cbfbba$8d5e2fc0$a81a8f40$@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: Acv4RPaAwKW3FKbCS76FU3Oxx/og4QAGIvjAANawgzA= Content-Language: en-us Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:14:58 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, > Fred L > Sent: Monday, April 11, 2011 2:18 PM > To: v6ops@ietf.org > Subject: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - > (pre-draft) > > Hello, > > The following should not be construed as a draft, but > rather just a set of ideas that might be considered > for inclusion in a new or existing draft. Any > comments or suggestions? > > Introduction > ************ > Countless end user sites in the Internet today still have > predominantly IPv4 infrastructures. These sites range in > size from small home/office networks to large corporate > enterprise networks, but share the commonality that IPv4 > continues to provide satisfactory internal routing and The requirements for end-users and large corporate networks are different. For a commercial network, making sure external- facing servers are IPv6-enabled is a higher priority than making sure users have IPv6 access. Commercial/enterprise networks have network administrators who configure routers (and might even have routers that support ISATAP). If you're providing general advice about how to make IPv6 available, you need to advise on how to evaluate options, which may include ISATAP. The document you've written isn't general operational guidance, it's an ISATAP primer, and it would be less confusing if it were labeled as such. Lee From Fred.L.Templin@boeing.com Fri Apr 15 15:40:33 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F18CDE0665 for ; Fri, 15 Apr 2011 15:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUEfuoXVbRWr for ; Fri, 15 Apr 2011 15:40:32 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 065F7E0661 for ; Fri, 15 Apr 2011 15:40:31 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3FMePRA013131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2011 15:40:26 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3FMeLc4026451; Fri, 15 Apr 2011 17:40:22 -0500 (CDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3FMeKFb026411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 15 Apr 2011 17:40:20 -0500 (CDT) 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; Fri, 15 Apr 2011 15:40:19 -0700 From: "Templin, Fred L" To: Lee Howard , "v6ops@ietf.org" Date: Fri, 15 Apr 2011 15:40:19 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv4RPaAwKW3FKbCS76FU3Oxx/og4QAGIvjAANawgzAAAMjAAA== Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-Reply-To: <001201cbfbba$8d5e2fc0$a81a8f40$@org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18076.001 x-tm-as-result: No--71.644800-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:40:33 -0000 Hi Lee, Thanks for the thoughts, and see below:=20 > -----Original Message----- > From: Lee Howard [mailto:lee@asgard.org]=20 > Sent: Friday, April 15, 2011 3:15 PM > To: Templin, Fred L; v6ops@ietf.org > Subject: RE: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft) >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, > > Fred L > > Sent: Monday, April 11, 2011 2:18 PM > > To: v6ops@ietf.org > > Subject: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly > IPv4 Sites - > > (pre-draft) > >=20 > > Hello, > >=20 > > The following should not be construed as a draft, but > > rather just a set of ideas that might be considered > > for inclusion in a new or existing draft. Any > > comments or suggestions? > >=20 > > Introduction > > ************ > > Countless end user sites in the Internet today still have > > predominantly IPv4 infrastructures. These sites range in > > size from small home/office networks to large corporate > > enterprise networks, but share the commonality that IPv4 > > continues to provide satisfactory internal routing and >=20 > The requirements for end-users and large corporate networks > are different. I understand your point, but end-user sites come in infinitely many shapes and sizes. There is my home network behind a NAT, which is really just a single flat IP subnet supporting a few laptops, printers etc. Then there is my local tire dealer down the street which probably has a network of 20-odd computers, some number of handheld devices, printers, faxes, etc. Then there are banks - some with only 1-2 branches, and some with 100's or 1000's of branches. Then there are mobile vehicular networks like cars and planes. Then there are disaster relief networks, tactical military networks, and other forms of MANETs. And, finally we come to major multinational large corporations. This is why whenever I see a solution proposal I ask folks to write an applicability statement. So far, no one but me has: http://www.rfc-editor.org/rfc/rfc6139.txt What people don't seem to be getting is that there is a rich continuum of what can be classified as a "site" ranging from the very small (my cellphone and its attached bluetooth devices) to the very huge (the Boeing Corporate network). And the degree to which the site needs to become "IPv6 native" vs. "still IPv4, but IPv6-enabled" varies on a case by case basis and is not binary based, e.g. on "corporate" vs. "end-user".=20 > For a commercial network, making sure external- > facing servers are IPv6-enabled is a higher priority than making=20 > sure users have IPv6 access. Commercial/enterprise networks > have network administrators who configure routers (and might > even have routers that support ISATAP). Sure. > If you're providing general advice about how to make IPv6 > available, you need to advise on how to evaluate options, > which may include ISATAP. The document you've written > isn't general operational guidance, it's an ISATAP primer, and > it would be less confusing if it were labeled as such. Well, this was specifically labeled as "pre-draft" and nothing has gone to the I-D repository. I don't mind hearing about other options - do you have any you want to propose? Thanks - Fred fred.l.templin@boeing.com =20 > Lee >=20 > = From pch-b6B5344D9@u-1.phicoh.com Sat Apr 16 01:43:14 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80FE7E06F4 for ; Sat, 16 Apr 2011 01:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NMwnH9Ip-+k for ; Sat, 16 Apr 2011 01:43:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 65976E0675 for ; Sat, 16 Apr 2011 01:43:12 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QB15u-0001m4C; Sat, 16 Apr 2011 10:43 +0200 Message-Id: To: "Templin, Fred L" From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-reply-to: Your message of "Fri, 15 Apr 2011 15:40:19 -0700 ." Date: Sat, 16 Apr 2011 10:42:47 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 08:43:14 -0000 In your letter dated Fri, 15 Apr 2011 15:40:19 -0700 you wrote: >What people don't seem to be getting is that there is >a rich continuum of what can be classified as a "site" >ranging from the very small (my cellphone and its >attached bluetooth devices) to the very huge (the Boeing >Corporate network). And the degree to which the site >needs to become "IPv6 native" vs. "still IPv4, but >IPv6-enabled" varies on a case by case basis and is >not binary based, e.g. on "corporate" vs. "end-user". I think for this discussion it would be good if you try to narrow down the range of sites to something where ISATAP would be most appropriate. Yes we can try to discuss how ISATAP can be used in an ordinary home site with just a single NAT router, but it doesn't make much sense. >> If you're providing general advice about how to make IPv6 >> available, you need to advise on how to evaluate options, >> which may include ISATAP. The document you've written >> isn't general operational guidance, it's an ISATAP primer, and >> it would be less confusing if it were labeled as such. > >Well, this was specifically labeled as "pre-draft" >and nothing has gone to the I-D repository. I don't >mind hearing about other options - do you have any >you want to propose? Assuming a big site with just a few places that need IPv6 right now I can imagine: IPv6 capable routers in places that need IPv6 connected by: - 6in4 tunnels, or - A parallel IPv6 backbone (assuming intra-site connection are all some kind of ethernet, that should be quite easy), or - A 'sparse' IPv6 backbone based on vlans. From fred@cisco.com Sun Apr 17 11:00:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 07B06E06EC for ; Sun, 17 Apr 2011 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.379 X-Spam-Level: X-Spam-Status: No, score=-110.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+a94ANsxq95 for ; Sun, 17 Apr 2011 11:00:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 5583FE06A0 for ; Sun, 17 Apr 2011 11:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2211; q=dns/txt; s=iport; t=1303063228; x=1304272828; h=from:subject:date:message-id:cc:to:mime-version; bh=Zt6uvszKz3eHbM/hWKoL64U/l8uYEqwRvCX4dqNTPqk=; b=lzGL38Jis76VM5xe1If1k0Gujs+0/K5q/IKt2jF7zVQ0FPGpc+zl/Dd9 RoJrtL4Sq3jloH1lR7m3YKk/yvSEDy25WZRZdRoLbDn/4X9nDtAJziZml rdu/bo/94UT28kMf6DR959OhEXNOw5NIZjOoARPvlUXe+LWn8PzB0BMMh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAD0qq02tJV2Y/2dsb2JhbACCYZVjjUF3p0GbGYVxBIViiCGDdQ X-IronPort-AV: E=Sophos;i="4.64,228,1301875200"; d="scan'208,217";a="296315730" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 17 Apr 2011 18:00:27 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3HI0Lkq031510; Sun, 17 Apr 2011 18:00:27 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 17 Apr 2011 11:00:27 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 17 Apr 2011 11:00:27 -0700 From: Fred Baker Date: Sun, 17 Apr 2011 11:00:07 -0700 Message-Id: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-485976685 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:00:29 -0000 --Apple-Mail-13-485976685 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week working group last call of = draft-ietf-v6ops-6to4-to-historic. 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.= --Apple-Mail-13-485976685 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a two week working = group last call of draft-ietf-v6ops-6to4-to-historic. 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.
= --Apple-Mail-13-485976685-- From fred@cisco.com Sun Apr 17 11:00:31 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D65D6E072B for ; Sun, 17 Apr 2011 11:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.398 X-Spam-Level: X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN+zdAcuvV0J for ; Sun, 17 Apr 2011 11:00:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id AD77BE06A0 for ; Sun, 17 Apr 2011 11:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2205; q=dns/txt; s=iport; t=1303063230; x=1304272830; h=from:subject:date:message-id:cc:to:mime-version; bh=PrN2DIE02zQarvm2vhdqX9DuAbTdKbzUyUnpTa51TKQ=; b=ADNO54KBUzgkJEt71LpRlxMLLQZrckhOyESWP7Q4wvPtsS8g1uWIDzAQ 1iFhJoRpgUtLus48SLWGyp0lvAevXhxEcyKZMKPSPtFJdlAaPeXYTv8p+ QTD4txd99VfykbdCrrUyYglLkQB8PLLKvTzOG03bipzdyIhBuJthDaVse M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAHUqq02tJV2Y/2dsb2JhbACCYZVjjUF3p0KbGYVxBIViiCGDdQ X-IronPort-AV: E=Sophos;i="4.64,228,1301875200"; d="scan'208,217";a="339295951" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2011 18:00:26 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3HI0Lkp031510; Sun, 17 Apr 2011 18:00:26 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 17 Apr 2011 11:00:26 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 17 Apr 2011 11:00:26 -0700 From: Fred Baker Date: Sun, 17 Apr 2011 11:00:05 -0700 Message-Id: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-485974960 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:00:32 -0000 --Apple-Mail-12-485974960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week working group last call of = draft-ietf-v6ops-6to4-advisory. 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.= --Apple-Mail-12-485974960 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a two week working = group last call of draft-ietf-v6ops-6to4-advisory. 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.
= --Apple-Mail-12-485974960-- From prvs=1088eeeaf3=jordi.palet@consulintel.es Sun Apr 17 11:27:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3809EE070C for ; Sun, 17 Apr 2011 11:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xplfcv3sp7Az for ; Sun, 17 Apr 2011 11:27:27 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 435D4E06EC for ; Sun, 17 Apr 2011 11:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303064434; x=1303669234; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=lhjmK5Zozvryem1bPqA7iG6GS C84wWikw38HSWOzoWo=; b=jnrQRgSabU7M/suck7YfEejlMKu5DOU+i/bOhAARR XEUytBqUItYLUfMJ3nv6J5kr8aRJgeOALE8Cg0cTl2YmB8sfW+fuyWX1Ouc0DBXl OlfxDfwuwP/gJ2OeHgd6Z1wv8Ph8udF2ytabr2n2gSNn48yKrAEiF4tF83SLRp5N gw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gxXh3Cax9/rvEUAQ8M3HkzwU0TW3zE7dBxP9unSnYqqZyv+mLzvjBVTqytZm nuqbYOKkl5SudunApCCFs3qX8TXzfy9mXEjNXWs47FCDVo3NSUAyywizO zDAVSPpp2hH+xmTFKJUcCL0TpKHijNY4MceunYzn1OFQoyetF/xwtA=; X-MDAV-Processed: consulintel.es, Sun, 17 Apr 2011 20:20:34 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003874995.msg for ; Sun, 17 Apr 2011 20:20:34 +0200 X-Spam-Processed: consulintel.es, Sun, 17 Apr 2011 20:20:34 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110417:md50003874995::n8C0gGta1+9oB7Lm:000079xV X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1088eeeaf3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 17 Apr 2011 20:27:14 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:27:29 -0000 Hi Fred, I think this is not correct. My recall from the discussions in the last meeting and the mailing list is that there is no a general agreement (so no consensus), that this is the correct way. Furthermore, is not true the text in the document that indicates that this mechanism is unsuitable for widespread deployment and the same applies to "has rarely if ever been deployed". Measurements show that there is a lot of 6to4 usage in the network, probably 40% of the IPv6 traffic is that way. If the wrong think is people using filtering then we should also deprecate PMTU because many folks filter ICMP ? Should, because filtering deprecate any kind of tunnelling because proto-41 filtering ? What about GRE filtering ? There are several alternatives to this and we should discuss all them to reach consensus, not moving one ahead of the others. I could agree on deprecating RFC3068 and let the people use 6to4 end to end, or with manually configured relays, but not definitively RFC3056. Regards, Jordi -----Mensaje original----- De: Fred Baker Responder a: Fecha: Sun, 17 Apr 2011 11:00:07 -0700 Para: CC: , Ron Bonica Asunto: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >This is to initiate a two week working group last call of >draft-ietf-v6ops-6to4-to-historic. 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. > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From swmike@swm.pp.se Sun Apr 17 11:41:32 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26DC6E06EC for ; Sun, 17 Apr 2011 11:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVdK5ze26mBh for ; Sun, 17 Apr 2011 11:41:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 88987E06A0 for ; Sun, 17 Apr 2011 11:41:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 896E29C; Sun, 17 Apr 2011 20:41:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8725D9A; Sun, 17 Apr 2011 20:41:29 +0200 (CEST) Date: Sun, 17 Apr 2011 20:41:29 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:41:32 -0000 On Sun, 17 Apr 2011, JORDI PALET MARTINEZ wrote: > I could agree on deprecating RFC3068 and let the people use 6to4 end to > end, or with manually configured relays, but not definitively RFC3056. Do you oppose the new advise to recommend against having 6to4 default on? I think that's the major point I'm after anyway. It should be a concious decision to run 6to4, not something that is enabled by default. -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=1088eeeaf3=jordi.palet@consulintel.es Sun Apr 17 11:47:44 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7439CE06A0 for ; Sun, 17 Apr 2011 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+XgRlH4Ir6C for ; Sun, 17 Apr 2011 11:47:43 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 5BABFE0689 for ; Sun, 17 Apr 2011 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303065651; x=1303670451; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=YqRtY2IdOJX0pFU/tq0zINfxi BRjbRxucbKO9fmn0ow=; b=s3wvUhjDAS2BI0xS2I0FsFsWdsHErli9pqCZkV+lI 5+bqubMBxR/xvRz0G5X0tXTBf5pXeQp7UvIZ1M4La12uanx4IBhynO9EQsePLG2D n/z3XVXK1+TdpSrQWtKohJW64TKTTAAqs4A4SLXx1DZVAZA33LxqPr76OQGAih6j bA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dDjMURqzqhlAtp1BZUi8ttinmlEDoxIa/ARchD0yRr6cvu66M9fLhNhs6kYp /W+/GfVF9cD02o4s+CTsdm9pvnbFH5ntg3rhP3fvTC+THVTAuwXx5ALY6 WVZiHDJ+QWszDQbSyn5u7mgVe2RIoYefGvU/SUNXgLAxr15m6Exbbw=; X-MDAV-Processed: consulintel.es, Sun, 17 Apr 2011 20:40:51 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003875006.msg for ; Sun, 17 Apr 2011 20:40:51 +0200 X-Spam-Processed: consulintel.es, Sun, 17 Apr 2011 20:40:51 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110417:md50003875006::w1jOQTFZr+7wGoEA:00003E2l X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1088eeeaf3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 17 Apr 2011 20:47:33 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:47:44 -0000 I oppose to a deprecation of 6to4. It is already the last resort, and I will be happy if the anycast is by default configured off. This way, 6to4 is still useful peer-to-peer. Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo (I mean deprecating them), and for many many many other transition mechs. Regards, Jordi -----Mensaje original----- De: Mikael Abrahamsson Organizaci=F3n: People's Front Against WWW Responder a: Fecha: Sun, 17 Apr 2011 20:41:29 +0200 (CEST) Para: Jordi Palet Martinez CC: , Ron Bonica Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >On Sun, 17 Apr 2011, JORDI PALET MARTINEZ wrote: > >> I could agree on deprecating RFC3068 and let the people use 6to4 end to >> end, or with manually configured relays, but not definitively RFC3056. > >Do you oppose the new advise to recommend against having 6to4 default on? > >I think that's the major point I'm after anyway. It should be a concious >decision to run 6to4, not something that is enabled by default. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From swmike@swm.pp.se Sun Apr 17 11:52:09 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB977E0719 for ; Sun, 17 Apr 2011 11:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JenRmvA7TlRE for ; Sun, 17 Apr 2011 11:52:09 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id F2D43E06EC for ; Sun, 17 Apr 2011 11:52:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 720119C; Sun, 17 Apr 2011 20:52:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6FB039A; Sun, 17 Apr 2011 20:52:08 +0200 (CEST) Date: Sun, 17 Apr 2011 20:52:08 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:52:09 -0000 On Sun, 17 Apr 2011, JORDI PALET MARTINEZ wrote: > It is already the last resort, and I will be happy if the anycast is by > default configured off. This way, 6to4 is still useful peer-to-peer. I don't want p2p 6to4 default on either. > Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo > (I mean deprecating them), and for many many many other transition mechs. Why? They're not causing as much trouble as 6to4 is right now. Teredo doesn't have the "silent fail" that 6to4 has. -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=1088eeeaf3=jordi.palet@consulintel.es Sun Apr 17 11:56:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 117F4E0719 for ; Sun, 17 Apr 2011 11:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1QxFlQTFAUc for ; Sun, 17 Apr 2011 11:56:28 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id EDD02E06EC for ; Sun, 17 Apr 2011 11:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303066176; x=1303670976; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=LtO/UpK8dCfbzlfLFhqcFKvCB BU2XEji0qav/YGN87Y=; b=nKeDodU/r3qATjql6VNYpHNkgUfHJFvy/gxOsU8SE qQo7KcpqMPdUQneom6uyVScwX8QOz6srV2slU0wQakUhHym24u6mknysJhS9nwMd t8uOVW2mOYcO0aY8Gsz+7nWfFbxBjHIy/VvBvlYTGOHwkHRVq2aEEkif3f9IgUMC Bk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=pInUEzIRViwtD5D6c9D6Bs8cJjGYeu6dabP229ewZ5oLkIilEtAew44Zn/c1 RLU3GAzI6gwtrD9anBe+5Su8ZmqtclALF47MhG03NNErg3CyPwrOewaTU tcHNdjrrLCX0iMbFQ2nRjjPS3bxrCE+8zv1ulRuO1REcol9nuu9SEY=; X-MDAV-Processed: consulintel.es, Sun, 17 Apr 2011 20:49:36 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003875015.msg for ; Sun, 17 Apr 2011 20:49:36 +0200 X-Spam-Processed: consulintel.es, Sun, 17 Apr 2011 20:49:36 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110417:md50003875015::32xuNW80MzzGgN/y:000015SW X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1088eeeaf3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 17 Apr 2011 20:56:21 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:56:29 -0000 I don't agree, the problem is not the "silent fail", but folks missconfiguring filters, and the filters create the same trouble for any protocol using proto-41 (so tunnel brokers, ISATAP, 6over4, etc.). But same that folks filter proto-41, others filter other protocols, so again, should we kill all them ? Regards, Jordi -----Mensaje original----- De: Mikael Abrahamsson Organizaci=F3n: People's Front Against WWW Responder a: Fecha: Sun, 17 Apr 2011 20:52:08 +0200 (CEST) Para: Jordi Palet Martinez CC: , Ron Bonica Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >On Sun, 17 Apr 2011, JORDI PALET MARTINEZ wrote: > >> It is already the last resort, and I will be happy if the anycast is by >> default configured off. This way, 6to4 is still useful peer-to-peer. > >I don't want p2p 6to4 default on either. > >> Otherwise, we need to follow the same approach for 6over4, ISATAP, >>Teredo >> (I mean deprecating them), and for many many many other transition >>mechs. > >Why? They're not causing as much trouble as 6to4 is right now. Teredo >doesn't have the "silent fail" that 6to4 has. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From sthaug@nethelp.no Sun Apr 17 12:02:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 819D3E0717 for ; Sun, 17 Apr 2011 12:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcUx5FySq-Es for ; Sun, 17 Apr 2011 12:02:56 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfc.amsl.com (Postfix) with SMTP id 77738E06EC for ; Sun, 17 Apr 2011 12:02:55 -0700 (PDT) Received: (qmail 33563 invoked from network); 17 Apr 2011 19:02:53 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Apr 2011 19:02:53 -0000 Date: Sun, 17 Apr 2011 21:02:53 +0200 (CEST) Message-Id: <20110417.210253.74655326.sthaug@nethelp.no> To: jordi.palet@consulintel.es From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:02:56 -0000 > I don't agree, the problem is not the "silent fail", but folks > missconfiguring filters, and the filters create the same trouble for any > protocol using proto-41 (so tunnel brokers, ISATAP, 6over4, etc.). > > But same that folks filter proto-41, others filter other protocols, so > again, should we kill all them ? We should make sure that any use of 6to4 is a conscious decision, and that 6to4 should not default to on. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From swmike@swm.pp.se Sun Apr 17 12:08:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92455E0730 for ; Sun, 17 Apr 2011 12:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ItnsXqKUDer for ; Sun, 17 Apr 2011 12:08:55 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id E480EE06A0 for ; Sun, 17 Apr 2011 12:08:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6357F9E; Sun, 17 Apr 2011 21:08:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5FFD09C; Sun, 17 Apr 2011 21:08:54 +0200 (CEST) Date: Sun, 17 Apr 2011 21:08:54 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:08:55 -0000 On Sun, 17 Apr 2011, JORDI PALET MARTINEZ wrote: > I don't agree, the problem is not the "silent fail", but folks > missconfiguring filters, and the filters create the same trouble for any > protocol using proto-41 (so tunnel brokers, ISATAP, 6over4, etc.). TCP is resilient to ICMP filtering by means of MSS blackhole detection . The problems with ICMP filters was noticed and a detection method was deviced to workaround the problem. > But same that folks filter proto-41, others filter other protocols, so > again, should we kill all them ? If we're going to keep 6to4 we need to make it more robust, so either we make is historic or we put in the effort to try to make it work better by means of it being able to detect problems. I think we should spend our time on better things, thus I support moving it to historic. Moving it to historic doesn't mean people have to stop using it, it just means we don't think it's a good idea to use it. I agree with that statement. -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=1088eeeaf3=jordi.palet@consulintel.es Sun Apr 17 12:09:25 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DDECE0747 for ; Sun, 17 Apr 2011 12:09:25 -0700 (PDT) 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=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leIEzwSj0r1D for ; Sun, 17 Apr 2011 12:09:24 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id E56BAE06A0 for ; Sun, 17 Apr 2011 12:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303066951; x=1303671751; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=6dP+KInP5vqZwD1FOWAaZUpwc v7A0OH+R7F+FZLjWrg=; b=tO+W/xqCFRDuwUBCDWOgLAUKMBc36oYOzztOHcOz2 s9+dHPVlg4YyQv+nl0D4I7W/i0Xqu4tBzUlYR8JpNhvdiqPOm9Aj9qyDsA5POBMe 4sl93b6OM99fDabdIVVUnQLOJOQZUfm5DUR89oqSKXwt9yJty+8/1pW9B5OVrwQU tE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cWrg/cSqyRxa17Ke/WL5+aiivItLUB33eJwshE2RAwPTOqIQWvNIQ3BbpWOn QLymqy9ZXMFG0nBmEyrLUgtjpg2AmtTC5xbMg9YxwLBe9y+UvcboGiUxu LG2YXYDpl7F5hSTgWEiVECVCSF5ccheues4VPnkJZE+IVDx6HRNdtA=; X-MDAV-Processed: consulintel.es, Sun, 17 Apr 2011 21:02:31 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003875024.msg for ; Sun, 17 Apr 2011 21:02:31 +0200 X-Spam-Processed: consulintel.es, Sun, 17 Apr 2011 21:02:31 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110417:md50003875024::HqvDzNVLNcljPwy8:000000kF X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1088eeeaf3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 17 Apr 2011 21:09:15 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: <20110417.210253.74655326.sthaug@nethelp.no> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:09:25 -0000 There are two ways of doing this: 1) Killing all the protocols that may not work because some operators don't know how to configure filters 2) Making sure that protocols are better, for example by means of ensuring mechanisms such as "happy eyeballs" make a smart decision about what to use Choice 1) means we lose IPv6 connectivity until IPv6 is globally deployed. Choice 2) means we facilitate automatic transition if possible, until IPv6 is globally deployed, making this automatic transition more efficient and not being tried by apps when it doesn't work. The failure rate will drop with the time as many operators learn about IPv6 and better ways to do filtering. Regards, Jordi -----Mensaje original----- De: Responder a: Fecha: Sun, 17 Apr 2011 21:02:53 +0200 (CEST) Para: Jordi Palet Martinez CC: , Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> I don't agree, the problem is not the "silent fail", but folks >> missconfiguring filters, and the filters create the same trouble for any >> protocol using proto-41 (so tunnel brokers, ISATAP, 6over4, etc.). >> >> But same that folks filter proto-41, others filter other protocols, so >> again, should we kill all them ? > >We should make sure that any use of 6to4 is a conscious decision, and >that 6to4 should not default to on. > >Steinar Haug, Nethelp consulting, sthaug@nethelp.no ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From fred@cisco.com Sun Apr 17 13:08:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1475E0724 for ; Sun, 17 Apr 2011 13:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.33 X-Spam-Level: X-Spam-Status: No, score=-110.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5pshU1I6fEQ for ; Sun, 17 Apr 2011 13:08:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 06FCEE0681 for ; Sun, 17 Apr 2011 13:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2401; q=dns/txt; s=iport; t=1303070891; x=1304280491; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2srYb9/IiJmTwr7GeZ+t5Gm3cAk64b7mKXYIyhzI1zE=; b=KGTPWNVsKqZTMOoc24Q08BdEko3evtuU8MrIXtc4Fd7hgJgE0T0uVB7g WUN4X2o92/s5EvkNvE9KgEJBkfrVQTRewOsuswdMfUu2/sc5cC1KibncG D0/fGxs8Ea1cge6rqBBHKHWbkVdi6ypUSAEyHF+sbBrH9iBW/nivwfgdb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgGAMNHq02rRDoJ/2dsb2JhbACYG41Bd4hvniibGYVxBIViiCGDdQ X-IronPort-AV: E=Sophos;i="4.64,228,1301875200"; d="scan'208";a="339319087" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2011 20:08:10 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3HK858K018370; Sun, 17 Apr 2011 20:08:10 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 17 Apr 2011 13:08:10 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 17 Apr 2011 13:08:10 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 17 Apr 2011 13:07:51 -0700 Message-Id: References: To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:08:12 -0000 On Apr 17, 2011, at 11:47 AM, JORDI PALET MARTINEZ wrote: > Otherwise, we need to follow the same approach for 6over4, ISATAP, = Teredo > (I mean deprecating them), and for many many many other transition = mechs. If by 6over4 you mean explicit tunnels, I think they are already = something someone does consciously. =46rom my perspective, so-called "transition mechanisms" are poorly = named; they are in fact "coexistence" mechanisms (mechanisms that help = IPv6 be an equal player in an otherwise-IPv4 network) or "prototyping" = mechanisms that enable us to gain IPv6 experience in an otherwise IPv4 = network. Again from my perspective, we have entered a new phase. In this new = phase, IPv6 and IPv4 are essentially equal players, and the objective is = to develop and harden that deployment. There will be a turndown phase = for IPv4 at some point in the future; that will be driven by business = requirements. People with old equipment will continue to run it, which = will mean that IPv4-only printers will continue to be used on people's = desks and so on. But at the point that the vast majority of people, = equipment, and applications are just as happy with either IPv4 or IPv6, = folks will wonder why they need both and start turning IPv4 off. = Solutions like ds-lite and 4rd are best thought of as in support of = that; I can run IPv4 as an overlay on an otherwise IPv6-only network at = some point. But in this phase, to my way of thinking, the objective is to harden and = stabilize the IPv6 infrastructure. Solutions that are primarily useful = for prototyping at best have a limited role in that; anything that = depends on IPv4 should either be operated by the network administration = for a specific purpose, such as for example using 6rd as a way of = working around equipment that is difficult or expensive to upgrade at = the time the rest of the network is. If you heard Geoff Huston's talk at = IETF-80, yes, there's a lot of 6to4 and Teredo in the network; he finds = a lot of each in his dark nets, demonstrating that people that use it = are often experiencing a degraded IPv6 service as a result of using it. = That doesn't sound like "hardening and stabilizing". I would agree with the point that things people are doing should be = things they consciously decide to do, and can easily decide to not do.= From prvs=1088eeeaf3=jordi.palet@consulintel.es Sun Apr 17 13:16:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C0DCE0731 for ; Sun, 17 Apr 2011 13:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI8mP-PN-Toe for ; Sun, 17 Apr 2011 13:16:37 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 13AFBE06F9 for ; Sun, 17 Apr 2011 13:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303070983; x=1303675783; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=F/ACt64HWSkA6yQtodAvwLaIz tSSuhPHtdnnC6DIepM=; b=mJZrcxGVspDPQtgs0VHS+/tvDeY5apremeimtZdDt yG0Hp3eu9QZMckIrhMa19juskJ85mKzGKyEfYtkRNSE0NBUjsnfVqpop6C8iHNQ/ reUyoxIMOBTAJI4rEc8RvNt65jWjPzgd006Xl+YBwTbBpMTCcwFwAxLmajA1IV7k Ls= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=k06LWHpE+wNq/j62H4EhcLGG3NoUfDxBK9xLDnGqMEBfi8KYbFyPp/mX/U2H VbcpvVPabGjRpecjPhW5tcYntxKMlggkDVdbH+y8KMcNLVqXe+w3BptWf j+E8yndQ4yGtnF7sKvSTEmkHWLMFR6KkM4Vc0EH4nFzl70U4LQc56k=; X-MDAV-Processed: consulintel.es, Sun, 17 Apr 2011 22:09:43 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003875047.msg for ; Sun, 17 Apr 2011 22:09:43 +0200 X-Spam-Processed: consulintel.es, Sun, 17 Apr 2011 22:09:43 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110417:md50003875047::Eb9xlLCfFzQyhWEq:00002Bgu X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1088eeeaf3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 17 Apr 2011 22:16:21 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:16:38 -0000 However, we have heard also different views than the one presented by Geoff. My own experience, using an average of 30 different networks every year, while traveling, during the last 10 years, is that it fails to me less than 1% of the times. This clearly means that is not "so broken" as Geoff measurements seems to indicate, so may be not so many network is filtering it. I don't know the reason for such a difference, but it is statistically impossible that my situation of not "so much" broken, is just good luck, specially when is a view shared by others. And by the way, it still seems to be a better approach than killing protocols, making sure that they are used smartly, as said before for example with "happy eyeballs". Regards, Jordi -----Mensaje original----- De: Fred Baker Responder a: Fecha: Sun, 17 Apr 2011 13:07:51 -0700 Para: Jordi Palet Martinez CC: , Ron Bonica Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >On Apr 17, 2011, at 11:47 AM, JORDI PALET MARTINEZ wrote: > >> Otherwise, we need to follow the same approach for 6over4, ISATAP, >>Teredo >> (I mean deprecating them), and for many many many other transition >>mechs. > > > >If by 6over4 you mean explicit tunnels, I think they are already >something someone does consciously. > >From my perspective, so-called "transition mechanisms" are poorly named; >they are in fact "coexistence" mechanisms (mechanisms that help IPv6 be >an equal player in an otherwise-IPv4 network) or "prototyping" mechanisms >that enable us to gain IPv6 experience in an otherwise IPv4 network. > >Again from my perspective, we have entered a new phase. In this new >phase, IPv6 and IPv4 are essentially equal players, and the objective is >to develop and harden that deployment. There will be a turndown phase for >IPv4 at some point in the future; that will be driven by business >requirements. People with old equipment will continue to run it, which >will mean that IPv4-only printers will continue to be used on people's >desks and so on. But at the point that the vast majority of people, >equipment, and applications are just as happy with either IPv4 or IPv6, >folks will wonder why they need both and start turning IPv4 off. >Solutions like ds-lite and 4rd are best thought of as in support of that; >I can run IPv4 as an overlay on an otherwise IPv6-only network at some >point. > >But in this phase, to my way of thinking, the objective is to harden and >stabilize the IPv6 infrastructure. Solutions that are primarily useful >for prototyping at best have a limited role in that; anything that >depends on IPv4 should either be operated by the network administration >for a specific purpose, such as for example using 6rd as a way of working >around equipment that is difficult or expensive to upgrade at the time >the rest of the network is. If you heard Geoff Huston's talk at IETF-80, >yes, there's a lot of 6to4 and Teredo in the network; he finds a lot of >each in his dark nets, demonstrating that people that use it are often >experiencing a degraded IPv6 service as a result of using it. That >doesn't sound like "hardening and stabilizing". > >I would agree with the point that things people are doing should be >things they consciously decide to do, and can easily decide to not do. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From wmaton@ryouko.imsb.nrc.ca Sun Apr 17 13:34:44 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0ED5AE0734 for ; Sun, 17 Apr 2011 13:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBax+dL4F88m for ; Sun, 17 Apr 2011 13:34:43 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfc.amsl.com (Postfix) with ESMTP id 19B06E0681 for ; Sun, 17 Apr 2011 13:34:43 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.4) with ESMTP id p3HKYYSS023405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Apr 2011 16:34:39 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p3HKYYQ5023402; Sun, 17 Apr 2011 16:34:34 -0400 Date: Sun, 17 Apr 2011 16:34:34 -0400 (EDT) From: "William F. Maton Sotomayor" To: Brian E Carpenter In-Reply-To: <4DA5C098.1070302@gmail.com> Message-ID: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com><0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4D9D2D50.4040801@dougbarton.us><0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com><4D9EB2FF.2060900@gmail.com><3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com><4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> <4269EA985EACD24987D82DAE2FEC62E503765088@XMB-AMS-101.cisco.com> <4DA575C1.9060304@gmail.com> <21CA8579-04BB-4F07-8B81-2EF7210B05E8@townsley.net> <4DA5C098.1070302@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:34:44 -0000 On Thu, 14 Apr 2011, Brian E Carpenter wrote: >>> This is not very scientific as an analysis. We need data, as in the excellent >>> example below, to get some idea of the total usage as well as the problem cases: >> >>> http://stats.ottix.net/ipv6/ >> >> Nice data. How are you discerning problem cases from this though? > > You can't, but the person who runs that site is aware of Geoff Huston > and Emile Aben's work on counting failed sessions, and may be integrating > that sort of analysis too. At the moment you'd have to assume that > the failure rates Geoff and Emile have reported would apply everywhere. Indeed. I'm working with Emile to supply some data to get this ball rolling. wfms From Dmitry.Anipko@microsoft.com Sun Apr 17 15:49:57 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A23C8E06FA for ; Sun, 17 Apr 2011 15:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4TnRAfnMg6S for ; Sun, 17 Apr 2011 15:49:56 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id B44A2E068B for ; Sun, 17 Apr 2011 15:49:56 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 17 Apr 2011 15:49:55 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sun, 17 Apr 2011 15:49:55 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Sun, 17 Apr 2011 15:49:55 -0700 From: Dmitry Anipko To: Fred Baker , "v6ops@ietf.org" Date: Sun, 17 Apr 2011 15:49:54 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv9KZKqMZLQdK/MTV2VTw6z+wxJDAAJL8hA Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:49:57 -0000 The draft proposes to move both RFC 3056 and RFC 3068 to historic status on= the following grounds: 1. A statement that 6to4 has rarely if ever been deployed. 2. A list of specific issues related to 6to4. I couldn't find a reference in the draft which would support statement (1).= If there has been some study showing that 6to4 deployment, by some quantif= iable metric, is indeed many times lower than deployment of other tunnels (= for example, Teredo), then I think having a reference to such data would ma= ke statement (1) more justified.=20 In the list of issues related to 6to4, the first 4 of the issues are relate= d to relay and, in my opinion, moving RFC 3068 (+ potentially anything rela= ted to relays in RFC 3056) to historic status is a possible solution to tho= se issues, however those issues don't seem to be relevant to moving to hist= oric status RFC 3056 in general. The remaining two issues are: A) filtering of protocol 41 in intermediate f= irewalls and PMTUD/ICMP not working correctly, and B) 6to4 not able to work= in networks where non-RFC-1918 addressing is used. Specifically, the issue (A) states that "6to4 has no specified mechanism to= handle the case where protocol 41 is blocked...". Do other tunneling mecha= nisms using protocol 41 have such mechanism? If they don't, then should usa= ge of protocol 41 be moved to historic, because the stated filtering/PMTUD = problems are then not specific to RFC 3056? If they do, then having a brief= overview of those and how/why they don't apply to 6to4 would help to stren= gthen the statement. The issue (B), if I understand correctly, it is essentially about usage of = non-RFC1918 addresses in networks, connected to Internet e.g. using a NAT. = There are existing mitigations to this problem (e.g. Windows implementation= will not configure 6to4 interface if there is other IPv6 connectivity in t= he network; depending on particular implementation, in managed environments= administrators may have control whether to enable or disable 6to4 on hosts= ). But even leaving those mitigations aside, it seems that the de-prioritiz= ation of 6to4 in prefix policy table below IPv4 in the proposed RFC 3484 re= vision would take care of this issue, and moving RFC 3056 is a much stronge= r measure, which doesn't seem to be necessary, as far as the issue (B) is c= oncerned. With the revised RFC 3484, 6to4 will be one of the "last resort" = mechanisms, which will essentially be used only if nothing else can, so it = won't be harmful. So to summarize, in my opinion, in the current draft there seem to be suffi= cient arguments to move RFC 3068 to historic, but not RFC 3056. There may b= e such arguments for RFC 3056, but if there are, I think they are not suffi= ciently reflected in the draft.=20 Thank you, Dmitry From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Sunday, April 17, 2011 11:00 AM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC This is to initiate a two week working group last call of draft-ietf-v6ops-= 6to4-to-historic. Please read it now. If you find nits (spelling errors, mi= nor suggested wording changes, etc),=A0comment 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=A0list. 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=A0also an important comment to make. From prvs=1088eeeaf3=jordi.palet@consulintel.es Sun Apr 17 16:09:14 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BD187E06E3 for ; Sun, 17 Apr 2011 16:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsWGcZndanWZ for ; Sun, 17 Apr 2011 16:09:13 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 4A226E068B for ; Sun, 17 Apr 2011 16:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303081340; x=1303686140; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=5AmiKK7zuGkiipXw/7R9U3yZ8 caQU4zKyPC0sSi+mMk=; b=IFP7n10YCIzVrLjSHhqicdej1vadrvMPAeNWcYruF KHnrHzIi5BjBWmrxTmtMpRiGS1jWx4WTivTttTqu7Vzy/2UfcOManXk8wGHpu2H8 bgto8c1D4C1Ld5fJs9TAgA6wz6ZgPNsrJhi0TzSFEwP6WJY0En60mU+6FqdiBeFh JQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=tQWtqXNqANWszhFRzLfgWqCT8dpg+y55Hi1st7SXq2VJZZmmtE/yy5QTObap Jck/7M4InbSdGWe2KNGBiEnjX/n1Z3fb5QzI/srv8w8nU9bWDh/fSIcV9 O5y6hB+g6GwxgvZWjXV9KpfHa3DXh43IUNE9A+PN3PijN7vrj0hBMw=; X-MDAV-Processed: consulintel.es, Mon, 18 Apr 2011 01:02:20 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003875100.msg for ; Mon, 18 Apr 2011 01:02:20 +0200 X-Spam-Processed: consulintel.es, Mon, 18 Apr 2011 01:02:20 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110417:md50003875100::hckn5qpk7Xpq9v8H:000031Wj X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1088eeeaf3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 18 Apr 2011 01:08:57 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:09:14 -0000 Agree, and by the way, proto-41 also works behind many NAT boxes with private addresses, as studied long time ago: http://tools.ietf.org/html/draft-palet-v6ops-proto41-nat-03 So this should not be one more excuse for making this historic, otherwise, all the other proto-41 transition mechanism will be in the same situation as well. Regards, Jordi -----Mensaje original----- De: Dmitry Anipko Responder a: Fecha: Sun, 17 Apr 2011 15:49:54 -0700 Para: Fred Baker , "v6ops@ietf.org" CC: "v6ops-chairs@tools.ietf.org" , Ron Bonica Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >The draft proposes to move both RFC 3056 and RFC 3068 to historic status >on the following grounds: > >1. A statement that 6to4 has rarely if ever been deployed. > >2. A list of specific issues related to 6to4. > >I couldn't find a reference in the draft which would support statement >(1). If there has been some study showing that 6to4 deployment, by some >quantifiable metric, is indeed many times lower than deployment of other >tunnels (for example, Teredo), then I think having a reference to such >data would make statement (1) more justified. > >In the list of issues related to 6to4, the first 4 of the issues are >related to relay and, in my opinion, moving RFC 3068 (+ potentially >anything related to relays in RFC 3056) to historic status is a possible >solution to those issues, however those issues don't seem to be relevant >to moving to historic status RFC 3056 in general. > >The remaining two issues are: A) filtering of protocol 41 in intermediate >firewalls and PMTUD/ICMP not working correctly, and B) 6to4 not able to >work in networks where non-RFC-1918 addressing is used. > >Specifically, the issue (A) states that "6to4 has no specified mechanism >to handle the case where protocol 41 is blocked...". Do other tunneling >mechanisms using protocol 41 have such mechanism? If they don't, then >should usage of protocol 41 be moved to historic, because the stated >filtering/PMTUD problems are then not specific to RFC 3056? If they do, >then having a brief overview of those and how/why they don't apply to >6to4 would help to strengthen the statement. > >The issue (B), if I understand correctly, it is essentially about usage >of non-RFC1918 addresses in networks, connected to Internet e.g. using a >NAT. There are existing mitigations to this problem (e.g. Windows >implementation will not configure 6to4 interface if there is other IPv6 >connectivity in the network; depending on particular implementation, in >managed environments administrators may have control whether to enable or >disable 6to4 on hosts). But even leaving those mitigations aside, it >seems that the de-prioritization of 6to4 in prefix policy table below >IPv4 in the proposed RFC 3484 revision would take care of this issue, and >moving RFC 3056 is a much stronger measure, which doesn't seem to be >necessary, as far as the issue (B) is concerned. With the revised RFC >3484, 6to4 will be one of the "last resort" mechanisms, which will >essentially be used only if nothing else can, so it won't be harmful. > >So to summarize, in my opinion, in the current draft there seem to be >sufficient arguments to move RFC 3068 to historic, but not RFC 3056. >There may be such arguments for RFC 3056, but if there are, I think they >are not sufficiently reflected in the draft. > >Thank you, >Dmitry > >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >Fred Baker >Sent: Sunday, April 17, 2011 11:00 AM >To: v6ops@ietf.org >Cc: v6ops-chairs@tools.ietf.org; Ron Bonica >Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >This is to initiate a two week working group last call of >draft-ietf-v6ops-6to4-to-historic. 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. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From dr@cluenet.de Sun Apr 17 16:16:58 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50048E06E3 for ; Sun, 17 Apr 2011 16:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui6xgVdqbLyd for ; Sun, 17 Apr 2011 16:16:57 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfc.amsl.com (Postfix) with ESMTP id B13FCE068B for ; Sun, 17 Apr 2011 16:16:57 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id A0A4D1080EC; Mon, 18 Apr 2011 01:16:56 +0200 (CEST) Date: Mon, 18 Apr 2011 01:16:56 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110417231656.GA4874@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110405123002.20640.18877.idtracker@localhost> <4D9B2DED.3060608@redpill-linpro.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] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:16:58 -0000 On Tue, Apr 05, 2011 at 12:32:45PM -0700, Dmitry Anipko wrote: > I have a question regarding http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-00 and IPv6 day. > > In section 4.1. among other items the draft recommends to vendors to > disable Anycast 6to4 functionality by default. If an OS vendor has > an ability to do that for existing implementations, is there a WG > consensus whether such changes should be done before the IPv6 day? Speaking only for myself (obviously), I'd like to see 6to4 disabled by default, or at least priority lowered below IPv4. There's no point in having folks run into known problems - I think that would be detrimental to the overall goal. And while you're at it, fixing the ICS RA-on-WAN and RA undeprecation problems as well would be appreciated. :-) Best regards, Daniel (an operator voice) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From cb.list6@gmail.com Sun Apr 17 16:22:27 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8948E06B1 for ; Sun, 17 Apr 2011 16:22:27 -0700 (PDT) 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.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdSpona+CvJH for ; Sun, 17 Apr 2011 16:22:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 37F43E068B for ; Sun, 17 Apr 2011 16:22:27 -0700 (PDT) Received: by eye13 with SMTP id 13so1580061eye.31 for ; Sun, 17 Apr 2011 16:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=i7jTSM4ktSfo3Jiab3bfox0B6D8nbMD0EvgJLGqqV5M=; b=o/0XXCK2X98Z/PiBvYoFT7tn73K+hHM1c+ROIbEQWmUTWCfPx6L7vNFFOlIh5Ab3Cb lq94BZDSiO3lMRL3zi+qQlNSOyermT+l9VCy22qkqTQ8vZQryIpGG9KUeLwgf2/1oHzD kKscpzyLcF1fa62DhRgj8okc/djVXPgXCKoLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=LcDU0fO76faLtTdK4zEpo48ph9uarGfu61eyCiipJsHcB6kB6llyWBy9LoQ/rHW9y9 5ubWo0W1ihJ+Tq7M8iSa99MkrQyUoDk/iLfrGwQD/rMMMlAllTCX7yjkjZxtirssKln9 PdCh4DPNmxRZtw6t4OtmL+IGmfEUUmuN4LXwA= MIME-Version: 1.0 Received: by 10.213.34.74 with SMTP id k10mr1757611ebd.98.1303082546427; Sun, 17 Apr 2011 16:22:26 -0700 (PDT) Received: by 10.213.114.147 with HTTP; Sun, 17 Apr 2011 16:22:26 -0700 (PDT) Received: by 10.213.114.147 with HTTP; Sun, 17 Apr 2011 16:22:26 -0700 (PDT) Date: Sun, 17 Apr 2011 16:22:26 -0700 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: multipart/alternative; boundary=0015174bee0c4af75c04a1258c04 Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:22:28 -0000 --0015174bee0c4af75c04a1258c04 Content-Type: text/plain; charset=ISO-8859-1 As a network operator who currently null routes the 6to4 anycast since it creates stale half opened sessions that will never work in my cgn, I support this draft and support 6to4 never being enabled by default. Anycast 6to4 is not fit for what the internet has become or will be. Cameron --0015174bee0c4af75c04a1258c04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

As a network operator who currently null routes the 6to4 anycast since i= t creates stale half opened sessions that will never work in my cgn,=A0 I s= upport this draft and support 6to4 never being enabled by default.

Anycast 6to4 is not fit for what the internet has become or will be.

Cameron

--0015174bee0c4af75c04a1258c04-- From randy@psg.com Sun Apr 17 16:34:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D70DE06B1 for ; Sun, 17 Apr 2011 16:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY2I+0FcfBnE for ; Sun, 17 Apr 2011 16:34:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 1897DE068B for ; Sun, 17 Apr 2011 16:34:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBbUA-000OaX-I3; Sun, 17 Apr 2011 23:34:35 +0000 Date: Mon, 18 Apr 2011 08:35:00 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:34:36 -0000 > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-to-historic. > ... > We are looking specifically for comments on the importance of the > document it is important to get rid of this bad kludge. it was a bad design on day one, and has proven to be *really* bad in operation. deprecation is far too mild. randy From randy@psg.com Sun Apr 17 16:36:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 646D4E0692 for ; Sun, 17 Apr 2011 16:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw3N1WiPnXsV for ; Sun, 17 Apr 2011 16:36:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id E0744E068B for ; Sun, 17 Apr 2011 16:36:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBbWP-000Ob7-BH; Sun, 17 Apr 2011 23:36:54 +0000 Date: Mon, 18 Apr 2011 08:37:19 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:36:55 -0000 this proposal is far too mild. 6to4 should not be less preferred, it should be removed. it is damaging to ipv6 in that it gives the users the belief that ipv6 sucks, when it is 6to4 that sucks. randy From joelja@bogus.com Sun Apr 17 18:54:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2C26CE066C for ; Sun, 17 Apr 2011 18:54:55 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osp1ju5iSiO4 for ; Sun, 17 Apr 2011 18:54:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id 76FA8E0665 for ; Sun, 17 Apr 2011 18:54:54 -0700 (PDT) Received: from 23173jjaeggli.local (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 p3I1sFNk008446 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 18 Apr 2011 01:54:18 GMT (envelope-from joelja@bogus.com) Message-ID: <4DAB99C1.8010106@bogus.com> Date: Sun, 17 Apr 2011 18:54:09 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mikael Abrahamsson References: 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, 18 Apr 2011 01:54:20 +0000 (UTC) Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 01:54:55 -0000 On 4/17/11 11:52 AM, Mikael Abrahamsson wrote: > On Sun, 17 Apr 2011, JORDI PALET MARTINEZ wrote: > >> It is already the last resort, and I will be happy if the anycast is >> by default configured off. This way, 6to4 is still useful peer-to-peer. > > I don't want p2p 6to4 default on either. > >> Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo >> (I mean deprecating them), and for many many many other transition mechs. > > Why? They're not causing as much trouble as 6to4 is right now. Teredo > doesn't have the "silent fail" that 6to4 has. by all accounts teredo just induces really bad performance... I'm not willingto call that a win From joelja@bogus.com Sun Apr 17 18:56:14 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7EFDAE0680 for ; Sun, 17 Apr 2011 18:56:14 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RAVYFzg8oXd for ; Sun, 17 Apr 2011 18:56:13 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id 3164EE066C for ; Sun, 17 Apr 2011 18:56:11 -0700 (PDT) Received: from 23173jjaeggli.local (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 p3I1u9eV008478 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 18 Apr 2011 01:56:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4DAB9A38.1000506@bogus.com> Date: Sun, 17 Apr 2011 18:56:08 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: IPv6 Ops WG 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]); Mon, 18 Apr 2011 01:56:11 +0000 (UTC) Subject: [v6ops] draft minutes second session Thursday 31 March, 17:40-19:40 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 01:56:14 -0000 Thursday 31 March, 17:40-19:40 12) Advisory Guidelines for 6to4 Deployment http://tools.ietf.org/agenda/80/slides/v6ops-6.pdf 11-Mar-11, brian capenter - trying to put toothpaste back in the tube people having been complaining about this is an attempt to do something was not deisnged as an unmanaged solution filtering of protocol 41 is the main reason for these failures summary of issues advice to vendors do not enable 6to4 by default do not do it from rfc1918 addresses (bug) return destination unreachable if you can't do v6 don't break protocol 41 advice to transit ISPs even if you hate 6to4 you can only make things better if you run a router as a content provider running a local relay will definently help if you plan to support ipv6 randy B - 7th of june is too late tore (jabber)- The "defend against rogue RA" advice is equally important for ISPs that do not support IPV6 tim chown - Recommendation internet connection sharing should use a lower default router preference SwedeMike (jabber) - tore: yes. if you don't support ipv6, just block all 86dd between your customers brian - consider running them(relays) wes george - let me respond to that end hosts are going to do whatever 13) 6to4 Provider Managed Tunnels 13-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-13.pptx Victor k - level set we still belive native v6 is sthe best solution 6to4 is is challanging especially when covered by carrier grade nat cgnet is already out there. There are legitimate uses of non-rfc1918 addresses behind cgnat. As noted it's low cost and can run on existing relays. Has been test since Beijing p2p with another 6to4 device doesn't work. Referalls to the address are challanging when behind the CGN it's either broken or it's not. Works for the use case we defined. Ole troan - still a symetric nat 14) Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status 9-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-5.pptx ole troan - Summary, makes 3056 and and 3068 historic. What is historic? If it is superceeded or made obsolete by another specification or no longer used. We are pretty sure that protocol 42 is not going through a lot firewalls. We are saying that this is a technology that the ietf will not evolve further. Wes george – we have to struggle with the definition of historic it's good to differentiate beween turning it off in the hosts vs turning it off in the relays fred b – precent for a widely used protocol being taken to historic, ripv1. Every cpe supported ripv1. Ripv1 had no context for cidr. That was not to say don't use it. Brian C - we should do both e.g. you can consider victor's and ole's draft at the same time. Ole t - I need this document for our linksys people Mark Handley - you stole my anecdote another certification body says do this ietf thing dave t - same thing as brian second point I likened it to two issues try to depricate different rfcs is less jsutification for 6to4 bc's presentations covered potential jsutification regarding 3484, if it changes that as well then the title needs to reflect it. Primary problem is for relays, what is fairly easy to do without code changes is to tell it not to use the relay. Tom chown - what do we use behind a host instead of 6to4 for connection sharing Igor G – guidance as to how to make it better, and oh by the way don't use it. because it's protocol 41 and it's everywhere p2p and relay are both broken Mikael A (jabber) - for me, 6to4 should go away asap, both the relay and the direct version jordi M - question of making the protocol historic vs the question of making anycast histoic. Ole T - have list of drafts for other protocols this draft says depricate the whole thing Lorenzo C - I hate to think of anything else going through it if it's this hard for us. Igor g – depricate 3068 geoff h - there are many ways that 6to4 can fail in the mehtodology I used, failures due to relays are not tested. The only failure I was seeing was really narrowed down to protocol 41 I can't measure the failures that don't get to me. Brian c - I don't believe that 3056 is broken, nobody deployed it. It's true that what microsoft did is that when folks use dns to rendezvous then you don't see much teredo. Tore A (jabber) - you will get 3056 between two end sites when the end users both have CPEs that implement it by default and send out RAs by default. and what happens then? the end hosts have 1) an IPv6 address - the 6to4 one, and 2) a default router - the CPE. this is a recipe for end-user brokenness. Geoff – whatver is going on in terredo the failure rate is right up there. Mark H - if we do something less than depricate everything we leave the door open, then disabled by default needs to also be in there. Igor G - in that spirit optional should be considered harmful and ill advised. James Woodyatt (jabber) - that would be going to far erik kline - +1 for depricating 3068 consider whether we want to save 2002 in global scope dave t (jabber)- without a relay 2002 is the same as ula erik kline - what is the status of ipv6 nat, 6pt is what I would be thinking of fred b - calling the question, this is my summary is this the recommedation we want to make? Do you believe that in general this is the way that we want to go. Hum, generally in favor, some opposition noted... for brian's draft yes for ole's draft yes for victors draft no fred - victors draft could proceed as an indivual submission lorenzo c - ipv6 day is not about deployment, we can't deploy it in two months it's about fiding problems igor g – if the drafts come out first it's useful ammunition mark handley – the bullets are nice and should be captured in one of the documents tony hain (jabber) - this decision should not be driven by intentional deployment in way that breaks it (6to4) 15) IPv6 anycast based feedback data aggregation 7-Mar-11, (not presented) 16) Scalability issues in CGN Address Sharing LAFT6: Lightweight address family transition for IPv6 14-Mar-11, Considerations for Stateless Translation (IVI/dIVI) in Large SP Network 6-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-15.ppt ? - experience developed on recommendations from softwire. Communications scenarios, two major first ipv4-ipv4 for most current applications and ipv6 – ipv4 for p2p cgn brings a lot of cost enumeration of changes required by solution address consumption by solution punchline ipv4 address sharing is complex roberta Maglione - need a more scalable address sharing mechanism Randy b - shes correct dslite can easily go that path Basaraj P - where do you se stateless getting mediated Shin Miazawa – pros and cons of stateless divi it is still dificult to identify behavior nat 444 can do static mappings mark h – I'm a big fan of the stateless mechanisms, when they're possible, they're not always possible. Fred - would be nice to capture all this information in an internet draft-carpenter-v6ops Jari arko - in the int area we discussed stateless and aggreed to work on stateless (in softwire) Roberta M – motivation document in softwire is called stateless solutions mark h - not supposed to specify the actual bits, architeturaly both solutions are a tunnel divi or 4rd jari a - what mark said tina t - reduce the burden fo stateful translation fred - softwire is the a place to have the future discussion. 17) Multicast Transition to IPv6 Only in Broadband Deployments 14-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-2.pdf tina tsuo - presentation end comments? thanks 18) Solution Model of Source Address Tracing for Carrier Grade NAT (CGN) 16-Feb-11, http://tools.ietf.org/agenda/80/slides/v6ops-20.ppt Dong zang - problem is the identification of end user through nat translation hostid is another potential example. Shin M - this is a cgn requirement and we are working that. Fred B- It can't be done here it's a protocol James W (jabber) – ietf policy wiretapping (28040 is relevant to this draft). Fred B - At a minimum if people do find this useful the question is where to do it. Chris M - we have lots of methodoigies to address this. Tina T - in the cgn enviroment this one connection may belong to different users as to the question fo whether this work is useful, I think it is useful and needed. In the case of a cgn it identifies thousands of subscribers. There are other use cases roberta m - this is a useful we need traceback, other use cases in the internet area. Shin M - this is a useful but not here, we have discussed it in softwire Randy B - you know who the you who wants to know who I am is (leo) Dan wing (jabber) - the draft is inaedquate to meet the needs of law enforcement Joel j – (channeling james w at the mic) 2804 applies in that it is out of scope to consider the law enforcement requirements igor g - while I'm not advocating this randy it does provide a more fine grained method. 19) Advanced Requirements for IPv6 Customer Edge Routers 5-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-3.pdf lee Howard - state mechanisms for variosu technologies in which order they should be usd do we need to support multihoming? Requirements for the smart grid. Alain durand - pcp? Lee howard - didn't want to include things that are incomplete wess g (jabber)- pcp? Joel j (jabber) - port control protocol stuart cheshire - concerned that this leaves us with one layer deep routing randy b - not cheered by the topology contraint also 1812 in the router fred b - ipv4 should be a off the table I don't have a problem with ospf randy b - is worried about rip tony (jabber) - +1 to that comment tom herbst - one case is ula scopped addresses lee h - we want requirements as approiate lorenzo c - I kind of despise ula in general but if we solve the topology problem with ospf then there's a boundry once we've figured out how to given /64s to everyone the ula works. Lee h - take it to the list ole t - this document is suppposed to be non-inovative lorenzo please write the draft. Fred B - We're finished done From martin@millnert.se Sun Apr 17 19:55:45 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2738E06C1 for ; Sun, 17 Apr 2011 19:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHnl27dzC9pl for ; Sun, 17 Apr 2011 19:55:37 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfc.amsl.com (Postfix) with ESMTP id 28AF6E066A for ; Sun, 17 Apr 2011 19:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 20E4377A2; Mon, 18 Apr 2011 05:09:59 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXn9TLYvbLdM; Mon, 18 Apr 2011 05:09:59 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id D72AED8; Mon, 18 Apr 2011 05:09:57 +0200 (CEST) From: Martin Millnert To: Joel Jaeggli In-Reply-To: <4DAB99C1.8010106@bogus.com> References: <4DAB99C1.8010106@bogus.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 17 Apr 2011 22:55:36 -0400 Message-ID: <1303095336.4385.281.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] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 02:55:45 -0000 On Sun, 2011-04-17 at 18:54 -0700, Joel Jaeggli wrote: > On 4/17/11 11:52 AM, Mikael Abrahamsson wrote: > > Why? They're not causing as much trouble as 6to4 is right now. Teredo > > doesn't have the "silent fail" that 6to4 has. The primary reason Teredo "doesn't fail" is that it isn't used when hitting A+AAAA or AAAA records from browsers. And even though the tunnel modes *are* different, had Teredo been prioritized higher, we'd had another "co-exist" mechanism to scratch our heads about today. Thankfully, we get off easy on this one. > by all accounts teredo just induces really bad performance... I'm not > willingto call that a win There is, to my knowledge, no "default on" implementation of Teredo which does not do sufficiently proper source- and destination address selection (and more). Thus, the only result from any default mode operating Teredo implementation is that you are able to connect to IPv6 addresses, which you otherwise would not be. I don't agree with you that zero v6-connectivity is better than some connectivity that also does not hurt in any of the scenarios where 6to4 is hurting today. In fact, I'm wondering how you came about your conclusion. Regards, Martin From joelja@bogus.com Sun Apr 17 22:03:41 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D4E2E0766 for ; Sun, 17 Apr 2011 22:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2bVk25B5xpV for ; Sun, 17 Apr 2011 22:03:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id B3B4DE06A5 for ; Sun, 17 Apr 2011 22:03:39 -0700 (PDT) Received: from 23173jjaeggli.local (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 p3I53KsJ002198 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 18 Apr 2011 05:03:22 GMT (envelope-from joelja@bogus.com) Message-ID: <4DABC618.8030406@bogus.com> Date: Sun, 17 Apr 2011 22:03:20 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: jordi.palet@consulintel.es References: 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, 18 Apr 2011 05:03:23 +0000 (UTC) Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 05:03:41 -0000 On 4/17/11 11:27 AM, JORDI PALET MARTINEZ wrote: > Hi Fred, > > I think this is not correct. > > My recall from the discussions in the last meeting and the mailing list is > that there is no a general agreement (so no consensus), that this is the > correct way. >From my vantage point you're misreading the outcome of the dicussion. I have observed general consensus on the question of the usage of 6to4 being harmful to user's experience. you should demonstrate otherwise if you're going to pursue this line of reasoning. > Furthermore, is not true the text in the document that indicates that this > mechanism is unsuitable for widespread deployment and the same applies to > "has rarely if ever been deployed". > > Measurements show that there is a lot of 6to4 usage in the network, > probably 40% of the IPv6 traffic is that way. If the wrong think is people > using filtering then we should also deprecate PMTU because many folks > filter ICMP ? Should, because filtering deprecate any kind of tunnelling > because proto-41 filtering ? What about GRE filtering ? > > There are several alternatives to this and we should discuss all them to > reach consensus, not moving one ahead of the others. > > I could agree on deprecating RFC3068 and let the people use 6to4 end to > end, or with manually configured relays, but not definitively RFC3056. > > Regards, > Jordi > > > > > > > -----Mensaje original----- > De: Fred Baker > Responder a: > Fecha: Sun, 17 Apr 2011 11:00:07 -0700 > Para: > CC: , Ron Bonica > Asunto: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-6to4-to-historic. 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. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Dmitry.Anipko@microsoft.com Sun Apr 17 22:56:35 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0CCBE0655 for ; Sun, 17 Apr 2011 22:56:35 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsvqn0tUFUSn for ; Sun, 17 Apr 2011 22:56:31 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 9C8CAE05F5 for ; Sun, 17 Apr 2011 22:56:31 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 17 Apr 2011 22:56:30 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sun, 17 Apr 2011 22:56:30 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Sun, 17 Apr 2011 22:56:30 -0700 From: Dmitry Anipko To: Joel Jaeggli , "jordi.palet@consulintel.es" Date: Sun, 17 Apr 2011 22:56:29 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv9hgUn6SipQ8nVRkmnL9yibmc76AABTKFu Message-ID: References: , <4DABC618.8030406@bogus.com> In-Reply-To: <4DABC618.8030406@bogus.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" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 05:56:35 -0000 Hello Joel, from the notes of the Prague meeting you've sent out earlier it seems that = a few people expressed their concerns regarding moving RFC 3056 to historic= (and suggestions to move only RFC 3068 to historic). That was followed by = voting: "fred b - calling the question, this is my summary is this the reco= mmedation we want to make? Do you believe that in general this is the way t= hat we want to go. Hum, generally in favor, some opposition noted...". Fro= m the notes it is not clear to me - did the "recommendation in general" ref= er to adopt the draft as a framework and continue work on it (which implies= further discussion and changes are possible) or it referred to the approva= l of the draft as it was at that time? >>I have observed general consensus on the question of the usage of 6to4 b= eing harmful to user's experience. you should demonstrate otherwise if you'= re going to pursue this line of reasoning. If the supporters of moving RFC 3056 to historic feel there is firm evidenc= e why RFC 3056 is harmful, it should not be difficult to elaborate on that = in the draft, and explain why alternative mitigations (such as changing RFC= 3484 prefix policy) would not be sufficient - that would help address conc= erns regarding moving RFC 3056 to historic. If there is no such evidence ho= wever, then to me it seems reasonable to remove such recommendation for RFC= 3056, rather than postulating that RFC 3056 is harmful and requiring other= s to prove otherwise. Thank you, Dmitry ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Joel Jae= ggli [joelja@bogus.com] Sent: Sunday, April 17, 2011 10:03 PM To: jordi.palet@consulintel.es Cc: v6ops@ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On 4/17/11 11:27 AM, JORDI PALET MARTINEZ wrote: > Hi Fred, > > I think this is not correct. > > My recall from the discussions in the last meeting and the mailing list i= s > that there is no a general agreement (so no consensus), that this is the > correct way. >From my vantage point you're misreading the outcome of the dicussion. I have observed general consensus on the question of the usage of 6to4 being harmful to user's experience. you should demonstrate otherwise if you're going to pursue this line of reasoning. > Furthermore, is not true the text in the document that indicates that thi= s > mechanism is unsuitable for widespread deployment and the same applies to > "has rarely if ever been deployed". > > Measurements show that there is a lot of 6to4 usage in the network, > probably 40% of the IPv6 traffic is that way. If the wrong think is peopl= e > using filtering then we should also deprecate PMTU because many folks > filter ICMP ? Should, because filtering deprecate any kind of tunnelling > because proto-41 filtering ? What about GRE filtering ? > > There are several alternatives to this and we should discuss all them to > reach consensus, not moving one ahead of the others. > > I could agree on deprecating RFC3068 and let the people use 6to4 end to > end, or with manually configured relays, but not definitively RFC3056. > > Regards, > Jordi > > > > > > > -----Mensaje original----- > De: Fred Baker > Responder a: > Fecha: Sun, 17 Apr 2011 11:00:07 -0700 > Para: > CC: , Ron Bonica > Asunto: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-6to4-to-historic. 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 statemen= t >> 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. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the use of the individua= l(s) named above. If you are not the intended recipient be aware that any d= isclosure, copying, distribution or use of the contents of this information= , including attached files, is prohibited. > > > > _______________________________________________ > 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 jhw@apple.com Sun Apr 17 23:19:58 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 90A97E0680 for ; Sun, 17 Apr 2011 23:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.691 X-Spam-Level: X-Spam-Status: No, score=-106.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqMtK7FhvYNQ for ; Sun, 17 Apr 2011 23:19:58 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 0CAE4E0655 for ; Sun, 17 Apr 2011 23:19:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJU00601499SW90@mail-out.apple.com> for v6ops@ietf.org; Sun, 17 Apr 2011 23:19:57 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-26-4dabd80d039f Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id F0.E8.18996.D08DBAD4; Sun, 17 Apr 2011 23:19:57 -0700 (PDT) Received: from [172.16.1.2] ([75.101.54.88]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJU00M25498W420@cardamom.apple.com> for v6ops@ietf.org; Sun, 17 Apr 2011 23:19:57 -0700 (PDT) From: james woodyatt In-reply-to: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Date: Sun, 17 Apr 2011 23:19:56 -0700 Message-id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:19:58 -0000 On Apr 17, 2011, at 11:00 AM, Fred Baker wrote: > > 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. Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should not published in its current form because it sets no standard for network operations without 6to4. A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft. -- james woodyatt member of technical staff, core os networking From randy@psg.com Sun Apr 17 23:33:43 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25050E075A for ; Sun, 17 Apr 2011 23:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue04I43HzbOr for ; Sun, 17 Apr 2011 23:33:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 976FEE0758 for ; Sun, 17 Apr 2011 23:33:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBi1i-00012q-RG; Mon, 18 Apr 2011 06:33:39 +0000 Date: Mon, 18 Apr 2011 15:34:05 +0900 Message-ID: From: Randy Bush To: james woodyatt In-Reply-To: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@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-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:33:43 -0000 > this draft should not published in its current form because it sets no > standard for network operations without 6to4. try ipv6 randy From tore.anderson@redpill-linpro.com Sun Apr 17 23:40:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3D7FE06C4 for ; Sun, 17 Apr 2011 23:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4eQKFLQxsDg for ; Sun, 17 Apr 2011 23:40:32 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfc.amsl.com (Postfix) with ESMTP id 8AEF7E0655 for ; Sun, 17 Apr 2011 23:40:32 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 867F0C43B0; Mon, 18 Apr 2011 08:40:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 sn7DCU+wGDOd; Mon, 18 Apr 2011 08:40:29 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 18 Apr 2011 08:40:29 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 3A988170C00B; Mon, 18 Apr 2011 08:40:29 +0200 (CEST) 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 gnAU9XnUN+6K; Mon, 18 Apr 2011 08:40:24 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 7169B170C00A; Mon, 18 Apr 2011 08:40:24 +0200 (CEST) Message-ID: <4DABDCD8.6020300@redpill-linpro.com> Date: Mon, 18 Apr 2011 08:40:24 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: , <4DABC618.8030406@bogus.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" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:40:37 -0000 * Dmitry Anipko > If the supporters of moving RFC 3056 to historic feel there is firm > evidence why RFC 3056 is harmful, it should not be difficult to > elaborate on that in the draft, and explain why alternative > mitigations (such as changing RFC 3484 prefix policy) would not be > sufficient - that would help address concerns regarding moving RFC > 3056 to historic. If there is no such evidence however, then to me it > seems reasonable to remove such recommendation for RFC 3056, rather > than postulating that RFC 3056 is harmful and requiring others to > prove otherwise. Dmitry, 6to4 connectivity is at its most harmful when it's being shared from a router-like device (including, but certainly not limited to, ICS) to a number of other devices that possibly do not implement RFC 3484 or something similar. In this situation, the devices behind the 6to4 router will have: 1) A globally-scoped unicast IPv6 address, and 2) a default route to the IPv6 internet. In the 3056+3068 case, this has an up to 85% chance of actually working for internet-bound traffic [Aben, Huston]. In the 3056-only case, it has a _0%_ chance of actually working. In other words: Removing the 3068 functionality, while leaving 3056 intact, will only aggravate the 6to4-problems that network/content operators struggle with today. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From joelja@bogus.com Sun Apr 17 23:43:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DCB6E06C4 for ; Sun, 17 Apr 2011 23:43:39 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpmzDBb4IuOB for ; Sun, 17 Apr 2011 23:43:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id D6487E06C1 for ; Sun, 17 Apr 2011 23:43:38 -0700 (PDT) Received: from 23173jjaeggli.local (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 p3I6gu8t002684 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 18 Apr 2011 06:42:58 GMT (envelope-from joelja@bogus.com) Message-ID: <4DABDD6F.30106@bogus.com> Date: Sun, 17 Apr 2011 23:42:55 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: , <4DABC618.8030406@bogus.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, 18 Apr 2011 06:43:01 +0000 (UTC) Cc: "v6ops@ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:43:39 -0000 On 4/17/11 10:56 PM, Dmitry Anipko wrote: > Hello Joel, > If the supporters of moving RFC 3056 to historic feel there is firm > evidence why RFC 3056 is harmful, it should not be difficult to > elaborate on that in the draft, and explain why alternative > mitigations (such as changing RFC 3484 prefix policy) would not be > sufficient - that would help address concerns regarding moving RFC > 3056 to historic. If there is no such evidence however, then to me it > seems reasonable to remove such recommendation for RFC 3056, rather > than postulating that RFC 3056 is harmful and requiring others to > prove otherwise. on the contrary support for the document as a whole to advance has been very much in evidence, hence it's status as a wg document and the decision to WGLC it, if the inclusion of 3056 is a problem that should be demonstrated as you are doing now. As Brian carpenter noted and I think I captured. "I don't think 3056 is broken, nobody deployed it." > Thank you, Dmitry > From tore.anderson@redpill-linpro.com Mon Apr 18 00:02:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6F9EE0655 for ; Mon, 18 Apr 2011 00:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abRiiDDeOrJ5 for ; Mon, 18 Apr 2011 00:02:32 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfc.amsl.com (Postfix) with ESMTP id 9AE6CE0660 for ; Mon, 18 Apr 2011 00:02:32 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 11D1BC426E; Mon, 18 Apr 2011 09:02:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 5Q35xC3cJvYZ; Mon, 18 Apr 2011 09:02:29 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 18 Apr 2011 09:02:29 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 2DA81170C00C; Mon, 18 Apr 2011 09:02:29 +0200 (CEST) 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 nmwnejK1V907; Mon, 18 Apr 2011 09:02:24 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 5CCF0170C00A; Mon, 18 Apr 2011 09:02:24 +0200 (CEST) Message-ID: <4DABE200.3040504@redpill-linpro.com> Date: Mon, 18 Apr 2011 09:02:24 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Fred Baker References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:02:37 -0000 * Fred Baker > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-to-historic. 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. I really hope this document will in the medium- to long-term really help out limiting the 6to4-related performance/reliability problems that the IPv6 internet currently suffers from. I therefore support it emphatically. 6to4 is often labelled a «transition technique», suggesting that it is helping internet community deploy native IPv6. Perhaps that was true to begin with. Today's operational reality, however, is exactly the opposite - 6to4's ubiquity combined with its unreliability is a major obstacle to IPv6 deployment; it caused my own customers to push back their native IPv6 deployments for about 14 months while attempting to minimize the problems in every imaginable way. It is high time we retire 6to4 and start focusing on real IPv6 deployments instead. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From tore.anderson@redpill-linpro.com Mon Apr 18 00:18:52 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5BB52E06C1 for ; Mon, 18 Apr 2011 00:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCsed8Ptrh8d for ; Mon, 18 Apr 2011 00:18:48 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfc.amsl.com (Postfix) with ESMTP id 2472BE0655 for ; Mon, 18 Apr 2011 00:18:48 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 806701DBBED; Mon, 18 Apr 2011 09:18:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 fWuzvH80h+c6; Mon, 18 Apr 2011 09:18:47 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 18 Apr 2011 09:18:47 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id F358F170C00C; Mon, 18 Apr 2011 09:18:46 +0200 (CEST) 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 vp1n0kCmA8Bp; Mon, 18 Apr 2011 09:18:42 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 2DF57170C00B; Mon, 18 Apr 2011 09:18:42 +0200 (CEST) Message-ID: <4DABE5D2.1080702@redpill-linpro.com> Date: Mon, 18 Apr 2011 09:18:42 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Fred Baker References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:18:52 -0000 * Fred Baker > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-advisory. 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. I support this document. While the preferred long-term solution is to avoid unsolicited use of 6to4 entirely (i.e. 6to4-to-historic); in the short term, it can only help to try to alleviate the pain that is being caused by problematic implementations that have already found their way into people's homes. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From rogerj@gmail.com Mon Apr 18 00:27:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 406EBE06D3 for ; Mon, 18 Apr 2011 00:27:07 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doXgg2nZ+gCg for ; Mon, 18 Apr 2011 00:27:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 060DDE0790 for ; Mon, 18 Apr 2011 00:27:02 -0700 (PDT) Received: by iwn39 with SMTP id 39so4876918iwn.31 for ; Mon, 18 Apr 2011 00:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nTtbE8dB+AtSjX1bSNa9nCUC+IQRrLRVIexPRaX52Qs=; b=tQmHFptHv1Kygg3fYKQQopMWYUjX0E5q0yvotJB2oE+kAozSwMIdRRND2ohAW9U/R2 FxyUeS6IaCgFIuRw8COZVLKaim069EyJzzofDsPPWlF1RGX3Qz5hYBzEcxZ1TrsgkzzN KzxGSO0f6Im97PL9J5xhCju92QdPYNGIdv5yI= 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=Ay/ay9BnBuVy8oHbidkWvf+/ex+owz/pSvAE6y3EtVKXqeFQwdEpbUTMpwEDpLa/0r /I+/zKqU952R3oDNd4peNOntB/lEe8XZM9oO/GgvqJtqcIbKCCIAQYOH6z76bR4yQtyx 147PWKab9upmWBNWR9m7N99JqNsSJQoUcMER0= MIME-Version: 1.0 Received: by 10.43.48.131 with SMTP id uw3mr5243042icb.405.1303111622520; Mon, 18 Apr 2011 00:27:02 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Mon, 18 Apr 2011 00:27:02 -0700 (PDT) In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> Date: Mon, 18 Apr 2011 09:27:02 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:27:07 -0000 On Sun, Apr 17, 2011 at 8:00 PM, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-advisory. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc),=A0comment 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=A0list. > We are looking specifically for comments on the importance of the documen= t > as well as its content. If you have read the document and believe it to b= e > of operational utility, that is=A0also an important comment to make. I support this document, it is one step in a long process of making IPv6 more robust and stable for everyone. --=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 ichiroumakino@gmail.com Mon Apr 18 00:34:33 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9F3AE06A9 for ; Mon, 18 Apr 2011 00:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHAC5YX1-gRO for ; Mon, 18 Apr 2011 00:34:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9E80EE06A8 for ; Mon, 18 Apr 2011 00:34:32 -0700 (PDT) Received: by wwa36 with SMTP id 36so3513397wwa.13 for ; Mon, 18 Apr 2011 00:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=88vnpThhDX3WlyWQ56G55gbEOJ5P7Yj8JRLtNCGUMlY=; b=VCdLc45quhnBLyE/gkM/malJxMI2A6LO5Jb9tbKMicojk8O87oQGl+unZEhbFJ/z/C zSO6rJLjuEfXItyAajdjjSP8h7dKn4+hrg5GL7QgR4Si9mBYvBZs3KQ1cFbhSsakA06E D3Lp+9Nv1UfSbDFjWTq9uTd+3opKpcG9qJxd4= 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=fTS4JJ04f2CDbNAOFs0g4uAnKlBJg1CtKROE8ss2Hszl+0DU4L//t4fvnU0J7a8QBK xmOqpnz8tzXFh3LDDjXjDPFAPC4+bACePgFg+obQ3R6KCwV4c7dSBZXBSc7+CUNEBy0R 4L85zDGT0Il3fzdZnC38GlO6yaWJZgjs2t54Y= Received: by 10.216.143.135 with SMTP id l7mr10121701wej.86.1303112071806; Mon, 18 Apr 2011 00:34:31 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-102.cisco.com (dhcp-osl-vl300-64-103-53-102.cisco.com [64.103.53.102]) by mx.google.com with ESMTPS id a50sm2421992wer.18.2011.04.18.00.34.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 00:34:30 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 18 Apr 2011 09:34:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:34:34 -0000 Dmitry, > The draft proposes to move both RFC 3056 and RFC 3068 to historic = status on the following grounds: >=20 > 1. A statement that 6to4 has rarely if ever been deployed. >=20 > 2. A list of specific issues related to 6to4. >=20 > I couldn't find a reference in the draft which would support statement = (1). If there has been some study showing that 6to4 deployment, by some = quantifiable metric, is indeed many times lower than deployment of other = tunnels (for example, Teredo), then I think having a reference to such = data would make statement (1) more justified.=20 the "non deployed" reference is with regards to this RFC3056 deployment = model: RFC3056, section 5.2: 2.2 An IPv6 exterior routing protocol is used. The set of 6to4 routers using a given relay router obtain native IPv6 routes from the relay router using a routing protocol such as BGP4+ [RFC 2283, BGP4+]. The relay router will advertise whatever native IPv6 routing prefixes are appropriate on its 6to4 pseudo-interface. These prefixes will indicate the regions of native IPv6 topology that the relay router is willing to relay to. Their choice is a matter of routing policy. It is necessary for network operators to carefully consider desirable traffic patterns and topology when choosing the scope of such routing advertisements. The relay router will establish BGP peering only with specific 6to4 routers whose traffic it is willing to accept. I have never heard nor seen this model having been deployed. anyone? > In the list of issues related to 6to4, the first 4 of the issues are = related to relay and, in my opinion, moving RFC 3068 (+ potentially = anything related to relays in RFC 3056) to historic status is a possible = solution to those issues, however those issues don't seem to be relevant = to moving to historic status RFC 3056 in general. in this model: RFC3056, section 5.2: 2.1 No IPv6 exterior routing protocol is used. The 6to4 routers using a given relay router each have a default IPv6 route pointing to the relay router. The relay router MAY apply source address based filters to accept traffic only from specific 6to4 routers. 6to4 does not work without relays. RFC3056 works with a known relay in = the forward direction and a remote relay in the reverse direction. the = only difference between 3068 and 3056's use of relays is that in the = 3056 case the forward relay is configured with an IPv4 unicast address = as opposed to a well known IPv4 anycast address. all the other relay = related issues still remain in 3056. are you suggesting to create a version of 6to4, where 6to4 nodes can = only reach other 6to4 nodes? i.e. no relays whatsoever? > The remaining two issues are: A) filtering of protocol 41 in = intermediate firewalls and PMTUD/ICMP not working correctly, and B) 6to4 = not able to work in networks where non-RFC-1918 addressing is used. >=20 > Specifically, the issue (A) states that "6to4 has no specified = mechanism to handle the case where protocol 41 is blocked...". Do other = tunneling mechanisms using protocol 41 have such mechanism? If they = don't, then should usage of protocol 41 be moved to historic, because = the stated filtering/PMTUD problems are then not specific to RFC 3056? = If they do, then having a brief overview of those and how/why they don't = apply to 6to4 would help to strengthen the statement. >=20 > The issue (B), if I understand correctly, it is essentially about = usage of non-RFC1918 addresses in networks, connected to Internet e.g. = using a NAT. There are existing mitigations to this problem (e.g. = Windows implementation will not configure 6to4 interface if there is = other IPv6 connectivity in the network; depending on particular = implementation, in managed environments administrators may have control = whether to enable or disable 6to4 on hosts). But even leaving those = mitigations aside, it seems that the de-prioritization of 6to4 in prefix = policy table below IPv4 in the proposed RFC 3484 revision would take = care of this issue, and moving RFC 3056 is a much stronger measure, = which doesn't seem to be necessary, as far as the issue (B) is = concerned. With the revised RFC 3484, 6to4 will be one of the "last = resort" mechanisms, which will essentially be used only if nothing else = can, so it won't be harmful. >=20 > So to summarize, in my opinion, in the current draft there seem to be = sufficient arguments to move RFC 3068 to historic, but not RFC 3056. = There may be such arguments for RFC 3056, but if there are, I think they = are not sufficiently reflected in the draft.=20 if RFC3056 was 6to4 node to 6to4 node communication only, I would agree = with you. but 3056 uses relays in the same fashion as 3068. unless you = deploy it the way Brian intended originally. cheers, Ole From dr@cluenet.de Mon Apr 18 02:22:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7BC6EE06CD for ; Mon, 18 Apr 2011 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqD66g6hWsx6 for ; Mon, 18 Apr 2011 02:22:36 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfc.amsl.com (Postfix) with ESMTP id D1BE2E069D for ; Mon, 18 Apr 2011 02:22:35 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 2273E108110; Mon, 18 Apr 2011 11:22:34 +0200 (CEST) Date: Mon, 18 Apr 2011 11:22:34 +0200 From: Daniel Roesen To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Message-ID: <20110418092234.GA19317@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.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.5.17 (2007-11-01) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 09:22:36 -0000 On Mon, Apr 18, 2011 at 09:27:02AM +0200, Roger Jørgensen wrote: > I support this document, it is one step in a long process of making > IPv6 more robust and stable for everyone. +1. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From gvandeve@cisco.com Mon Apr 18 04:03:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6685AE0792 for ; Mon, 18 Apr 2011 04:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.271 X-Spam-Level: X-Spam-Status: No, score=-9.271 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05-Y0-Ba5CJv for ; Mon, 18 Apr 2011 04:02:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 69945E0790 for ; Mon, 18 Apr 2011 04:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=893; q=dns/txt; s=iport; t=1303124577; x=1304334177; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=NIQiUOQVHfDiH8r8sKuUSwnr/82qbz1UHiy5/dbCnlg=; b=iPOiUPimzXFFKi1Q/KW6Jgzr1Kh8Sa/U5lk2xrlVEoeNbU84XJyPCg9Z Ib2TmXLkZP8ifGnz1zFQAWnWGYjdUsTSe0EI0pMXBUecrvC0kilSnVhAE FiWNM+T8ixG0gj7Dtif6Ei+fz+hqGr65KsaEL41JIRj0Ut9+5J08JFc9X 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8EAIgZrE2Q/khRgWdsb2JhbAClWxQBARYmJadJm2iFcQSRfg X-IronPort-AV: E=Sophos;i="4.64,231,1301875200"; d="scan'208";a="26099086" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 18 Apr 2011 11:02:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3IB2uQ6013629; Mon, 18 Apr 2011 11:02:56 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, 18 Apr 2011 13:02:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 12:59:50 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503765CFB@XMB-AMS-101.cisco.com> In-Reply-To: <20110418092234.GA19317@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC Thread-Index: Acv9qjty0yq2il/hTqWWXsap9X8AbwADTFsg References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <20110418092234.GA19317@srv03.cluenet.de> From: "Gunter Van de Velde (gvandeve)" To: "Daniel Roesen" , , X-OriginalArrivalTime: 18 Apr 2011 11:02:56.0528 (UTC) FILETIME=[2C108100:01CBFDB8] Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:03:01 -0000 +1 One can only promote improving the existing situation. Nevertheless the 6to4 should be made historical to control the = increasing the=20 negative influences of 6to4 on the ever growing internet. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Daniel Roesen Sent: 18 April 2011 11:23 To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC On Mon, Apr 18, 2011 at 09:27:02AM +0200, Roger J=F8rgensen wrote: > I support this document, it is one step in a long process of making > IPv6 more robust and stable for everyone. +1. 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 sthaug@nethelp.no Mon Apr 18 04:26:31 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1CDBE0737 for ; Mon, 18 Apr 2011 04:26:31 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqYdiGkWtl2i for ; Mon, 18 Apr 2011 04:26:30 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfc.amsl.com (Postfix) with SMTP id 5268AE00BE for ; Mon, 18 Apr 2011 04:26:30 -0700 (PDT) Received: (qmail 4892 invoked from network); 18 Apr 2011 11:26:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 Apr 2011 11:26:28 -0000 Date: Mon, 18 Apr 2011 13:26:28 +0200 (CEST) Message-Id: <20110418.132628.41727832.sthaug@nethelp.no> To: tore.anderson@redpill-linpro.com From: sthaug@nethelp.no In-Reply-To: <4DABE200.3040504@redpill-linpro.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:26:31 -0000 > > This is to initiate a two week working group last call of > > draft-ietf-v6ops-6to4-to-historic. 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. > > I really hope this document will in the medium- to long-term really help > out limiting the 6to4-related performance/reliability problems that the > IPv6 internet currently suffers from. I therefore support it emphatically. Support from an operator here. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sthaug@nethelp.no Mon Apr 18 04:27:35 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA92AE0768 for ; Mon, 18 Apr 2011 04:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.779 X-Spam-Level: X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKgiJOsj6LPM for ; Mon, 18 Apr 2011 04:27:33 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfc.amsl.com (Postfix) with SMTP id D5B30E0707 for ; Mon, 18 Apr 2011 04:27:32 -0700 (PDT) Received: (qmail 4954 invoked from network); 18 Apr 2011 11:27:32 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 Apr 2011 11:27:32 -0000 Date: Mon, 18 Apr 2011 13:27:31 +0200 (CEST) Message-Id: <20110418.132731.71186820.sthaug@nethelp.no> To: tore.anderson@redpill-linpro.com From: sthaug@nethelp.no In-Reply-To: <4DABE5D2.1080702@redpill-linpro.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DABE5D2.1080702@redpill-linpro.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:27:35 -0000 > > This is to initiate a two week working group last call of > > draft-ietf-v6ops-6to4-advisory. 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. > > I support this document. While the preferred long-term solution is to > avoid unsolicited use of 6to4 entirely (i.e. 6to4-to-historic); in the > short term, it can only help to try to alleviate the pain that is being > caused by problematic implementations that have already found their way > into people's homes. Support from an operator here. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From gert@space.net Mon Apr 18 04:27:46 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C739CE07BC for ; Mon, 18 Apr 2011 04:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow3Dh+y-N84e for ; Mon, 18 Apr 2011 04:27:46 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfc.amsl.com (Postfix) with ESMTP id 2B12FE07BF for ; Mon, 18 Apr 2011 04:27:46 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4CFF4F8160 for ; Mon, 18 Apr 2011 13:27:45 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 324DBF80FE for ; Mon, 18 Apr 2011 13:27:45 +0200 (CEST) Received: (qmail 25872 invoked by uid 1007); 18 Apr 2011 13:27:45 +0200 Date: Mon, 18 Apr 2011 13:27:45 +0200 From: Gert Doering To: Fred Baker Message-ID: <20110418112745.GA24606@Space.Net> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:27:46 -0000 Hi, On Sun, Apr 17, 2011 at 11:00:07AM -0700, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-to-historic. Support. Gert Doering -- Operator -- 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 Wesley.E.George@sprint.com Mon Apr 18 05:48:04 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3B76E06F5 for ; Mon, 18 Apr 2011 05:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St21Eewm7ZT6 for ; Mon, 18 Apr 2011 05:48:04 -0700 (PDT) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfc.amsl.com (Postfix) with ESMTP id B151CE06ED for ; Mon, 18 Apr 2011 05:48:03 -0700 (PDT) Received: from mail62-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 12:48:02 +0000 Received: from mail62-am1 (localhost.localdomain [127.0.0.1]) by mail62-am1-R.bigfish.com (Postfix) with ESMTP id 99F5F2D81BA; Mon, 18 Apr 2011 12:48:02 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371Ozz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail62-am1 (localhost.localdomain [127.0.0.1]) by mail62-am1 (MessageSwitch) id 1303130882261833_17970; Mon, 18 Apr 2011 12:48:02 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.252]) by mail62-am1.bigfish.com (Postfix) with ESMTP id 3D97E11F004C; Mon, 18 Apr 2011 12:48:02 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 12:48:01 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3IClwOA029155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2011 07:47:59 -0500 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PDAWEH02.ad.sprint.com (144.226.111.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 07:47:58 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 07:48:01 -0500 From: "George, Wes E IV [NTK]" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/SlhqpajWsmz1Eij6v0rgI8jKJRjktWQ Date: Mon, 18 Apr 2011 12:47:58 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C72FC1@PLSWM12A.ad.sprint.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001C_01CBFDA5.51D9A3C0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:48:05 -0000 ------=_NextPart_000_001C_01CBFDA5.51D9A3C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001D_01CBFDA5.51D9A3C0" ------=_NextPart_001_001D_01CBFDA5.51D9A3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support. I believe that the document is an acceptable compromise between acknowledging that 6to4 has fatal flaws that make it a liability and the fact that people are still using it with some degree of success. Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Sunday, April 17, 2011 2:00 PM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-to-historic. 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. ------=_NextPart_001_001D_01CBFDA5.51D9A3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support. I believe that the document is an acceptable compromise = between acknowledging that 6to4 has fatal flaws that make it a liability = and the fact that people are still using it with some degree of = success.

 

Wes George

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Fred Baker
Sent: Sunday, April 17, 2011 2:00 = PM
To: v6ops@ietf.org
Cc: = v6ops-chairs@tools.ietf.org; Ron Bonica
Subject: [v6ops] = draft-ietf-v6ops-6to4-to-historic = WGLC

 

This is = to initiate a two week working group last call of = draft-ietf-v6ops-6to4-to-historic. 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.

------=_NextPart_001_001D_01CBFDA5.51D9A3C0-- ------=_NextPart_000_001C_01CBFDA5.51D9A3C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxODEy NDc1OVowIwYJKoZIhvcNAQkEMRYEFIi7RMqmOY/WXq7lE0oh8l9Ca1B4MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgI4BhiTx8vrmNyakIIIMDv+rRFig95phxPB0sQi+6/ISRQUp9mzDbTyJ0wjAziN9bfpO kmrml2ehVW8LoWhhRe+HpasI6WJ+l9we4EIt5WeK+bhBW/wQcYj0fDI6kLipcuBrXSO4e97Ffk4q dJGxCVPTw+Cb9FK1BzD+18o2IZomAAAAAAAA ------=_NextPart_000_001C_01CBFDA5.51D9A3C0-- From Wesley.E.George@sprint.com Mon Apr 18 05:50:51 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6BD1BE06E9 for ; Mon, 18 Apr 2011 05:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.768 X-Spam-Level: X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ystQ5pviJ0Qm for ; Mon, 18 Apr 2011 05:50:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by ietfc.amsl.com (Postfix) with ESMTP id 939BAE06D6 for ; Mon, 18 Apr 2011 05:50:50 -0700 (PDT) Received: from mail32-ch1-R.bigfish.com (216.32.181.169) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 12:50:49 +0000 Received: from mail32-ch1 (localhost.localdomain [127.0.0.1]) by mail32-ch1-R.bigfish.com (Postfix) with ESMTP id B0AA615400EE; Mon, 18 Apr 2011 12:50:49 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371Ozz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h34h61h) 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 mail32-ch1 (localhost.localdomain [127.0.0.1]) by mail32-ch1 (MessageSwitch) id 1303131037960429_29856; Mon, 18 Apr 2011 12:50:37 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail32-ch1.bigfish.com (Postfix) with ESMTP id C14A013400B5; Mon, 18 Apr 2011 12:50:06 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 12:50:04 +0000 Received: from PDAWEH03.ad.sprint.com (PDAWEH03.corp.sprint.com [144.226.110.91]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3ICo2jr020653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2011 07:50:03 -0500 Received: from PLSWEH04.ad.sprint.com (144.226.251.22) by PDAWEH03.ad.sprint.com (144.226.110.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 07:50:04 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH04.ad.sprint.com ([2002:90e2:fb16::90e2:fb16]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 07:50:02 -0500 From: "George, Wes E IV [NTK]" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC Thread-Index: AQHL/Slu1uqaUzpVgE2DdiAWCWtGQ5Rjk4Vw Date: Mon, 18 Apr 2011 12:50:00 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C72FD4@PLSWM12A.ad.sprint.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0032_01CBFDA5.9AE01900" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:50:51 -0000 ------=_NextPart_000_0032_01CBFDA5.9AE01900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0033_01CBFDA5.9AE01900" ------=_NextPart_001_0033_01CBFDA5.9AE01900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support. This document is critical to ensuring that 6to4 works as well as possible while there are still a non-trivial number of deployments in the wild. Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Sunday, April 17, 2011 2:00 PM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-advisory. 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. ------=_NextPart_001_0033_01CBFDA5.9AE01900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support. This document is critical to ensuring that 6to4 works as = well as possible while there are still a non-trivial number of = deployments in the wild.

 

Wes George

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Fred Baker
Sent: Sunday, April 17, 2011 2:00 = PM
To: v6ops@ietf.org
Cc: = v6ops-chairs@tools.ietf.org; Ron Bonica
Subject: [v6ops] = draft-ietf-v6ops-6to4-advisory WGLC

 

This is = to initiate a two week working group last call of = draft-ietf-v6ops-6to4-advisory. 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.

------=_NextPart_001_0033_01CBFDA5.9AE01900-- ------=_NextPart_000_0032_01CBFDA5.9AE01900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxODEy NTAwMlowIwYJKoZIhvcNAQkEMRYEFH+cktNO87HfTHe3TaYEg/mvn9UlMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgHYXU0dnJLlK6pstK8LUgThSJhyZjnCrVT4H/crSZBUig4+LReZzVthwzNg5TjEqtZqG +RcDXX0Pw74Vujjbd7Y50o60DAmhSdhTYVOIntjP6xeYXIuk4Go+mWyY24FSm6UoK59TMYwLmxGE 78kSImfSOP0rO+6A97Y+R4PoFnQIAAAAAAAA ------=_NextPart_000_0032_01CBFDA5.9AE01900-- From rogerj@gmail.com Mon Apr 18 05:52:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D824E06C0 for ; Mon, 18 Apr 2011 05:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7k1fNgJZ-ZI for ; Mon, 18 Apr 2011 05:52:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id C2055E06AF for ; Mon, 18 Apr 2011 05:52:51 -0700 (PDT) Received: by iye19 with SMTP id 19so5144250iye.31 for ; Mon, 18 Apr 2011 05:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6y4chgeO1l87hCoySBTSwaoSiSwhnt9IFDmCyzXj7nk=; b=m4fa3LICZjgQ2zoJ+JHpOtfUmFFjo50Lmv02j5qRZ4dhVdedbJXQWEVZKzhphXcmxS 2oI5qxSn3DEqOp6aZJSpW1UDR9GoUk+cjNUpYY4n76OvWLPuZjzQNUDqhPTuTSJjyMzu wUF0SXzCGUCraxbbRXh5nv/lYFq7kb64qXS6o= 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=h0ZSud+R6D+CHUUqp/ixtuPwXAOFfU9wMI7N7dyrgcWeOvNVW+PuZTaRrukS8iUqgw o7Rrn8YAxpidsv8yd6F8B75dQGS0Jga+0uxT8gED/+5I0rR5vRA9DR2BpWOqqAhcy5N9 P3Rnkaa0XJtxf6T3OmX4SgWO9XjnTQzDwfSNU= MIME-Version: 1.0 Received: by 10.231.79.131 with SMTP id p3mr3744594ibk.191.1303131170174; Mon, 18 Apr 2011 05:52:50 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Mon, 18 Apr 2011 05:52:50 -0700 (PDT) In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Date: Mon, 18 Apr 2011 14:52:50 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:52:56 -0000 On Sun, Apr 17, 2011 at 8:00 PM, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-to-historic. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc),=A0comment 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=A0list. > We are looking specifically for comments on the importance of the documen= t > as well as its content. If you have read the document and believe it to b= e > of operational utility, that is=A0also an important comment to make. Same with this document, another small step in the process of making IPv6 internet more reliable and stable, more userfriendly:) --=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 Guillaume.Leclanche@swisscom.com Mon Apr 18 06:09:03 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 869D4E06F6 for ; Mon, 18 Apr 2011 06:09:03 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8dw4S5RTrbN for ; Mon, 18 Apr 2011 06:08:59 -0700 (PDT) Received: from mail.swisscom.com (outmail100.swisscom.com [193.222.81.100]) by ietfc.amsl.com (Postfix) with ESMTP id 18FDFE0693 for ; Mon, 18 Apr 2011 06:08:58 -0700 (PDT) Received: by intmail1.corproot.net; Mon, 18 Apr 2011 15:08:56 +0200 From: To: , Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC Thread-Index: AQHL/Slxzl9AVQfgMkGcZc/KZ/vQCZRjGCsAgAAgRwCAABstAIAARIRA Date: Mon, 18 Apr 2011 13:08:55 +0000 Message-ID: <1BE5D090C6244A49B9815F339F76EA4507ADD883@SG000708.corproot.net> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <20110418092234.GA19317@srv03.cluenet.de> <4269EA985EACD24987D82DAE2FEC62E503765CFB@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503765CFB@XMB-AMS-101.cisco.com> Accept-Language: fr-CH, de-CH, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.29.88.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:09:03 -0000 U3VwcG9ydCBhcyB3ZWxsLg0KDQpTb21lYm9keSBzaG91bGQgbWFrZSBzdXJlIHRoYXQgdGhlcmUg aXMgbm8gc2lkZS1lZmZlY3RzIG9uIFJGQzU5NjkgKDZyZCkgdGhhdCByZWZlcmVuY2VzIFJGQzMw NTYgc2V2ZXJhbCB0aW1lcy4NCg0KR3VpbGxhdW1lIChPcGVyYXRvcikNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEd1bnRlciBWYW4gZGUgVmVs ZGUgKGd2YW5kZXZlKQ0KPiBTZW50OiBNb25kYXksIEFwcmlsIDE4LCAyMDExIDE6MDAgUE0NCj4g VG86IERhbmllbCBSb2VzZW47IHY2b3BzQGlldGYub3JnOyB2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02dG80LWFkdmlz b3J5IFdHTEMNCj4gDQo+ICsxDQo+IE9uZSBjYW4gb25seSBwcm9tb3RlIGltcHJvdmluZyB0aGUg ZXhpc3Rpbmcgc2l0dWF0aW9uLg0KPiANCj4gTmV2ZXJ0aGVsZXNzIHRoZSA2dG80IHNob3VsZCBi ZSBtYWRlIGhpc3RvcmljYWwgdG8gY29udHJvbCB0aGUNCj4gaW5jcmVhc2luZyB0aGUNCj4gbmVn YXRpdmUgaW5mbHVlbmNlcyBvZiA2dG80IG9uIHRoZSBldmVyIGdyb3dpbmcgaW50ZXJuZXQuDQo+ IA0KPiBHLw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiBPZiBEYW5pZWwgUm9lc2VuDQo+IFNlbnQ6IDE4IEFwcmlsIDIwMTEgMTE6MjMNCj4gVG86 IHY2b3BzQGlldGYub3JnOyB2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02dG80LWFkdmlzb3J5IFdHTEMNCj4gDQo+IE9u IE1vbiwgQXByIDE4LCAyMDExIGF0IDA5OjI3OjAyQU0gKzAyMDAsIFJvZ2VyIErDuHJnZW5zZW4g d3JvdGU6DQo+ID4gSSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQsIGl0IGlzIG9uZSBzdGVwIGluIGEg bG9uZyBwcm9jZXNzIG9mIG1ha2luZw0KPiA+IElQdjYgbW9yZSByb2J1c3QgYW5kIHN0YWJsZSBm b3IgZXZlcnlvbmUuDQo+IA0KPiArMS4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gRGFuaWVsDQo+ IA0KPiAtLQ0KPiBDTFVFLVJJUEUgLS0gSmFiYmVyOiBkckBjbHVlbmV0LmRlIC0tIGRyQElSQ25l dCAtLSBQR1A6IDB4QTg1QzhBQTANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg== From wmaton@ryouko.imsb.nrc.ca Mon Apr 18 06:10:30 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D133E06F6 for ; Mon, 18 Apr 2011 06:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7NklkXwSq9F for ; Mon, 18 Apr 2011 06:10:29 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfc.amsl.com (Postfix) with ESMTP id 94AAEE06A1 for ; Mon, 18 Apr 2011 06:10:29 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.4) with ESMTP id p3IDALKa030588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Apr 2011 09:10:26 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p3IDAL6F030585; Mon, 18 Apr 2011 09:10:21 -0400 Date: Mon, 18 Apr 2011 09:10:21 -0400 (EDT) From: "William F. Maton Sotomayor" To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org In-Reply-To: <1BE5D090C6244A49B9815F339F76EA4507ADD883@SG000708.corproot.net> Message-ID: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <20110418092234.GA19317@srv03.cluenet.de> <4269EA985EACD24987D82DAE2FEC62E503765CFB@XMB-AMS-101.cisco.com> <1BE5D090C6244A49B9815F339F76EA4507ADD883@SG000708.corproot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:10:30 -0000 Support. wfms From Wesley.E.George@sprint.com Mon Apr 18 06:10:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EBB43E0705 for ; Mon, 18 Apr 2011 06:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ylYDSutddhw for ; Mon, 18 Apr 2011 06:10:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by ietfc.amsl.com (Postfix) with ESMTP id B2621E07CB for ; Mon, 18 Apr 2011 06:10:35 -0700 (PDT) Received: from mail216-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 13:10:35 +0000 Received: from mail216-ch1 (localhost.localdomain [127.0.0.1]) by mail216-ch1-R.bigfish.com (Postfix) with ESMTP id 2A1A4710165; Mon, 18 Apr 2011 13:10:35 +0000 (UTC) X-SpamScore: -41 X-BigFish: VS-41(zz9371O542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h34h61h) 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 mail216-ch1 (localhost.localdomain [127.0.0.1]) by mail216-ch1 (MessageSwitch) id 1303132234937552_9658; Mon, 18 Apr 2011 13:10:34 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail216-ch1.bigfish.com (Postfix) with ESMTP id D65CF152804C; Mon, 18 Apr 2011 13:10:34 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 13:10:32 +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 p3IDAVX7001400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2011 08:10:31 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 08:10:31 -0500 From: "George, Wes E IV [NTK]" To: james woodyatt , IPv6 Ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/ZCiRpzrMbmu706bV0wmdJ07w5RjlNXQ Date: Mon, 18 Apr 2011 13:10:30 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C73030@PLSWM12A.ad.sprint.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> 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.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003F_01CBFDA8.7864DC00" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:10:40 -0000 ------=_NextPart_000_003F_01CBFDA8.7864DC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit James , every network is going to be different in terms of the amount of 6to4 traffic present on it and when it makes sense to stop supporting it. As CGN becomes prevalent, especially if providers choose to squat on non-1918 space for their internal NAT pools, it's going to break anyway. I don't believe that we gain much value in declaring a flag day when all of the 6to4 relays get turned off, or the anycast blocks get null-routed everywhere. The draft already recommends turning it off by default or ceasing implementation in hosts, and recommends that operators should continue providing relays until traffic levels have dropped to the point that they feel that there will be negligible impact. It might be useful to write a companion draft recommending a standard way to intercept 6to4 traffic to notify people that it's about to stop working, but that's about as much of a phaseout plan as I can see adding value. What else would you want to see in a phaseout plan? Also, what do you actually mean by "sets no standard for network operations without 6to4"? Wes George -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Monday, April 18, 2011 2:20 AM To: IPv6 Ops WG Cc: v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 17, 2011, at 11:00 AM, Fred Baker wrote: > > 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. Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should not published in its current form because it sets no standard for network operations without 6to4. A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft. -- james woodyatt member of technical staff, core os networking _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_NextPart_000_003F_01CBFDA8.7864DC00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxODEz MTAzMlowIwYJKoZIhvcNAQkEMRYEFCrPaaVAUuQXJPudVv3K8RlKBqUbMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgDj6rdKKu046utYC+ZvmUHpz0luFi4QssttbYznIoDIVUV7uXRFcMUR86tR92MhlFVhA eKpqcFBhb3o61GcdzVJ6PE5LkdrS3uaQiAv/7BsdbPKoQi59WgZ3AbIuSGnY9VcDXEmCsUB18z5r vls1/vBJRsJly3agjHpjQY6mneWRAAAAAAAA ------=_NextPart_000_003F_01CBFDA8.7864DC00-- From dr@cluenet.de Mon Apr 18 06:17:45 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12C74E0693 for ; Mon, 18 Apr 2011 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgYCQnRw8Wbh for ; Mon, 18 Apr 2011 06:17:44 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfc.amsl.com (Postfix) with ESMTP id 02FB9E06AD for ; Mon, 18 Apr 2011 06:17:42 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 06336108111; Mon, 18 Apr 2011 15:17:41 +0200 (CEST) Date: Mon, 18 Apr 2011 15:17:41 +0200 From: Daniel Roesen To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Message-ID: <20110418131741.GA30412@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DABE200.3040504@redpill-linpro.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:17:45 -0000 On Mon, Apr 18, 2011 at 09:02:24AM +0200, Tore Anderson wrote: > I really hope this document will in the medium- to long-term really help > out limiting the 6to4-related performance/reliability problems that the > IPv6 internet currently suffers from. I therefore support it emphatically. Support, from an operator. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From nick@inex.ie Mon Apr 18 06:57:06 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92F56E072C for ; Mon, 18 Apr 2011 06:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsnpYZx4ThhS for ; Mon, 18 Apr 2011 06:57:06 -0700 (PDT) Received: from mail.acquirer.com (unknown [IPv6:2001:1bb8:2004:150::2]) by ietfc.amsl.com (Postfix) with ESMTP id C3A8FE070E for ; Mon, 18 Apr 2011 06:57:04 -0700 (PDT) X-Envelope-To: 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 p3IDv0OY009778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Apr 2011 14:57:00 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DAC432B.90403@inex.ie> Date: Mon, 18 Apr 2011 14:56:59 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110314 Thunderbird/3.3a3 MIME-Version: 1.0 To: v6ops@ietf.org References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:57:06 -0000 On 18/04/2011 07:19, james woodyatt wrote: > Now that we have an official WGLC, I'm going to repeat what I wrote in a > previous thread: this draft should not published in its current form > because it sets no standard for network operations without 6to4. A > phaseout plan for RFC 3056 and RFC 3068 would be required before I could > drop my objections to this draft. James: if this document were to explicitly set a phaseout date for 2002::/16 some time in the future, would this work for you? ID Authors: would you view such an addition as within scope for this document, or do you see an explicit end-game definition as work for a future ID? Nick From Wesley.E.George@sprint.com Mon Apr 18 06:57:35 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72275E0755 for ; Mon, 18 Apr 2011 06:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.731 X-Spam-Level: X-Spam-Status: No, score=-3.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep4H1VvAczZG for ; Mon, 18 Apr 2011 06:57:34 -0700 (PDT) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfc.amsl.com (Postfix) with ESMTP id 9B786E07CE for ; Mon, 18 Apr 2011 06:57:33 -0700 (PDT) Received: from mail87-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 13:57:33 +0000 Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3-R.bigfish.com (Postfix) with ESMTP id 80C3FF5031D; Mon, 18 Apr 2011 13:57:33 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371O542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3 (MessageSwitch) id 1303135052311167_14428; Mon, 18 Apr 2011 13:57:32 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.240]) by mail87-va3.bigfish.com (Postfix) with ESMTP id 38162888057; Mon, 18 Apr 2011 13:57:32 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 13:57:26 +0000 Received: from PDAWEH05.ad.sprint.com (PDAWEH05.corp.sprint.com [144.226.110.92]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3IDvOoe001724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2011 08:57:25 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH05.ad.sprint.com ([2002:90e2:6e5c::90e2:6e5c]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 08:57:24 -0500 From: "George, Wes E IV [NTK]" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/SlhqpajWsmz1Eij6v0rgI8jKJRis6QAgAAD+4CAAAGygIAAAUgAgAABLYCAAAHUgIAAAceAgADgdSA= Date: Mon, 18 Apr 2011 13:57:23 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7309D@PLSWM12A.ad.sprint.com> References: <20110417.210253.74655326.sthaug@nethelp.no> 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.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0049_01CBFDAF.05C0B2D0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:57:35 -0000 ------=_NextPart_000_0049_01CBFDAF.05C0B2D0 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 JORDI PALET MARTINEZ Sent: Sunday, April 17, 2011 3:09 PM To: v6ops@ietf.org Cc: ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC There are two ways of doing this: 1) Killing all the protocols that may not work because some operators don't know how to configure filters ______ [WEG] Gross oversimplification. This isn't just about filters, and it certainly isn't just about operators' filters. Even at best, 6to4 is degraded because of all of the other things discussed in draft-ietf-v6ops-6to4-advisory 2) Making sure that protocols are better, for example by means of ensuring mechanisms such as "happy eyeballs" make a smart decision about what to use ______ [WEG] So... assuming we get critical mass on implementing happy eyeballs in a reasonable timeframe (which in and of itself is a stretch), it tests, confirms what we already know, which is that 6to4 is not really a viable option for a large portion of the users when compared with IPv4 or with native IPv6, and it never or almost never uses 6to4. Exactly how does that improve the situation and justify keeping 6to4 alive? Wes George ------=_NextPart_000_0049_01CBFDAF.05C0B2D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxODEz NTcyNlowIwYJKoZIhvcNAQkEMRYEFAxxlI+kfRCS+wTEohkFCzoSsmL2MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgAMnyDGGE0MCyEnf2PWeTFNlysQLYKIbIb03Uw79d6+fddTHIPI0Km4iET3J76CMEwPI 3B3wrHiEvWkFjMPeiJwrXXmU0niN8JxbPqfxczIkuTuoM33Xl5AKzZ7Yh98NSyfNZYd5UlWGDwVM hLj2IFGa2rimT4iSsRevN23/xV37AAAAAAAA ------=_NextPart_000_0049_01CBFDAF.05C0B2D0-- From martin@millnert.se Mon Apr 18 07:12:03 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE48CE06D6 for ; Mon, 18 Apr 2011 07:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpDNBunWJpU2 for ; Mon, 18 Apr 2011 07:12:03 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfc.amsl.com (Postfix) with ESMTP id E41B9E0700 for ; Mon, 18 Apr 2011 07:12:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id DBAF077EE; Mon, 18 Apr 2011 16:26:29 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqt4KkS6u1Yr; Mon, 18 Apr 2011 16:26:29 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id D93F678B; Mon, 18 Apr 2011 16:26:27 +0200 (CEST) From: Martin Millnert To: Fred Baker In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Apr 2011 10:12:06 -0400 Message-ID: <1303135926.4385.298.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:12:04 -0000 On Sun, 2011-04-17 at 11:00 -0700, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-to-historic. 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. I support the document wrt. the logic below (copying from ipv6-ops): On Mon, 2011-04-18 at 11:38 +0100, Nick Hilliard wrote: > The approach that's most likely to get widespread support is: > > 1. make it not be on by default > 2. make noise about it being A Bad Thing > 3. deprioritise 2002::/16 addresses in resolver libs > 4. then make the option hard to find on operating systems / CPEs > 5. then remove the option on operating systems > 6. then slowly decommission 6to4 relays over many years > > draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. I do think it would be useful to elaborate on the arguments Tore just provided to Dmitry for deprecation of 3056 in the draft, as a form of history writing for the archives. Regards, Martin From martin@millnert.se Mon Apr 18 07:15:08 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC773E070E for ; Mon, 18 Apr 2011 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9K2MIyeaxCf for ; Mon, 18 Apr 2011 07:15:08 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfc.amsl.com (Postfix) with ESMTP id 141C1E06D6 for ; Mon, 18 Apr 2011 07:15:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 476E877EE; Mon, 18 Apr 2011 16:29:35 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTTuuvoC9bGp; Mon, 18 Apr 2011 16:29:35 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id 3A0C878B; Mon, 18 Apr 2011 16:29:33 +0200 (CEST) From: Martin Millnert To: Daniel Roesen In-Reply-To: <20110418092234.GA19317@srv03.cluenet.de> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <20110418092234.GA19317@srv03.cluenet.de> Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Apr 2011 10:15:13 -0400 Message-ID: <1303136113.4385.299.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:15:09 -0000 v6ops, On Mon, 2011-04-18 at 11:22 +0200, Daniel Roesen wrote: > On Mon, Apr 18, 2011 at 09:27:02AM +0200, Roger Jørgensen wrote: > > I support this document, it is one step in a long process of making > > IPv6 more robust and stable for everyone. > > +1. *2 Best, Martin From bs7652@att.com Mon Apr 18 07:30:26 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76E32E07F3 for ; Mon, 18 Apr 2011 07:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55Iz0ozUEDHh for ; Mon, 18 Apr 2011 07:30:25 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfc.amsl.com (Postfix) with ESMTP id 6E2E4E07F1 for ; Mon, 18 Apr 2011 07:30:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1303137022!13311193!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 466 invoked from network); 18 Apr 2011 14:30:23 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Apr 2011 14:30:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3IETLgX009220; Mon, 18 Apr 2011 10:29:21 -0400 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p3IETHAS009112; Mon, 18 Apr 2011 10:29:17 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 10:29:59 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 10:29:58 -0400 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: Mon, 18 Apr 2011 10:29:56 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1B8947E4@crexc50p> In-Reply-To: <1303136113.4385.299.camel@shakira.millnert.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC Thread-Index: Acv90wVsqnSrsDGATvSDYxNahiX9fAAAfrdQ References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com><20110418092234.GA19317@srv03.cluenet.de> <1303136113.4385.299.camel@shakira.millnert.se> From: "STARK, BARBARA H (ATTSI)" To: "Martin Millnert" , "Daniel Roesen" X-OriginalArrivalTime: 18 Apr 2011 14:29:59.0056 (UTC) FILETIME=[1877D900:01CBFDD5] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:30:26 -0000 PiBPbiBNb24sIDIwMTEtMDQtMTggYXQgMTE6MjIgKzAyMDAsIERhbmllbCBSb2VzZW4gd3JvdGU6 DQo+ID4gT24gTW9uLCBBcHIgMTgsIDIwMTEgYXQgMDk6Mjc6MDJBTSArMDIwMCwgUm9nZXIgSsO4 cmdlbnNlbiB3cm90ZToNCj4gPiA+IEkgc3VwcG9ydCB0aGlzIGRvY3VtZW50LCBpdCBpcyBvbmUg c3RlcCBpbiBhIGxvbmcgcHJvY2VzcyBvZiBtYWtpbmcNCj4gPiA+IElQdjYgbW9yZSByb2J1c3Qg YW5kIHN0YWJsZSBmb3IgZXZlcnlvbmUuDQo+ID4NCj4gPiArMS4NCj4gDQo+ICoyDQoNCisxDQoN CkJhcmJhcmENCg== From joelja@bogus.com Mon Apr 18 07:46:53 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E7BFE070E for ; Mon, 18 Apr 2011 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2khdoto6nVO for ; Mon, 18 Apr 2011 07:46:52 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id 9BB35E06D9 for ; Mon, 18 Apr 2011 07:46:52 -0700 (PDT) Received: from 23173jjaeggli.local ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p3IEkmfQ005324 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 18 Apr 2011 14:46:51 GMT (envelope-from joelja@bogus.com) Message-ID: <4DAC4ED2.2040805@bogus.com> Date: Mon, 18 Apr 2011 07:46:42 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nick Hilliard References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> In-Reply-To: <4DAC432B.90403@inex.ie> 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, 18 Apr 2011 14:46:51 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:46:53 -0000 On 4/18/11 6:56 AM, Nick Hilliard wrote: > On 18/04/2011 07:19, james woodyatt wrote: >> Now that we have an official WGLC, I'm going to repeat what I wrote in a >> previous thread: this draft should not published in its current form >> because it sets no standard for network operations without 6to4. A >> phaseout plan for RFC 3056 and RFC 3068 would be required before I could >> drop my objections to this draft. > > James: if this document were to explicitly set a phaseout date for > 2002::/16 some time in the future, would this work for you? the worked for the 6bone trial more or less, that said it's actual property of gone-ness has a lot to do with the existence of devices which still have it enabled, and relays which still exist. > ID Authors: would you view such an addition as within scope for this > document, or do you see an explicit end-game definition as work for a > future ID? > > Nick > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Wesley.E.George@sprint.com Mon Apr 18 07:53:52 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25C77E068E for ; Mon, 18 Apr 2011 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=1.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D98mXRcMWNPz for ; Mon, 18 Apr 2011 07:53:51 -0700 (PDT) Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfc.amsl.com (Postfix) with ESMTP id 1E1B0E06D9 for ; Mon, 18 Apr 2011 07:53:50 -0700 (PDT) Received: from mail130-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.8; Mon, 18 Apr 2011 14:53:50 +0000 Received: from mail130-tx2 (localhost.localdomain [127.0.0.1]) by mail130-tx2-R.bigfish.com (Postfix) with ESMTP id 1B264B10101; Mon, 18 Apr 2011 14:53:50 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zz9371O542M1418Mzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) 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 mail130-tx2 (localhost.localdomain [127.0.0.1]) by mail130-tx2 (MessageSwitch) id 1303138429830310_26073; Mon, 18 Apr 2011 14:53:49 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.240]) by mail130-tx2.bigfish.com (Postfix) with ESMTP id C6188238051; Mon, 18 Apr 2011 14:53:49 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 18 Apr 2011 14:53:47 +0000 Received: from PDAWEH05.ad.sprint.com (PDAWEH05.corp.sprint.com [144.226.110.92]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3IErjGi009989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2011 09:53:46 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH05.ad.sprint.com ([2002:90e2:6e5c::90e2:6e5c]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 09:53:45 -0500 From: "George, Wes E IV [NTK]" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/SlhqpajWsmz1Eij6v0rgI8jKJRis6QAgAAD+4CAAAGygIAA4MyQ Date: Mon, 18 Apr 2011 14:53:45 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C73185@PLSWM12A.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0060_01CBFDB6.E594F1D0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:53:52 -0000 ------=_NextPart_000_0060_01CBFDB6.E594F1D0 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 JORDI PALET MARTINEZ Sent: Sunday, April 17, 2011 2:48 PM To: v6ops@ietf.org Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC I oppose to a deprecation of 6to4. It is already the last resort, and I will be happy if the anycast is by default configured off. This way, 6to4 is still useful peer-to-peer. _______ [WEG] Please explain what value having peer to peer 6to4 would provide that makes you keen to try to preserve it - actual use cases, please. If the idea is to use 6to4 as a method to deploy IPv6 more widely when the provider of the upstream network is not doing so, peer to peer 6to4 buys us...what, exactly? Not connectivity to the IPv6 internet, that's for sure. And as I've said at the mic and in other emails, it's simply not valid to assume that 6to4 is going to keep working anyway. draft-kuarsingh-v6ops-6to4-provider-managed-tunnel (and Cameron Byrne's previous message that they're already null-routing this traffic on their network) is evidence of two common breakage cases that are only going to get more common. Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo (I mean deprecating them), and for many many many other transition mechs. _______ [WEG] I don't buy the extension of the argument that if we deprecate 6to4 (or Teredo) that we also need to deprecate 6over4 and other less automatic transition mechanisms. It's hyperbole. However, there was more than one comment (list or Mic, or both, don't remember) that recommended exactly that - a companion draft deprecating Teredo too, for much the same reason - significantly degraded service that is not going to be easy to solve, especially when weighed against the competing priority of deploying IPv6 for real. For a lot of implementations, I think it's binary - they can either work on buffing the turd some more, or they can work on implementing IPv6, not both. However, we have heard also different views than the one presented by Geoff. My own experience, using an average of 30 different networks every year, while traveling, during the last 10 years, is that it fails to me less than 1% of the times. This clearly means that is not "so broken" as Geoff measurements seems to indicate, so may be not so many network is filtering it. I don't know the reason for such a difference, but it is statistically impossible that my situation of not "so much" broken, is just good luck, specially when is a view shared by others. _______ [WEG] This example leaves me unconvinced. We in the IETF are the exception when it comes to deploying things, not in any way representative of the general populace. We routinely test things in our own networks that are limited deployment and "not ready for primetime" because we're interested in them. We're also more likely to be able to fix things when they're broken, and tolerate service degradation (our own) during that testing. Since we're trying to get to IPv6 service that is as good as or better than IPv4, this needs to be less about "I personally use 6to4 and I don't want it to break" and more about why the larger populace needs 6to4, if in fact they do. Personally, I think that the only folks who have consciously enabled 6to4 are either testing it, have something to prove by using IPv6 (because they want IPv6 deployment to increase), or (marginally) because their P2P client let them click a button to potentially bypass ISP P2P interference by moving the traffic to IPv6. You will have trouble convincing me that 6to4 is necessary assuming IPv4 is working, and I can't see too many average folks choosing a degraded service over one that is not. Continuing to support this protocol in the face of this limited of a deployment and the obvious tradeoffs is really more about ideology than operational considerations. Wes George ------=_NextPart_000_0060_01CBFDB6.E594F1D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxODE0 NTM0OFowIwYJKoZIhvcNAQkEMRYEFHWia+I4QUAY85d48/3q9NmyJvD+MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgCIy0jjHLVaEfnAHTxgd9BeKMx0ZLfdn5MP8tIgRe3ikrkkWn/vhFgttPUZ99uqjyo/Y rT6og7nauWc1LNFpJVRHJSTka1oi/J/QQv0HrWFItfBXgbN2bKlc4YUSHK4XKj+DmyALzPmZP+3n wJWEVhWvff1yWTmlmrm8WFEkPyLgAAAAAAAA ------=_NextPart_000_0060_01CBFDB6.E594F1D0-- From dwcarder@wisc.edu Mon Apr 18 08:00:59 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B5AFE07DF for ; Mon, 18 Apr 2011 08:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N81Z5gymmKuf for ; Mon, 18 Apr 2011 08:00:58 -0700 (PDT) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by ietfc.amsl.com (Postfix) with ESMTP id 3C16AE068E for ; Mon, 18 Apr 2011 08:00:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LJU00204SDLX300@smtpauth2.wiscmail.wisc.edu> for v6ops@ietf.org; Mon, 18 Apr 2011 10:00:57 -0500 (CDT) Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LJU001J6SDJHA00@smtpauth2.wiscmail.wisc.edu>; Mon, 18 Apr 2011 10:00:56 -0500 (CDT) Date: Mon, 18 Apr 2011 10:00:55 -0500 From: "Dale W. Carder" In-reply-to: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> To: Fred Baker Message-id: <20110418150055.GA332@ricotta.doit.wisc.edu> X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.18.145119, SenderIP=144.92.67.161 References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:00:59 -0000 Thus spake Fred Baker (fred@cisco.com) on Sun, Apr 17, 2011 at 11:00:05AM -0700: > This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-advisory. 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. I support this document, but considering nearly all of our site's failures with 6to4 (and IPv6, for that matter) is section 4.1.5, I see two issues: - This is hardly discussed in section 3 - The text 4.1.5 may not be strong enough to disable this awful behavior. I would claim that an "internet sharing" host MUST not ever advertise 6to4 prefixes. This would very much help the interim situation between now and when 6to4 is off by default. I am not sure that setting the preference to low actually would change anything. Dale From Fred.L.Templin@boeing.com Mon Apr 18 08:44:37 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F3B6AE0811 for ; Mon, 18 Apr 2011 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.503 X-Spam-Level: X-Spam-Status: No, score=-7.503 tagged_above=-999 required=5 tests=[AWL=1.096, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErZy19CBq9o4 for ; Mon, 18 Apr 2011 08:44:36 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 328F1E080D for ; Mon, 18 Apr 2011 08:44:36 -0700 (PDT) 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 p3IFiXIl024498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2011 08:44:34 -0700 (PDT) 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 p3IFiWIf016955; Mon, 18 Apr 2011 08:44:32 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3IFiWot016942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Apr 2011 08:44:32 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 18 Apr 2011 08:44:32 -0700 From: "Templin, Fred L" To: Philip Homburg Date: Mon, 18 Apr 2011 08:44:31 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv8ElHfhGPl5xosSzid0lNNVw9PTgBzHk8w Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:44:37 -0000 Hi Philip,=20 > -----Original Message----- > From: pch-b6B5344D9@u-1.phicoh.com=20 > [mailto:pch-b6B5344D9@u-1.phicoh.com] On Behalf Of Philip Homburg > Sent: Saturday, April 16, 2011 1:43 AM > To: Templin, Fred L > Cc: Lee Howard; v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft)=20 >=20 > In your letter dated Fri, 15 Apr 2011 15:40:19 -0700 you wrote: > >What people don't seem to be getting is that there is > >a rich continuum of what can be classified as a "site" > >ranging from the very small (my cellphone and its > >attached bluetooth devices) to the very huge (the Boeing > >Corporate network). And the degree to which the site > >needs to become "IPv6 native" vs. "still IPv4, but > >IPv6-enabled" varies on a case by case basis and is > >not binary based, e.g. on "corporate" vs. "end-user".=20 >=20 > I think for this discussion it would be good if you try to=20 > narrow down the > range of sites to something where ISATAP would be most=20 > appropriate. Yes we can > try to discuss how ISATAP can be used in an ordinary home=20 > site with just a > single NAT router, but it doesn't make much sense. OK - I will narrow it down to that set of sites that are currently predominantly IPv4 and that have satisfactory intra-site communications using IPv4. > >> If you're providing general advice about how to make IPv6 > >> available, you need to advise on how to evaluate options, > >> which may include ISATAP. The document you've written > >> isn't general operational guidance, it's an ISATAP primer, and > >> it would be less confusing if it were labeled as such. > > > >Well, this was specifically labeled as "pre-draft" > >and nothing has gone to the I-D repository. I don't > >mind hearing about other options - do you have any > >you want to propose? >=20 > Assuming a big site with just a few places that need IPv6=20 > right now I can > imagine: IPv6 capable routers in places that need IPv6 connected by: > - 6in4 tunnels, or > - A parallel IPv6 backbone (assuming intra-site connection=20 > are all some kind > of ethernet, that should be quite easy), or > - A 'sparse' IPv6 backbone based on vlans. None of these are simpler nor more catch-all than just turning up the domainname "isatap.domainname" in the site. Thanks - Fred fred.l.templin@boeing.com= From fred@cisco.com Mon Apr 18 08:49:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87F4CE0712 for ; Mon, 18 Apr 2011 08:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.041 X-Spam-Level: X-Spam-Status: No, score=-110.041 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOURdTRIYUmU for ; Mon, 18 Apr 2011 08:49:04 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id F3F6CE068E for ; Mon, 18 Apr 2011 08:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=75738; q=dns/txt; s=iport; t=1303141743; x=1304351343; h=from:subject:date:message-id:to:mime-version; bh=vur9faFRdYMhmpqFuG2wmUjKy/lMz1gm3vByp7ncjt0=; b=EadwGShWl5u1Us62v0AApR5Bmcb1OOm05VmVS9CnuB5CtwaJy3rkLg64 HtFMYAdpK3S4wkvCWCqVsyfcp4V5i33203jeSHuWuGKN151enCARyYlua WG3ZdA5niLeZ2XadjB9RaPQYY8eRc+2GDs7NrKz2Aa9/8x8OmHzNuS0gN U=; X-Files: 6to4-m.png, 6to4-y.png : 15652, 16222 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKJcrE2rRDoJ/2dsb2JhbAClXXeIb557nB+FcQSFYoZxgS+DdQ X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="png'150?scan'150,208,150";a="432164853" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 18 Apr 2011 15:49:01 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3IFlvge025931 for ; Mon, 18 Apr 2011 15:48:59 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 18 Apr 2011 08:48:59 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 18 Apr 2011 08:48:59 -0700 From: Fred Baker Date: Mon, 18 Apr 2011 08:48:59 -0700 Message-Id: To: IPv6 Ops WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/mixed; boundary=Apple-Mail-16-564508345 Subject: [v6ops] 6to4 - for the record X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:49:07 -0000 --Apple-Mail-16-564508345 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There has been a discussion on ipv6-ops@lists.cluenet.de regarding the = 6to4 discussion. I'm forwarding thread as of this morning "for the = record". Hopefully, other operators commenting in that forum will post = to v6ops@, although I'm not holding my breath :-( Begin forwarded message: > From: "William F. Maton Sotomayor" > Date: April 1, 2011 8:02:58 AM PDT > To: ipv6-ops@lists.cluenet.de > Subject: 6to4 stats found, are there other places? > Reply-To: wmaton@ryouko.imsb.nrc.ca >=20 >=20 > Folks, > Given the talk of moving 6to4 in the IETF to historic, I was = told that it may be a good idea to share some stats of what one public = 6to4 relay in Canada is doing. Originally this page was meant to get = the institutions listed moving with IPv6 adoption, rather than = languishing with tunnels and inviting (erroneous) criticism over IPv6. >=20 > http://stats.ottix.net/ipv6/ >=20 > Does anyone else have public web pages of 6to4 stats that can be = shared? Data as well? >=20 > Thanks, >=20 > wfms Begin forwarded message: > From: Simon Leinen > Date: April 17, 2011 10:10:56 AM PDT > To: wmaton@ryouko.imsb.nrc.ca > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > William F Maton Sotomayor writes: >> Given the talk of moving 6to4 in the IETF to historic, I was >> told that it may be a good idea to share some stats of what one = public >> 6to4 relay in Canada is doing. Originally this page was meant to get >> the institutions listed moving with IPv6 adoption, rather than >> languishing with tunnels and inviting (erroneous) criticism over = IPv6. >=20 >> http://stats.ottix.net/ipv6/ >=20 > very nice, thanks! >=20 >> Does anyone else have public web pages of 6to4 stats that can be >> shared? Data as well? >=20 > We have simple Cricket graphs for the public 6to4 relay in AS559, but > unfortunately they aren't reachable from the general Internet. I'm > sending a snapshot. >=20 --Apple-Mail-16-564508345 Content-Disposition: inline; filename=6to4-m.png Content-Type: image/png; name="6to4-m.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAACbCAYAAAB7939+AAAABmJLR0QA/wD/AP+gvaeTAAAgAElE QVR4nO2de3gUVZr/v024CTSBNAkXwyWGBDHholwUwiVcQrK4gju7v3V3cBXHYUaJjiijj6OOgJfx MoKOCOq4RlkGl2fiOAIrhnghgCAOCSFAguTShCSkyaVDkoaQK/37I56mu7qqq066uvt08n6ep5+k q7996q23qk6feuut9xhyc3PtIAiCIAiCIFRpaGhAr0AbQRAEQRAEEQw0NDTAbDajN1swfvz4QNpD EARBEAQhNOnp6QBAkSeCIAiCIAgeaPBEEARBEATBAQ2eCIIgCIIgOOitLiEIgiAIgui+ZGRkyC5P SUmRXU6RJ4IgCIIgejQpKSlISUnBwoULHe89QZEngiAIgiB6PFevXkV+fj5CQkJQX1+P3r2Vh0g0 eCIIgiAIokdz7tw5mM1m3HjjjRg3bhyOHTuGsWPHKupp8EQQBEEQRI+mrq4Os2bNwoABAwAASUlJ HvU0eCIIgiAIokdTU1ODmpoat+WUME4QBEEQBCEDJYwTBEEQBEFwQgnjBEEQBEEQGqGE8S5y7uBB AEDUvHkBtoQgCIIgCH+iS8K40WhUXZHNZuuCeWLS3tKCr196CQDwwJ496N2vX4AtIgiCIAjCX/Am jMsOnpwHRr///e8xePBg/PrXvwYAvPvuu2hubtbDVmE49uGHaLxwwfH/rNWrA2wRQRAEQRD+wmAw YMmSJTAYDAAAu92OzMxMZX1ubq4dAMaPHy8rCA8Px4ULF9C3b18AQEtLC0aPHo3q6mq9bQ8IjRcu 4KO77kJ7SwsAoHe/fnhgzx4MvvHGAFtGEARBEIQ/OHLkCCIjIxEZGQkAqKioQEVFBWbPnu2iS09P B6ChVEFsbCy2bNkCm80Gm82Gd955BzExMboYu3PnTkyZMgVhYWGYM2cODv6Ud1ReXo5FixbBZDJh 0aJFqKio8LhcCaPRiM2bNwMA3n77bdnbkd+8/LJj4AR03sL75uWXddk+giAIgiDEZ9KkSbBYLPjq q6/w1VdfwWKxYPLkyYp61cHTtm3bsH//fkRHRyM6OhoHDhzAxx9/rIuxX3zxBT755BNUVlbikUce wX333QcAeOaZZzBnzhxcuHABc+bMwXPPPedxuZr9drsd27Ztk/38X7Zuxdr8fDT9x39gbX4+fv71 1/iXrVs1b4PFYtGsFU3P23bb2bM+s4VXL5IfefUi+ZFXL5ItAJ8vRbNdpP0k0jEpkh959SL5kVcv ki0Avy+9xWg04vbbb0dycjKSk5Nx++2347vvvlPUqw6exo8fj927d6O6uhrV1dXYvXu3bpGn7du3 Iy4uDv3798fcuXPR2NiItrY2HDx4EKmpqejfvz9SU1ORlZUFAIrLPREWFoY33ngDw4YN02RTVVUV 1zYEs5637eajR31mC69eJD/y6kXyI69eJFsAPl+KZrtI+0mkY1IkP/LqRfIjr14kWwB+X/obISqM W61WrFixAg899BD69OmD+vp6DBs2DEuWLIHJZEJ9fT0AKC73xKpVq/DSSy9h1apVsp931NXBlpaG a5cuAdnZmDFjBpCdjUGDBmn6G8z6+OZmze0OGjQIA8aM4dLzts+jF8mPvHqR/Bjsfg//938Xwi8+ 12/Z4tP9xONHX+9XofzOqRfJj8Hudy39ZP+WFtjS0tBaUOD1OCQjI8Pt5ZHc3Fx7bm6u3Wazyb7S 0tLso0ePthsMBjsAx0tJz/s6dOiQfdy4cfYnnnjC3tDQYLfZbPawsDC72Wy222w2e0lJid1kMnlc rvSS2unJ7qeeesput9vtxcXFdh6CWc/btu3AAZ/ZwqsXyY+8epH8yKsXyRa7nc+XotnOpQfo3A4C vUh+5NWLZIvdrt2Xeo1F5F7p6emyY6K0tDS76tN2Y8aMwVtvvYXly5cjJCTE69GdM9u3b8eHH36I 1157Dbfffrtj+b333ouYmBg8/fTTePXVV2E2m7Ft2zbF5UoYjUaXsgvS9868+OKLeO211/TbOIIg CL0wGAC7PdBWEIRwXL582WdtZ2RkuNV50vy0HdBZJErvgRMArF69Gjk5OVi8eDGMRiOMRiOuXLmC P/zhD8jKysLIkSNx4MABvPRTAUul5XpSUlLSY/S8bV/+6WlIX7XvS9tF0ovkR169SLYAfL4UzXaR 9pNIx6RIfuTVi+RHXr1ItgD8vvQFniYHVo08vf/++2hsbERqaqqjbHl3hCJPBEEIC0WeCEIWvSJP tbW1OHv2rKO9QYMGYcKECW4Pm2mOPP32t7/FCy+8gOHDhzuiQ1qmbwlWRBt9i3SlIdJVlUh+5NWL 5EdevUi2ABR50qttkY5JkfzIqxfJj7x6kWwB/B95ysvLQ0xMDJKSkpCUlISYmBjk5eUp6lUjTz0F ijwRBCEsFHkiCFn0ijx98803mDx5siPSVFNTg1OnTmHRokUuOq6cp56EaKNvka40RLqqEsmPvHqR /MirF8kWgCJPerUt0jEpkh959SL5kVcvki2A/yNPkydPRmFhITIzM5GZmYmioiKPFcZVI09nz57F E088gWPHjgEAZsyYgU2bNmHChAk+MD9wUOSJIAhhocgTQcjiy6ft5NAceXrwwQeRmJiI4uJiFBcX Y968efjlL3/pcwP9RVtbG8rKylBbWwugc3JAADCbzZr+BrO+pKREc7tmsxmXDx7k0vO2z6MXyY+8 epH8GOx+L9izRwi/+FoPwKf7icePXWnfl/2SSHqR/MirF8mPZrO2frKwsBBlZWXcU7/IUVtbi8OH D2Pfvn3Yt28fDh8+7BgXyKEaeRo6dCguXryIfv36AQBaWlowcuRI1NXVeW2sSFDkiSAIYaHIE0HI omfO06RJkxw5T7W1td7lPMXFxWHLli2w2Wyw2WzYvHkz4uLidDFWRES77yvSPW6R7ueL5EdevUh+ 5NWLZAtAOU96tS3SMSmSH3n1IvmRVy+SLUBg6jwZDAbHS1XLm/M0ffp0vPnmm5TzRBAE4S8o8kQQ sugVeaqpqUFhYaFLnafY2FiEh4e76DRHniZMmIAvvvgC1dXVqK6uxt69e7vdwMkZ0UbfIl1piHRV JZIfefUi+ZFXL5ItAEWe9GpbpGNSJD/y6kXyI69eJFsA/0eewsPDkZCQgOTkZCQnJyMhIcFt4OQM 1Xn6CYo8EQQhLBR5IghZ9Io8ZWRkyC7v8tx2ctXEqcJ499DT1Wlg9CL5kVcvki0ARZ70alukY1Ik P/LqRfIjr14kW4DA5DylpKS4vZRQjTwZjUbYbDbVZcEORZ4IghAWijwRhCx6Rp48DZYYmiNPoaGh sFqtjvc1NTUYMmSIFyaKjWijb5GuNES6qhLJj7x6kfzIqxfJFoAiT3q1LdIxKZIfefUi+ZFXL5It QGAiTzyoRp4eeugh9OrVC6+88grsdjuefvppAMB7773nPyv9AEWeCIIQFoo8EYQswlYYf/3119HS 0oIJEybg5ptvRltbG15//XWfG+gvqMK4vhVf/VWBViQ/8upF8mOw+50qjPvfj11pP5grXfPoRfIj r14kP5rN/q8wzgs9bfcTFHkiCEJYKPJEELIIG3nqaYh231eke9wi3c8XyY+8epH8yKsXyRaAcp70 alukY1IkP/LqRfIjr14kW4BukPN06NAhPProozCbzWhsbARAT9sRBEH4FYo8EYQswkaeUlNTsWnT Jth7yIkr2uhbpCsNka6qRPIjr14kP/LqRbIFoMiTXm2LdEyK5EdevUh+5NWLZAvg38jT999/j8rK Sq5xjmrkyWQywWKxwGQywWaz4fLly4iOjkZVVZU+VgsCRZ4IghAWijwRhCx6RJ4aGhpQWlqKS5cu ITIyEqNHj0a/fv1ktZojTwkJCfj8888BAM3NzXj55ZexcOFCr40VFdFG3yJdaYh0VSWSH3n1IvmR Vx8IWxo7GmHIMaCmvcbtM4o86dO2SMekSH7k1YvkR169SLYA/o08hYaGYsqUKZg1axaAzkhUXl4e GhoaFL+jGnm6ePEi1qxZg/3796NXr15YuHAh/vSnP2HYsGE+2ITAQZEnghCTguYCxOXHISs2C/ON 8wNtTmCgyBNByOKLnKdr167h4sWLOH/+vGNAxdAceRoxYgR27tyJqqoqWCwW7Nixo9sNnJwRbfQt 0pWGSFdVIvmRVy+SH3n1gbClorUCAJDfnO/2WXePPFnaLDDkGLjbp3M7MHqR/MirF8kWILBP2/Xq 1QujRo1yGzi5aPxoj5BIi2QaDJ0dldZiXsGsj46O5ipaNmjePC49b/s8epH8yKsXyY/B4PeK1grE WeOQfzXfTV8dGSmEX3ylP3D2ABi+3E88fuxK+77sl0TSi+RHXr1IfjSbtfWTgSySidzcXHtubq7d ZrPJvgDYbTabvaqqyj5z5kx7aGiofefOnYr6YH099dRTdrvdbi8uLrbzEMx63rZtBw74zBZevUh+ 5NWL5EdefSBsWV+53o5s2Oefne/2GY8vfWX7/sb9dmTDfrLwpGbt1Y6rmtpn224H6NwOAr1IfuTV i2SL3a7dl/4eK6SlpdnT0tLsqjlPrKZTeno6PvroIzz99NNYu3Ytjh075s8xns+hnCeCEJMHzz+I tNo0hPcOR/WU6kCb48aCwgXIsmUhPy4ft/S/RZO2cnIlRvYZqdr2suJl2NOwB/bpoJwngpBB2DpP ISEh6OjowPHjx7Fw4ULMnj0bRUVFPjcwUIh231eke9wi3c8XyY+8epH8yKsPZM5TTXsNDDkGZNmy HJ8FMueJPQXI7DlTdEZRu8GywUV7qeOSJnuym7I12+MMnduB0YvkR169SLYA3aDC+G233Yb33nsP jz32GF544QUkJSVRhXGCIPxGXH4cCpoLHO8TjYnYH7tfUc+ezls/aj3WjVznM7vYehgfjv0Qvxj2 CxdNaWspok5FuX33uwnfIWFQgmLbWbYsLChc4HhPkSeCkEfYyNNzzz2Hu+++GyaTCYmJib62K+CI NvoW6UpDpKsqkfzIqxfJj7z6gESe2ipc3mfZsmDIMcDSZpH1Zfqlzs5tfeV6h04vW1zsanW1y1Lq nrTqHCVzpq6jzmP7GywbuO3pqhYQ65gU6Xjn1YvkR169SLYAYkSeMjIyFD9TjTz1FCjyRBBi0djR iNAToYqf7x6/G3eF3uW2XBqpUtJ5S1ptGh48/6Dj/S+G/QIfjv3QRfNA6QP42Pqx23e3jduG+0z3 uS23tFkw6uQot+UUeSIIeXwZecrIyEBKSorLMs2Rp56GaKNvka40RLqqEsmPvHqR/Mir91XbBc0F qGmvcdFLI05Sjjcdd/Ely0FyHjgxHY8tDDV9eVu5y/vWslY3jVLkSSnnyTnHideermoBsY5JkY53 Xr1IfuTVi2QL4P/IU0ZGhtvLExR5+gmKPBFE4Nhg2YDEQYkuFcQzGzORXJSs+J27Qu/C7vG7He+l OUhKOildzZFiTwEybul/C/LjOgt51rTXICIvQvG7SuvaYNmA9ZXr3ZZT5Ikg5KHIU4CQFsk8cuQI AO1FyIJZX1JSwlW07PLBg1x63vZ59CL5kVcvkh8D5fcfS36EIceAl3NeBgAcPXsU+c35LnpWHBOA 7N/spmwU7Nmjqs9uyva4nemX0hFnjcP6yvWIz4xHli1Lk1+k6xtkGeT4/Puz3yvaDQDN5c2y7Z83 n5fVA/DpfnL2oy/a92W/JJJeJD/y6kXyo9msrZ8MZJFMijz9BEWeCMJ/lLeWY8ypMS7LVoevxpYx WxzvlaIwUqqnVCO8d7hbDpKUc5POYVzfcW7LeZ/mU/qe8zq21mxFalmq4nfvM92HbeO2uS0fdXKU I8HdGYo8EYQ8wj5t19MQ7b6vSPe4RbqfL5IfefUi+ZFXr1XLnog7VXRK9vOa9hq3ZfnN+S7tl7WW qa5n2elIFFztHMBIc5CkfFXwlct7Nm+cdADEbN91epfH9qQ5WfHWeEeOU/5V93n4nLnU7przVNpa 6vJkoBx0bouvF8mPvHqRbAH8n/NUW1uLw4cPY9++fdi3bx8OHz7suCMlBw2eJERHR/cYPW/bg+bN 85ktvHqR/MirF8mPvHqtWvaofcjoENnP69rr3JYVXC1waV9aCkCO3fEVjgmD1QZbR4YccXnvKTkb AN7q+5bscjboauxodFl+2nQaB2ydc9HJTWLsTF1Hncu2KiWWO0Pntvh6kfzIqxfJFoDfl96Sl5eH mJgYJCUlISkpCTExMcjLy1PU0+BJgmijb5GuNES6qhLJj7x6kfzIq1fT2jpsmqpuWzusbstq2msw KXOS47taBk/LTkc6ojxq+jKz6+CKPYWnRG1prVtFc0B50OUceWLRMCWkkSc26PIEndvi60XyI69e JFuAwNR5MhgMjpeqlnKeOqGcJ4LwnsLmQkzIn+B4L1d1GwA2V2/Gb8p/I9sGyzkKPRHqFt2RY75x PrJis2RzkOTYH7sficZEx7xxakhzoLTmYnliZJ+RqJxc6XgfdSoKpa2linrKeSIIefTKeaqpqUFh YaGjvUGDBiE2Nhbh4eEuOs05TwkJCVizZo0uxgUDoo2+RbrSEOmqSiQ/8upF8CPLsWnsaNTV75Vt lS7v5apuA523reRg0Ru522JyOOc8qdWFirfGA7h+S1Htth3TM3tYVCnnSo5HvRZYnSc2552ngROD zm3x9SL5kVcvki2A/yNP4eHhSEhIQHJyMpKTk5GQkOA2cHJGNfI0fPhwmM1mDBw4UHdjjUaj43/n ufLKy8uxcuVKnDhxAlOnTsW2bdsQGRmpuNxT+3/4wx/w6KOP4u2338azzz6rOCcfRZ6InsTH1o/x QOkDyI/Lxy39b9Gt3f+t+1/8/NzPHe/lqm4DwG/Kf4PN1Zt1W68/YBEopSfifAlFnghCHr0iT0pF Mbtc52nVqlV47bXXfPI4oM1mkx3MPPPMM5gzZw4uXLiAOXPm4LnnnvO43BPbtm2D3W7Htm3ujwXL IdroW6QrDZGuqkTyI6/eF35kScyWNosmPcuxqWit8Kiva6+DIcfgeGUXeo7WSAcVclW3AaC6rVp2 OU/0BuiMPGmFt22p3nlOPV+0rwad2+LrRfIjr14kW4DA5DyxgVJKSorboEmKauTJOTrkjFIEpysY jUaX9saOHYtjx44hIiIC1dXVmDlzJkpLSxWXe2p31qxZSEpKwtdff40jR45Q5InwO3XtdTDlmRTr DOnBnoY9WFa8TPM8bizHRiknifHDlR9wx493ON6rtb+2Yi02VW1yvHeuuu1MUlESvm78WtVOohOK PBGEPHoFdjIzMzFr1iwcOXIEs2bNQq9evXD06FEsXrzYRac58sSiQ9KXL6mvr8ewYcOwZMkSmEwm 1NfXe1zuiVWrVuGll17CqlWrZD/vqKuDLS0N1y5dwuWsLJSUlOByVhYAaPobzHrzX/+quV0AqH3v PS49b/s8epH8qKYv/+bvAIAzmdsB+MaPx5uO4+6TkTjedNyjvrGjEf/y0WiUtpbi7pORKG8r96gv binG3Sc7ozt3n4zEyaKTHu2wtFlc9IMsg2R1de11Ljr2N94aL7tc6e+y05Ga9Y8cuUNzuyLqfXl+ XD54UJjzyZf9hq/1Ivkx2P2upZ9st1phS0tDa4H6gyJqREZG4ujRo5g4cSKOHz+O77//HrGxsYp6 IZ62k4s8ZWdnIzw83C3yJLdca7vS985Q5InwFTvqduDec/dipWklPhr3kU/WwZ4c0zqPG0MpJ4kh fbJMrf0FhQtkaxZJ53Ibc2oMyls9F7UkrkORJ4KQhyqMOzF37lxs3boVLS0tePfddzF//nyPy/VE tPu+It3jFul+vkh+VNMXtxQDuF4I0Rd+ZE+OZTdle9RLayGp5TwVNRe5vK8/7xrtLWgucHkSTfq0 HcvrWV+5HoYcg+NJt9p2+cq9Iuc8BVpP57b4epH8yKsXyRaA35feIpcwrpREDmiIPB06dAiPPvoo zGYzGhs7Hx32FMHhQS6fymazoaysDPfffz/y8vIcT9WNHj1acbmn9inyRASae8/dix11Oxzv225r Q29Db93ab+howJATQ1yWsfnepEjnf1PKSWLc8eMd+OHKD27LWa0kFpliT6INPjEYtg7f3tbviVDk iSDkEfZpu9TUVGzatAl2H5y4SrlUY8aMwf79+1FXV4dvv/3WMUBSWu6pfU/v5RBt9C3SlYanKwH2 tBd7FTQXCGW7CJEnRt0BvkRpNVukNYLirfGKFa6l879VtKlEnlpcI0/SWkl/revMY2BPokkHTr6O xlDkyXstIFbEJJjObSki+ZFXL5ItgP8jT8D1p+x0edrOZDLBYrHAZDLBZrPh8uXLiI6ORlVVlf6W BxCKPLlT2lqKqFNRbvkqcrCnvRhavtNTMOWZXOZyK59Ujsi+2n/01dhVvwt3l9ztsmzLmC1YHb7a Tfvg+QeRVpvmtlxa70mPKtqEflDkiSDkETbnKSEhAZ9//jkAoLm5GS+//DIWLlzoW+sCiGijb54a P03XmnS90mB5LCxfpWK/cqKwdJ6wv9b9tUddJcnp2X6RToLbfOiIpjZb7C2d+URnsjzq5CJPbL43 KXLzv8Vb45F+qbNDYBEkpYGTaNGYnhR5mpQ5CU3XmjRpKfIUGL1IfuTVi2QLEJjIEw+qg6c///nP +OyzzzBgwABERUWhrKwMmzcHV2VgHkSbWVqLniULV7ZV6jqLtnSy0tzblCdLlE5ZUdBcgPH141HT XuNxHSzhuK69LqhnAJfTK03/0TT7Zk1tNnQ0AAAODPE8aey5lnMu70+bTiO/Wfvg6bTptOP2G7sd p8Rp02mPn/tbvzteffJgf9niD31Vm7aIv69nsPfl+RQM57YSIvmRVy+SLQC/L/2N6uBpxIgR2Llz J6qqqmCxWLBjxw4MGzbMH7YFBNFG31r0LOpT016jSc+iC7mFuao6Zy4d+EZRKzdQ8JR7w2ARj6KW oqC7SmIDPyW/S6NxjLZD7gnYcrDB0w8/etbz5DzJzf8Wb413e2pOCdGiMT0p8hRvjVd8SlEKRZ4C oxfJj7x6kWwBukHkqbvT1taGsrIy1NZ2dkoGQ2d0xWw2a/orgj7nSg7irHGdt4k06DdYNiDOGofG kY2yn9e01yA+Mx6lraWIs3bWBIqzxuHTW8xu+tyiXBhyDAi7GObQsb+nTadxqviUR3uOnj0KAMgv zkd0dLSqP3bl74Ihx4DL1y4H3O/pl9IRZ41DwdUCWT3bL1K/WO8Yq8mOho4GxFnj8OXgLxGf2Tlh rpyutKXUze8RVREw5BhwtLDTv0cLj8KQY8Do6tGy+0nOTrm/dtg16fylLxkZqlnPs52i6YHOyNO5 c51RRr2P9+qf5ggVod/T0g8EWp9XlOdyfqn5kfVbOUU5fvNjsPt90Lx5qrrCwkKUlZXBYvHvXJOA hoTx4uJi/Pa3v8X3338PALjjjjuwcePGgBbV9AUsYbykpIQrvCiCnk1U+u6Yd5HUmKSolz7SvrnX Zjxy6yNuugO2A0gsTHRbft+ZeGy795QmLdB5pTzv5nnYMmaLqi3rR63HvU33qm4rK8K4t/9e/FPc P3nUOqPFj1m2LCwoXIDKyZVoKmtS1cflx6GguQBbxmxBcmOym15pAtmsmk2Yn/K4qs3f2L7B4sLF iLfG47TptKMcgJQhJ4Y4olQAHHoA+GjcR1hpWumYCFgOZ70aPFp/6JedjtR8604023n09unApH3x WDttLVaaVqrqefuZywcPct0m8WW/J0KfqqZn0xax84uh5EfWb0mnNxJpWwNpi6XNglEnR8E6xYqw 3p0X4lqPSWETxu+77z7MmzcPxcXFKC4uxty5c3H//ff73MBAIdp9X09658lgAaCqvcqjXnp754zp jKxOKV/mfyaedpsYVUkLeM69kdpS1Fzk0XY2QS27rVQ3sk5RK12PIceAvwz4i6qW5ftkN2UjOjra 8V3pAIgtL2juvDWWfzXfxXZ2C0xpAtkLM4drsp0NiNgPLLvdKn05D5yc9cD1vDVp/pqSXg3R8oB6 Ws6T1tt2lPPkWz0rP8LOK3ZuGgfOlz1HWb8lvZXfFVtY/9LY0dgl2/XQ6q1naR/OpVGCPuepqKgI jzzyCIxGI4xGIx599FEUFRWpfS1oEe2+rye9NM/oYttFj/rSllKX99bzVlmd0pNaLL/Eeb1KWsBz 7o3UluKWYq56Q6XmUnmhBNZpfXrqU8UBjTTf53jTcZSUlDjeS/0szQvKb853sZ3lcSkx6PtCTbaz QZE3uTTMVk+5TDzti5YH1NNynrQmjHuTX8LOB+kFDsPSZsGkzEmqD4N01Z5g6IOlswawCy+141H6 YE3WmSyXyvtabGH9i1z+opxeK976xdZh83jceGqfDSqda+JdPngQGywbXC5UfUltbS0OHz6Mffv2 Yd++fTh8+LAjnUcO1cHTQw89hHfeecdRxHLz5s14+OGHdTVaJILhqochvYqpbqvmijx9O/hbWZ1S tIhd5TuvVy3yVNNeI3tCuUWeWlwjT03XmlwGO9JCk0pRMynsypBd5csltksHOzlXchAdHe34rtTP 0ihOwdUCF9vZk2tKnJsxVJPt0siTVpz1LEqm1KHxti9aNIYiT/J4E3lyLlshR3ZTNk6bTqs+DNJV e4KhD2bTFrHzi/lK7XiU9j/sSVpWDob1d+yugnQfREdHO/oX9uQsi8rLneP+9DuzXem48dQ+G1Sy fr60tRTGgfMdJVPULkj1IC8vDzExMUhKSkJSUhJiYmKQl5enqFcdPL311ltYt24dRo0ahVGjRmHD hg3YtGmTIxLV3dD7KoaFc9mVBc/TcHXtdR710qsYS5vFo176SPvwquGyo3qlTpFdVTmv11MHKhcB UbKlrr0OkzInOSpUsznSWGcjHTxdLbuquF5n2HqZLXJPwEkHO2x+OPZdt6tFybbUtNdgUuYkl+rq ngg/qm1CXD0iT3rrRbIF6HmRp+r2ak1abyJP7HxQutV7vOl4Zy0xDxdO3lJ3rRYAABzNSURBVNij Zx/MIhfOA4uutC8dJEn7I4ba8cgGRez3QPokrfMclcx+RkFzASZlTnL0L2zwxKLycoMWf/qd9dlK x42WuyhsUJply3LxpXMpFZ5IHS8Gg8HxUkN18CQ3hYp0OpXuhN5XMWwnsyuLkNEhqm2y70ijMVKk VzE17TVckSd25SstkKgUjmdXVdlN2Y6D2FPoXi73RskWpmdXL6xdNtiRTlCbNSRLcb3O28LWw2xx HggxjXSwY2mzYHz9eMd3nTsypSs8nijCqWl9NOn0iDzprRfJFqDnRZ603irrauSpoLnAcT4oRRBy ruR05jN6uGWvxZ7GjkbF6AoPcno22GGRC+d1yOnZrUq5H+Xo6Gi323PSNAKG1uOR/R58OfhLl+Ws v2N/s2xZjnWnX0p3OWbYVEvS/Cup7VoJRORJmlfqvC3OvmT7h+1P5j89mTx5MgoLC5GZmYnMzEwU FRVh8uTJivoeX6pAil5XPUph168KvlJsS+7qRq59ditMmr9T2VbJlfPErny1FkhkVwKWNoumqTs8 RZ6ktjA9u3ph2yYN5zJGVY3yWJdIui3MFucBp6ftdbad7UtP28wTRRjzD223Xurb67nb9rVeJFuA nhd58nWdJ+fbI9L+iJHdlK1L5Inl7EjPQ5YH5OlWs4s9hdluAx+pzc4DCzlb2HazH2XnRO+SkhK3 xHDprAEMnuMRcD8GWH/nfJHnPI+ks76stQyAe/6VM/6MPLE+mx030mR5ufalNjtH0Xh96S3h4eFI SEhAcnIykpOTkZCQgPBw98nVGTR4kqBX5EmpuvSRIcpTc0gPpOKWYvmrJIVbZU3XmlwiJlKUIk9a CyTyXOU7t8/W7dzBqUWeqts6b0/IPYXh3La042XRIem2ML3zBMaetteXUYQTt2k77SjypE5Pizz5 usK4XL4eO8fYuWVps7jkPLHl7CV3To6vH+/4nA082G0nNiBh5yPLA1LrjxiW4Z19Bhv4ZNmy3KIw 0siTNJ1CKU9xg2WDS+RJDW/6SMD9th3gGiF31jtu20nyr5wj6XLHAcuRkvaD3v72XWi7IKtjPo6O jnbrn6X7yTl/i9eX3pKRkSH7UqLHD56kRTKPHOkc3Ggt5qWkP1l8EoB7sbuWEy2K7R2wHXDRFzUX ybaf35yvWExvaelSt2KKWbYsxGfGO4ouMn28NZ6rqN+y05Fcern200+lw5BjQGR1pKzeUtrZEVrL Op8EDLsYBkOOASOrRrptJwDUlHZG4eIz42HIMSD9VLqiX7Ta7Wv9Tdn1XEUyefeTL/Ui+REAHsid L4RffK0HOqMUUTVRssUZ1folVqTxwI8HZPX/2LWz88f0gsFt/az/WF+53mU/sWK6zsvjrHFYX7ne cT6yz533a1FLEcxmMypaK1y+t8GyAWazGT/8+APirHE4YDsg249J+7eTRSfd2jl/7rzLdgy0DIQh x4CXc15GSUkJ3j/xPoDr/ZHcdgOd/cukzEkYaBmoaT/xHI/Mj87vWX8nV3RYqq9orYDZbEZxS7GL Lv1SusNfd/7tTsd+qGmvgdlsRlFLkazfS0pKuIpYSvWWNovsdrL9NilzkqN/Zv6X7ife3xu9i2Sm pKQ4/rL/lVAtktlTYEUy9WJZ8TLsadgj+9n+2P1INCa6LY86FeUSkbl94O04evNRN11qWSq21mxV XPdK00p8NO4jx3tWoC0YeGL4E9gYuREPlz2M92reC7Q5PmH5kOX4PPpzVd2MMzMUI5hEz8I+HTA4 HQrS4oxqsD5g/aj1WDdyndvnexr2YFnxMh0sVecvUX/BirAV2GDZ4PFW+Li+43Bu0vUHS9g2SIvF eupruzODQwajYWoDTHkml9uIt/S/Bflx+W79flZsFuYb52NH3Q7ce+5e1faVfqcYbP/lx+Xjlv63 BOR3xj7NrluRzIyMDKSkpDj+Oi9zRnORzJ6GXjlPSj968dZ4xVtNco/vy7XvKdcg3hrvktzo6faU L/NLutJ+vDXe7badnm2Loo/PadWko6ft1OlpOU8MT0VPgev9kvSWmNLtKU/zVqrZwqtnOTosZ0dJ q5Q7I73lVn++3m+2q+GPPpLBEu6l+VfOaRjOeva7ofSkoNQWpd8p9vr01KcArueLsXxVLbZrwd85 T7xQ5Okn9Io8FTQXIC4/Tl3IgfQKICIvgqtAXTDBripn/zgb31/5PtDm+IQ5g+bg0IRDqrrhecM1 P5pOdG+kkSdpVEYJpWjAuUnnMK7vOMd7f0ZvVoStwF+i/oLkomRkNmb6ZZ0EsDp8NbaM2YJ7z92L HXU7dGuXRboGnxjsKDXjL/SMPMlBkScOvI08qRXz6sqVhjRh09PAyZdRBH9cVbGrF7XBochRATWm Hr+mSUeRJ3V6auRJGpWR1hhjT6wpRZ2ly4ceVR+I6WU7i3ywhGc92w603p+RJ149b+RJa9ss0qU2 cKLIUzdFr8gTmyyW6BrGECMapzZiYO5ANF1rCrQ5PiGmXwwK45WnaGETFBMEQxp5UoLlNKnlE7G8 yEAca2G9w2CdYkXoiVBN87MR+hDeOxzVU6rdcqSCGb1znuTocuSJVRFvamrCokWLEBkZiS+++MJb O4Wlq5En9gi82sBJpKskESNPbH4ktYGTSH7k1Sfk3eDxc6UaVb6whVcvki1Az408KcFymqSVq6Xw zsnWFVuU9OxxdKWBkwh+7Kpe5MgTqw+oNHASyY+A/yNP7Ak755cnVCNPRqMRNpsN6enp+Oijj/D0 009j7dq1OHbsmP7WBxBvI0/+fFqFCG5CQ0JRP9U9ybWuvQ6mPFMALCJER2vkiSB6EkLnPIWEhKCj owPHjx/HwoULMXv2bBQVyZem7w50NfIkN2eaHCKN7kWMPInQtq/1C08OkV2uNOWDSLaLZAtAkSe9 2qZzWx+9SH7k1YtkCyBGzpOn6JNq5Om2227De++9h8ceewwvvPACkpKSHNGo7oS3kaeeWmuE6DrW KVaE9Q5zvNdaf4XoeVDkiSDc8UWdJ7VlmiNPzz33HO6++26YTCYkJibqYqRIKFUYP/DjARhyDNiV vwuAeiXfS2WXAAS+4jKPPt7q/wrj3bXSNY+e+ZFVWgYgWynYH34Mdr/3tArjIvixK+37sl8SSS+S H3n1IvkxzhqYCuNap2YB6Gk7B9LIE3taRVrNVkppaymiTkX5w0Sim8EqLTP0rr9CdB8o8kQQ7ggd eeppsBwm9tSKtJqtlK8KvuJqX6T7ypQXERg986O03ore9Vd8oRfJFoBynvRqm85tffQi+ZFXL5It QGCettOyjEGRp5948cUX8fq/v65Zz6p+P1D6AD62fuw7w4huC6u0zOhO9VcIfaHIE0G44+un7eTg rvOktqy7oHV0zCJRZWb5+Zm8bd8fero6DYxeGnli0c1gqL8iki0ARZ70apvObX30IvmRVy+SLYD/ I0/SfCe1vCfNdZ4YZ86cQWJiIqqqqnQ2PbDwRp4IwltYpeVAzEZOBBcUeSIId3wReTp79izq6uow bdo09O3b1+1z1ciT0Wh0RJjY/0ajEYmJiXj00Ud1NVYkRBt9i3SlIdJVlUh+5NUzP7JKy2oDJ5Fs F8kWgCJPerVN57Y+epH8yKsXyRbA/5Gnq1evIjs7G1arFTfddBNOnjyJ5uZmRT135Km7QpEngiBE hSJPBOGOnpGnb775BlFRUYiKioLBYMDVq1eRn5+P6dOnu+joaTsFRBt9i3SlIdJVlUh+5NWL5Ede vUi2ABR50qttkY5JkfzIqxfJj7x6kWwB/B95uuOOO3DTTTfBYDAAAG644QZMnjxZUa86eOruUSdp kUw77AC0FyELZv1p02muomW74yu49Lzt8+hF8iOvXiQ/BrvfS0aGCuEXX+sB+HQ/8fixK+37sl8S SS+SH3n1Ivkxzqqtn9SzSOahQ4fcksW//fZbRX2XShV0x1t57LZdvDUep02nNX8vmPW8bS87HYnd 8RU+sYVXL5IfefUi+ZFXL5ItAJ8vRbOdR2+fDkzaR+e26HqR/MirF8kWQJsvfVEk07kwpqcimTR4 +gnKeSIIQlQo54kg3Ank4En2tp1zHSfnJ+2cn8Drroh231eke9wi3c8XyY+8epH8yKsXyRaAcp70 alukY1IkP/LqRfIjr14kWwD/5zzx0qWn7SjyRBAE4T8o8kQQ7ghdYbynIdroWzf9lcHAdHvnKyex S22LdFXls7ZzEoHpdsSvLL7uryuDdbVHJD/y6kWyBaDIk15ti3RMiuRHXr1IfuTVi2QL0A0qjItE eXk5Vq5ciRMnTmDq1KnYtm0bIiP1cXC3jzx9uQL4+v8BP38L+PX+zmX7RgKmi4G1yx9YRwDJkqcx DoQCAxuvv78yGJjf0Pn/+wuAaVmd/6/9HFicDvzTDr+YShByUOSJINxxjjz9PTUVC3/3O4R6OSZo bW3Ft99+65b/xAjKyNMzzzyDOXPm4MKFC5gzZw6ee+453dfhcXT8U1TCEb3JSbweobCOuK6zjriu k9M7a6U4fzcnUb/R/df/r3MQMC0LyDYAKzYhfveT6g062bNsT5I+tuig52r7f55EfOqmzu3ONgDz dwEH73LVHLyrc3m2AZiWdb39xemdvtPRHl2uTiXHSVdt4dVznR8+tgVA5zHJ1unpvNLLFi1+l/GD XBtufYFSv6Fkj4f1UOQJrv508rPm9pX2kwf85ke5Y0XLMeMLW3yk5/WlOSsLHy9fju+3bkW7h8rg nrh69SpOnjyJkJAQ1NfXo3fv3opa1chTcXExnnjiCRw9ehQGgwGzZs3Cxo0bER0d3SXjvGHs2LE4 duwYIiIiUF1djZkzZ6K0tFSXtl988UW8/vpr1xc4Rx9yEq9Ha95f0PnX+T37IX58beffNze6vnf+ /s3HO9uV+8y5rXl7XJfL2SLFWcdw1jtHW5yjMXLfY7BtkbPHG1v8rXeOsrEo3Ma7r3+uFGFyjkip 4c1+0rINzt+T2y9dscVZD2jTefK7Ujtq9vxqA/DndZ61npZLz0G5dXTFJ9JtVTofANf25PoJ6b5j aOg37DBcjzyp9UdqvusKaselsw1KaDk2uorUPudjgsH8qvQdqS1K+0mLDVrPcbXzSem8kB4rvDao 2QT4Zj/x2KBhXc6Rp41x12uihY4ejYW/+x1umj9f8+rPnTsHs9mMG2+8EcOGDUNubi7Gjh2L2NhY F53mUgWzZ8/Gv/3bv2HVqlWd2/T++/j888/x3XffaTZKL0JDQ3Hp0iWkpKTgyy+/hMlkQn19fZfa KiwsxCeffAJ7SwvaS0txqq4OU6KiUN+nD1Dbjt1HIjFuYCVKr4zCuIGVmDgvAuGwIGTECHRcvOj4 W9+nDwY0tWPn1676O+6KQN8Gd30N+uDMwWsOXemVUVg2uwJtoSNw5mA1Sq+Mwn8srsANo4ej4+JF lDf3wbl/uOtNE4ZL2h2JMwer0TakN/rUt6vqQ0aMQENxMa4OinGs19l+57/MntZTp1AXPtlFL+cX 69kq7D4SiVsjf0Ruxc2qfuyKPud8X7ftVNtPQ9raEDJiBFovVGFHZqTbdq5YUoG+Nw5300v9JveX Zz9dzjmNQ9VTFf0t/Z7SfnI+TpztqTpdjL3HJmryi1TvSddVv6udT2z/L5tdAVu/3rJ+dD4/nJeH 9m2C4YYb0Bo6Ekf3uH/O/FiDkbh4qtjl+FI6L5T0cn5n513plVFYOuMMhsePl/WbdPvvuCsCV8uK sOvIRLfl0n7DerYKU78uxp7YEQ57PJ1H4wZWOvqBifMi0Kfhotv6pX+NfZpgaxvgsR9w9hc7P5y3 35M/nc8P6X6R7le5fsDTX6Zn7Tr74Y67IoDaiy79s3P7csehlv2k9PfWiZfR0XeAqr/ZfvF0PrH9 5nz8O/fvSue/2u+B0t+lM87APixGdn/quZ+0+GX3kUjMjTjhsZ+8JbwSM5MGo720FCEREQj9+uvr Y4XIyM7BU2Ki5jFBTk4OJk6ciAEDBnjUaR48hYeH48KFC47ZhVtaWjB69GhUV1drNkovxo4di+zs bISHh/sk8vT73/8e58+fx9ixYzV/L5j1vG03HzmC/rNn+8QWXr1IfuTVi+RHXr1ItgB8vhTNdpH2 k0jHpEh+5NWL5EdevUi2APy+3BgXh979+2PGL36BmQ8+iN79+2v+Lg+ac54eeughvPPOO7DZbLDZ bNi8eTNWr17tE6PUmDt3LrZu3YqWlha8++67mM8RktPKyJEje4yet+22oiKf2cKrF8mPvHqR/Mir F8kWgM+Xotku0n4S6ZgUyY+8epH8yKsXyRaA35c3zZ+PlZ9/jtmpqT4bODkjG3nSUggzEHWeysrK cP/99yMvL8/xtN3o0aN1aZtFnghlOmprETJsWKDNCHrIj/pBvtQH8qM+kB/1Q1RfejU9S3ekoKAA t9xyS6DNIAiCIAhCUIKyVIEvCeTAqbtPeeMvyI/6Qb7UB/KjPpAf9YN8qQ80eOoiY8eOdUmar6qq 4kqG8waleQbLy8uxaNEimEwmLFq0CBUV2mf3DhQi+jFY53EU0Zc7d+7ElClTEBYWhjlz5uDgwYN+ sccbRPTj7t27MXPmTJhMJsybNw+HDx/2iz3eIKIfGRs3bgyq81tEX/akOW/loMFTF4mJiUFRURFi Y2MxYcIEx//+gCXvS/FHEVG9EdGPSstFR0RffvHFF/jkk09QWVmJRx55BPfdd59f7PEGEf342Wef Yfv27aisrMSTTz5JflTB0zl88uRJbNmyxS926IWovmSfBWN/6S00eOoiMTExOHbsGPr27YvevXsj JycHMTExADprSC1evBhhYWGYOnWq4ypRaTmjtrYWS5cuxY4dXZsK5ODBg0hNTUX//v2RmpqKrKws r7bRH4jox2BFRF9u374dcXFx6N+/P+bOnYvGxka0tbV5t6E+RkQ/fvzxx5gwYQKuXbuG9vZ2DBky xLuN9AMi+rGlpQWrVq3CK6+84t3G+RkRfQkAkZGRGD58OP71X/8VZWVlXd/AIIQGT11kwoQJ2L17 N2bMmIEZM2Zg165dmDBhAgDgl7/8JX71q1/BYrHgjTfeQGpqqsflAHD27FksX74cTz75JFasWNEl m+rr6zFs2DAsWbLEqwKi/kREPwYrIvvSarVixYoVeOihh9CnTx+v2vI1ovrRaDQiIiICa9aswYcf fujdRvoBEf34wgsv4Oabb8Y999zj/Qb6ERF9abPZUFFRgfz8fEycOBEPPPCA9xsaRNDTdl3kiy++ wH/+53/i1Vdfhd1ux+9+9zvs3LkTS5cuxdChQ9He3u7QGgwGNDY2Ki43Go2YNGkSLl68iP/7v//T nLxuNBpdwqW+LCLqK0T0o9pyURHVlydOnMB//dd/4Wc/+xnWrVuHXr3EvmYT1Y8A0NTUhL179+KP f/wjfvjhB+831oeI6MfQ0FBcu3bNRRMM57iIvnSmubkZo0aNQl1dnXcbGgTQ03ZeEhsbC7vdjpkz Z2LmzJmw2+2Oe9BTpkxBeno6ampqYLPZ0NjY6HE5AOzatQubN2/GPffc0+Xq7f4oIqo3IvoxWBHR l9u3b8eaNWvw3//939iwYYPwAydATD8+/PDDKC8vR0hICEJCQmCxWLzfUB8joh8bGhpccnSCYeAE iOlLxuXLl7F582ZMnjzZq3aCDYo8dZG2tjaMHj0aZWVlsNvtGDt2LCoqKtC7d28UFRVhzZo1+Mc/ /oHmn2Z3ttlsisudR/Tbt29HWloa9u7dixtuuEF23XJPNthsNp8WEfUVIvpRabnoBIsvL168iIED B+q12bojoh8/+eQTvPLKK6ioqEBsbCxefPFFLFmyxEce0AcR/SjVBMN5DYjpS7a8X79+uP322/H2 228jOjraF5svFFQkkyAIgiAIggO6bUcQBEEQBNEFaPBEEARBEATBAQ2eCIIgCIIgOKDBE0EQBEEQ BAc0eCIIgiAIguCABk8EQRAEQRAc0OCJIAiCIAiCg97efFmueJaUYClC5gu0FGHzd6G2YCoMRxAE 4UvoN8wzIv6GiYJXgycAQLaHz6ZrayIxMREAkJWV5a01QYfSQeerA7InHuQEQRDK2D18ZtDUAv2G uSPSoMoXtng/ePKS6upqlJSUAABqamoQHh4eYIsIgiAIQhv0G9YzCXjOU2ZmJhYuXIgFCxYgMzPT sXzatGk4efIkACAvLw/Tpk1zfHbx4kUsX74cJpMJU6dOxeHDh13aNBqNeP755zF8+HAkJCS4LDca jRg6dChmz56N/fv3Oz4rKSlBQkICIiIisH79epdwrtr6PLFu3TpERERg9uzZKC4udrNFGjZ2Xib3 +a5duzB9+nQMHTpU9nMllNbHPnv//fcxZswYjB07Fn/72980bx9BEERPhn7D/PMbVlRUhHnz5iEs LAzz5s1DUVGRyzqlNmixxRsCPnjKyMhASkoKUlJS8OWXXzqWL1u2zHEgZmZmYtmyZY7P1qxZgxUr VqCyshJvvPEGUlNTZdsuKSnBjBkzHO/ZbNq1tbXYtGkTfvWrXzk+W7t2LZYtW4by8nI3B2tdnxxG oxHl5eX42c9+hrVr17rZIkU647dU8/DDD2Pz5s2OmbK1hiLVtPX19fjxxx/x5ptv4vnnn9fUJkEQ RE+HfsNc8dVv2OOPP45ly5bBYrHgzjvvxOOPP676HTVbvMGriYGNRqNqzpMnY9va2hAVFYW8vDwA wJQpU3Du3Dn06dMHubm5eOqpp/DVV19h8eLF+OMf/4hbb70VADB8+HA0NTVd3wiDAY2NjS52WSwW DBo0yGV9+/btw7PPPovi4mJ0dHS4fC8iIgLFxcUYPHgwbDYbRo0a5bBdbX2e/FNZWem43zp+/HhU VVW5aeR8pLT8n//5n2G1WpGYmIhp06Zh6dKlGDBggKotnto1Go2oqqrCgAED0NHRgaFDh2raPoIg iGCmc5DhOeeJfsPE+A2LiIhASUkJjEYjGhsbMX78eFRXV8uuS+29NwgxMfDhw4fR0NCAcePGYdy4 cWhoaHCEE2+99VZUVVXh3LlzqKqqchx0ANCrVy+XUavcQSA96ABg9erVWLduHaqrq2GxWGC3ezpp rqNlff7i73//OzZs2ICwsDCkpaVh+fLlurTLDt6QkBDNfiEIgujJ0G8YP139DfO0rQaDAR0dHQDg Mkj0JQEdPGVkZOD555937NBnn30W+/btc3y+dOlSPP3007jzzjtdvrdgwQK89NJLuHLlCtf6mpub MWzYMLS2tuLVV191+Wz27NnYunUrWlpa8MEHH+iyPgD44IMP0Nraig8++ACzZs3S/L0BAwbgzJkz bsv79OmDJUuW4IknnsAzzzwjqyEIgiB8D/2GKaP3b9iMGTPwwQcfoKWlBe+//77L7czIyEjs2rUL TU1N2LJli2ZbvCHgg6clS5Y43svdM967d6/LvWIA+NOf/oTi4mJERUVxJYG98soruOeeezBx4kRE Rka6fLZx40bs2bMHkZGRuHz5Mnr1uu6arq4PAC5duoQbb7wRn376Kd544w3HcrVEttTUVMyfP18x Gc9kMuGxxx7Du+++q8kOXybOEQRB9EToN8x/v2FvvvkmPvvsM4wYMQK7du3Cpk2bHJ+tX78ea9as wc0334whQ4a4fVfJFm/wPudJBVHqPGjl2rVr2Lt3L9atW4ecnJxAm0MQBEH4CPoNI3hhOU9e1XkK toNKDaPRCIPBgHHjxsmG/giCIIjuA/2GEV0l4EUyRaK7nUgEQRBEz4F+w/xHwOs8EQRBEARBBBM0 eCIIgiAIguCABk8EQRAEQRAc0OCJIAiCIAiCAxo8EQRBEARBcGDIzc21NzQ0wGw2B9oWgiAIgiAI 4elFAyeCIAiCIAjt/H/JffXi1IdbvAAAAABJRU5ErkJggg== --Apple-Mail-16-564508345 Content-Disposition: inline; filename=6to4-y.png Content-Type: image/png; name="6to4-y.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAACbCAYAAAB7939+AAAABmJLR0QA/wD/AP+gvaeTAAAgAElE QVR4nO2de3QTdd7/34FyK4RSSiuXAgURtFwVkEeKpVCBnnUtPp51d5/jKuzjomjliLI/HxcRkgXX XVcB5baIi/Zx1+NSV7kIW242ZUXYp5R7w9KWNpS2ofdLoE3apvn9EWaYJDPJJJ1kJp3P65yctJPJ vL+fuX7y+X6+n6/m3LlzDhAEQRAEQRA+aWpqQg+5G0EQBEEQBBEONDU1oaSkBBHMgnHjxsnZHoIg CIIgCEWTlZUFABR5IgiCIAiC8AdyngiCIAiCIPyAnCeCIAiCIAg/iPC9CkEQBEEQRPclOzubd3la Whrvcoo8EQRBEAShatLS0pCWlob58+ez/3uDIk8EQRAEQaie1tZWFBQUoGfPnmhsbEREhLCLRM4T QRAEQRCqprS0FCUlJRgxYgQSEhKQl5eH0aNHC65PzhNBEARBEKqmvr4ejzzyCCIjIwEACxYs8Lo+ OU8EQRAEQaiampoa1NTUeCynhHGCIAiCIAgeKGGcIAiCIAjCTyhhnCAIgiAIQiSUMB4gpSdOAADG JCfL3BKCIAiCIEKJJAnjWq3Wp5DFYgmgecqkw2bDsQ0bAAC/PHAAEX36yNwigiAIgiBChb8J47zO E9cxevvttzFw4EC8+OKLAIAdO3bAarVK0VbFkPfnP6O5ooL9+5GXX5a5RQRBEARBhAqNRoOFCxdC o9EAABwOB44cOSK8/rlz5xwAMG7cON4VYmNjUVFRgd69ewMAbDYbRo4cierqaqnbLgvNFRX49Ikn 0GGzAQAi+vTBLw8cwMARI2RuGUEQBEEQoeCHH35AfHw84uPjAQDl5eUoLy/H7NmzXdbLysoCIKJU wfjx47Ft2zZYLBZYLBZs3boV9913XxCaLg/H33mHdZwAZxfe8XfekbFFBEEQBEGEksmTJ8NsNuPo 0aM4evQozGYzpkyZIri+T+cpMzMTOTk5uPfee3HvvfciNzcXn332mZRtlpX/3L4dqwoK0PLzn2NV QQFWFRTgP7dv91iv/epVGVonr74abZZTVwn6arZdbn2yXT7Upq82e8Wg1Woxa9YsLFq0CIsWLcKs WbPw/fffC67v03kaN24c9u/fj+rqalRXV2P//v3dKvIkFuvp06rTV6PNcuoqQV/NtsutT7bLh9r0 1WZvMKBSBRwGDBgg+FlkVRV6ePk82PT96U8REWJ9OTSVoK9Wu+XWVrs+2S6f7Wq7v8u9v6XUv3Xr liTbyc7O9mt9n5GnrKwsJCYmYuDAgdBqtexLbfRYv15WfeuVK6rQVIK+Wu2WW1vt+mS7fKjt/i73 /pZbnw9mehbuyxs+R9uNGjUKmzdvxuLFi9GzZ0/pW6wQ1q9fjz/84Q/CK2g0gMMRugYRBEEQoYHu 72GLVJEnPrKzsz2cKNGj7QCnR9adHadw4NadCujdXVMJ+mq1W25tteuT7eol1PbLvb/l1heLt+iT T+fprbfewrZt29DS0iJpo5RCe3s7ysrKUFtbCwAoKSnhfWcQ+jzY79V3ak+EUndAcrJs9sqpr1a7 AXnOM9KX/7jLrS/3cWdQi/1y72+p9AsLC1FWVgaz2YyuUltbi5MnT+Lw4cM4fPgwTp48yfoFfPjs thPKb+pO07MAyu+2u3XiBAaEeN49OTSVoK9Wu+XWVrs+2S6f7Wq7v8u9v6XUl6rb7vjx45g8eTKG DBkCwOlMXbp0CampqS7rMd12PkfbdTcnKVyR40SX9WYmo75a7ZZbW+36ZLt6CbX9cu9vufWF0Gg0 7PQsvhCV80TID+U8dX9dJeir2Xa59cl29UI5T/IzZcoUFBYW4siRIzhy5AiKioq8Vhj32W139epV vP7668jLywMAzJw5Exs3bsSECROC0Hz5UHq3HUEQBBEk6P4etgRztB0fokfbPf/880hJSUFxcTGK i4uRnJyMX/3qV0FvIOEKRZ66v64S9NVsu9z6ZLt6ociT/EieMB4dHY2bN2+iT58+AACbzYZhw4ah vr4+CM2XD4o8EQRBqBS6v4ctciWM+4w8TZw4Edu2bYPFYoHFYsGWLVswceJESRqrBMKlVIHxwIGQ 6946cUI2e+XUV6vdgDznGenLf9zl1pf7uDOoxX6597dU+lKWKgDuJoyLSRr3O+dpxowZ2LRpE+U8 EQRBEN0Dur+HLVJFnmpqalBYWMhub8CAARg/fjxiY2Nd1hMdeZowYQIOHjyI6upqVFdX49ChQ93O cQoHKOep++sqQV/NtsutT7arF8p5kp/Y2FgkJSVh0aJFWLRoEZKSkjwcJy4+I09qgSJPBEEQKoXu 72GLVJGn7Oxs3uUBz23HV2FcqOo4ETwo8tT9dZWgr2bb5dYn29ULRZ6UQVpamsdLCFmLZH755ZeY OnUqBg8ejDlz5uDEnR1648YNpKamIiYmBqmpqSgvL/e6XAitVostW7YAAD766KOwdvqownj311WC vpptl1ufbFcvVGE8/PDpPEVFRaGuro79v6amBoMGDZJE/ODBg/jiiy9QWVmJV155Bc899xwAYPXq 1ZgzZw4qKiowZ84crFmzxutyb2RmZsLhcCAzM1OSNssFRZ7CS9dgMcDUZpJNP1DUesyVoE+2qxeK PIUfPnOeli9fjh49euDdd9+Fw+HAm2++CQD405/+JGlDKioqMHnyZFRVVWHcuHHIy8tDXFwcqqur 8fDDD8NkMmH06NG8y4XQarV45JFHsGDBAhw7dgw//PCD4Fx9lPNESMm8wnlYErMES2OW+vU9g8WA uF5xSOybGJyGEQThCd3fwxbFVhh/7733YLPZMGHCBNx///1ob2/He++9J2lj6urq8Mwzz2D58uXo 1asXGhsbMWTIECxcuBAxMTFobGwEAMHl3li2bBk2bNiAZcuW8X5ur6+HZfdudDY04JbBAACKfL91 4kTIdWvvOMhy2S2Xfld187J3wGAxoD7niN/f15v1KNu+URa75TrPSN/5rtbrTe79roT3UNsv9/6W Sr+jrg6W3bvRZjQi1Mg+2u78+fN49tln8dRTT2HdunXo0aMHRo8ejTNnziA2NtYj8sS3XAitVusS aXL/nwtFngipmFc4DwaLAQm9E1A6uVT098ztZgy/OByJfRNRMLEgiC0kCMIFur+HLYqNPAWTzz// HCtXrsQnn3wCvV6PHj2czXn00Uexfft22Gw27NixA3PnzvW6XA1QzlN46NZ01MBgMQAATG0m6M16 6M16UflPZ1rOAADGnWmGxc7v5AcbtR5zJeiT7eqFcp7CD5+Rp3/+859YsWIFSkpK0NzcDMB7BMcf +Ea/3bx5E3V1dViyZAkuXLiAadOmITMzEyNHjkRZWRnvcm/bp8gTEUpyLblIKUzxWP5pwqdYGrMU 1k4r+p3rB91wHdYNW+eyjt6sh65SBwC4OvEqxvcdH4IWEwRB9/fwRbGRp4yMDGzcuBGOIJxYzHx5 3Ff//v0xatQo5OTkoL6+Ht999x3rIAkt97Z9b/+HExR5Cg/dAit/d1uuJRcA0Gh35unpKnUe0aj8 2/kAgPTL8ahsrwy4DV1BrcdcCfpku3qhyJO8nDp1CpWVlX75OT6dJ6YsAMOtW7cQGRkZWAuJgKE6 T+GhW9DK7zwxXXmM88QsM1qNqOmoAXC3227/pHKY2/knujS3m2G0Bi85Uq3HXAn6ZLt6oTpP8pKY mIiamhrk5uaiuLgYNpvN53d8Ok9JSUnYu3cvAMBqteKdd97B/Pnzu95awi8o8hQeukKRJ1ObCa2d rS7OU64lF1kNWTC2GmFuN7MOU/rleEHn6UzLGWQ1ZAXcPl+o9ZgrQZ9sVy8UeZKXqKgoTJ06FY88 8ggAZyTqwoULaGpqEvyOT+fp448/xtdff43IyEiMGTMGZWVlbNXu7kB7ezvKyspQW1sLACgpKeF9 ZxD6PNjv1fHxIdcdkJwsm71y6ndFt/1GOwBgYt1Ej/fajlqUl5az/xssBpy+ehoF1gLkXs1ll++f VI766/W8279YfBF76vd0q/OM9NV9vQHyH3cGtdgv9/6WSr+wsBBlZWUwm/l/bPpLnz59MG7cOCQn JyM2NhZGLyUQZC9VoBSUnjB+68SJkIc65dBUgn6gus32ZkSdjxL8PP+BfBTZivDzkp+7LH859mXE 9Ypjk8XTL8ejf/Kj+GLMFx7bSC9Ox4GmAyiYWOBXIU29WY+no5/2+R21HnMl6JPt8tmutvu73Ptb Sn3FJowTyoBynpSvW97ufa7F+o56NHZ4FnYtsBawyeKA95wnJi/Kn647c7sZukqdqO+o9ZgrQZ9s Vy+U8xR++HSemHICLS0tSE1NRXx8PA4ePBj0hhGuUM6T8nXL27w7T3X2OpecJwZjq5F1igDh0Xbc vKg99XtEt4vZ9p76PdCb9WjtbBVcV63HXAn6ZLt6oZyn8EN05OngwYPo06cPvvjiC+h0uiA2ieCD Ik/K1/XlPFW3V6PB3uCxvKajxiXSJBR54jpYRqsRBotB1ATEZ1vOst/RVepQ21EruK5aj7kS9Ml2 9UKRp/DDp/PUs2dP2O12nD17FvPnz8fs2bNRVFQUirYRHCjypHzdG+03vH5eb6/njTy5k345Hha7 BZp8DVviALjrBDEw1cu56/DB7RIEwJZG4EOtx1wJ+mS7eqHIU/jh03kaO3Ys8vPzYTAYMHXqVERE RMBut4eibQQHijwpX7esrczr53Uddbw5T+7sn3Q3gqU369m/3Z0gJvLEFOAUghuxApy5V0Ko9Zgr QZ9sVy8UeQo/fDpPa9aswZNPPomYmBikpKSEoEkEHxR5Ur6umG47sZEnBoPFAE2+Bnqz3sMJ4q4D OLvl3Lvw3LsEAWfulRBqPeZK0Cfb1QtFnpRJdna24Gc+naennnoKlZWV+Pbbb9GrVy8A4T3NiTtU 50n4Xa11ZwLVLW8r563vxLzX2evQ39xf8HPmff8kz+1kXcqCud3Mu76pzYR9BfuQ1ZCFo1eOurTr 1NVTHutXt1cr6jwjfXVfb4D8x51BLfbLvb+VWufJH6jO0x2ozpMyNJWgH6hu1PkoNNubBT9/KPIh tHS24N/Wf3vdTvrleJeuOzGkaFNQ3V6Nh/s/jE8TPoXerMeSmCU41HQIGWUZLuvyTUrMoNZjrgR9 sl0+29V2f5d7fyuxzpNQlCktLc3lf6bOU4QkqkTQoZwn5erqzXq2wKU3ajpq0O5o97mev44TcLfr rqWzhW3P6N6jeefaq+sQ7rZT6zFXgj7Zrl4o50l+3J0koIvddoQyoJwn5enqzXpo8jWiHCcAqO2o 9TvnyV9MbSa2PbmWXN659qrbqwW/r9ZjrgR9sl29UM5T+EHddndQercdoSwMFgPmFc6TuxleSeid gNudtz1KEzw28DEcve+oTK0iCAVC9/ewhaZnIbyihshTs73ZpWaRkiNP3BICUtOVyBMXU5uJt6aT t1IFcv8iVLM+2a5eKPIkP7W1tTh58iQOHz6Mw4cP4+TJk+xAMj4o8nQHijzJj9FqREZZBnLG54RE j+sAvRz7MmIjYr2uX9NRg7gLccFuVtAZ2XskyiZ7r0klBQaLAQ9GPoionsKTJROEIqD7e9giVeTp +PHjmDx5MoYMGQLA6UxdunQJqampLutR5OkO4VKqwHjgQMh1b504EVK98rZy1JhqYGozBV1/X8E+ 52S5l7Kgq9SxQ/q96RpbjV5LDEj1nn45Pqjbr+2oDcl5pjfrcabojF/fk+M8V4p+qK83JenLfdwZ 1GK/3PtbKn2pSxVoNBr25XNdijw5ociT/Oyu3Y3nrz+PTxM+xdKYpQCck+F+XPux4NB6MRgsBiT0 SUBC7wR22bzCeS5dhNtGbcPLsS973c72mu0ew/7DldsP3kZkj8gubcNoNSKrIYv32JjbzRh+cTj2 3rsXiwct7pIOQQQdur+HLVJFnmpqalBYWMhub8CAARg/fjxiY117JERHnpKSkrBy5UpJGkcEjhpy npi54ZjpRm6dOIEzLWegq9SxU5Fo8jU+J8J1x33+N2ZSXS7cIf1CdvMN+w8GUuU8eaOqvYp3ubvt RqvRY449hqwGZ9SO73gw1dD9PVZy50KoOe9HzbbLDeU8yU9sbCySkpKwaNEiLFq0CElJSR6OExef dZ6Ki4tx5MgRSRtJ+I8a6jwxc8MxD+oByck4eycviZufZLAY2MgUH3qzHk9HP43Evoms05XQO4H9 TlZDlsd3uEP6hezmG/YfDAKp8+QvtR21GNNnjMdyd9uZfaU365GiTQHg3P+5t3Kxp34P+7/78WAm MS61lfrVLrnrv6i51pGabZcbqvMkP2KLZDL4jDwtW7YMf/jDH0I+HJBwpbtFngwWA5rsTS7LmLnh mFFit06cYCfDZZwgAF4nwjVYDM5cJs5Dn1nOwDz0uRhbjezfQnZz1wkmoYg88Y3CAzxt5zpIeo4j q6vUwWh17g++48EcN4o8hYe23Ppy2y43FHlSBoyjlJaWJug0MfiMPH344YcAgE2bNrks707z24UD 3S3ypDfrsXnkZkztN5Vdxp1Y19hqxNzkuThz8ece3+XrQnJ3krgPfcD5EGfWYR76XGo6atBkb0JU zyheu1s7WwUdDqkJReSpuoO/UCbXdnO72WVf6Sp1vAVB+Y4H221nM/nVLrl/kao5+qJm2+WmO0ee ajpqUNNRg8S+ibLoi6VHjx6wWCzQaDRobm5Gjx49EBEh7CL5jDxZLBbel1pxr0UUKrpT5MnaaYXB YvB4sJa333UaCqwFKP3u7zC3e46i4DpCzP/Mg505Nkar0eNBL/Tw524H4Le7tkO43ofUhCLyJGQP 13bGAfKFqc3kck2Y2kzscaPIU3hoy60vt+1y050jT8ZWo0uqhMFiQN6RnSHTF0t8fDxOnz6NBx54 AGfPnsWpU6cwfvx4wfVVX6rAX8rby4NaIFGI7hR5arA3ALj7YG2yN0GTr3GZVLegtQC5U4WddF2l Dpp8DW/yd6Awzhyf3aGKOgGhiTwJJYxzbWfylsTgnpPG0GRvgsUu/seW3L9I1Rx9UbPtctOdI08F 1gKXVAm9WY83Er4Mmb5YEhMTsWDBAowaNQopKSns30Ko3nnyt87TleIrMFgMOFd0zuv6Sq2LoYS6 Lw32Bkysm4hSWylKSkpgajN51COqu16HOsNRn3WLvin4BrmWXEnqH3mrL3W95HqXty/2Pdh1ngCg rbzNxT7ueVbTUYN9BfuQfztf9PZqTDXQ5Guwr2Cfx/Ewt5sVfZ4rRZ/qPMl33BnUYn8o9QpaC6Cp 0EBv1uOd/HdgsBgw5oQDHY6OLm9fyjpPfAnj3iYG9lnn6Z///CdWrFiBkpISNDc7IwNarbbbdd2J rfPE1CIyjDdgrnZuyNrXnTh56yTmXJ2DxYMWY++9e7GvcR+evPakyzqxEbHo36O/z26fxL6JaOls 8bt7iI9X417F5pGbeT/7W8Pf8PMSz/yrcOVHUT/CwXEHeT/LteRCZ9bhqvUqb7epN1K0KTDZTC7H I2d8DjtSjyAUCdV5ChophSm8g0oapzVKMvuAVIPZxI62E13nKSMjAxs3boSDTiwAd2sRhWrYOkN3 ynmqtzvnVmO6yfgcn5qOGkw52+FzW0arURLHidsOPrur2/kTrIOB3KPtCqwFMFgMfjtOgLPLzv14 +LMduXNf1Jz3o2bb5aa75zy5k345Hrc6lTeCnxllJ2a0nU/nqaKiAnPmzGH/v3XrFiIju1aZOJxh ahGFqmAiQ7fKeepwzXkSqgUUitwfLiabM/FZ238um0/FwDh8oSBUdZ74GJCcLPm57Y/z5O2ccx8o EAzUnPejZtvlprvmPAlNTr5/UjmsndaQtEEsfM6SNwdKVIXxvXv3AgCsViveeecdzJ8/vwtNvItW q2VfXG7cuIHU1FTExMQgNTUV5eXlXpd72/6WLVsAAB999JGHjjf4btRGq5EdTk+Rp8BhEsab7E1e I0ehiMBwYY45o8sdIVLXUReydshRYVxv1kOTr0HekZ2Sn9sV7RWi1/V2zjE1vPxJQPcXNUdf1Gy7 3HTXyJPQYJ70y/Fo6WwJSRuChU/n6eOPP8bXX3+NyMhIjBkzBmVlZaxD0lWEyh6sXr0ac+bMYaNe a9as8brcG5mZmXA4HMjMzPSrbcyNmht9yGrIYp0nY6sRerPeo9BjsFBS5Kmmw5kcbHPYXJa3drZC k6/xiNq402hvZP/OasgSrAUU6shTk70JBouB1eWOEAllt10o7G7pbGGPEVP0EgDeSPhS8mKggUae zO1mlx8wTN5EIN2JgeiHGrmjL2q2XW66a+RJqKDx/knlQf0RFAp8Ok9Dhw7Fl19+iaqqKpjNZvz1 r3/FkCFDgtqoEydOICMjA3379kVGRgYMBoPX5d4YPHgw3n//fb/bzBx0bvRhT/0ethZRTUeN4Lxe wUBJkSfm4eruOHK7gvimQGFguu0A5z5VSuTJXZcbFauzd6/IE+A8RsyPBIaBp4olL8sQaM4TM6+h Jl/jMj9hZXul123UdNQEXL5CzdEXNdsuN2qMPFkdyuq28xdFlipobGzEkCFDsHDhQsTExKCxsdHr cm8sW7YMGzZswLJly3g/t9fXw7J7NzobGnDrjjN2y+CcCuTJi/HYU7+HXT7+/5rRbG/GkxedD7cn L8bDZDO5fC9Y7wOSk0Oiw31HZyfv8gbDUQBAs+E7l+VNhuMA4LHf3N9H/quKXc9oNWLeOS37P/e9 h1PeY3mw37m6BosBtwwG1HfUy6IfzPea7/4BvVnvsnz/pHLJde7PcyaG+nueN+YcY7ejq9Rh2hnn AIL23FNet3P92N+hN+vx+d5X2eMHAHnZO1z+V8p15ut6U4O+nPtdCe+htj8UennZO2BqM/HeF/ZP Kkfvf17ssk5HXR0su3ejzRiaqbO4+CxVUFxcjF//+tc4dcp5w/qP//gPfPDBB4LrB4J76YPRo0fj zJkziI2NRXV1NR5++GGYTCbB5WK3663EArdUAbcbAwAKJhYgsd9EaHgKLm8euRmvxr3qn8EBcOvE iZCHdoU0M8oysL1mO/IeyMOMyBns8mPNx7CgaAH7f+WUSgzrNczj++nF6TjQdMCnfvrl+JB33bnr Lo1Zik8TPsWoS6Nwo+1GyPVDTTC0tT21aJ7W7HtFuJ5zQufJB/Ef4PV7XndZZmozoY+mD4b1Gobt NduRUZYBwFk6IWd8DgBgXuE8AM7SCQaLAdMjp0Pb0zUPUo7rTAnacuvLbbvcpQpCbX8o9OYVzvMa efr5E+/hvwb/V5d1Qj3vruhSBc899xySk5NRXFyM4uJiPProo1iyZElQG/foo49i+/btsNls2LFj B+bOnet1uZS4O06A9y4of2eNDxQl5TwxCcXu3XbuXVtC03uIHbkmlwPB1WUu/lBOzyKX3cHSttgt orvuuOec0PnDl4BusBjY9bmjBZkJpbkvvVkPvVnP2yY15/2o2Xa56W45T75mftg/qbz7d9sVFRXh lVdeYUfFrVixAkVFRZKIc0facf/+3e9+B4PBgGHDhiE3NxcbNmzwulwq3PM/GLiJw+6Y2kzsiWKw OLt3gkE45Dy5J1ULTe/BzXnyhtw5T4Dz+GryNWjtbJVFP9QES1vsPHnMOSfk3AD8OVS5llz2fHMf Lcg4SwzMHIh8uVNqzvtRs+1y091ynrwFHIA7OU8KK1VQW1uLkydP4vDhwzh8+DBOnjzJzjzCh/CU wXdYvnw5tm7dyuYM7dy5Ey+99JIkjRXqQhs1ahRycnJELxe7fV9V0YVqyHgbOWaymdjEWwD4/Yjf Y1bELNFtFItSIk82h41NKHZ3ntwjSvm383m3y5Qq8IUSIk9q0w+W9tmWs3gi6gmP5aY2E8ZcGoPS yaVI6J2AAcnJvNFfLnzOk8FiwOSOyQA8i/IJ/QKmyJNy9OW2XW66W+TJW8ABcN5nHgnRSHWxXLhw AZMnT2YHl9XW1uLChQtITU3lXd9n5Gnz5s1Yt24dhg8fjuHDh0Ov12Pjxo289ZnCnUBG6JjaTNhT v4eNPBXbiqVvGJQTeeJO3uvRbdfB323HHSkFiHeelBB5Upt+sLQZR9pgMbiUs2DOC4PFAKPViMWZ I706ToBztB13O5p8DUxtJpxpOQO9WS96tCCf86Tm6IuabZeb7hJ5auls8VmqBnDeZ9xL3SgBjUbD vnzhM/LU3eawk5ome5OLExEs50nqXwpN9iYMOj8IAFA62Zm3ZbKZXOYg49P05jy5d9uZ283Q5DtP whRtClK0KTBYDKLDtRR56j7aXEeagVvjK9eSi+tt10Xpu9d/4i735Xhx4cudUnP0Rc22y013iTy5 F98VYv+kciQqrNtuypQpKCwsxNmzzu7/AQMGYMqUKYLrK7JUQShpb29HWVkZ27cpNGs8g5jZ5QHl zIKd++9cmNpMHsvPFJ1h222wGHD0ylHozXqfs6yXlpSy32uyN7l8Xmev87pf9GY9dp7fKWo/Tqyb iPTL8aLWk/pdLl0l6P/y3NygbHfwzcHQ5GvY62Ni3UTsqd+D66XXAQDXS69jT/0eUfoWu8VlO4G+ m9vNss9u7+t6U4u+nPudi1rsD5Ze4bVCAOLuM+7Pj4D0CgtRVlYGs7nrhXNjY2ORlJSERYsWYdGi RUhKSkJsbKzg+j5LFaiF9evX472fvif4uWMGeEsVuDOr/yycvv+0hC3rGnqzHqN7j8bSmKUuy/c1 7sOT154EAPazz+o+EywvwGCwGNgh37+M+SV2J+xmP5t+ZbpgkjhBKA1uGQNC5chcqiBc0Jv1eDr6 aST2TXRZbrAY8FDkQ/j+1vd4vPhxUdtyf34EilSlCrKzs3mXu89vJ7pUAeEfRTZpRiK6E2gf9Z76 Pbwl8rlVvZl8LcB1VJS/OU9SV6amnCd1aYdan0bbKUdfbtvlJhxynoxWI3SVOt6RdHqzHuXt5aju EDeNlVIrjDOOUlpamtdJgQFyniSnvqOeN/GcSXANdNoIoT5q7naZGjYMzBNbuXIAAB8HSURBVMS7 fJrc+lSmNhPrTHEjR7w5T53CzpPUtZAo50ld2qHWl2K0nbXT6pF/xSS/+4vceT+U8yQf4ZDzxDhN 7iPpmGdPeVu56GfA/knlLj/EhWBKxQT63Awm5DwFAb5kVmaZUDkEXwj9UuBulxnircnXoL6jnnWI mBOQGZXELOODW17An8hTTUeN5LWQKPKkLu1Q61vsFpfrx2Ax4NaJEz4L/HFptDe6zL/HbEvo1zl3 dKH7Q0Hu6AtFnuQjHCJPjNNktBpdnmPM3+Vt5aITxtMvx4t6XjDXR6DPzWBCzlMQ4KtmzL1pukds xMD3S8F9qDf3RlxkK2JHMrm3DQDvZwDY4d56s56tucMt/CnkPLnX1pECijypS1sOfcbx0VXq2HM+ qyGLvQZ8RZAa7Xfn12S2ZbAYPH6dM10e7j+iuA8FuaMvFHmSD6VHntyvBeZc5/4AuNF+w6/IE9Nt Z243C/5YYVJO3HtVmGVSwu2yEwM5T0GCGwlyHz4tFPUBhLv9+H4peKviWmwr5tVhTkahNjDDvXWV OrbmDjePi+swcf92r+osBRR5Upe23PoGiwH/u38lW7dNKL+DC9d54mK0Gl2iUcx23CNO3IeC3NEX ijzJh5IjT0Izb7hT1lbmV86Txe4sg8T8YBfSZtBV6lwcOLmjUT7rPBGB4c0rNtlMmNpvKu9nRbYi 6M16l3pLgOsvBYPFgNxbuV6ruBbbinmnQWFu1mKiX0wUoNhWjFn9nVXThSJP3PnEpIIiT+rSVoL+ khEfApw8Vu41tm7YOo/1fV1HzEPH27Wqq9RhScwSJFDkSbUoOfIk1kkpbyv3a/aIezv7AHDm2TLP pXXD1rmM6HYnqyGLXUfqyJPQaDshfEaemCriLS0tSE1NRXx8PA4ePBhY6xSI1HWexLy7110yWo24 UHQBAFBQXACDxYDThafZzwHXuhx6sx5Zl7JgtBq91lUytZk8lvc394euUudXvaFiWzHbDk2Fhv3c 5rBh0pFJMFgMqLteJ9n+cdeXertK1VWCfrDqPIWrvqbC2aWXdSnLow4aANw03fS5XV2lzuW64Xs/ euUo1XmSyW4uarFfjJ7FbmHv72Kun/K2cmjNWp/rAc7rzNppRUlJCfJv57PXyTv570Bv1gt+7/RV 53ORqRcoZZ0nZoQd9+UNn3WetFotLBYLsrKy8Omnn+LNN9/EqlWrkJeX1+XGKgmp6jyJ4dW4V7F5 5Gb2f71Zj7SBaZjVfxbb1fdpwqcetZkAePXKuczqPwvWTisutF7ocnufGfwM/jLmLwCAxdcWY3/j fpfPU7QpKGgtkLxUAUEojeqp1YiNuFs4b2fNTiwvW97l7S6NWYpPEz7t8nYAsPeQnPE5HhFsQgCq 8+RBobUQEwomiF5/YM+B6HB0oKWzRdT6UT2j0DitEcMvDhecBNwXjukOyeo88ZGdnR14naeePXvC brfj7NmzmD9/PmbPno2iouDUMlILpjaTS07Envo97LQuRVbnvnWvzcSdbV4MRbYir7lVYmDyT7hT zvANLzVYDEFxnCjnSV3a4aDvPjBCKOfJX5iRfmLWM1qNHiOeGLiTKvu6V7gn4VLOk3woMeeJrw6a N5rtzaIdp/TL8bjdeRt6sz5gxykUeIs++XSexo4di/z8fBgMBkydOhURERGw2+2SNlBtmGwmNoGU SYJjHBTm3b0/d0Bysl9DqOs76gMa1ceFyT8RShgPNpTzpC7tcNB3HxghNsfDF6Y2E7T957okmQN3 B55wX1kNWchqyPIYvceMGmTgG6HEhXG0mNG0lPMkH0rMeQqmU7N/Ujk6HB1+zUUZbPhynrzlQflM GF+zZg2efPJJPPTQQ0hJSelS4wgnpjaTRwIpE3FiHBWmNhPD/9X9CYcm3wxdI+H8dbB/Ujk7AjBF myKqsJnU+qFGLl0l6KvZdjH67gMjpIo8cbW5DxS+hwt3Am6+0bxcfH0OOO85syJm4daJE7I5MXJq K4FA7Te3m3HVetXv7lkxesF0nuS+zoXwJ2ncp/P01FNP4amnnnJZZrFY/G8VwdJkb/KI4BTbimGw GFxqKnF5I+FLVNeLGwYqFdyTmxkBGErniSJP6tIOB333yFNjh3TOE1fbm8MTSPVybzCjaSnyJB+B 2n+m5Qw2Vm3023kSo1fRXhFQm8Qg93UuhHs3nTdniuo8KQSmRIEQA08VS37T9AU3/4PpAgh15EkO lJ530121w0E/WDlPYrSDBZMq4J4Hwy3uG2wo5ykw+5lh/sysElLqBTvypDT48pu6lPPU3ZGjVAHf +7CqYV6HhF4bFhVUfb73/ZPKPYZcj6sdJ5t+d9dVgr4c51k46cdVxaG+o54d0t3f3F8yfbmOe5G1 CCUlJRiQnMzalV+UD12lDjvP74TerMekI5N4SzVI9V4dHx+U7YZLqYJA7b9ech3AneNoK5JUz9xu Vvx1LmWpAn8RXarA17JwJ5SlCgJBjj5iufulKedJXdrhon/6/tNs0dgHCh7Av63/Dpl2MJjVfxZO 33/aJQ/mQNMBpBen865fOrkUCb0TJG2D7DlPEpYq0Jv1eDr6aST2TRT9nUDt5w7z/8uYv+CZwc9I pjehYAIKrYV+t0kMUp3rUpYqEOqiC7hUgTtXrlxBZGRkAE0juoIcN1W5+6Up50ld2uGizy3dIWW3 nVy2MykDH9yXwy4723JWcP1gdOX56zi4jyRkSjjIjdhpfdwJxHEyWo0uXWvc8zJQPWbUZrBLCMh9 nfPBFMYcM2YMoqKiMH/+/MC67bRaLVtdnPlbq9UiJSUFK1askL7lhFfk6COWu1+acp7UpR0u+sFy nuSyvb6jHrpKHc4e+YR1jPJv5wuuz9SgY0onCMF1cHxNsuxvzg9TZoF50DMlHPja4F7+ga99zDbF 1NFzLx3h/hngOh2PmO0GkvPkbi8zYlsM7nrMfmIGKugqdezcc8FA7uucj9bWVpw5cwZ1dXUYO3Ys Ll68CKvVKrh+QN123RGld9sRBKEMmIr7RqsREwsmyt0cSUnRpiBnfI7Xqs8JvROwdMhS15IKw3Ue c//NK5znOrGr2zrMHJ3cZexk6nfWZb7PjCbjFgF1J7FvIgomFrDrMRrMNtz1mfbphuuwbrjO6/2d 2a4/x1s33NlO9/a6tyPQivATCya6OKRM9yt3u3MHzBW1TfdjFS5I2W13/PhxjBkzBmPGjIFGo0Fr aysKCgowY8YMl/WYbjtynu6gdOeJcp66v64S9NVsu1h95iHl7UEeLO1gIoU+4xjw7RuucwO4Oi+r iubhg/tyPBwy5oGeMz5H8v3Nxdf9XcgRkor0y/FofmQccsbn+F4Z/NN0DY4YjLqpdS77KUWbghRt yt2I0p3jk3dkJw5Nvil4rIKNEnOebt++jf79+7ssa2trQ+/evV2WiXae1ILSnSeCIJQB85By/+VP CGCNBObcBk73hm7UWwCC54QEiq/7O5P8HezjXTCxQFSieVciRYxTGo6RJnfCKmEcAJsLRYQOynnq /rpK0Fez7WL16zvqocnXSP4gDQfbA+LiI873irGCFc9lsT0/BZjhAG4P9LkqM59gsGDsF0o0Z+Yy ZBK6u+L46Cp1GHhKfHJ5MJD7XBeCcZSY5HFvUJ0nhdR5UmL9G7XWO1Kr3YDy6yx1Z/1ue97lp2Di xBKg/F7l7PeaKcCLOZg4/TJw4gkwyH3enb7qzFlyr7v0TcE3zlF8l7Ik1ZPb3q5uR3F1nrh5TkJR pu6WB6X0bjvKeer+ukrQV7Ptcut3W9t/9U+gKQZ4aifwXx+GVluIa5OAN/cA//0OcOxpOHKfVMz9 nUkc5ybUS91F3F3ONam77dLS0th37jIuXUoY745J5Ep3ngiCIMKG/BTgRU7yc8ZqoGY48IZCytwc +Rlw/CfA2ueBuU1wQAPN4aFATGgnX+eDGfEYriPgQomUzpNYupTzRIQeynkKAXVDgRkOpD+Z68yF +FjnfK8bGtJmhMTuO7a653uo7pgrSL/b2H57oNNx2jkPOKNxvsZfAMqFByWF3PbSRGCsEejf7Gwf APzv/wttGzi4zyOqOREFw4QcpxMaZD05kFufj+zsbN6XED6dJ74Ik1xRpxs3biA1NRUxMTFITU1F ebnyqpQGi7CrMM4kY3bh4ufVZ7YrdtvM+mIcoP/9f8AzG7F/71znjf/jdcD9Z53L/dlOF/Gwm3F0 pNRmHhScfA9e7RCjOn3m2OandB/bTzwBzN0HTDfcXRZ/Dbg+PvjaYilJBMa4dYP99fWgOSu+8LD/ xBPAgCanE9rF+6govRATDP1vMjLQ1AWfgEkSnz9/Pvu/N8Iq8rR69WrMmTMHFRUVmDNnDtasWSNf Y7gPcW6UQujFnPx8ToWQo8FZ7pen7t42MVo8pB9YIPx9Pnu5Nv5PFvCC3vnOrOu+D7y1Iz/lbgSI WY/Z7s55zhdzYxE6Bh/rnOvffxZ49aDnttzb/9fXgef+6NzX0w3OX6QfPu5c/mLOXUdKKrjHgnus 3fc7o8m8cx64Aev+9XVg5a+BY0+7fCTrqKePdZ5RPykfHN6uvTuv9AMLvK/P971A2sd8/9WDzvPq f7Kc2iKvDdHtcr9e3a9FDh7HXsR9iXedY08Dj2W5fmdECVAxVtCmoJ13QjaUTATuLXBdxr2nBMuJ 4rvvcKPdzOsP24D/yXDeg9zvde73Ob62cu8RPOeU3JGfYOiXGAz4bPFinNq+HR1eKoN7o7W1FRcv XkTPnj3R2NiIiIgI4ZXPnTvnOHfunMNisfC+zp0755g3b56jX79+jsjISEdqaqrj/PnzgusH8zV4 8GDHtWvXHBaLxXHt2jVHTEyMZNt+4403HM6ZIflfDsBz+c4UB87A+c793/3FfM68XtB5botvmbfl vl7ubQt0m97ayrXXXcdd3307O1P42+bLBl/7mO+YHB7Krym0LaEXdztijrOYfSrmbzgc+GLa3b/v z3e+AjkvuLbnDuzaNvjaGej5yj2nuMdO7D7tyvkc6LXS1fYx2z481PO89LVdf9rFrOv+Huj+cl/O t07uwMCvj0Bs9tYeoe+d7sW2zQGBdno7N3y1j3scuJ/5uu8w3/G2D7ntGlTjuc1nPnC9RwidU2Lu 5WLv93zXrdA+ENoXQvdngWesw+Fgn+G6UaPY16akJMeFb7/1ywe4ePGiY+/evY68vDxHaWmp4+uv v3bk5+d7rLd7927H7t27HT4TxmfPno2f/OQnWLZsGQBg586d2Lt3L77//vuAPLuuEBUVhYaGBqSl peEf//gHYmJi0NgY2NxShYWF+OKLL+Cw2dBhMuFSfT2mjhmDnkOHwn7zpsf7j/Py8O3MmYKfB/vd 0doKTb9+IdVtu3QJvSdPlsVeOfW96dZgGK6cqIbp9nAk9K/0eH8gOQ6xMAtun/m+t/XE6P/HE3Ho 3SSsE4rzrO5qFfb/EI/02eWImXCPx//hcp4rRV+t15uY/e7tuuGed+1RQ31eX3zvfPd3ZrvM9e3t vHZvH/c+MTexArnGEV6/35Xzzr2dzPvPHytHv5HCek1tkdj/QzzbPr77GGPHoPuGorHopsv23a/7 hP6VLutxt8ssZ7bL1XdvN/c4cpe7tzMxthIPLxiIDpMJPePiEHXs2F1fIT4e83/zG4xNSRHtE+Tn 5+OBBx5AZGSk1/VEj7aLjY1FRUUFW6LcZrNh5MiRqK6uFt0oqRg9ejTOnDmD2NhYVFdX4+GHH4bJ ZJJk2+vXr8fbb78t+Ln1hx/Qd/ZsSbQCQQ59Ndosp64S9NVsu9z6ZLs6bZdDvzva+8HEiYjo2xcz //u/8fDzzyOib19Jt88gerTd8uXLsXXrVlgsFlgsFmzZsgUvv/xyUBrli0cffRTbt2+HzWbDjh07 MHfu3JBptxeJn7G6u+ir0WY5dZWgr2bb5dYn2+VDbfrd0d6xc+di6d69mJ2RETTHiYtgkUxfyDHi rqysDEuWLMGFCxcwbdo0ZGZmYuTIkZJs21fkyV5bi55DhkiiFQhy6KvRZjl1laCvZtvl1ifb1Wm7 HPpqs1dKaGJgN4xGIxITfU/ISBAEQRCEOqEimW6ozXGiyZ2JUKDVatkXQRChga634EPOk4TI+aDg aoeqDVqtFlu2bAEAfPTRR7LYbTQaodVqYTQGb8ZzPpRgu1LON28wuZJSI9dxB4BTp04hJSUFMTEx mDJlCv72t7+FRNdkMiElJQWDBw9GSkoKysrKfH5HynNDq9Xiww8/dPk/VGi1WgwcOBDjxo3Dr3/9 a7S2toZMm9sGJVxvdH9XBuQ8SUiwHhT+6oeyHZmZmXA4HMjMzAyJnjtHjx5Fjx49cPTo0ZBry227 nOeb3Oe6nMf92WefxbJly1BeXo5vv/0WOTk5IdH9zW9+g8cffxxmsxlpaWn4zW9+ExJdLpmZmSGf S4yhqakJubm5qK+vx9q1a0OuL/c5T/d3ZUHOU5BhfiVER0dj9uzZ7I1Wq9Vix44dGDVqFEaOHBm0 k7OwsBCPPfYYBg8ejGnTpuHkyZPsZ2vXrkVcXBymT5+O/Pz8gLY/ePBgvP/++xjCSf4Tspn5bO3a tbjnnnuQlJQUuGF3OHbsGH7xi1/gGKfGh1arxZo1axAbG+thm5T6/tg+b948fPfddwCAv//971iw YAHvNruK+69D5v9QnG9C2sFA6Ljz6Z89exYzZsxAbGws1q1b1+V29e/fH2VlZbh06RJiY2Pxpz/9 CYDwtebtfPSH77//Hs8//zz69OmDZcuWsbX2Lly4gDlz5mDQoEEutnGPvVTH4plnnsG2bdtclv3r X//CzJkzER0djZkzZ+Jf//oXACApKYk9/7/77jvMmTOnS9oajQYjRozA+vXrsXfvXgDC+1xon0gN 3d+77/3dF+Q8BRnmV0JtbS02btyIF154gf0sIiICV69exe7du7Fu3boua/GFdX/1q1/hhRdegNls xvvvv4+MjAx2/bFjx+L69etYuXJlwOUnli1bhg0bNrBFVAHvNgPO2mGlpaWYOXNmQJoMLS0tyMvL w9tvv428vDy0tLSwn40bNw5lZWVYuXKli81S6vtje0ZGBj7//HMAwIcffojXXnutS9qBIPX5Jhfe jjsfGRkZeOmll3D9+nWMHTu2y/pff/01qqqqsGrVKkyYMAF79uwB4P1a83Y+iqW5uRmDBg0CAERH R6OpqQmAs5zMs88+i6qqKpeIBPO3lJGK5cuX44svvmC1Aef+XbFiBSorK5GRkYFXXnkFgDNCx5zz n3/+OZ599llJ2jB06FDU1tYCEN7nQvtEauj+3n3v776g0XYSY7fbXSqf79q1C5s3b0Z5eTk6Ozuh 0WjQ3NwMrVaLhoYGdu4crVbbpYtc6PvR0dHo6Ohg/+fqV1dXo1+/fmhtbcWIESNQX1/fJU3mfyGb mXXq6+vRq1evAC29S3Z2Np5++u7cbFlZWUhLS/Nqm1T6/tre0dGB6dOnQ6/XY8OGDcjLy4NGo+lS GwDP843bro6ODkRHR8NisUh+vvmjLZUeg7fjzqcfHR2NyspK9nyIi4uTrC0FBQV4/PHHYTKZgnqt AcDIkSNx8eJFREdHo66uDg899BCuX7+O6OhoVFRU8FZGlnK/M9vatGkTLBYL/vjHP8JisWDQoEEw m83o168fWlpaMGLECDQ0NKChoQGTJ0/GyZMnkZSUhMuXL7POX6DaAFBRUYGUlBQUFRUJ7nNv+6Qr 0P1dHfd3b9BoO4lZs2YNmpubcfz4cZfaU6tXr8bmzZtx8+ZNfPXVV3A4HOxnXicdlIipU6ciKysL NTU1sFgs7EkOOE+C1tZWfPXVVxg/XnjGc3/xZjMAyU7so0eP4re//S0sFgt++9vfuvSLc21z/2EQ zAtLyPaIiAgsXboUL774IlasWNFlx0nofIuJicHx48dhtVrx2WefuXxHqvMtEO2hQ4fi/PnzkugL HXch/QkTJuDLL79Ea2sr/v73v3dZf9myZSgtLYXNZoPRaITdbgcg/loL9Ifq7Nmz8ec//xk2mw2f fPIJ2y0xYcIEfP7552hra/P4Tu/evUUllvvDiy++yEbbAOcPb8a+PXv2sPZFR0fjsccewy9+8Qss WLAgYMeJweFwoLKyEjqdDunp6QCE97m3fRIIdH+/i5rv71zIeZKI4cOHIzExES+++KJLiHbVqlX4 5S9/ifvuuw9XrlwJebt27dqFLVu2YOTIkR65D4WFhRg1ahQ2bdrkkcfQFUJl89GjR7Fw4UIAwMKF C10uLq5tW7duDVob3PFm+5IlS9C3b1/89Kc/7bKO0Pmm0+mwZMkSjB8/nn2oS00g2qtXr8aiRYsk yT8ROu5C+tu2bcOWLVswatQoXL16FT16dO22N2/ePCxevBhDhw7F73//e+zYsQOA+Gst0PPx3Xff xYEDBzBs2DAcOnQIv/vd7wAAO3bsQGZmJmJjYz327wsvvIDp06dLmvcTGRnp0o2zdetWfPTRRxg2 bBi2bt3qYt9zzz2H8+fPS9JlFxUVhUcffRQDBgzA+vXrAQjvc2/7JBDo/n4XNd/fuVC3HdHtkLKr Qio6OzvxySefoLS0FO+++67czVElnZ2dOHToENatWxdwAm0gKPF8JIhwRe7riem2C35ckSAIREVF YcqUKfjmm2/kbooq0Wq10Gg0SEhIkPRXOEEQ6oScJ6LbocRf+Upsk5qQuz4PQRDSoJTriXKeCIIg CIIg/ICcJ4IgCIIgCD8g54kgCIIgCMIPyHkiCIIgCILwA3KeCIIgCIIg/KBLo+3EFB9TSma8HIip RxHqmhVy18ggCIJQCvQM844Sn2FKoeulCs54+WyGuE2kpKQAAAwGQ1dbE3YInXTBOiHVeJITBEEI 4/DymbhplOgZ5omSnKpgtEX2Ok/V1dW4du0aAKCmpgaxsbEyt4ggCIIgxEHPMHUie87TkSNHMH/+ fMybNw9Hjhxhl0+fPh0XL14EAFy4cAHTp09nP7t58yYWL16MmJgYTJs2DSdPnnTZplarxdq1a3HP Pfewk2cyy7VaLaKjozF79mzk5OSwn127dg1JSUmIi4uDTqdzCef60vPGunXrEBcXh9mzZ6O4uNij Le5hY+4yvs/37duHGTNmIDo6mvdzIYT0mM927tyJUaNGYfTo0ZJMnkoQBKEG6BkWmmdYUVERkpOT MXjwYCQnJ6OoqMhF070NYtrSFWR3nrKzs5GWloa0tDT84x//YJenp6ezJ+KRI0fYWbQBYOXKlXjm mWdQWVmJ999/HxkZGbzbvnbtGmbOnMn+b7FYYLFYUFtbi40bN+KFF15gP1u1ahXS09Nx48YNjx0s Vo8PrVaLGzdu4KmnnsKqVas82uIOdznfOi+99BK2bNnCzqItNhTpa93Gxkb8+9//xqZNm7B27VpR 2yQIglA79AxzJVjPsNdeew3p6ekwm814/PHH8dprr/n8jq+2dIUuTQys1Wp95jx5a2x7ezvGjBmD CxcuAACmTp2K0tJS9OrVC+fOncMbb7yBo0eP4rHHHsMf//hHPPjggwCAe+65By0tLXeN0GjQ3Nzs 0i6z2YwBAwa46B0+fBhvvfUWiouLYbfbXb4XFxeH4uJiDBw4EBaLBcOHD2fb7kvP2/6prKxk+1vH jRuHqqoqj3X49pHQ8h//+Meoq6tDSkoKpk+fjh/96EeIjIz02RZv29VqtaiqqkJkZCTsdjuio6NF 2UcQBBHOOJ0M7zlP9AxTxjMsLi4O165dg1arRXNzM8aNG4fq6mpeLV//dwVmYmBZI08nT55EU1MT EhISkJCQgKamJjac+OCDD6KqqgqlpaWoqqpiTzoA6NGjh4vXyncSuJ90APDyyy9j3bp1qK6uhtls hsPh7aK5ixi9UPHNN99Ar9dj8ODB2L17NxYvXizJdpmTt2fPnqL3C0EQhJqhZ5j/BPoM82arRqOB 3W4HABcnMZjI6jxlZ2dj7dq17AF96623cPjwYfbzH/3oR3jzzTfx+OOPu3xv3rx52LBhA27fvu2X ntVqxZAhQ9DW1obf//73Lp/Nnj0b27dvh81mw65duyTRA4Bdu3ahra0Nu3btwiOPPCL6e5GRkbhy 5YrH8l69emHhwoV4/fXXsXr1at51CIIgiOBDzzBhpH6GzZw5E7t27YLNZsPOnTtdujPj4+Oxb98+ tLS0YNu2baLb0hVkd54WLlzI/s/XZ3zo0CGXvmIA+PDDD1FcXIwxY8b4lQT27rvv4mc/+xkeeOAB xMfHu3z2wQcf4MCBA4iPj8etW7fQo8fdXROoHgA0NDRgxIgR+Oqrr/D++++zy30lsmVkZGDu3LmC yXgxMTF49dVXsWPHDlHtCGbiHEEQhBqhZ1jonmGbNm3C119/jaFDh2Lfvn3YuHEj+5lOp8PKlStx //33Y9CgQR7fFWpLV+h6zpMPlFLnQSydnZ04dOgQ1q1bh/z8fLmbQxAEQQQJeoYR/sLkPHWpzlO4 nVS+0Gq10Gg0SEhI4A39EQRBEN0HeoYRgSJ7kUwl0d0uJIIgCEI90DMsdMhe54kgCIIgCCKcIOeJ IAiCIAjCD8h5IgiCIAiC8ANyngiCIAiCIPyAnCeCIAiCIAg/0Jw7d87R1NSEkpISudtCEARBEASh eHqQ40QQBEEQBCGe/w/8vOvBwDNk6AAAAABJRU5ErkJggg== --Apple-Mail-16-564508345 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > At the moment, most of the traffic seems to be peer-to-peer file > sharing. This type of application can probably benefit from the > additional paths provided by 6to4 relaying. > --=20 > Simon. Begin forwarded message: > From: "William F. Maton Sotomayor" > Date: April 17, 2011 1:38:52 PM PDT > To: Simon Leinen > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? > Reply-To: wmaton@ryouko.imsb.nrc.ca >=20 > On Sun, 17 Apr 2011, Simon Leinen wrote: >=20 >> William F Maton Sotomayor writes: >>> Given the talk of moving 6to4 in the IETF to historic, I was >>> told that it may be a good idea to share some stats of what one = public >>> 6to4 relay in Canada is doing. Originally this page was meant to = get >>> the institutions listed moving with IPv6 adoption, rather than >>> languishing with tunnels and inviting (erroneous) criticism over = IPv6. >>=20 >>> http://stats.ottix.net/ipv6/ >>=20 >> very nice, thanks! >=20 > Thanks SImon and for the grpahs as well. I have data stretching = further back for the tunnel interface itself which I've been thinking = bout how to make more public, aside from the graph there now. Since I'm = now responding to this, I suppose I'll end-up finding a way to do it = anyways. >=20 > It's a pity that 6to4 deprecation is being discussed within the IETF = at the moment, because I would like to see the issues fixed instead = throwing the thing away (whatever that degree may be). It's worked for = us and for the other R&E networks thus far so I'd hate to see the OttIX = one go. >=20 > wfms Begin forwarded message: > From: Nick Hilliard > Date: April 17, 2011 1:48:54 PM PDT > To: wmaton@ryouko.imsb.nrc.ca > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On 17/04/2011 21:38, William F. Maton Sotomayor wrote: >> It's a pity that 6to4 deprecation is being discussed within the IETF = at >> the moment, because I would like to see the issues fixed instead >> throwing the thing away (whatever that degree may be). >=20 > It's not a pity, really. The protocol is terminally broken because it = cannot work around return-path blackholing. >=20 > We need to move beyond 6to4. Static tunnels work, as does teredo. >=20 > Nick Begin forwarded message: > From: Mikael Abrahamsson > Date: April 17, 2011 1:59:18 PM PDT > To: "William F. Maton Sotomayor" > Cc: Simon Leinen , ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On Sun, 17 Apr 2011, William F. Maton Sotomayor wrote: >=20 >> It's a pity that 6to4 deprecation is being discussed within the IETF = at the moment, because I would like to see the issues fixed instead = throwing the thing away (whatever that degree may be). It's worked for = us and for the other R&E networks thus far so I'd hate to see the OttIX = one go. >=20 > The proponents for deprecating 6to4 doesn't want to kill 6to4, just = want to have vendors stop enabling it by default. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se Begin forwarded message: > From: JORDI PALET MARTINEZ > Date: April 17, 2011 2:00:37 PM PDT > To: > Subject: Re: 6to4 stats found, are there other places? > Reply-To: jordi.palet@consulintel.es >=20 > It will be important that you then voice up your opinion in v6ops. >=20 > I'm just having this discussion because they are trying to kill it. = Yes, > the argument is "is not killing it, but making it off by default", but > this is not what the vendors will read. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 >=20 > -----Mensaje original----- > De: "William F. Maton Sotomayor" > Responder a: > Fecha: Sun, 17 Apr 2011 16:38:52 -0400 (EDT) > Para: Simon Leinen > CC: > Asunto: Re: 6to4 stats found, are there other places? >=20 >> On Sun, 17 Apr 2011, Simon Leinen wrote: >>=20 >>> William F Maton Sotomayor writes: >>>> Given the talk of moving 6to4 in the IETF to historic, I was >>>> told that it may be a good idea to share some stats of what one = public >>>> 6to4 relay in Canada is doing. Originally this page was meant to = get >>>> the institutions listed moving with IPv6 adoption, rather than >>>> languishing with tunnels and inviting (erroneous) criticism over = IPv6. >>>=20 >>>> http://stats.ottix.net/ipv6/ >>>=20 >>> very nice, thanks! >>=20 >> Thanks SImon and for the grpahs as well. I have data stretching = further >> back for the tunnel interface itself which I've been thinking bout = how to >> make more public, aside from the graph there now. Since I'm now >> responding to this, I suppose I'll end-up finding a way to do it = anyways. >>=20 >> It's a pity that 6to4 deprecation is being discussed within the IETF = at >> the moment, because I would like to see the issues fixed instead = throwing >> the thing away (whatever that degree may be). It's worked for us and = for >> the other R&E networks thus far so I'd hate to see the OttIX one go. >>=20 >> wfms >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 Begin forwarded message: > From: Fred Baker > Date: April 17, 2011 2:48:58 PM PDT > To: wmaton@ryouko.imsb.nrc.ca > Cc: draft-ietf-v6ops-6to4-advisory@tools.ietf.org, = draft-ietf-v6ops-6to4-to-historic@tools.ietf.org, Simon Leinen = , IPv6 operators forum = > Subject: Re: 6to4 stats found, are there other places? >=20 >=20 > On Apr 17, 2011, at 1:38 PM, William F. Maton Sotomayor wrote: >=20 >> It's a pity that 6to4 deprecation is being discussed within the IETF = at the moment, because I would like to see the issues fixed instead = throwing the thing away (whatever that degree may be). It's worked for = us and for the other R&E networks thus far so I'd hate to see the OttIX = one go. >=20 > There are actually two things under discussion in the IETF. Brian = Carpenter wrote a document on how to fix 6to4, and Ole Troan wrote a = document suggesting that RFCs 3068 and 3056 be "off by default". >=20 > I think it's at least fair to point out what "deprecate" or "move to = historic" means in the IETF environment. When the Internet moved from = classful addressing to CIDR in the early 1990's, the IESG "deprecated" = RIPv1, moving it to "historic". We (I include myself as I was on the = IESG at the time) had no expectation that this would mean people would = stop using RIP, or that manufacturers would change their products. It = meant that RIPv1 didn't address the needs of the growing Internet, and = was not something the IETF found useful to continue enhancing. RIPv2 = came along a couple of years later, and included several important = changes - it moved from broadcast to multicast, it carried a prefix as = opposed to a classful address, and it dropped the aggregation algorithms = RIPv1 used across classful address boundaries. >=20 > In the IETF, we have a fair bit of evidence that 6to4 isn't all its = cracked up to be; take a look at Geoff Huston's discussion, in the = IETF-80 proceedings. Basically, he's looking at darknet data, and finds = 6to4 and Teredo traffic there, which says that at best the protocols = send traffic to places its doesn't intend, and at worst they are = components of or carriers of attacks of various kinds. >=20 > What I understand the two drafts to be saying is > a) if someone is using 6to4, they should be doing so intentionally, = not by accident (troan) > b) They should do so in ways that work (carpenter) > c) As IPv6 deploys in native space, transition technologies in general = and 6to4 in specific should atrophy. >=20 > Commentary from the operator community would be interesting and = helpful in the IETF discussion. >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory > "Advisory Guidelines for 6to4 Deployment", Brian Carpenter, 31-Mar-11 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic > "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to > Historic status", Ole Troan, 5-Apr-11 Begin forwarded message: > From: Martin Millnert > Date: April 17, 2011 5:26:06 PM PDT > To: Mikael Abrahamsson > Cc: Simon Leinen , "William F. Maton = Sotomayor" , ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On Sun, 2011-04-17 at 22:59 +0200, Mikael Abrahamsson wrote: >> The proponents for deprecating 6to4 doesn't want to kill 6to4, just = want=20 >> to have vendors stop enabling it by default. >=20 > Mikael, if that is the case, I suggest that they double- or = triple-check > http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html = before > any mistakes are made wrt. publishing the draft as-is. >=20 > Regards, > Martin >=20 Begin forwarded message: > From: Doug Barton > Date: April 17, 2011 5:31:09 PM PDT > To: Mikael Abrahamsson > Cc: Simon Leinen , "William F. Maton = Sotomayor" , ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On 04/17/2011 13:59, Mikael Abrahamsson wrote: >> On Sun, 17 Apr 2011, William F. Maton Sotomayor wrote: >>=20 >>> It's a pity that 6to4 deprecation is being discussed within the IETF >>> at the moment, because I would like to see the issues fixed instead >>> throwing the thing away (whatever that degree may be). It's worked = for >>> us and for the other R&E networks thus far so I'd hate to see the >>> OttIX one go. >>=20 >> The proponents for deprecating 6to4 doesn't want to kill 6to4, just = want >> to have vendors stop enabling it by default. >=20 > In some cases that's true, however some (including me) want to kill it = outright. Unfortunately that's not the opinion of even a substantial = minority of the WG however. >=20 >=20 > Doug >=20 > --=20 >=20 > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go >=20 > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ >=20 Begin forwarded message: > From: Ole Troan > Date: April 17, 2011 11:33:01 PM PDT > To: jordi.palet@consulintel.es > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > Jordi, >=20 >> It will be important that you then voice up your opinion in v6ops. >>=20 >> I'm just having this discussion because they are trying to kill it. = Yes, >> the argument is "is not killing it, but making it off by default", = but >> this is not what the vendors will read. >=20 > "they"? I thought I saw you in Prague? ;-) >=20 > at the IETF80 we discussed a two pronged approach: > - make 6to4 historic. provide a statement that can be referenced in a = standards document that 6to4 should be off by default. > - 6to4 advisory. as it will take some time before CPEs and host = implementations are upgraded, encourage operators to > do what little is possible to improve 6to4. >=20 > are you arguing that I should go back to our consumer products = (Linksys) people and ask them to enable 6to4 by default again? > I'm not pretending to speak for all vendors (not even the one I'm = working for), but if you are trying to create a scare that vendors will = remove 6to4 from their code base, then a couple of data points is that = NAT-PT and Automatic tunnels (from rfc1933) are still in IOS. >=20 > as there is considerable statistics from people like Geoff, Tore, = Emile, showing how badly 6to4 performs, I think for you to argue against = making it historic, you should show that they are wrong... or show us = how it can be fixed. >=20 > please read rfc5218. a protocol that requires every other remote = network in the Internet to upgrade or change their behaviour has little = chance to succeed. >=20 > cheers, > Ole >=20 >=20 >=20 Begin forwarded message: > From: JORDI PALET MARTINEZ > Date: April 17, 2011 11:37:38 PM PDT > To: > Subject: Re: 6to4 stats found, are there other places? > Reply-To: jordi.palet@consulintel.es >=20 > Hi Ole, >=20 > If the problem is filtering, as expressed by Geoff, then we should = kill > any protocol that can be filtered ? >=20 > I'm not going to repeat myself here, and I'm not the only one = objecting to > this document in v6ops, so there is no consensus. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 >=20 > -----Mensaje original----- > De: Ole Troan > Responder a: > Fecha: Mon, 18 Apr 2011 08:33:01 +0200 > Para: Jordi Palet Martinez > CC: > Asunto: Re: 6to4 stats found, are there other places? >=20 >> Jordi, >>=20 >>> It will be important that you then voice up your opinion in v6ops. >>>=20 >>> I'm just having this discussion because they are trying to kill it. = Yes, >>> the argument is "is not killing it, but making it off by default", = but >>> this is not what the vendors will read. >>=20 >> "they"? I thought I saw you in Prague? ;-) >>=20 >> at the IETF80 we discussed a two pronged approach: >> - make 6to4 historic. provide a statement that can be referenced in a >> standards document that 6to4 should be off by default. >> - 6to4 advisory. as it will take some time before CPEs and host >> implementations are upgraded, encourage operators to >> do what little is possible to improve 6to4. >>=20 >> are you arguing that I should go back to our consumer products = (Linksys) >> people and ask them to enable 6to4 by default again? >> I'm not pretending to speak for all vendors (not even the one I'm = working >> for), but if you are trying to create a scare that vendors will = remove >> 6to4 from their code base, then a couple of data points is that = NAT-PT >> and Automatic tunnels (from rfc1933) are still in IOS. >>=20 >> as there is considerable statistics from people like Geoff, Tore, = Emile, >> showing how badly 6to4 performs, I think for you to argue against = making >> it historic, you should show that they are wrong... or show us how it = can >> be fixed. >>=20 >> please read rfc5218. a protocol that requires every other remote = network >> in the Internet to upgrade or change their behaviour has little = chance to >> succeed. >>=20 >> cheers, >> Ole >>=20 >>=20 >>=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 Begin forwarded message: > From: Ole Troan > Date: April 17, 2011 11:48:10 PM PDT > To: jordi.palet@consulintel.es > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > Jordi, >=20 >> If the problem is filtering, as expressed by Geoff, then we should = kill >> any protocol that can be filtered ? >=20 > filters are just one among many problems. > please read = http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-00 >=20 > bad performance, high latency, packet drops and blackholes unrelated = to filtering are the ones I've seen and experienced. >=20 >> I'm not going to repeat myself here, and I'm not the only one = objecting to >> this document in v6ops, so there is no consensus. >=20 > apart from "I disagree", it be fruitful if you could provide = arguments. >=20 > in the meantime I suggest you sit yourself behind a Linksys WRT610N = (with current firmware - 1) and a Mac OSX <=3D10.6.4 machine use the = google whitelisted DNS server from HE and enjoy 'the web' for a while. = even better enable, make sure you are behind a NAT and enable 6to4 = locally on the OSX box... ;-) >=20 > cheers, > Ole Begin forwarded message: > From: JORDI PALET MARTINEZ > Date: April 18, 2011 12:02:20 AM PDT > To: > Subject: Re: 6to4 stats found, are there other places? > Reply-To: jordi.palet@consulintel.es >=20 > As said in v6ops, I have been traveling heavily the last 10 years, and > using an average of 30 networks per year and have 6to4 enabled by = default > in my Mac (previously it was and XP for the first 5 years), and my = failure > rate is below 1%. >=20 > Statistically it is impossible that it just good luck for me ! >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 >=20 > -----Mensaje original----- > De: Ole Troan > Responder a: > Fecha: Mon, 18 Apr 2011 08:48:10 +0200 > Para: Jordi Palet Martinez > CC: > Asunto: Re: 6to4 stats found, are there other places? >=20 >> Jordi, >>=20 >>> If the problem is filtering, as expressed by Geoff, then we should = kill >>> any protocol that can be filtered ? >>=20 >> filters are just one among many problems. >> please read = http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-00 >>=20 >> bad performance, high latency, packet drops and blackholes unrelated = to >> filtering are the ones I've seen and experienced. >>=20 >>> I'm not going to repeat myself here, and I'm not the only one = objecting >>> to >>> this document in v6ops, so there is no consensus. >>=20 >> apart from "I disagree", it be fruitful if you could provide = arguments. >>=20 >> in the meantime I suggest you sit yourself behind a Linksys WRT610N = (with >> current firmware - 1) and a Mac OSX <=3D10.6.4 machine use the google >> whitelisted DNS server from HE and enjoy 'the web' for a while. even >> better enable, make sure you are behind a NAT and enable 6to4 locally = on >> the OSX box... ;-) >>=20 >> cheers, >> Ole >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 Begin forwarded message: > From: Mikael Abrahamsson > Date: April 18, 2011 12:31:48 AM PDT > To: JORDI PALET MARTINEZ > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On Mon, 18 Apr 2011, JORDI PALET MARTINEZ wrote: >=20 >> I'm not going to repeat myself here, and I'm not the only one = objecting to this document in v6ops, so there is no consensus. >=20 > If 20 people support it and 3 object, that is consensus. >=20 > >=20 > "Working groups make decisions through a "rough consensus" process. = IETF consensus does not require that all participants agree although = this is, of course, preferred. In general, the dominant view of the = working group shall prevail. (However, "dominance" is not to be = determined on the basis of volume or persistence, but rather a more = general sense of agreement). Consensus can be determined by a show of = hands, humming, or any other means on which the WG agrees (by rough = consensus, of course). Note that 51% of the working group does not = qualify as "rough consensus" and 99% is better than rough. It is up to = the Chair to determine if rough consensus has been reached (IETF Working = Group Guidelines and Procedures)." >=20 > -- Mikael Abrahamsson email: swmike@swm.pp.se Begin forwarded message: > From: Gert Doering > Date: April 18, 2011 3:36:15 AM PDT > To: JORDI PALET MARTINEZ > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > Hi, >=20 > On Mon, Apr 18, 2011 at 08:37:38AM +0200, JORDI PALET MARTINEZ wrote: >> If the problem is filtering, as expressed by Geoff, then we should = kill >> any protocol that can be filtered ? >=20 > This argument is ridiculous, and completely missing the point. >=20 > (BTW: IETF uses *rough* consensus - that means "not everybody has to = agree") >=20 > Gert Doering > -- NetMaster > --=20 > did you enable IPv6 on something today...? >=20 > 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 Begin forwarded message: > From: Nick Hilliard > Date: April 18, 2011 3:38:27 AM PDT > To: Doug Barton > Cc: ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On 18/04/2011 01:31, Doug Barton wrote: >> In some cases that's true, however some (including me) want to kill = it >> outright. Unfortunately that's not the opinion of even a substantial >> minority of the WG however. >=20 > I think most people want it gone. Problem is, it's difficult to = remove and it will take a long, long time before it disappears = completely. The approach that's most likely to get widespread support = is: >=20 > 1. make it not be on by default > 2. make noise about it being A Bad Thing > 3. deprioritise 2002::/16 addresses in resolver libs > 4. then make the option hard to find on operating systems / CPEs > 5. then remove the option on operating systems > 6. then slowly decommission 6to4 relays over many years >=20 > draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. >=20 > Nick >=20 Begin forwarded message: > From: Gert Doering > Date: April 18, 2011 3:41:56 AM PDT > To: Nick Hilliard > Cc: Doug Barton , ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > Hi, >=20 > On Mon, Apr 18, 2011 at 11:38:27AM +0100, Nick Hilliard wrote: >> 1. make it not be on by default >> 2. make noise about it being A Bad Thing >> 3. deprioritise 2002::/16 addresses in resolver libs >> 4. then make the option hard to find on operating systems / CPEs >> 5. then remove the option on operating systems >> 6. then slowly decommission 6to4 relays over many years >=20 > Just for the record: support. >=20 > Gert Doering > -- Operator > --=20 > did you enable IPv6 on something today...? >=20 > 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 Begin forwarded message: > From: sthaug@nethelp.no > Date: April 18, 2011 3:49:20 AM PDT > To: gert@space.net > Cc: ipv6-ops@lists.cluenet.de, dougb@dougbarton.us, nick@foobar.org > Subject: Re: 6to4 stats found, are there other places? >=20 >>> 1. make it not be on by default >>> 2. make noise about it being A Bad Thing >>> 3. deprioritise 2002::/16 addresses in resolver libs >>> 4. then make the option hard to find on operating systems / CPEs >>> 5. then remove the option on operating systems >>> 6. then slowly decommission 6to4 relays over many years >>=20 >> Just for the record: support. >=20 > And support here too from another operator. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no Begin forwarded message: > From: Tore Anderson > Date: April 18, 2011 3:57:15 AM PDT > To: sthaug@nethelp.no > Cc: dougb@dougbarton.us, nick@foobar.org, gert@space.net, = ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > * sthaug@nethelp.no >=20 >>>> 1. make it not be on by default >>>> 2. make noise about it being A Bad Thing >>>> 3. deprioritise 2002::/16 addresses in resolver libs >>>> 4. then make the option hard to find on operating systems / CPEs >>>> 5. then remove the option on operating systems >>>> 6. then slowly decommission 6to4 relays over many years >>>=20 >>> Just for the record: support. >>=20 >> And support here too from another operator. >=20 > It would be great if all of you could voice your support on the IETF > v6ops list too, so that I-D.ietf-v6ops-6to4-to-historic can proceed > towards publication. :-) >=20 > Best regards, > --=20 > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > Tel: +47 21 54 41 27 Begin forwarded message: > From: Tim Chown > Date: April 18, 2011 4:02:58 AM PDT > To: IPv6 operators forum > Subject: Re: 6to4 stats found, are there other places? >=20 >=20 > On 18 Apr 2011, at 11:41, Gert Doering wrote: >=20 >> Hi, >>=20 >> On Mon, Apr 18, 2011 at 11:38:27AM +0100, Nick Hilliard wrote: >>> 1. make it not be on by default >>> 2. make noise about it being A Bad Thing >>> 3. deprioritise 2002::/16 addresses in resolver libs >>> 4. then make the option hard to find on operating systems / CPEs >>> 5. then remove the option on operating systems >>> 6. then slowly decommission 6to4 relays over many years >>=20 >> Just for the record: support. >>=20 >> Gert Doering >> -- Operator >=20 > Progressing RFC3484-bis also alongside #3 helps a lot. It's that = lack of RFC3484 support in past versions of MacOS X that's caused bigger = issues for Mac users. >=20 > Somewhere in there there should also be a 'don't use 6to4 for Internet = connection sharing', which causes a lot of the problems. >=20 > Tim >=20 Begin forwarded message: > From: Tim Chown > Date: April 18, 2011 4:07:47 AM PDT > To: IPv6 operators forum > Subject: Re: 6to4 stats found, are there other places? >=20 >=20 > On 18 Apr 2011, at 01:26, Martin Millnert wrote: >=20 >> On Sun, 2011-04-17 at 22:59 +0200, Mikael Abrahamsson wrote: >>> The proponents for deprecating 6to4 doesn't want to kill 6to4, just = want=20 >>> to have vendors stop enabling it by default. >>=20 >> Mikael, if that is the case, I suggest that they double- or = triple-check >> http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html = before >> any mistakes are made wrt. publishing the draft as-is. >=20 > Well, Apple has chosen to not implement various other IPv6 features = too, which has been frustrating, e.g. RFC3484, DHCPv6, MLDv2. =20 >=20 > It's of course up to Apple what they do implement, so they can choose = to ignore the 6to4 IETF outputs. As a user of Apple products, I would = personally prefer them to be a little more advanced in their IPv6 = support. There are some signs of this in Lion. >=20 > As a data point, we're an academic site and <2% of our web traffic = from outside is IPv6 transport, and of that <1% is successful 6to4. So = loss of 6to4 hits 0.02% of our customers. >=20 > Tim Begin forwarded message: > From: Martin Millnert > Date: April 18, 2011 6:54:29 AM PDT > To: Nick Hilliard > Cc: Doug Barton , ipv6-ops@lists.cluenet.de > Subject: Re: 6to4 stats found, are there other places? >=20 > On Mon, 2011-04-18 at 11:38 +0100, Nick Hilliard wrote: >> 1. make it not be on by default >> 2. make noise about it being A Bad Thing >> 3. deprioritise 2002::/16 addresses in resolver libs >> 4. then make the option hard to find on operating systems / CPEs >> 5. then remove the option on operating systems >> 6. then slowly decommission 6to4 relays over many years >=20 > +1 >=20 > Regards, > Martin >=20 --Apple-Mail-16-564508345-- From rogerj@gmail.com Mon Apr 18 09:32:45 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2A2A6E0776 for ; Mon, 18 Apr 2011 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.942 X-Spam-Level: X-Spam-Status: No, score=-2.942 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjobxrAAqoKV for ; Mon, 18 Apr 2011 09:32:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id BECFFE06D9 for ; Mon, 18 Apr 2011 09:32:43 -0700 (PDT) Received: by iwn39 with SMTP id 39so5344333iwn.31 for ; Mon, 18 Apr 2011 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SWI1YWQ8mz9Tjzi7MDuwEpBwkEFdETNwM1HzqgvwW6M=; b=bnFhJqX6GwSxXB5C/CR0yM2IhlCnoB8nqUTTmnhBdY2Po2cUU8AtoojbDzlPEpAru7 ireCUEeulZziPQvZcpqWkKlzrAkvau7MaGpj2KhflWyjyAp6W6ol08slXGNSODifcM1g EfIVqqUt15nXqNiviu7AExWgbTGpDKd1kGx6M= 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=IsSUZrXNvNloUv8pl6Q6Z413EaJl8mwg8sqsPo6bU35RJ9eqEYLWkxKiczTDi4xp0O 50oDCiJ1Rb0u92ztrqoyTCf4AK+3rTS1rO0UdVNnNViCXCN9faR88xfeKkN9wO5MuTmN bGaQrJbZnci8JnQT2R2ICcXIexMuiex5zH1zE= MIME-Version: 1.0 Received: by 10.43.54.193 with SMTP id vv1mr6570242icb.338.1303144363101; Mon, 18 Apr 2011 09:32:43 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Mon, 18 Apr 2011 09:32:43 -0700 (PDT) In-Reply-To: <4DABE200.3040504@redpill-linpro.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.com> Date: Mon, 18 Apr 2011 18:32:43 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Fred Baker , v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:32:45 -0000 On Mon, Apr 18, 2011 at 9:02 AM, Tore Anderson wrote: > * Fred Baker >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-6to4-to-historic. 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. > > I really hope this document will in the medium- to long-term really help > out limiting the 6to4-related performance/reliability problems that the > IPv6 internet currently suffers from. I therefore support it emphatically= . > > 6to4 is often labelled a =ABtransition technique=BB, suggesting that it i= s > helping internet community deploy native IPv6. Perhaps that was true to > begin with. Today's operational reality, however, is exactly the > opposite - 6to4's ubiquity combined with its unreliability is a major > obstacle to IPv6 deployment; it caused my own customers to push back > their native IPv6 deployments for about 14 months while attempting to > minimize the problems in every imaginable way. > > It is high time we retire 6to4 and start focusing on real IPv6 > deployments instead. I'm a bit surprised with some of the argument against this and the other document in the queue right now, why are people _still_ focused on tunnels over IPv4 to get IPv6 running? 6to4 is one of them. Wasn't that something we did like 10 years ago when there was not so many other real options? Shouldn't the focus now being on real IPv6 deployment as Tore say? --=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 pch-b6B5344D9@u-1.phicoh.com Mon Apr 18 10:08:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9930DE0694 for ; Mon, 18 Apr 2011 10:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlySFFjmwBRH for ; Mon, 18 Apr 2011 10:08:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 9057CE0670 for ; Mon, 18 Apr 2011 10:08:34 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QBrw3-0001iPC; Mon, 18 Apr 2011 19:08 +0200 Message-Id: To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.com> In-reply-to: Your message of "Mon, 18 Apr 2011 18:32:43 +0200 ." Date: Mon, 18 Apr 2011 19:08:18 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:08:36 -0000 In your letter dated Mon, 18 Apr 2011 18:32:43 +0200 you wrote: >On Mon, Apr 18, 2011 at 9:02 AM, Tore Anderson > wrote: >> It is high time we retire 6to4 and start focusing on real IPv6 >> deployments instead. > >I'm a bit surprised with some of the argument against this and the other >document in the queue right now, why are people _still_ focused on tunnels >over IPv4 to get IPv6 running? 6to4 is one of them. That depends on your role. From ISP perspective, 6to4 doesn't make a lot of sense. But for end users, sometimes a tunnel is all you can get. Sometimes, tunnels offer even a more complete IPv6 experience than native. I can imagine that if you are now using 6to4, you don't want the next firmware upgrade of your router to remove that feature completely. >Shouldn't the focus now being on real IPv6 deployment as Tore say? If you are an ISP, certainly yes. From pch-b6B5344D9@u-1.phicoh.com Mon Apr 18 10:16:59 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DF42E06E5 for ; Mon, 18 Apr 2011 10:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoq3VEYDPbch for ; Mon, 18 Apr 2011 10:16:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 84D10E06D9 for ; Mon, 18 Apr 2011 10:16:58 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QBs4D-0001h1C; Mon, 18 Apr 2011 19:16 +0200 Message-Id: To: "Templin, Fred L" From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-reply-to: Your message of "Mon, 18 Apr 2011 08:44:31 -0700 ." Date: Mon, 18 Apr 2011 19:16:38 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:16:59 -0000 In your letter dated Mon, 18 Apr 2011 08:44:31 -0700 you wrote: >None of these are simpler nor more catch-all than >just turning up the domainname "isatap.domainname" >in the site. I don't have any operational experience with ISATAP, so these are just some of questions that come to mind: - what do you do with hosts that do support IPv6 over ethernet but don't support ISATAP? - This looks like an all of nothing property: either you enable ISATAP for all hosts in your organisation or you don't. What if you just want a few subnets to have IPv6 connectivity (or if you want the phase it in gradually)? - It seems that all hosts are in a single subnet. What about the security implications. If you have internal IPv4 firewalls in your organisation do you also have to figure out how to filter ISATAP traffic with them? - ISATAP doesn't have multicast. What about protocols that rely on multicast, like mDNS? - Suppose that at some point you will have a native IPv6 backbone. How do you route (in a decentralized way) between ISATAP and the native IPv6 nets? From dwcarder@wisc.edu Mon Apr 18 10:34:10 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D2613E07F0 for ; Mon, 18 Apr 2011 10:34:10 -0700 (PDT) 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_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhqcYhrIqpg0 for ; Mon, 18 Apr 2011 10:34:09 -0700 (PDT) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by ietfc.amsl.com (Postfix) with ESMTP id E1D6DE06D9 for ; Mon, 18 Apr 2011 10:34:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LJU00F12ZGBL000@smtpauth1.wiscmail.wisc.edu> for v6ops@ietf.org; Mon, 18 Apr 2011 12:33:47 -0500 (CDT) Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LJU00F6QZG8A600@smtpauth1.wiscmail.wisc.edu>; Mon, 18 Apr 2011 12:33:45 -0500 (CDT) Date: Mon, 18 Apr 2011 12:33:44 -0500 From: "Dale W. Carder" In-reply-to: To: Roger J?rgensen Message-id: <20110418173344.GE332@ricotta.doit.wisc.edu> X-Spam-PmxInfo: Server=avs-9, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.18.172115, SenderIP=144.92.67.161 References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:34:11 -0000 Thus spake Roger J?rgensen (rogerj@gmail.com) on Mon, Apr 18, 2011 at 06:32:43PM +0200: > On Mon, Apr 18, 2011 at 9:02 AM, Tore Anderson > wrote: > > * Fred Baker > > It is high time we retire 6to4 and start focusing on real IPv6 > > deployments instead. > > I'm a bit surprised with some of the argument against this and the other > document in the queue right now, why are people _still_ focused on tunnels > over IPv4 to get IPv6 running? 6to4 is one of them. This aligns with my thoughts. 6to4 is quite broken, which is supported by evidence for a variety of situations. Sure, we could spend time fixing it, but it would be best to spend that effort working on real IPv6 deployments. The time for 6to4 was the last 10 years. We need to set 6to4 to historic and move on. Dale From jhw@apple.com Mon Apr 18 10:45:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 05260E07F7 for ; Mon, 18 Apr 2011 10:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydUEU1Xas+Yc for ; Mon, 18 Apr 2011 10:45:28 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id 83DB7E066B for ; Mon, 18 Apr 2011 10:45:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJU00CDXZU2HUJ0@mail-out.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 10:45:26 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-ff-4dac78b6f700 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 8A.ED.29082.6B87CAD4; Mon, 18 Apr 2011 10:45:26 -0700 (PDT) Received: from [17.193.13.64] by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJU003FXZZP9A20@koseret.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 10:45:26 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 18 Apr 2011 10:45:25 -0700 Message-id: <71CD928A-34B2-43B1-8E50-E60BC26AA3B3@apple.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:45:29 -0000 On Apr 17, 2011, at 23:34 , Randy Bush wrote: > [I wrote:] >> >> this draft should not published in its current form because it sets no >> standard for network operations without 6to4. > > try ipv6 That's not a phaseout plan for 6to4. I've written before about what a proper phaseout plan for 6to4 should look like. You seem to be in favor of having a proper phaseout plan in the draft... perhaps you could propose a plan that would make sense for operators. I look forward to seeing it. -- james woodyatt member of technical staff, core os networking From Fred.L.Templin@boeing.com Mon Apr 18 10:45:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35947E082B for ; Mon, 18 Apr 2011 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.043 X-Spam-Level: X-Spam-Status: No, score=-7.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, GB_I_LETTER=-2, J_BACKHAIR_46=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 151nyJFtj7Dm for ; Mon, 18 Apr 2011 10:45:55 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 1B17CE0815 for ; Mon, 18 Apr 2011 10:45:55 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3IHjkb5016188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2011 10:45:50 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3IHjkNB011998; Mon, 18 Apr 2011 12:45:46 -0500 (CDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3IHjjK0011957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Apr 2011 12:45:45 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Mon, 18 Apr 2011 10:45:45 -0700 From: "Templin, Fred L" To: Philip Homburg Date: Mon, 18 Apr 2011 10:45:43 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv97G5nhcyvpHpZQOGaIepac0/DLQAAEuMw Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:45:56 -0000 Hi Philip,=20 > -----Original Message----- > From: pch-b6B5344D9@u-1.phicoh.com=20 > [mailto:pch-b6B5344D9@u-1.phicoh.com] On Behalf Of Philip Homburg > Sent: Monday, April 18, 2011 10:17 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft)=20 >=20 > In your letter dated Mon, 18 Apr 2011 08:44:31 -0700 you wrote: > >None of these are simpler nor more catch-all than > >just turning up the domainname "isatap.domainname" > >in the site. >=20 > I don't have any operational experience with ISATAP, so these=20 > are just some > of questions that come to mind: > - what do you do with hosts that do support IPv6 over=20 > ethernet but don't > support ISATAP? Hosts that don't support ISATAP but that are buried somewhere deep in an IPv4-routed site would require the site administrator to dig down deep into the site while turning up IPv6 routing on all of the routers in the path. That might be easier for some sites than for others. You can probably tell from this that I believe all hosts should support ISATAP. It really isn't hard to do, and can be slipped in as part of an automated (or pulled) host S/W upgrade. > - This looks like an all of nothing property: either you=20 > enable ISATAP for all > hosts in your organisation or you don't. What if you just=20 > want a few subnets > to have IPv6 connectivity (or if you want the phase it in=20 > gradually)? It doesn't have to be all or nothing, and there are ways to operationally limit IPv6 connectivity to only certain IPv4 subnets. For example, configure ISATAP routers to only send RA responses to hosts that use specific IPv4 subnet prefixes. Another way is to partition the site based on domain names, e.g., configure the domain name 'isatap.engineering.foo.com' but do not configure the domain name 'isatap.marketing.foo.com'.=20 > - It seems that all hosts are in a single subnet. What about=20 > the security=20 > implications. If you have internal IPv4 firewalls in your=20 > organisation do > you also have to figure out how to filter ISATAP traffic with them? Well, if there are IPv4 firewalls in the site then the ISATAP link (or links) would be partitioned, and some ISATAP hosts would not be able to reach others directly. This could be solved if the firewalls were reconfigued to recognize ip-proto-41 and perform IPv6 firewalling based on the inner IPv6 packet, but that seems somewhat unlikely in general practice. Remember however that I am anticipating the use of IPv6 only for accessing IPv6 correspondents outside of the site, so in the general case all/most ISATAP-serviced IPv6 traffic would be going from host<->router. > - ISATAP doesn't have multicast. What about protocols that=20 > rely on multicast, > like mDNS? For service discovery within the site, why not just continue to use IPv4? For site-internal communications, why fix what isn't broken? > - Suppose that at some point you will have a native IPv6=20 > backbone. How do you > route (in a decentralized way) between ISATAP and the=20 > native IPv6 nets? I'm not sure I quite understand the question (some pictures might help) but when native IPv6 routers show up on the link the hosts should begin using native IPv6 and either deprecate ISATAP or use it as a backup service. Thanks - Fred fred.l.templin@boeing.com= From jhw@apple.com Mon Apr 18 10:56:09 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11CF1E066B for ; Mon, 18 Apr 2011 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+Yd3ajHKT1s for ; Mon, 18 Apr 2011 10:56:08 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 7F13FE0669 for ; Mon, 18 Apr 2011 10:56:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00FQZ0HI3UW0@mail-out.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 10:56:07 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-53-4dac7b3719b6 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 5F.51.29082.73B7CAD4; Mon, 18 Apr 2011 10:56:07 -0700 (PDT) Received: from [17.193.13.64] by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJV00JCT0HJVC20@cardamom.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 10:56:07 -0700 (PDT) From: james woodyatt In-reply-to: <4DAC432B.90403@inex.ie> Date: Mon, 18 Apr 2011 10:56:07 -0700 Message-id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:56:09 -0000 On Apr 18, 2011, at 06:56 , Nick Hilliard wrote: > > James: if this document were to explicitly set a phaseout date for 2002::/16 some time in the future, would this work for you? Yes. I cannot support this draft unless it has an explicit phaseout plan for 2002::/16 included. If you want to send a signal to equipment makers that they should remove 6to4 routing functions from their future product plans, then you need to include a phaseout plan for it. Otherwise, you are engaging in a pointless exercise, and it won't happen. Am I making myself clear? Because I really can't be more explicit than that. -- james woodyatt member of technical staff, core os networking From rogerj@gmail.com Mon Apr 18 11:03:06 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0401AE07B6 for ; Mon, 18 Apr 2011 11:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.987 X-Spam-Level: X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rWo-AfmqwC3 for ; Mon, 18 Apr 2011 11:03:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id D59A1E076F for ; Mon, 18 Apr 2011 11:03:04 -0700 (PDT) Received: by iwn39 with SMTP id 39so5424215iwn.31 for ; Mon, 18 Apr 2011 11:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2H1nKf8z6CzqU4g38SXdRzbd9pfCUlFJ1NgwpKixiP8=; b=AsnEC5jIXOaytAL9DkZOmUGE+4gFgpM+9w//sz8LurAhT1ghB9SFglp5vXLvSvqs77 RSvRUm2r5ifsA3HmiiadznV5NYG5/PbGRtPWB7Qi+TGqS6AeoULmxwKZvW7p91BHON7x 9fnToCoV2Sq/OGzNzx0dDp3PM/rK+FbYXQmm4= 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=N1fRj7eqoC2kBN9+yVwe+t63y09CyiZYncGNBhv/lRGgN2k3ClTPaXZQYMM0yL2u/5 MfE+TaXweilJYAaO49jeGl1aCONOv5dtcfYjJTfvXN6spS9IIYlpjjJqJkdzf+3RvYz3 SW6fBwKCtEI2WngFT4MkbeKMGllGzwUeUgHAs= MIME-Version: 1.0 Received: by 10.231.3.76 with SMTP id 12mr3913948ibm.166.1303149784209; Mon, 18 Apr 2011 11:03:04 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Mon, 18 Apr 2011 11:03:04 -0700 (PDT) In-Reply-To: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> Date: Mon, 18 Apr 2011 20:03:04 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:03:06 -0000 On Mon, Apr 18, 2011 at 7:56 PM, james woodyatt wrote: > On Apr 18, 2011, at 06:56 , Nick Hilliard wrote: >> >> James: if this document were to explicitly set a phaseout date for 2002:= :/16 some time in the future, would this work for you? > > Yes. =A0I cannot support this draft unless it has an explicit phaseout pl= an for 2002::/16 included. =A0If you want to send a signal to equipment mak= ers that they should remove 6to4 routing functions from their future produc= t plans, then you need to include a phaseout plan for it. =A0Otherwise, you= are engaging in a pointless exercise, and it won't happen. > > Am I making myself clear? =A0Because I really can't be more explicit than= that. I suggested 4.June 2016 a couple of weeks ago.... --=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 swmike@swm.pp.se Mon Apr 18 11:04:19 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B531E07B6 for ; Mon, 18 Apr 2011 11:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtGdrg9KcANS for ; Mon, 18 Apr 2011 11:04:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 90706E076F for ; Mon, 18 Apr 2011 11:04:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D76149C; Mon, 18 Apr 2011 20:04:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D44639A; Mon, 18 Apr 2011 20:04:16 +0200 (CEST) Date: Mon, 18 Apr 2011 20:04:16 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:04:19 -0000 On Mon, 18 Apr 2011, james woodyatt wrote: > Yes. I cannot support this draft unless it has an explicit phaseout > plan for 2002::/16 included. If you want to send a signal to equipment > makers that they should remove 6to4 routing functions from their future > product plans, then you need to include a phaseout plan for it. > Otherwise, you are engaging in a pointless exercise, and it won't > happen. Could you please elaborate as to why? Not working for an equipment vendor, I don't get why there needs to be a firm phaseout plan. I never saw a phaseout plan for RIPv1. -- Mikael Abrahamsson email: swmike@swm.pp.se From yanodd@otenet.gr Mon Apr 18 11:09:42 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE651E07F7 for ; Mon, 18 Apr 2011 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-7qUbVR5zla for ; Mon, 18 Apr 2011 11:09:42 -0700 (PDT) Received: from noc.otenet.gr (noc.otenet.gr [195.170.0.29]) by ietfc.amsl.com (Postfix) with ESMTP id 3E4DEE06A2 for ; Mon, 18 Apr 2011 11:09:42 -0700 (PDT) Received: from loco.otenet.gr (loco.otenet.gr [212.205.221.32]) by noc.otenet.gr (Postfix) with ESMTP id 5862A8B815F; Mon, 18 Apr 2011 21:09:40 +0300 (EEST) Received: from loco.otenet.gr (localhost.localdomain [127.0.0.1]) by loco.otenet.gr (8.14.4/8.14.4) with ESMTP id p3IIEsiZ010734; Mon, 18 Apr 2011 21:14:54 +0300 Received: (from yanodd@localhost) by loco.otenet.gr (8.14.4/8.14.4/Submit) id p3IIEqkY010731; Mon, 18 Apr 2011 21:14:52 +0300 Date: Mon, 18 Apr 2011 21:14:52 +0300 From: yannis nikolopoulos To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Message-ID: <20110418181452.GG3991@otenet.gr> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.com> <20110418131741.GA30412@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110418131741.GA30412@srv03.cluenet.de> Precedence: first-class User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:09:42 -0000 On Mon, Apr 18, 2011 at 03:17:41PM +0200, Daniel Roesen wrote: > On Mon, Apr 18, 2011 at 09:02:24AM +0200, Tore Anderson wrote: > > I really hope this document will in the medium- to long-term really help > > out limiting the 6to4-related performance/reliability problems that the > > IPv6 internet currently suffers from. I therefore support it emphatically. > > Support, from an operator. +1 (from an operator also) regards, Yannis > 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 -- Yannis Nikolopoulos OTE Hellenic Telecommunications Organization e-mail: yanodd@otenet.gr IP Network Planning ---------------------------------------------------------------------------- () ASCII Ribbon Campaign - against HTML email & vCards /\ From jhw@apple.com Mon Apr 18 11:20:43 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A914E0835 for ; Mon, 18 Apr 2011 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b9C6fQy3o59 for ; Mon, 18 Apr 2011 11:20:42 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id B2E4BE07F6 for ; Mon, 18 Apr 2011 11:20:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV006Z71MESWS0@mail-out.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 11:20:42 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-35-4dac80f9a3bd Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 0B.0C.29082.9F08CAD4; Mon, 18 Apr 2011 11:20:42 -0700 (PDT) Received: from [17.193.13.64] by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJV004121MH9N30@cardamom.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 11:20:41 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 18 Apr 2011 11:20:41 -0700 Message-id: <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:20:43 -0000 On Apr 18, 2011, at 11:04 , Mikael Abrahamsson wrote: > > Could you please elaborate as to why? Too many service providers today have not announced any IPv6 transition plans, leaving our customers with only 6to4 as their only hope for acquiring even marginally acceptable IPv6 services with a reasonable level of configuration human interface burden. Until this changes, I doubt Apple and other equipment makers will stop supporting 6to4 routing in their products, and people will continue to use it despite the IETF deprecation, and IPv6 brokenness related to 6to4 will probably remain at the unacceptable levels that operators and content providers hope to address with the publication of this draft. On the other hand, if IETF publishes a standards track document with phaseout plan for 2002::/16, then product managers can know with reasonable certainty when their 6to4 routing feature will no longer be useful to any of their customers, and they can plan accordingly. -- james woodyatt member of technical staff, core os networking From swmike@swm.pp.se Mon Apr 18 11:32:00 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB250E0827 for ; Mon, 18 Apr 2011 11:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc0S6lLYJsP9 for ; Mon, 18 Apr 2011 11:32:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 23FF5E070A for ; Mon, 18 Apr 2011 11:32:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 990FB9C; Mon, 18 Apr 2011 20:31:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 96C179A; Mon, 18 Apr 2011 20:31:59 +0200 (CEST) Date: Mon, 18 Apr 2011 20:31:59 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:32:00 -0000 On Mon, 18 Apr 2011, james woodyatt wrote: > On the other hand, if IETF publishes a standards track document with > phaseout plan for 2002::/16, then product managers can know with > reasonable certainty when their 6to4 routing feature will no longer be > useful to any of their customers, and they can plan accordingly. How agressive does the phaseout plan need to be? I'm looking at 6bone , it gave 2.5 years to remove it from the Internet. It's just that won't allowing ISPs to filter the anycast prefixes for 6to4 just make the problem worse? How would a phase-out be structured to cause the users the least amount of problems? By 2014-01-01 people should start sending unreachables for any traffic for 192.88.99.1 ? -- Mikael Abrahamsson email: swmike@swm.pp.se From ichiroumakino@gmail.com Mon Apr 18 11:49:15 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2FD1EE0720 for ; Mon, 18 Apr 2011 11:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2gqzWhhSvUT for ; Mon, 18 Apr 2011 11:49:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 05E28E085F for ; Mon, 18 Apr 2011 11:49:13 -0700 (PDT) Received: by eye13 with SMTP id 13so1909015eye.31 for ; Mon, 18 Apr 2011 11:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=gPVYOIL7QTXKwhX3ZcHNBB//aD8VZ+D+3qFI+kfv2ec=; b=KhT8jL7F1Gyp/gh+AhH7W0jM7hEo/zF0A63lzqiVkbRGoQvcHSU5YgMvRvuwj9y8cA OLekLUxCvo7RGCk9iKQiRlRqXA7D35ooFr48cnoxZiAwNipxX3kiHbJERa4C6oA/p0Gq zp3mrW0e9z1mBejdEtMvKIuBp3FdoA0VidXvM= 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=sPdNcsCNfMmW6u2a4WnTWHq/wmdYGsIEA1xQO/YqYZWRk7aEfuHAqt3KByTrNS9mrx y4oE34JbuTPoJ/X7uYF30tFydM7az8JfFVQlkRg7us/edNJMq8UTOb+Bm4Nbr/XouTWl dgl01NcEvDJ86NAePdxt/XGUMBYtiUkFKwuUg= Received: by 10.213.4.69 with SMTP id 5mr291138ebq.123.1303152553194; Mon, 18 Apr 2011 11:49:13 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id k51sm4285807eei.24.2011.04.18.11.49.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 11:49:12 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> Date: Mon, 18 Apr 2011 20:49:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <705ADBE3-459E-4D7E-B206-0449EF57978F@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:49:15 -0000 James, >> Could you please elaborate as to why? >=20 > Too many service providers today have not announced any IPv6 = transition plans, leaving our customers with only 6to4 as their only = hope for acquiring even marginally acceptable IPv6 services with a = reasonable level of configuration human interface burden. Until this = changes, I doubt Apple and other equipment makers will stop supporting = 6to4 routing in their products, and people will continue to use it = despite the IETF deprecation, and IPv6 brokenness related to 6to4 will = probably remain at the unacceptable levels that operators and content = providers hope to address with the publication of this draft. people who have made an informed choice to use 6to4 will continue to do = so, regardless of the IETF or what equipment makers do in upgraded = products. giving those users a different solution or forcing them to = stop using 6to4 is not the purpose of this draft. the problem is when equipment vendors decide on their users behalf, that = they should have 6to4 IPv6 access, wether they want it or not. this = document provides a stable reference for both vendors and perhaps more = importantly those who buy equipment. I see 6to4-historic and 6to4-advisory as complimentary. you should = implement the suggestions in section 4.1. I would like to see a reachability check for the 6to4 relay in there = too. > On the other hand, if IETF publishes a standards track document with = phaseout plan for 2002::/16, then product managers can know with = reasonable certainty when their 6to4 routing feature will no longer be = useful to any of their customers, and they can plan accordingly. I don't see that logical implication. cheers, Ole From ichiroumakino@gmail.com Mon Apr 18 11:53:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 111CEE0848 for ; Mon, 18 Apr 2011 11:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4J+E7h9eXek for ; Mon, 18 Apr 2011 11:53:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 28570E0720 for ; Mon, 18 Apr 2011 11:53:00 -0700 (PDT) Received: by eye13 with SMTP id 13so1910220eye.31 for ; Mon, 18 Apr 2011 11:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=h0Pf5ZsHm7ADk39/ZqsBV0ack7OqsqrcFSHkTRLUYSM=; b=DSecQ1ah4pElZDZfmlmLA7kqFfwewNMnAlncL5mRKab2ScQf4Upj1GHTCQ3AJudQva pLO6dzkAEAWz/xDn3T9kPVdREhfPwIxnmoMS0XyD3cSHhVyCHVuV2+qfuWUDzwiWpZqq 7YDreeAx/2yvipRNTPVwiryDPhM7QvaXsTmSM= 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=kV4W99FKYHN7xCvYMBp2EQU908axsASnhGAX8REkHTIqm687i/WGkKCYmRIBJIoy25 U4lCDbJKcGDAU4dbU4cFeC93pb4GZ3vh6fJqjrYRbkIU32SwSdonujn1Gi/MLmhV8eSC dHPgpbl/rMe7176uxIgb6Y6eSiArYxZOP2nuk= Received: by 10.213.29.199 with SMTP id r7mr2154942ebc.53.1303152779137; Mon, 18 Apr 2011 11:52:59 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id x54sm4276520eeh.26.2011.04.18.11.52.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 11:52:58 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> Date: Mon, 18 Apr 2011 20:52:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:53:01 -0000 > This is to initiate a two week working group last call of = draft-ietf-v6ops-6to4-advisory. 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. >=20 > 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. I support this document. two comments: [I-D.vandevelde-v6ops-harmful-tunnels]. as I'm not entirely certain if = we will continue this document now that we have the two 6to4 document, = you may want to remove this reference. section 4.1. on vendor issues. I would have liked to see a suggestion of = a "reachability check" for the 6to4 relay. and make that as a = prerequisite to enable the 6to4 function in an implementation. a = reachability check could be as simple as sending an ICMP echo packet to = one of ones own addresses via the 6to4 relay. cheers, Ole From jhw@apple.com Mon Apr 18 12:01:20 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE1C4E0896 for ; Mon, 18 Apr 2011 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNycSinCcRsV for ; Mon, 18 Apr 2011 12:01:20 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id B10CEE088D for ; Mon, 18 Apr 2011 12:01:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00MZE3GF6WQ0@mail-out.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 12:01:16 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-7d-4dac8a7bbfca Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id E2.9E.20744.B7A8CAD4; Mon, 18 Apr 2011 12:01:15 -0700 (PDT) Received: from [17.193.13.64] by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJV003N13I39A40@koseret.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 12:01:15 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 18 Apr 2011 12:01:15 -0700 Message-id: <2540370C-4D4A-41D7-94B2-740CA2793FBB@apple.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:01:20 -0000 On Apr 18, 2011, at 11:31 , Mikael Abrahamsson wrote: > > How agressive does the phaseout plan need to be? Not for me to say. I would estimate that if product managers were to see a standards track phaseout plan that says 2002::/16 MUST NOT appear in the default-free zone after $DATE, then they might feel confident at ${DATE - 2 years} making the 6to4 routing feature a hidden and marginally-supported feature for customers upgrading from previous models, and that new products released after ${DATE - 3 months} could dispense entirely with the 6to4 routing feature, and firmware updates for existing products could actively disable 6to4 in deployed configurations. At least, that's the recommendation I would make to my product managers. Or you could decide not to mark an explicit date for phaseout, and I would recommend they continue supporting 6to4 until the last major Internet service provider stops providing IPv4-only service in the public address realm. -- james woodyatt member of technical staff, core os networking From Dmitry.Anipko@microsoft.com Mon Apr 18 13:22:50 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7850E0891 for ; Mon, 18 Apr 2011 13:22:50 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK2phSECzk2O for ; Mon, 18 Apr 2011 13:22:49 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 3FF1AE07B2 for ; Mon, 18 Apr 2011 13:22:49 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 13:22:48 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 13:22:48 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Mon, 18 Apr 2011 13:21:17 -0700 From: Dmitry Anipko To: Ole Troan Date: Mon, 18 Apr 2011 13:21:16 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv9mycEJyjwPeLAQuCbuuo1cIVK7wAaTepw Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> In-Reply-To: <074A75C3-C87A-445D-BAEF-3F39CA027A22@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: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:22:50 -0000 Hello Ole, >> the "non deployed" reference is with regards to this RFC3056 deployment = model: RFC3056, section 5.2: >> I have never heard nor seen this model having been deployed. anyone? RFC 3056 has other scenarios, such as e.g. in section 5.1 and 5.4. While th= e statement in the draft-ietf-v6ops-6to4-to-historic that " IPv6 transition= mechanism... has rarely if ever been deployed" refers to the whole RFC, an= d not to the specific section you're referring to. If the scenarios relying= on BGP haven't been deployed, should not that be stated as such, instead o= f referring to the whole RFC? >>6to4 does not work without relays.=20 >> are you suggesting to create a version of 6to4, where 6to4 nodes can onl= y reach other 6to4 nodes? i.e. no relays whatsoever? I'm not suggesting to create anything that doesn't already exist - such "ve= rsion" is essentially already documented in the RFC 3056, in section 5.1. W= hat I'm trying to understand is why those scenarios should be moved to hist= oric - in my opinion, draft-ietf-v6ops-6to4-to-historic doesn't explain tha= t to a sufficient extent. >> if RFC3056 was 6to4 node to 6to4 node communication only, I would agree = with you. but 3056 uses relays in the same fashion as 3068. There are parts which mention relays, and parts which don't. I think draft-= ietf-v6ops-6to4-to-historic fairly well explains what's wrong with relays, = but it doesn't address what's wrong with 6to4-6to4 communication. And if th= ere is not much wrong with 6to4-6to4 scenario (either between the nodes or = between nodes and islands), why should that part be moved to historic. Thank you, Dmitry -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, April 18, 2011 12:34 AM To: Dmitry Anipko Cc: Fred Baker; v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Dmitry, > The draft proposes to move both RFC 3056 and RFC 3068 to historic status = on the following grounds: >=20 > 1. A statement that 6to4 has rarely if ever been deployed. >=20 > 2. A list of specific issues related to 6to4. >=20 > I couldn't find a reference in the draft which would support statement (1= ). If there has been some study showing that 6to4 deployment, by some quant= ifiable metric, is indeed many times lower than deployment of other tunnels= (for example, Teredo), then I think having a reference to such data would = make statement (1) more justified.=20 the "non deployed" reference is with regards to this RFC3056 deployment mod= el: RFC3056, section 5.2: 2.2 An IPv6 exterior routing protocol is used. The set of 6to4 routers using a given relay router obtain native IPv6 routes from the relay router using a routing protocol such as BGP4+ [RFC 2283, BGP4+]. The relay router will advertise whatever native IPv6 routing prefixes are appropriate on its 6to4 pseudo-interface. These prefixes will indicate the regions of native IPv6 topology that the relay router is willing to relay to. Their choice is a matter of routing policy. It is necessary for network operators to carefully consider desirable traffic patterns and topology when choosing the scope of such routing advertisements. The relay router will establish BGP peering only with specific 6to4 routers whose traffic it is willing to accept. I have never heard nor seen this model having been deployed. anyone? > In the list of issues related to 6to4, the first 4 of the issues are rela= ted to relay and, in my opinion, moving RFC 3068 (+ potentially anything re= lated to relays in RFC 3056) to historic status is a possible solution to t= hose issues, however those issues don't seem to be relevant to moving to hi= storic status RFC 3056 in general. in this model: RFC3056, section 5.2: 2.1 No IPv6 exterior routing protocol is used. The 6to4 routers using a given relay router each have a default IPv6 route pointing to the relay router. The relay router MAY apply source address based filters to accept traffic only from specific 6to4 routers. 6to4 does not work without relays. RFC3056 works with a known relay in the = forward direction and a remote relay in the reverse direction. the only dif= ference between 3068 and 3056's use of relays is that in the 3056 case the = forward relay is configured with an IPv4 unicast address as opposed to a we= ll known IPv4 anycast address. all the other relay related issues still rem= ain in 3056. are you suggesting to create a version of 6to4, where 6to4 nodes can only r= each other 6to4 nodes? i.e. no relays whatsoever? > The remaining two issues are: A) filtering of protocol 41 in intermediate= firewalls and PMTUD/ICMP not working correctly, and B) 6to4 not able to wo= rk in networks where non-RFC-1918 addressing is used. >=20 > Specifically, the issue (A) states that "6to4 has no specified mechanism = to handle the case where protocol 41 is blocked...". Do other tunneling mec= hanisms using protocol 41 have such mechanism? If they don't, then should u= sage of protocol 41 be moved to historic, because the stated filtering/PMTU= D problems are then not specific to RFC 3056? If they do, then having a bri= ef overview of those and how/why they don't apply to 6to4 would help to str= engthen the statement. >=20 > The issue (B), if I understand correctly, it is essentially about usage o= f non-RFC1918 addresses in networks, connected to Internet e.g. using a NAT= . There are existing mitigations to this problem (e.g. Windows implementati= on will not configure 6to4 interface if there is other IPv6 connectivity in= the network; depending on particular implementation, in managed environmen= ts administrators may have control whether to enable or disable 6to4 on hos= ts). But even leaving those mitigations aside, it seems that the de-priorit= ization of 6to4 in prefix policy table below IPv4 in the proposed RFC 3484 = revision would take care of this issue, and moving RFC 3056 is a much stron= ger measure, which doesn't seem to be necessary, as far as the issue (B) is= concerned. With the revised RFC 3484, 6to4 will be one of the "last resort= " mechanisms, which will essentially be used only if nothing else can, so i= t won't be harmful. >=20 > So to summarize, in my opinion, in the current draft there seem to be suf= ficient arguments to move RFC 3068 to historic, but not RFC 3056. There may= be such arguments for RFC 3056, but if there are, I think they are not suf= ficiently reflected in the draft.=20 if RFC3056 was 6to4 node to 6to4 node communication only, I would agree wit= h you. but 3056 uses relays in the same fashion as 3068. unless you deploy = it the way Brian intended originally. cheers, Ole From Dmitry.Anipko@microsoft.com Mon Apr 18 13:38:25 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50C75E0875 for ; Mon, 18 Apr 2011 13:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnU7aquxfTqI for ; Mon, 18 Apr 2011 13:38:24 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 3D4A9E070B for ; Mon, 18 Apr 2011 13:38:24 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 13:38:23 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 13:38:23 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Mon, 18 Apr 2011 13:38:12 -0700 From: Dmitry Anipko To: Tore Anderson Date: Mon, 18 Apr 2011 13:38:11 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv9k4gfYmjXl+pETpqWpSeDZZuo6gAczpXA Message-ID: References: , <4DABC618.8030406@bogus.com> <4DABDCD8.6020300@redpill-linpro.com> In-Reply-To: <4DABDCD8.6020300@redpill-linpro.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" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:38:25 -0000 Hello Tore, >> other devices that possibly do not implement RFC 3484 or something simil= ar. This is a problem on its own, that should be fixed in those devices and sof= tware due to other reasons, not related to 6to4. That said, it seems to me (let me know if I misunderstood) you're assuming = a configuration where 6to4 router advertises a default route (while it itse= lf doesn't have any or working default route to the IPv6 Internet). I agree= that that is a misconfiguration that should be avoided. However there is n= o requirement for a 6to4 router to advertise the default route on the netwo= rk to support a scenario described in RFC 3056 section 5.1, instead the 6to= 4 router can advertise a specific route option for 6to4 well known prefix.= =20 Thank you, Dmitry -----Original Message----- From: Tore Anderson [mailto:tore.anderson@redpill-linpro.com]=20 Sent: Sunday, April 17, 2011 11:40 PM To: Dmitry Anipko Cc: Joel Jaeggli; jordi.palet@consulintel.es; v6ops@ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC * Dmitry Anipko > If the supporters of moving RFC 3056 to historic feel there is firm > evidence why RFC 3056 is harmful, it should not be difficult to > elaborate on that in the draft, and explain why alternative > mitigations (such as changing RFC 3484 prefix policy) would not be > sufficient - that would help address concerns regarding moving RFC > 3056 to historic. If there is no such evidence however, then to me it > seems reasonable to remove such recommendation for RFC 3056, rather > than postulating that RFC 3056 is harmful and requiring others to > prove otherwise. Dmitry, 6to4 connectivity is at its most harmful when it's being shared from a router-like device (including, but certainly not limited to, ICS) to a number of other devices that possibly do not implement RFC 3484 or something similar. In this situation, the devices behind the 6to4 router will have: 1) A globally-scoped unicast IPv6 address, and 2) a default route to the IPv6 internet. In the 3056+3068 case, this has an up to 85% chance of actually working for internet-bound traffic [Aben, Huston]. In the 3056-only case, it has a _0%_ chance of actually working. In other words: Removing the 3068 functionality, while leaving 3056 intact, will only aggravate the 6to4-problems that network/content operators struggle with today. Best regards, --=20 Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From Dmitry.Anipko@microsoft.com Mon Apr 18 13:52:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 48745E077D for ; Mon, 18 Apr 2011 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PRP6G8cYUN1 for ; Mon, 18 Apr 2011 13:52:35 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 6231AE0701 for ; Mon, 18 Apr 2011 13:52:35 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 13:52:34 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 18 Apr 2011 13:52:34 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Mon, 18 Apr 2011 13:51:54 -0700 From: Dmitry Anipko To: Joel Jaeggli Date: Mon, 18 Apr 2011 13:51:53 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv9lDZ5WBoeElJIR2S/SmeiTwwwWAAdFfeA Message-ID: References: , <4DABC618.8030406@bogus.com> <4DABDD6F.30106@bogus.com> In-Reply-To: <4DABDD6F.30106@bogus.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" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:52:36 -0000 Hello Joel, >> on the contrary support for the document as a whole to advance has been very much in evidence, hence it's status as a wg document and the decision to WGLC it, if the inclusion of 3056 is a problem that should be demonstrated as you are doing now. I think it is useful to separate evidence of fact and evidence of opinion.= =20 For the future readers of the standard, should draft-ietf-v6ops-6to4-to-his= toric become one, I don't believe it is not going to be very useful if the = standard says that 6to4 is moved to historic because that was a clear evide= nce that that was the majority opinion. On the other hand, I think it would be useful, if the reasons (evidence of = facts), based on which that majority opinion was reached, were explained (a= s the draft does for the relays issue) and an average reasonable engineer a= fter reading the standard would arrive to the same opinion as what the majo= rity reached. >> if the inclusion of 3056 is a problem that should be demonstrated as you= are doing now. Specifically, so far I fail to see reasons sufficiently explained in the dr= aft why peer-to-peer 6to4 scenarios need to be moved to historic, and with = the current text I do not support moving to historic RFC 3056 as a whole. Thank you, Dmitry -----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com]=20 Sent: Sunday, April 17, 2011 11:43 PM To: Dmitry Anipko Cc: jordi.palet@consulintel.es; v6ops@ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On 4/17/11 10:56 PM, Dmitry Anipko wrote: > Hello Joel, > If the supporters of moving RFC 3056 to historic feel there is firm > evidence why RFC 3056 is harmful, it should not be difficult to > elaborate on that in the draft, and explain why alternative > mitigations (such as changing RFC 3484 prefix policy) would not be > sufficient - that would help address concerns regarding moving RFC > 3056 to historic. If there is no such evidence however, then to me it > seems reasonable to remove such recommendation for RFC 3056, rather > than postulating that RFC 3056 is harmful and requiring others to > prove otherwise. on the contrary support for the document as a whole to advance has been very much in evidence, hence it's status as a wg document and the decision to WGLC it, if the inclusion of 3056 is a problem that should be demonstrated as you are doing now. As Brian carpenter noted and I think I captured. "I don't think 3056 is broken, nobody deployed it." > Thank you, Dmitry >=20 From fred@cisco.com Mon Apr 18 14:37:03 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6170E07FD for ; Mon, 18 Apr 2011 14:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msGrHRyPC+bA for ; Mon, 18 Apr 2011 14:37:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id EC5DFE07F3 for ; Mon, 18 Apr 2011 14:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1565; q=dns/txt; s=iport; t=1303162622; x=1304372222; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2vGgdI0HFGmOy/Jg0LBxZNY+127UHp/KYSadcV7gyAU=; b=fDyExnzqGDFsje1jdelR8nGY44CB2MGpoI5QQLm5MErz1uZBpkBmoaPs NupB0hDPx73b5zbenyc02HJQz7Vj8D2UZ+7i7xG5XGHLb+h2X295z3oET d9YsJDZ+zYwQDQcQghE3YeWtuSUTbcqRMyXibZz1e5GzqnIVAYgRgjynE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOWtrE2rRDoI/2dsb2JhbAClQXeIb6B3nFKFcQSFYogeg3U X-IronPort-AV: E=Sophos;i="4.64,235,1301875200"; d="scan'208";a="683468122" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2011 21:37:02 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3ILavwR001413; Mon, 18 Apr 2011 21:37:02 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 18 Apr 2011 14:37:02 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 18 Apr 2011 14:37:02 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DAC432B.90403@inex.ie> Date: Mon, 18 Apr 2011 14:36:46 -0700 Message-Id: <9A2C3AE3-8833-4A3F-8AFB-9E27209EFED3@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:37:03 -0000 On Apr 18, 2011, at 6:56 AM, Nick Hilliard wrote: > ID Authors: would you view such an addition as within scope for this = document, or do you see an explicit end-game definition as work for a = future ID? I'm wearing my "chair" hat here, but I don't have it pulled on too = tight. This is as much my personal opinion as it is chair-ness. To my way of thinking, turn-off dates are as much a business issue as a = technology issue. Telling vendors that we wish they would turn 6to4 off = by default is useful guidance to them; I have no delusions that it means = that they will have done so in new products they produce or (by way of = patches) have updated a significant subset of their field deployment by = any date certain. I might expect operators to look at the traffic in = their networks and make decisions about their own need to null-route = anycast addresses or implement 6to4 relays, and to include these two = drafts in their lines of reasoning. But I can just as easily imagine one = operator deciding that it has no business requirement to cater to 6to4 = traffic while the next one finds an overwhelming need. My suggestion to = the first would not be about 6to4; it would be to deploy IPv6 natively = to all of its customers and in so doing make the point irrelevant. My = suggestion to the second would be the same, albeit for different = reasons.=20 I don't think turn-off dates, whether now for 6to4 or a few years hence = for IPv4, are the IETF's purview. I do think technical advice we give = can be helpful.= From jhw@apple.com Mon Apr 18 16:03:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3165E082A for ; Mon, 18 Apr 2011 16:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8jJGIb6t8bk for ; Mon, 18 Apr 2011 16:03:12 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id 2AE38E069C for ; Mon, 18 Apr 2011 16:03:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00MJVEOU6W51@mail-out.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 16:03:08 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-bc-4dacc32b597a Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 4D.F1.20744.C23CCAD4; Mon, 18 Apr 2011 16:03:08 -0700 (PDT) Received: from [17.193.13.64] by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJV00NQAEP70P20@cardamom.apple.com> for v6ops@ietf.org; Mon, 18 Apr 2011 16:03:07 -0700 (PDT) From: james woodyatt In-reply-to: <9A2C3AE3-8833-4A3F-8AFB-9E27209EFED3@cisco.com> Date: Mon, 18 Apr 2011 16:03:07 -0700 Message-id: <7D82CF17-C3D9-40D3-BBD3-B115310292F2@apple.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <9A2C3AE3-8833-4A3F-8AFB-9E27209EFED3@cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 23:03:12 -0000 On Apr 18, 2011, at 14:36 , Fred Baker wrote: > > I don't think turn-off dates, whether now for 6to4 or a few years hence for IPv4, are the IETF's purview. That's not how I see it. IETF created 6to4 by issuing a Proposed Standard that defined the special-purpose usage of the 2002::/16 prefix. It is therefore perfectly within IETF's ambit to issue a new Proposed Standard that obsoletes the previous standard and redefines the usage of the 2002::/16 prefix as not for use on the public Internet. Shorter james: clearly, IETF *may* do this; the question before us is whether we *shall* do it. -- james woodyatt member of technical staff, core os networking From fred@cisco.com Mon Apr 18 16:15:50 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E777E0894 for ; Mon, 18 Apr 2011 16:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.207 X-Spam-Level: X-Spam-Status: No, score=-110.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsd6oACAl2T8 for ; Mon, 18 Apr 2011 16:15:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 07B18E073B for ; Mon, 18 Apr 2011 16:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1100; q=dns/txt; s=iport; t=1303168548; x=1304378148; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=hN48PDqW1OqpiwqXQwrGIp66ldl3sVlt137fZzMb5c0=; b=lxfiALE6GiIdhUZ91jGsJuUjKcHXHHxj7DmSSIh2++bwOeQhA2jxpgN6 c/g23O3bTZ9+Gp59BBZK+wcAET0yNqUMtJhc4Pa5jZru6qGf7uoP7mBvh FKesxubePYoSFDcmwLCETTNwtCtCxKyBvjj2gwKhIw3P1JSO4AVHtkNqQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOTErE2rRDoG/2dsb2JhbAClP3eIb6FlnFuFcQSFYogeg3U X-IronPort-AV: E=Sophos;i="4.64,236,1301875200"; d="scan'208";a="432426961" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 18 Apr 2011 23:15:47 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3INEhOs021549; Mon, 18 Apr 2011 23:15:47 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 18 Apr 2011 16:15:47 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 18 Apr 2011 16:15:47 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <7D82CF17-C3D9-40D3-BBD3-B115310292F2@apple.com> Date: Mon, 18 Apr 2011 16:15:47 -0700 Message-Id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <9A2C3AE3-8833-4A3F-8AFB-9E27209EFED3@cisco.com> <7D82CF17-C3D9-40D3-BBD3-B115310292F2@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 23:15:50 -0000 On Apr 18, 2011, at 4:03 PM, james woodyatt wrote: > On Apr 18, 2011, at 14:36 , Fred Baker wrote: >>=20 >> I don't think turn-off dates, whether now for 6to4 or a few years = hence for IPv4, are the IETF's purview. >=20 > That's not how I see it. IETF created 6to4 by issuing a Proposed = Standard that defined the special-purpose usage of the 2002::/16 prefix. = It is therefore perfectly within IETF's ambit to issue a new Proposed = Standard that obsoletes the previous standard and redefines the usage of = the 2002::/16 prefix as not for use on the public Internet. Or to simply declare the old RFC historic, which is what we're = discussing. That's significantly different than an operational turn-off date. > Shorter james: clearly, IETF *may* do this; the question before us is = whether we *shall* do it. >=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 Mon Apr 18 18:40:59 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A8AEE06E1 for ; Mon, 18 Apr 2011 18:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.829 X-Spam-Level: X-Spam-Status: No, score=-102.829 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj6YVKKB0vvA for ; Mon, 18 Apr 2011 18:40:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id A47C7E0692 for ; Mon, 18 Apr 2011 18:40:58 -0700 (PDT) Received: by iwn39 with SMTP id 39so5773377iwn.31 for ; Mon, 18 Apr 2011 18:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n+LQJJBjwLkMPitmxM2reYPUql+dpEU6rvNqqirk1FQ=; b=PcJiISLDAMvnK5EtnSHvm+17+l19dC2L1QBoR9PhPbW+DexcFbm79TxkHPKFZn1E+7 W4a0b2aFE7aJgiFfT6nHEUtmrjLWP7rzTuVaS5A5Z5s3SXecoaFrXRGC0IHP2m1b3WnH fhuEPyx636KD0AQsVMPuH7MnAUi9JQht3oxaM= 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=Gs3325MtJMJ50fsQfSsxfUWyOt8HBiyZXIj1JONPQxoXEHySqwONM3S3HNsQ03QAXa RUGS5Np3E1XGo9fOj50BHxpn/kgPHA05OB54mU268I//RmS3VEGoOGage5ebnWqz8Qbq 3JjD8l/GubHKwLXa61YEs5rpNC+ezzF/bf2fc= Received: by 10.42.161.71 with SMTP id s7mr7006149icx.507.1303177257118; Mon, 18 Apr 2011 18:40:57 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id ww2sm2818653icb.15.2011.04.18.18.40.55 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 18:40:56 -0700 (PDT) Message-ID: <4DACE824.1010402@gmail.com> Date: Tue, 19 Apr 2011 13:40:52 +1200 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: <4DAB9A38.1000506@bogus.com> In-Reply-To: <4DAB9A38.1000506@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft minutes second session Thursday 31 March, 17:40-19:40 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 01:40:59 -0000 On 2011-04-18 13:56, Joel Jaeggli wrote: > Thursday 31 March, 17:40-19:40 > 12) Advisory Guidelines for 6to4 Deployment > > http://tools.ietf.org/agenda/80/slides/v6ops-6.pdf > > 11-Mar-11, > > brian capenter - Brian Carpenter > > trying to put toothpaste back in the tube Actually I said that I don't believe in trying to put toothpaste back in the tube > people having been complaining about 6to4 for a long time > this is an attempt to do something > > was not deisnged as an unmanaged solution designed > > filtering of protocol 41 is the main reason for these failures > > summary of issues > > advice to vendors > > do not enable 6to4 by default > > do not do it from rfc1918 addresses (bug) > > return destination unreachable if you can't do v6 > > don't break protocol 41 > > advice to transit ISPs > > even if you hate 6to4 you can only make things better if you run a router > > as a content provider running a local relay will definently help if you > plan to support ipv6 Brian From newbery@gmail.com Mon Apr 18 18:50:26 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EB02FE0694 for ; Mon, 18 Apr 2011 18:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aYgjBNQEnVc for ; Mon, 18 Apr 2011 18:50:26 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2D8F2E067C for ; Mon, 18 Apr 2011 18:50:26 -0700 (PDT) Received: by pzk30 with SMTP id 30so3157510pzk.31 for ; Mon, 18 Apr 2011 18:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:cc:references:message-id:x-mailer; bh=F6eezXk94QN5hiEREIXxi3yw1pvhzRK2AoDRdNUbRao=; b=CQO6rZfC0qGDGfL+hn4zhkjEVEetDYzQhz9hG9JKeDNf8FpH+ADgwppmzzPuZqU/M7 wt+6RiFycRXPTPOAGlCIAd/BxYWQzoF+i35O419bNCNXtRFEO6rXMGHpcj68vUmsf8Q8 YnqYW3NTzw/oDkM6jGDoiPtCJ/EYkZTVMRiqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:cc :references:message-id:x-mailer; b=dJ8Ue48Ew0BqP7BoxeWEkw3b/hm648vnYmcxoKgbelP3pcxByqoSpi4p/YzruZex1x pUOPuZHL+qsZFFgJbWmq1HlWxW9x+Sf0/s2fsSfTtUcayT8M7IAC+Dbz4iP2xyURUstu nPRWMd0lKMJARKxImZu40T3FcpCfNfWGlr9hc= Received: by 10.68.21.164 with SMTP id w4mr1822874pbe.53.1303177825512; Mon, 18 Apr 2011 18:50:25 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id g6sm2649067pbh.59.2011.04.18.18.50.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 18:50:24 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2-600588293; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 19 Apr 2011 13:50:14 +1200 In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> Cc: IPv6 Ops WG References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> Message-Id: <36C3CD00-07C3-4D11-A2C5-6D69103541A3@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 01:50:27 -0000 --Apple-Mail-2-600588293 Content-Type: multipart/alternative; boundary=Apple-Mail-1-600583916 --Apple-Mail-1-600583916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18/04/2011, at 6:00 AM, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-6to4-advisory. 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. >=20 > 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. Support, from an operator. Anything that helps in the short term is to = be applauded, while I continue to beat on my vendors to fix their = equipment so I can deploy the real thing. --Apple-Mail-1-600583916 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This is = to initiate a two week working group last call of = draft-ietf-v6ops-6to4-advisory. 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.
=

Support, from an operator. = Anything that helps in the short term is to be applauded, while I = continue to beat on my vendors to fix their equipment so I can deploy = the real thing.

= --Apple-Mail-1-600583916-- --Apple-Mail-2-600588293 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNDE5MDE1MDE5 WjAjBgkqhkiG9w0BCQQxFgQUx0dX17VaCKlNj2DY+7kSQNEN74owgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBAGspVZTn3ETFvPTyNZSCOhnGRmI7Omx6YXqTYFlkJ9R03NN075rzv3TUteVY JfXPmyHtICA9UBlMiUP1DTUg+L/II9+iHROwK+wSqHATM6IzaA5wMiT7waQyFwAXUs1z4KyIP8TY aUochY7FemuNWfDRVRDxog0ouklQjCZwdcRfiaOORUHP9TpXT4WT2lO6XPO0ejztuAO1ncRqd0By b5boqNADFFAuHx9zeXfsI1wnK7JdDFMfUqQ0BixXJwpulzGsitqIM/emS5PrzGNTuDx/NqzUeFCW BP536zu3gLsXnN7WklNV0wWA/5Bv0WqzPgAmogkcK2wBymrxg6cDprEAAAAAAAA= --Apple-Mail-2-600588293-- From brian.e.carpenter@gmail.com Mon Apr 18 19:10:48 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 01B7BE0674 for ; Mon, 18 Apr 2011 19:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.683 X-Spam-Level: X-Spam-Status: No, score=-102.683 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28fQzGHUTkzs for ; Mon, 18 Apr 2011 19:10:47 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 48587E0690 for ; Mon, 18 Apr 2011 19:10:44 -0700 (PDT) Received: by iye19 with SMTP id 19so5795091iye.31 for ; Mon, 18 Apr 2011 19:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RrYP4s46llG+shTrcAntAah2GFDxda+GZbxFMb+ozfA=; b=vWcbYNUCwEf28xJlxwT6OdcOU/B3mrVhkI/sznxXyZ0W0U8pWrIPo1uXZGKSrCRFUz QYM+hR5bFQZBpkgxaQJMx6TFVGPUmjXJXSf9REr6bh929C9EJR/+NoJqpgso9fe2JioJ 7oEzkyOUtyRyo2nggUWl4/CIDGL9uRlhOa8pY= 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=oR0AMcS381Hq4+flogmJkKdKEcnnAHnQJppOmqS8TWdZIsAFR7nxSy0UMVrJfweST7 A2dy4BVeivk8j+LMteF0pkBf3m9h7uXJUjrrGnG5Ue9b384E0W7JaN2lassMZOEDnKiD Hfzbd23Qwv+ehx6pMoj0cGm97FDXudjF1ZHy4= Received: by 10.231.95.195 with SMTP id e3mr4160833ibn.122.1303179043933; Mon, 18 Apr 2011 19:10:43 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id e9sm3066878ibb.15.2011.04.18.19.10.41 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 19:10:43 -0700 (PDT) Message-ID: <4DACEF1F.8060608@gmail.com> Date: Tue, 19 Apr 2011 14:10:39 +1200 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: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@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-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:10:48 -0000 After a fair amount of thought, I have decided that I support this document without reservation. I support the recommendation that RFC 3068 support should be off by default in CPEs and end-user hosts; the reasons for this are clear enough in my companion draft. Specifically, I support the choice of "SHOULD NOT enable" (rather than MUST NOT) because it leaves open the option for a CPE or host vendor to enable RFC 3068 by default if there is a sound reason to do so for a specific product. I support the recommendation to reclassify RFC 3056 as Historic, because its time is past. The reason for inventing 6to4 in the first place was for the benefit of customers whose ISPs could not deploy IPv6. There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers, so it is entirely reasonable to consider the technique as Historic. I see no point in declaring a notional sunset date for the 2002::/16 prefix. On the contrary, as the companion draft indicates, relays advertising this prefix are needed as long as there is residual 6to4 traffic in the network. The question of 2002:: addresses in AAAA records is covered in the companion draft. Regards Brian Carpenter (co-author of RFC 3056) On 2011-04-18 06:00, Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-to-historic. 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon Apr 18 19:22:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43967E0674 for ; Mon, 18 Apr 2011 19:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.036 X-Spam-Level: X-Spam-Status: No, score=-103.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSSJJkbFyEVN for ; Mon, 18 Apr 2011 19:22:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id C03F4E0611 for ; Mon, 18 Apr 2011 19:22:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so5802361iwn.31 for ; Mon, 18 Apr 2011 19:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/WJGCHYHPqrNbRw5lwgJ90k8Zdc8uHhU8SWYxZWuiLI=; b=b5rOvsQPUMZTWE33gVFQ4HjpotKTCmL7vmoUkdb9s77p8IXJAKDYIIfvY2L2Q17y/r iWlgbCzJ1qD+bO4wfxjUL5tMvl/WJuJ/LGe8eAR/la/tjWqoadyLyrnFv7K8TjVh9Spw Kb7TSJgF6lv/q0P9YRWIyX+WvsdBJUxVhIV5I= 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=k+naZxCAix1DtdgWxt329ueqw4OxKdtzhBLwnQuaw9ze7xwTLlTdrClBBLD/qu1rEU +9MwH/R0Y5lw/rlAazlzWt0g6uxeHwDd2m0wU4IWK+6RpWsKsLsN6ynPeQmTUyOCvzkW nQ5OEtjjd9MefaeQ/6lC5jHrQlkkZaGgjNkak= Received: by 10.42.77.1 with SMTP id g1mr814784ick.329.1303179755882; Mon, 18 Apr 2011 19:22:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id i26sm3067040iby.58.2011.04.18.19.22.33 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 19:22:35 -0700 (PDT) Message-ID: <4DACF1E7.1090103@gmail.com> Date: Tue, 19 Apr 2011 14:22:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Guillaume.Leclanche@swisscom.com References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <20110418092234.GA19317@srv03.cluenet.de> <4269EA985EACD24987D82DAE2FEC62E503765CFB@XMB-AMS-101.cisco.com> <1BE5D090C6244A49B9815F339F76EA4507ADD883@SG000708.corproot.net> In-Reply-To: <1BE5D090C6244A49B9815F339F76EA4507ADD883@SG000708.corproot.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:22:38 -0000 > Somebody should make sure that there is no side-effects on RFC5969 (6rd) that references RFC3056 several times. I don't think so. The recommendations that are most likely to affect 6rd are ones like 'don't filter Proto 41', 'don't block PMTUD' and 'don't run 6to4 relays unintentionally' that can only help 6rd run better. Brian From ggm+ietf@apnic.net Mon Apr 18 19:26:43 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 796A4E06FE for ; Mon, 18 Apr 2011 19:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.004 X-Spam-Level: X-Spam-Status: No, score=-101.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sffhuk7bDecA for ; Mon, 18 Apr 2011 19:26:43 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfc.amsl.com (Postfix) with ESMTP id 73182E06EF for ; Mon, 18 Apr 2011 19:26:42 -0700 (PDT) Received: from dynamic149.apnic.net (dynamic149.apnic.net [203.119.42.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0D13FB67B5; Tue, 19 Apr 2011 12:26:41 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Date: Tue, 19 Apr 2011 12:26:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:26:43 -0000 There are ancillary services associated with 2.0.0.2.ip6.arpa which are = provided by APNIC under the auspices of RFC5158. I just want to confirm to people that irrespective of this proposed = change, APNIC intends to continue to provide reverse-DNS delegation, = until its clear the community at large doesn't require the service. Should de-delegation of the space be intended, can I please suggest that = this is done via an instruction in dnsop which re-delegates to the AS112 = service, since there exists a substantial volume of reverse-DNS in 6to4 = already, and having it delegated removes this NXDOMAIN load from the = root. This traffic exists as a consequence of packets being seen to come from = 2002::/16 source IP. It is not actually necessary for a complete = end-to-end exchange to run to completion for the DNS lookup to happen = (consider firewall/ACL rules with logging) And so will continue even if = the protocol itself is deprecated, for some time. -George On 18/04/2011, at 4:00 AM, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-6to4-to-historic. 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. >=20 > 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. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon Apr 18 19:38:09 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8561DE06B6 for ; Mon, 18 Apr 2011 19:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPdD-DVVgRRG for ; Mon, 18 Apr 2011 19:38:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id D91DCE06AB for ; Mon, 18 Apr 2011 19:38:08 -0700 (PDT) Received: by iye19 with SMTP id 19so5813813iye.31 for ; Mon, 18 Apr 2011 19:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4taGS3QTHSvR35A01iDdA8WSLSAJdf8wt48gznOP4Bs=; b=vLaiT0FVd/DkKlc1slqpuG9fhKnKZz6I1YQXaourSB6Uf7ZKzqZtXXdVBn2IFQVkVJ MmfSCKel/S/qiNZo7qsfYpgtd5wZxhccsYehMBEeh2LNdeEcuqEceOH7ghGGgKOaom8s haUnRc0iIx97YngkukFqrPnLj8Jfrt/HEv8Ho= 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=JECZF0ruvboVDBRvpOVIHZG91dao/Ja738ovlmbp/pXLbuZSn3aCPseJjglau7/ZFC Du60m+aGz0TPdMacerQXHeSywfArY9v706jfp3JHP+yvennkBLxLcJy5ib19HRLH4LoH +WILPcyydX7/hHPmI286Ey/mgWPlVgbPY31Zo= Received: by 10.42.172.2 with SMTP id l2mr1972655icz.113.1303180688514; Mon, 18 Apr 2011 19:38:08 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id uf10sm2845476icb.5.2011.04.18.19.38.05 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 19:38:07 -0700 (PDT) Message-ID: <4DACF58B.1030707@gmail.com> Date: Tue, 19 Apr 2011 14:38:03 +1200 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, Randy Bush , dwcarder@wisc.edu, otroan@employees.org References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:38:09 -0000 On 2011-04-18 11:37, Randy Bush wrote: > this proposal is far too mild. 6to4 should not be less preferred, it > should be removed. it is damaging to ipv6 in that it gives the users > the belief that ipv6 sucks, when it is 6to4 that sucks. I'm not sure this comment was really addressed to the document in question, whose goal is to reduce the sucking; it's the other document that attempts to reinsert the toothpaste into the tube. On 2011-04-19 03:00, Dale W. Carder wrote: > I support this document, but considering nearly all of our site's failures > with 6to4 (and IPv6, for that matter) is section 4.1.5, I see two issues: > > - This is hardly discussed in section 3 True. I only realised the seriousness of this issue for some sites very recently; I can expand the text. > - The text 4.1.5 may not be strong enough to disable this awful behavior. > I would claim that an "internet sharing" host MUST not ever advertise 6to4 > prefixes. This would very much help the interim situation between now > and when 6to4 is off by default. I am not sure that setting the > preference to low actually would change anything. If there is no other source of RAs it clearly won't help. I can strengthen the language, but this draft is not standards track, so you will have to campaign elsewhere for an official MUST NOT. On 2011-04-19 06:52, Ole Troan wrote: > I support this document. > > two comments: > [I-D.vandevelde-v6ops-harmful-tunnels]. as I'm not entirely certain if we will continue this document now that we have the two 6to4 document, you may want to remove this reference. If you can make a definite statement like "we will not continue this document" the choice will be easy ;-) > section 4.1. on vendor issues. I would have liked to see a suggestion of a "reachability check" for the 6to4 relay. and make that as a prerequisite to enable the 6to4 function in an implementation. a reachability check could be as simple as sending an ICMP echo packet to one of ones own addresses via the 6to4 relay. I think the idea is a good one (also see draft-nward-6to4-qualification), but I don't think we should recommend vapourware to ISPs in this draft, which is trying to say what can be done this afternoon or tomorrow morning. Thanks Brian From gaurab@lahai.com Mon Apr 18 19:58:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60A02E06AB for ; Mon, 18 Apr 2011 19:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ahzesbk5X2V for ; Mon, 18 Apr 2011 19:58:17 -0700 (PDT) Received: from ns.lahai.com (ns.lahai.com [204.61.215.166]) by ietfc.amsl.com (Postfix) with ESMTP id 929DDE06A0 for ; Mon, 18 Apr 2011 19:58:17 -0700 (PDT) Received: from Gaurabs-MacBook-Pro.local (cm38.epsilon112.maxonline.com.sg [222.164.112.38]) (authenticated bits=0) by ns.lahai.com (8.13.8/8.13.8) with ESMTP id p3J2wEdk001769 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Apr 2011 02:58:16 GMT Message-ID: <4DACFA45.2020806@lahai.com> Date: Tue, 19 Apr 2011 03:58:13 +0100 From: Gaurab Raj Upadhaya User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: v6ops@ietf.org References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.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 authentication, not delayed by milter-greylist-2.0.2 (ns.lahai.com [204.61.215.166]); Tue, 19 Apr 2011 02:58:16 +0000 (GMT) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:58:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, Section 4.4 I would say that the assumption IXPs have IPv6 connectivity is false. Modern Internet Exchange Points (IXP) are recognized to be layer2 providers. They have v6 addressing on the IXP-LAN, but that address space may or may not be routed (in most cases, it's not routed). Recommending that IXP provide any kind of transit service (6to4 relay is transit to 6to4 packets) is a major NO in my books. Otherwise, I have read the draft and support it. - -gaurab On 4/17/11 7:00 PM, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-6to4-advisory. 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. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2s+kUACgkQSo7fU26F3X0OswCgyqCyfEOw/xAaIki+hEqTMFQx rcAAoKuobMqnL5c3G1ccgbrcG1oTawg8 =dZku -----END PGP SIGNATURE----- From brian.e.carpenter@gmail.com Mon Apr 18 20:13:05 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC3D4E0710 for ; Mon, 18 Apr 2011 20:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwKae5HXxwDM for ; Mon, 18 Apr 2011 20:13:04 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 97C3FE0696 for ; Mon, 18 Apr 2011 20:13:04 -0700 (PDT) Received: by pwi5 with SMTP id 5so3374653pwi.31 for ; Mon, 18 Apr 2011 20:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E0mQnN983AHmFVdMR0MymRF8lio4fHhkQnOD11EDiYY=; b=GgFGubwdsakWkEYlt7AwfcRbpLrmMoXf8pvn2f8JbAIK4PFvTDtXXLMxOAUEnUfV7k 44geR8/d72W4GFdaYAC3VeEacArIh+jqF4Rjv12iH6eM/sV1HX7Do3kJHWYmfhdwu35x uFw1XAOGnZ8obEyCmHIjlmy2KhEUM8IRL8eM8= 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=nxq6yi0Xone+f/BUgKA3S2e/PSCrX4zty0MFEoQMFEtxjBFucsOfL+CvYIsyZHvCAp esSTMwaHd0QJ2RFbZVEwucZ15dK8nJ5aoAiqbfiKZ4VlQd6XaTpEdKu4SB2FKWtaBQtz iIcL3fCG/WFYGdgGoUev8RMT/UOnUUR3WuspM= Received: by 10.68.41.8 with SMTP id b8mr846220pbl.277.1303182782998; Mon, 18 Apr 2011 20:13:02 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g6sm2687443pbq.13.2011.04.18.20.13.01 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 20:13:02 -0700 (PDT) Message-ID: <4DACFDBB.3090001@gmail.com> Date: Tue, 19 Apr 2011 15:12:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gaurab Raj Upadhaya References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> In-Reply-To: <4DACFA45.2020806@lahai.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 03:13:05 -0000 On 2011-04-19 14:58, Gaurab Raj Upadhaya wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Brian, > > Section 4.4 > > I would say that the assumption IXPs have IPv6 connectivity is false. > > Modern Internet Exchange Points (IXP) are recognized to be layer2 > providers. They have v6 addressing on the IXP-LAN, but that address > space may or may not be routed (in most cases, it's not routed). > > Recommending that IXP provide any kind of transit service (6to4 relay is > transit to 6to4 packets) is a major NO in my books. Well, clearly the recommendation can only apply to an L3 service provider, so the draft should make it clear that it only refers to IXPs that are providing L3 services in general. Let's not discuss here whether that is a good or bad choice for an IXP. Brian > > Otherwise, I have read the draft and support it. > > - -gaurab > > > On 4/17/11 7:00 PM, Fred Baker wrote: >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-6to4-advisory. 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. >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > - -- > > http://www.gaurab.org.np/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.16 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2s+kUACgkQSo7fU26F3X0OswCgyqCyfEOw/xAaIki+hEqTMFQx > rcAAoKuobMqnL5c3G1ccgbrcG1oTawg8 > =dZku > -----END PGP SIGNATURE----- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gaurab@lahai.com Mon Apr 18 21:27:15 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C5A4E066C for ; Mon, 18 Apr 2011 21:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66hy65T9uAVp for ; Mon, 18 Apr 2011 21:27:14 -0700 (PDT) Received: from ns.lahai.com (ns.lahai.com [204.61.215.166]) by ietfc.amsl.com (Postfix) with ESMTP id 9FBE8E0611 for ; Mon, 18 Apr 2011 21:27:14 -0700 (PDT) Received: from Gaurabs-MacBook-Pro.local (cm38.epsilon112.maxonline.com.sg [222.164.112.38]) (authenticated bits=0) by ns.lahai.com (8.13.8/8.13.8) with ESMTP id p3J4QYFA002120 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2011 04:26:56 GMT Message-ID: <4DAD0EFA.4060508@lahai.com> Date: Tue, 19 Apr 2011 05:26:34 +0100 From: Gaurab Raj Upadhaya User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian E Carpenter References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> In-Reply-To: <4DACFDBB.3090001@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (ns.lahai.com [204.61.215.166]); Tue, 19 Apr 2011 04:27:02 +0000 (GMT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 04:27:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/19/11 4:12 AM, Brian E Carpenter wrote: >> Well, clearly the recommendation can only apply to an L3 service >> provider, so the draft should make it clear that it only refers to >> IXPs that are providing L3 services in general. Let's not discuss >> here whether that is a good or bad choice for an IXP. I disagree with the definition that an IXP can provide L3 transit services of any kind. When it does, it becomes an transit provider and ceases being an IXP. FWIW, I know do not know of any IXP, that provide L3 services in general. What can those be ? May be you can give some examples, if I am missing something there. - -gaurab - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2tDvoACgkQSo7fU26F3X12JQCdF9LGuiOGyzd15rsiLfy/Tjli VNIAn0SnyMcLbyTAbjUC//gg2VN4/yiX =fSj4 -----END PGP SIGNATURE----- From randy@psg.com Mon Apr 18 21:32:16 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 179C5E0683 for ; Mon, 18 Apr 2011 21:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN2rylA84YVb for ; Mon, 18 Apr 2011 21:32:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 981FAE066C for ; Mon, 18 Apr 2011 21:32:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QC2bj-0006is-3v; Tue, 19 Apr 2011 04:32:11 +0000 Date: Tue, 19 Apr 2011 13:32:36 +0900 Message-ID: From: Randy Bush To: Roger =?ISO-8859-1?Q?J=F8rgensen?= In-Reply-To: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DABE200.3040504@redpill-linpro.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-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 04:32:16 -0000 > I'm a bit surprised with some of the argument against this and the > other document in the queue right now, why are people _still_ focused > on tunnels over IPv4 to get IPv6 running? 6to4 is one of them. i am less surprised. after all, over in idr they are rediscovering slip. > Wasn't that something we did like 10 years ago when there was not so > many other real options? > > Shouldn't the focus now being on real IPv6 deployment as Tore say? +1 From randy@psg.com Mon Apr 18 22:50:13 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E8ECE06CC for ; Mon, 18 Apr 2011 22:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM4E94YxfOMt for ; Mon, 18 Apr 2011 22:50:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id D2862E0696 for ; Mon, 18 Apr 2011 22:50:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QC3pC-0006xe-Bx; Tue, 19 Apr 2011 05:50:10 +0000 Date: Tue, 19 Apr 2011 14:50:36 +0900 Message-ID: From: Randy Bush To: Gaurab Raj Upadhaya In-Reply-To: <4DAD0EFA.4060508@lahai.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> <4DAD0EFA.4060508@lahai.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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 05:50:13 -0000 > FWIW, I know do not know of any IXP, that provide L3 services in > general. What can those be ? May be you can give some examples, if I > am missing something there. ntp, name servers, ... randy From john.mann@monash.edu Mon Apr 18 23:00:57 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7CAD3E0688 for ; Mon, 18 Apr 2011 23:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtKYEKjfTvVX for ; Mon, 18 Apr 2011 23:00:56 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfc.amsl.com (Postfix) with ESMTP id 0F190E065F for ; Mon, 18 Apr 2011 23:00:55 -0700 (PDT) Received: from mail-vx0-f169.google.com ([209.85.220.169]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTa0lF3od2/D0m+bOjDXxjxTpp/eWuOJk@postini.com; Mon, 18 Apr 2011 23:00:56 PDT Received: by mail-vx0-f169.google.com with SMTP id 20so5447449vxk.0 for ; Mon, 18 Apr 2011 23:00:55 -0700 (PDT) Received: by 10.52.101.194 with SMTP id fi2mr5486865vdb.16.1303192855043; Mon, 18 Apr 2011 23:00:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.182.226 with HTTP; Mon, 18 Apr 2011 23:00:35 -0700 (PDT) In-Reply-To: <4DAD0EFA.4060508@lahai.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> <4DAD0EFA.4060508@lahai.com> From: "John Mann (ITS)" Date: Tue, 19 Apr 2011 16:00:35 +1000 Message-ID: To: Gaurab Raj Upadhaya Content-Type: multipart/alternative; boundary=bcaec548a40b32dde004a13f3ba0 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 06:00:57 -0000 --bcaec548a40b32dde004a13f3ba0 Content-Type: text/plain; charset=ISO-8859-1 Hi, >From the " [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question" thread, james woodyatt wrote on 14 April 2011 03:05 > When I review the data at , what I see is that a lot of academic networks are numbering their local area networks with public IPv4 addresses and that a fair > number of hosts on those networks are successfully getting workable IPv6 service over 6to4 through the Ottowa IX anycast relay. ... More-generally, http://ottix.net/resources.html they provide for their members and customers DNS, FTP, 6to4, NNTP, NTP, router servers, Web, whois Thanks, John On 19 April 2011 14:26, Gaurab Raj Upadhaya wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/19/11 4:12 AM, Brian E Carpenter wrote: > > >> Well, clearly the recommendation can only apply to an L3 service > >> provider, so the draft should make it clear that it only refers to > >> IXPs that are providing L3 services in general. Let's not discuss > >> here whether that is a good or bad choice for an IXP. > > I disagree with the definition that an IXP can provide L3 transit > services of any kind. When it does, it becomes an transit provider and > ceases being an IXP. > > FWIW, I know do not know of any IXP, that provide L3 services in > general. What can those be ? May be you can give some examples, if I am > missing something there. > > - -gaurab > > > - -- > > http://www.gaurab.org.np/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.16 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2tDvoACgkQSo7fU26F3X12JQCdF9LGuiOGyzd15rsiLfy/Tjli > VNIAn0SnyMcLbyTAbjUC//gg2VN4/yiX > =fSj4 > -----END PGP SIGNATURE----- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec548a40b32dde004a13f3ba0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

From the "=A0[v6ops] draft-ietf-v6op= s-6to4-advisory-00 and IPv6 day question" thread,
=A0james w= oodyatt <jhw@apple.com> wrote on= 14 April 2011 03:05
>=A0When I review the data at <http://stats.ottix.net/ipv6/>, what I see is that a lot of a= cademic networks are numbering their local area networks with public IPv4 a= ddresses and that a fair > number of hosts on those networks are success= fully getting workable IPv6 service over 6to4 through the Ottowa IX anycast= relay. ...

they provide for their= members and customers DNS, FTP, 6to4, NNTP, NTP, router servers, Web, whoi= s

Thanks,
=A0 =A0 John

On 19 April 2011 14:26, Gaurab Raj Upadhaya <gaurab@lahai.com>= wrote:
-----BEGIN PGP SIGNED MES= SAGE-----
Hash: SHA1

On 4/19/11 4:12 AM, Brian E Carpenter wrote:

>> Well, clearly the recommendation can only apply to an L3 service >> provider, so the draft should make it clear that it only refers to=
>> IXPs that are providing L3 services in general. Let's not disc= uss
>> here whether that is a good or bad choice for an IXP.

I disagree with the definition that an IXP can provide L3 transit
services of any kind. When it does, it becomes an transit provider and
ceases being an IXP.

FWIW, I know do not know of any IXP, that provide L3 services in
general. What can those be ? May be you can give some examples, if I am
missing something there.

- -gaurab


- --

http://www.gaurab.o= rg.np/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2tDvoACgkQSo7fU26F3X12JQCdF9LGuiOGyzd15rsiLfy/Tjli
VNIAn0SnyMcLbyTAbjUC//gg2VN4/yiX
=3DfSj4
-----END PGP SIGNATURE-----
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec548a40b32dde004a13f3ba0-- From geier@geier.ne.tz Mon Apr 18 23:59:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0B96BE068B for ; Mon, 18 Apr 2011 23:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTnVDp-ni9Dg for ; Mon, 18 Apr 2011 23:59:11 -0700 (PDT) Received: from tih.co.tz (a.mx.tih.co.tz [217.172.181.156]) by ietfc.amsl.com (Postfix) with ESMTP id 4B356E05F5 for ; Mon, 18 Apr 2011 23:59:11 -0700 (PDT) Received: from [127.0.0.1] ([::ffff:196.200.46.18]) (AUTH: LOGIN geier@tih.co.tz, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by tih.co.tz with esmtp; Tue, 19 Apr 2011 08:59:08 +0200 id 002C8117.4DAD32BD.00004ED4 Message-ID: <4DAD32BC.6040708@geier.ne.tz> Date: Tue, 19 Apr 2011 09:59:08 +0300 From: Frank Habicht User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: v6ops@ietf.org References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> <4DAD0EFA.4060508@lahai.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] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 06:59:12 -0000 Hi, first time, so be gentle ;-) On 4/19/2011 8:50 AM, Randy Bush wrote: >> FWIW, I know do not know of any IXP, that provide L3 services in >> general. What can those be ? May be you can give some examples, if I >> am missing something there. > > ntp, name servers, ... Randy: s/provide L3 services/provide L3 transit services/ agree with Gaurab. would like see "IXP" gone from that section. under 2. inside that section: "If it reaches a wider scope, the relay will be offering a free ride to non-clients" replaced by " .... non-transit-clients" ? though don't want to delay this ID. haven't read all of the ID yet. need to have the anycast 6to4 be disabled/unused [1] first before removing prefixes and reverseDNS Frank [1] by OS vendors, and they are on the list. From randy@psg.com Tue Apr 19 01:19:42 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E39B2E0680 for ; Tue, 19 Apr 2011 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1qUqg+PreEb for ; Tue, 19 Apr 2011 01:19:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 611D7E0677 for ; Tue, 19 Apr 2011 01:19:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QC69r-0007M8-Qb; Tue, 19 Apr 2011 08:19:40 +0000 Date: Tue, 19 Apr 2011 17:20:06 +0900 Message-ID: From: Randy Bush To: Frank Habicht In-Reply-To: <4DAD32BC.6040708@geier.ne.tz> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> <4DAD0EFA.4060508@lahai.com> <4DAD32BC.6040708@geier.ne.tz> 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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 08:19:43 -0000 >>> FWIW, I know do not know of any IXP, that provide L3 services in >>> general. What can those be ? May be you can give some examples, if I >>> am missing something there. >> ntp, name servers, ... > Randy: > s/provide L3 services/provide L3 transit services/ i strongly agree that, if the IX provider offers transit, then they are not an IX provider, they are a transit provider with a switch. randy From pch-b6B5344D9@u-1.phicoh.com Tue Apr 19 01:53:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D783E0677 for ; Tue, 19 Apr 2011 01:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.074 X-Spam-Level: X-Spam-Status: No, score=-4.074 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, GB_I_LETTER=-2, J_BACKHAIR_46=1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSsKTGom1kUe for ; Tue, 19 Apr 2011 01:53:35 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id ECED9E0665 for ; Tue, 19 Apr 2011 01:53:34 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QC6ge-0001hLC; Tue, 19 Apr 2011 10:53 +0200 Message-Id: To: "Templin, Fred L" From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-reply-to: Your message of "Mon, 18 Apr 2011 10:45:43 -0700 ." Date: Tue, 19 Apr 2011 10:53:25 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 08:53:36 -0000 In your letter dated Mon, 18 Apr 2011 10:45:43 -0700 you wrote: >> - what do you do with hosts that do support IPv6 over=20 >> ethernet but don't >> support ISATAP? > >Hosts that don't support ISATAP but that are buried >somewhere deep in an IPv4-routed site would require >the site administrator to dig down deep into the site >while turning up IPv6 routing on all of the routers >in the path. That might be easier for some sites than >for others. That's why I suggested that routers be connected by tunnels. Or alternatively the creation of vlans that bypass those IPv4 routers. Note, I'm just listing alternatives. I'm not implying that ISATAP should not be used at all. But I think that if this becomes an RFC, then it should try to list reasonable alternatives. >You can probably tell from this that I believe all >hosts should support ISATAP. It really isn't hard to >do, and can be slipped in as part of an automated >(or pulled) host S/W upgrade. Yes, for mainstream operating systems. But these days there are many other types of devices that people want to have internet access. >> - This looks like an all of nothing property: either you=20 >> enable ISATAP for all >> hosts in your organisation or you don't. What if you just=20 >> want a few subnets >> to have IPv6 connectivity (or if you want the phase it in=20 >> gradually)? > >It doesn't have to be all or nothing, and there are >ways to operationally limit IPv6 connectivity to only >certain IPv4 subnets. For example, configure ISATAP >routers to only send RA responses to hosts that use >specific IPv4 subnet prefixes. That could be an option. Assuming that all ISATAP clients understand that you can have an ISATAP interface without a prefix and that routers support that kind of functionality. >Another way is to partition the site based on domain >names, e.g., configure the domain name >'isatap.engineering.foo.com' but do not configure >the domain name 'isatap.marketing.foo.com'.=20 I doubt that anybody is going to change their use of DNS domain names just to accomodate ISATAP. >> - It seems that all hosts are in a single subnet. What about=20 >> the security=20 >> implications. If you have internal IPv4 firewalls in your=20 >> organisation do >> you also have to figure out how to filter ISATAP traffic with them? > >Well, if there are IPv4 firewalls in the site then the >ISATAP link (or links) would be partitioned, and some >ISATAP hosts would not be able to reach others directly. >This could be solved if the firewalls were reconfigued >to recognize ip-proto-41 and perform IPv6 firewalling >based on the inner IPv6 packet, but that seems somewhat >unlikely in general practice. >Remember however that I am anticipating the use of IPv6 >only for accessing IPv6 correspondents outside of the >site, so in the general case all/most ISATAP-serviced >IPv6 traffic would be going from host<->router. At work, there are kinds of filters between various nets. And not just completely denying all traffic between hosts, but allowing or denying incoming TCP connections, outgoing connections. To certain ranges of ports. Assuming an IPv4 router doesn't know anything about IPv6, it will be very hard to specify those kinds of filters for IPv6 traffic. So the only option will be to disallow proto-41 completely. If you do that, then putting IPv6 addresses for local servers in DNS will also not be an option. So you set yourself up to just being a client network that cannot have any servers. >> - ISATAP doesn't have multicast. What about protocols that=20 >> rely on multicast, >> like mDNS? > >For service discovery within the site, why not just >continue to use IPv4? For site-internal communications, >why fix what isn't broken? Because it is confusing? You enable a new protocol but have to keep relying on a legacy protocols for all kinds of services. Not a problem in the immediate future. But I would only introduce such an option as a last resort. >> - Suppose that at some point you will have a native IPv6=20 >> backbone. How do you >> route (in a decentralized way) between ISATAP and the=20 >> native IPv6 nets? > >I'm not sure I quite understand the question (some >pictures might help) but when native IPv6 routers >show up on the link the hosts should begin using >native IPv6 and either deprecate ISATAP or use it >as a backup service. Suppose you have a huge number of ISATAP hosts on a site and then you start introducing a few native subnets. How do you route the traffic from all those ISATAP hosts in an efficient way to the native subnets? From gaurab@lahai.com Tue Apr 19 02:54:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 56630E0682 for ; Tue, 19 Apr 2011 02:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ8QsH014slZ for ; Tue, 19 Apr 2011 02:54:54 -0700 (PDT) Received: from ns.lahai.com (ns.lahai.com [204.61.215.166]) by ietfc.amsl.com (Postfix) with ESMTP id A0EE8E0680 for ; Tue, 19 Apr 2011 02:54:54 -0700 (PDT) Received: from 19.80.16.172.in-addr.arpa.noptr.antlabs.com ([202.79.202.244]) (authenticated bits=0) by ns.lahai.com (8.13.8/8.13.8) with ESMTP id p3J9snhh003374 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2011 09:54:51 GMT Message-ID: <4DAD5BE9.6000209@lahai.com> Date: Tue, 19 Apr 2011 10:54:49 +0100 From: Gaurab Raj Upadhaya User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> <4DAD0EFA.4060508@lahai.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 authentication, not delayed by milter-greylist-2.0.2 (ns.lahai.com [204.61.215.166]); Tue, 19 Apr 2011 09:54:51 +0000 (GMT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 09:54:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/19/11 6:50 AM, Randy Bush wrote: >> FWIW, I know do not know of any IXP, that provide L3 services in >> general. What can those be ? May be you can give some examples, if I >> am missing something there. > > ntp, name servers, ... To rephrase myself, these services are not same as providing transit. With a 6to4 relay, the IXP essentially gets into a position where it's passing packets through its relay to another network. So, it's then a transit provider. The references to IXP in this document is not necessary. - -gaurab - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2tW+kACgkQSo7fU26F3X2WcACfVm9iR1nd7a1HI5/uJj0Rcoxl /e4AoJrKPw0IaUjprfMubG+JnQWAxNUs =xaNu -----END PGP SIGNATURE----- From gvandeve@cisco.com Tue Apr 19 07:04:16 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4154E06F6 for ; Tue, 19 Apr 2011 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.638 X-Spam-Level: X-Spam-Status: No, score=-9.638 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7rv4j8fO+Nh for ; Tue, 19 Apr 2011 07:04:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id E1701E068E for ; Tue, 19 Apr 2011 07:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=424; q=dns/txt; s=iport; t=1303221855; x=1304431455; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=deE0+7ebSeXZHDrMkvPWICa3VadiP6GRPET/9snLez0=; b=E+YmsbQxDIkQ6wu3n52arvZgt7siHz581UN4717baJP9vyHsdibpljcI REzb5hUWP7B7JVJ9ymSIQSzGvbr/Z7pd+Aj2zGZ3p1dbRc86Re6KpW7Df TfcP2hl0ltH/9xAK7J1YbXHyp24esATgHm9O9vUhOLxrzHU7B02gK7VX6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwEAAGVrU2Q/khRgWdsb2JhbAClKxQBARYmJagenGuFcQSSCg X-IronPort-AV: E=Sophos;i="4.64,239,1301875200"; d="scan'208";a="26296391" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2011 14:04:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3JE4EXL031062; Tue, 19 Apr 2011 14:04:15 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); Tue, 19 Apr 2011 16:04:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Apr 2011 16:04:13 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FC873@XMB-AMS-101.cisco.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C73185@PLSWM12A.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/SlhqpajWsmz1Eij6v0rgI8jKJRis6QAgAAD+4CAAAGygIAA4MyQgAGgbYA= References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C73185@PLSWM12A.ad.sprint.com> From: "Gunter Van de Velde (gvandeve)" To: "George, Wes E IV [NTK]" , , X-OriginalArrivalTime: 19 Apr 2011 14:04:14.0901 (UTC) FILETIME=[AA7E3E50:01CBFE9A] Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:04:16 -0000 Jordi> I oppose to a deprecation of 6to4. It is already the last resort, and I will be happy if the anycast is by default configured off. This way, 6to4 is still useful peer-to-peer. _______ GV> If it is v6 you want over v4 in a dynamic 'managed' tunnel infrastructure, then go to your favourite vendor and ask them about this. I am sure they have a solution for that. No need to have 6to4 for this at all. G/ From Fred.L.Templin@boeing.com Tue Apr 19 07:28:49 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EB7C9E073A for ; Tue, 19 Apr 2011 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.063 X-Spam-Level: X-Spam-Status: No, score=-7.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, GB_I_LETTER=-2, J_BACKHAIR_46=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lex1gc6izZCV for ; Tue, 19 Apr 2011 07:28:44 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 5F94FE070F for ; Tue, 19 Apr 2011 07:28:43 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3JESajI007606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2011 07:28:39 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3JESZJC026760; Tue, 19 Apr 2011 07:28:35 -0700 (PDT) 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 p3JESZVc026756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Apr 2011 07:28:35 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 19 Apr 2011 07:28:35 -0700 From: "Templin, Fred L" To: Philip Homburg Date: Tue, 19 Apr 2011 07:28:35 -0700 Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) Thread-Index: Acv+b0TOCz1iNkpaRAajeysV2+d+5gAKkrQg Message-ID: References: <7B64C6B4-23DB-44AE-8941-ACE9964A3578@cisco.com> <001201cbfbba$8d5e2fc0$a81a8f40$@org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in Predominantly IPv4 Sites - (pre-draft) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:28:50 -0000 Hi Philip,=20 > -----Original Message----- > From: pch-b6B5344D9@u-1.phicoh.com=20 > [mailto:pch-b6B5344D9@u-1.phicoh.com] On Behalf Of Philip Homburg > Sent: Tuesday, April 19, 2011 1:53 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment=20 > in Predominantly IPv4 Sites - (pre-draft)=20 >=20 > In your letter dated Mon, 18 Apr 2011 10:45:43 -0700 you wrote: > >> - what do you do with hosts that do support IPv6 over=3D20 > >> ethernet but don't > >> support ISATAP? > > > >Hosts that don't support ISATAP but that are buried > >somewhere deep in an IPv4-routed site would require > >the site administrator to dig down deep into the site > >while turning up IPv6 routing on all of the routers > >in the path. That might be easier for some sites than > >for others. >=20 > That's why I suggested that routers be connected by tunnels. Networks-within-networks, I guess? I have already described that in RANGER: http://www.rfc-editor.org/rfc/rfc5720.txt > Or alternatively > the creation of vlans that bypass those IPv4 routers. Tim Chown has already described that in RFC4554: http://www.rfc-editor.org/rfc/rfc4554.txt =20 > Note, I'm just listing alternatives. I'm not implying that=20 > ISATAP should not > be used at all. But I think that if this becomes an RFC, then=20 > it should try > to list reasonable alternatives. OK. If anything gets published, I'll be sure to cite RFC4554. > >You can probably tell from this that I believe all > >hosts should support ISATAP. It really isn't hard to > >do, and can be slipped in as part of an automated > >(or pulled) host S/W upgrade. >=20 > Yes, for mainstream operating systems. But these days there=20 > are many other > types of devices that people want to have internet access. Anything that runs embeded linux already has ISATAP. But, you have a point that there may be a class of low-end devices that might be better off as native IPv6. I'm not advocating that there be no native IPv6 edge networks - see Section 3.2.4 of: 'draft-ietf-v6ops-tunnel-loops'. > >> - This looks like an all of nothing property: either you=3D20 > >> enable ISATAP for all > >> hosts in your organisation or you don't. What if you just=3D20 > >> want a few subnets > >> to have IPv6 connectivity (or if you want the phase it in=3D20 > >> gradually)? > > > >It doesn't have to be all or nothing, and there are > >ways to operationally limit IPv6 connectivity to only > >certain IPv4 subnets. For example, configure ISATAP > >routers to only send RA responses to hosts that use > >specific IPv4 subnet prefixes. >=20 > That could be an option. Assuming that all ISATAP clients=20 > understand that > you can have an ISATAP interface without a prefix and that=20 > routers support > that kind of functionality. ISATAP interfaces without a prefix are certainly possible when the hosts can run DHCPv6 over the ISATAP interface (see Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops'). But, that's not what I'm saying. What I'm saying is that if the router receives an RS from a host on an IPv4 subnet that it is not configured to serve, then it can silently ignore the RS. > >Another way is to partition the site based on domain > >names, e.g., configure the domain name > >'isatap.engineering.foo.com' but do not configure > >the domain name 'isatap.marketing.foo.com'.=3D20 >=20 > I doubt that anybody is going to change their use of DNS=20 > domain names just to > accomodate ISATAP. No, that's not what I'm saying. I'm just talking about adding the hostname 'isatap' to the domain name suffixes that the site already has deployed. The 'engineering' and 'marketing' domain names I cited above are examples of domain names that are pre-existing within the (fictitious) site and not something that gets added just to accommodate ISATAP. > >> - It seems that all hosts are in a single subnet. What about=3D20 > >> the security=3D20 > >> implications. If you have internal IPv4 firewalls in your=3D20 > >> organisation do > >> you also have to figure out how to filter ISATAP traffic=20 > with them? > > > >Well, if there are IPv4 firewalls in the site then the > >ISATAP link (or links) would be partitioned, and some > >ISATAP hosts would not be able to reach others directly. > >This could be solved if the firewalls were reconfigued > >to recognize ip-proto-41 and perform IPv6 firewalling > >based on the inner IPv6 packet, but that seems somewhat > >unlikely in general practice. >=20 > >Remember however that I am anticipating the use of IPv6 > >only for accessing IPv6 correspondents outside of the > >site, so in the general case all/most ISATAP-serviced > >IPv6 traffic would be going from host<->router. >=20 > At work, there are kinds of filters between various nets. And not just > completely denying all traffic between hosts, but allowing or=20 > denying incoming > TCP connections, outgoing connections. To certain ranges of ports. Right. > Assuming an IPv4 router doesn't know anything about IPv6, it=20 > will be very > hard to specify those kinds of filters for IPv6 traffic. So=20 > the only option > will be to disallow proto-41 completely. Right, but that is for going "horizontally crosswise" within a site hierarchy - not "vertically up and down". Any path that would try to go horizontally crosswise would first have to be tested to see if there are filters in place. > If you do that, then putting IPv6 addresses for local servers=20 > in DNS will also > not be an option. > > So you set yourself up to just being a client network that=20 > cannot have any > servers. Why not? A client in the site can always get to the servers by going vertically up to an ISATAP router and then back down to the server. If there are no filters in the path, then it can route optimize and go horizontally crosswise instead. Again, please see Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops'.=20 >=20 > >> - ISATAP doesn't have multicast. What about protocols that=3D20 > >> rely on multicast, > >> like mDNS? > > > >For service discovery within the site, why not just > >continue to use IPv4? For site-internal communications, > >why fix what isn't broken? >=20 > Because it is confusing? You enable a new protocol but have=20 > to keep relying > on a legacy protocols for all kinds of services. Not a problem in the > immediate future. But I would only introduce such an option=20 > as a last resort. What's confusing about just leaving well enough alone and saving the site $M's of investment to change out applications, data bases, routers, etc. that only know about IPv4? Hosts will use the name service and source address selection to know when to use IPv4 vs. IPv6. > >> - Suppose that at some point you will have a native IPv6=3D20 > >> backbone. How do you > >> route (in a decentralized way) between ISATAP and the=3D20 > >> native IPv6 nets? > > > >I'm not sure I quite understand the question (some > >pictures might help) but when native IPv6 routers > >show up on the link the hosts should begin using > >native IPv6 and either deprecate ISATAP or use it > >as a backup service. >=20 > Suppose you have a huge number of ISATAP hosts on a site and then you > start introducing a few native subnets. How do you route the=20 > traffic from > all those ISATAP hosts in an efficient way to the native subnets? Section 3.2.4 of 'draft-ietf-v6ops-tunnel-loops'. Thanks - Fred fred.l.templin@boeing.com= From gvandeve@cisco.com Tue Apr 19 07:48:23 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8638E06E9 for ; Tue, 19 Apr 2011 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.718 X-Spam-Level: X-Spam-Status: No, score=-9.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO9ezPy-bUzZ for ; Tue, 19 Apr 2011 07:48:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 8A09AE06B2 for ; Tue, 19 Apr 2011 07:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=413; q=dns/txt; s=iport; t=1303224482; x=1304434082; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KIKcSQ+GVFk7zWYhOtQh2lS+EwSqccNhNgHo01Jvb4w=; b=NvrNXkTqHWRVBa+AxdwjHpZZcYVlpdQVfK+t7MnCjoNsoQKewDHhIbMS d93Gz8oFFjlcgBYFFALYrw8dJqz9JHaLgRhYnb+EbGLRI83/Hoab2inGN nWaj69xDhoyMIBarGokPg2V6j/Kz6qTeqmDrZKH9vdlTowe0mfek2zYNs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwEAACgrU2Q/khMgWdsb2JhbAClKxQBARYmJaganGmFcQSSCg X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="84237358" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2011 14:48:01 +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 p3JEm1Pw000979; Tue, 19 Apr 2011 14:48:01 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); Tue, 19 Apr 2011 16:48:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Apr 2011 16:47:59 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FC8B4@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv9Mwa6fASf9UxtTvKB5UONEAX/PABbYNZw References: <20110417.210253.74655326.sthaug@nethelp.no> From: "Gunter Van de Velde (gvandeve)" To: , X-OriginalArrivalTime: 19 Apr 2011 14:48:01.0543 (UTC) FILETIME=[C8180170:01CBFEA0] Cc: ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:48:23 -0000 <>start Jordi snip<> There are two ways of doing this: 1) Killing all the protocols that may not work because some operators don't know how to configure filters <>end snip<> GV> 6to4 is to die anyway when native is deployed, not sure that is for the other technologies you mentioned. And right now it causes more damage then it is bringing and fixing will cost more resources then its worth. G/ From joelja@bogus.com Tue Apr 19 08:10:35 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 857B9E076C for ; Tue, 19 Apr 2011 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+MhGguWObZ7 for ; Tue, 19 Apr 2011 08:10:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id AC47BE0766 for ; Tue, 19 Apr 2011 08:10:34 -0700 (PDT) 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 p3JFAEUO015507 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Apr 2011 15:10:14 GMT (envelope-from joelja@bogus.com) Message-ID: <4DADA5D1.2040404@bogus.com> Date: Tue, 19 Apr 2011 08:10:09 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <20110417.210253.74655326.sthaug@nethelp.no> <4269EA985EACD24987D82DAE2FEC62E5037FC8B4@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E5037FC8B4@XMB-AMS-101.cisco.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]); Tue, 19 Apr 2011 15:10:15 +0000 (UTC) Cc: v6ops@ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:10:35 -0000 On 4/19/11 7:47 AM, Gunter Van de Velde (gvandeve) wrote: > <>start Jordi snip<> > There are two ways of doing this: > > 1) Killing all the protocols that may not work because some operators > don't know how to configure filters There's always the case that protocol 41 filtering was done deliberately... we still break those users. joel > <>end snip<> > > GV> 6to4 is to die anyway when native is deployed, not sure that is for > the other technologies you mentioned. And right now it causes more > damage then it is bringing and fixing will cost more resources then its > worth. > > G/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From wmaton@ryouko.imsb.nrc.ca Tue Apr 19 08:10:49 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B80BE0793 for ; Tue, 19 Apr 2011 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63nm9oIExRTH for ; Tue, 19 Apr 2011 08:10:49 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfc.amsl.com (Postfix) with ESMTP id C90D9E078E for ; Tue, 19 Apr 2011 08:10:48 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.4) with ESMTP id p3JFAWU8005375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2011 11:10:37 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p3JFAV7u005369; Tue, 19 Apr 2011 11:10:31 -0400 Date: Tue, 19 Apr 2011 11:10:31 -0400 (EDT) From: "William F. Maton Sotomayor" To: George Michaelson In-Reply-To: <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:10:49 -0000 On Tue, 19 Apr 2011, George Michaelson wrote: > Should de-delegation of the space be intended, can I please suggest > that this is done via an instruction in dnsop which re-delegates to the > AS112 service, since there exists a substantial volume of reverse-DNS in > 6to4 already, and having it delegated removes this NXDOMAIN load from the > root. I agree with this, since we would need to capture such traffic at AS112. Perhaps the draft should have a modified IANA Considerations section to include a note about reverse delegation when the time comes. wfms From jhw@apple.com Tue Apr 19 08:48:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 427D2E077A for ; Tue, 19 Apr 2011 08:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.561 X-Spam-Level: X-Spam-Status: No, score=-105.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUT+C7RHaGDE for ; Tue, 19 Apr 2011 08:48:17 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id 5C4D6E0788 for ; Tue, 19 Apr 2011 08:48:02 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJW006GBOZBSY71@mail-out.apple.com> for v6ops@ietf.org; Tue, 19 Apr 2011 08:47:54 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-09-4dadaeaaff73 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 87.27.23242.AAEADAD4; Tue, 19 Apr 2011 08:47:54 -0700 (PDT) Received: from 67-218-103-230.cust.layer42.net ([67.218.103.230]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJW00GLXP7SRB20@koseret.apple.com> for v6ops@ietf.org; Tue, 19 Apr 2011 08:47:54 -0700 (PDT) From: james woodyatt In-reply-to: <4DACEF1F.8060608@gmail.com> Date: Tue, 19 Apr 2011 08:47:45 -0700 Message-id: <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:48:18 -0000 On Apr 18, 2011, at 7:10 PM, Brian E Carpenter wrote: > > There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers... I wonder if the operator community shares this assessment of their situation. Every major consumer ISP serving my metropolitan area today has one very good reason for not deploying native IPv6 yet, i.e. there is negligible market demand for it, because there is no content to speak of that requires it, and there won't be any such content until more enterprises are shut out of IPv4 by address exhaustion at the RIRs. Also, most consumer ISPs have the excuse that too many of their provider-provisioned CPE gateways do not support native IPv6 routing. -- james woodyatt member of technical staff, core os networking From swmike@swm.pp.se Tue Apr 19 09:19:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2359CE07C0 for ; Tue, 19 Apr 2011 09:19:39 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu2etBmKr+6L for ; Tue, 19 Apr 2011 09:19:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 87D82E077D for ; Tue, 19 Apr 2011 09:19:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4AC189C; Tue, 19 Apr 2011 18:19:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 46BB69A; Tue, 19 Apr 2011 18:19:34 +0200 (CEST) Date: Tue, 19 Apr 2011 18:19:34 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:19:39 -0000 On Tue, 19 Apr 2011, james woodyatt wrote: > Every major consumer ISP serving my metropolitan area today has one very > good reason for not deploying native IPv6 yet, i.e. there is negligible > market demand for it, because there is no content to speak of that > requires it, and there won't be any such content until more enterprises > are shut out of IPv4 by address exhaustion at the RIRs. ... or Microsoft customers actually start to use DA instead of their current VPNs. It's my personal belief that as a lot of enterprise is letting XP die and go for Windows 7, they will want IPv6 for some of the new functionality. Also, I belive customer demand might pick up quickly when services like Google Talk, Skype and perhaps Facetime supports IPv6 and all of a sudden people discover this and tell their friends that a lot of their former trouble from both parties sitting behind NAT is solved by getting IPv6. I will personally tell my mom to switch to an IPv6 enabled ISP when the things in the last paragraph happens. -- Mikael Abrahamsson email: swmike@swm.pp.se From ichiroumakino@gmail.com Tue Apr 19 10:39:52 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 516FCE071E for ; Tue, 19 Apr 2011 10:39:52 -0700 (PDT) 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw-lqlxqmigS for ; Tue, 19 Apr 2011 10:39:51 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id F36D8E069C for ; Tue, 19 Apr 2011 10:39:50 -0700 (PDT) Received: by eye13 with SMTP id 13so2279182eye.31 for ; Tue, 19 Apr 2011 10:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=y0LpGRMJycEM3LsxwuHB1THdeWOI5ToMkENRAuEXtlw=; b=bHjdIvYJxa3QsKCw+7Cv9zAQWoqL5W1ZB9B0tXUaa+p314xegzJdUETTxuX4RHcfT8 Jtjc4DTQi5rYlW+8W/am0SUy10Q0GLD/2dcRDKXyj0Imq+dr+wGM11tVHki0l/PFuxSy zJ743PILg6ZPsqvl04GSjvjyI7707TIsqQpIc= 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=r3u5Ne6x2xl8+EnVDQm/3/T0gwSB7+0hxs4e/xIphrjnvXmXY36hxb5vf+k0geHDh4 Hl/JvwMFMEVYbRbe6G4XdleY45Vz2iDXJoRx7Fn7AacmRW6GXCEhifmTBAVW8LDFNdB4 WTL7durtNK+VV/rcyRGz18+vqEK8AEoI1zaPI= Received: by 10.213.1.142 with SMTP id 14mr2775756ebf.143.1303234789456; Tue, 19 Apr 2011 10:39:49 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id m55sm84872eei.8.2011.04.19.10.39.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 10:39:48 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> Date: Tue, 19 Apr 2011 19:39:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:39:52 -0000 George, > There are ancillary services associated with 2.0.0.2.ip6.arpa which = are provided by APNIC under the auspices of RFC5158. >=20 > I just want to confirm to people that irrespective of this proposed = change, APNIC intends to continue to provide reverse-DNS delegation, = until its clear the community at large doesn't require the service. >=20 > Should de-delegation of the space be intended, can I please suggest = that this is done via an instruction in dnsop which re-delegates to the = AS112 service, since there exists a substantial volume of reverse-DNS in = 6to4 already, and having it delegated removes this NXDOMAIN load from = the root. >=20 > This traffic exists as a consequence of packets being seen to come = from 2002::/16 source IP. It is not actually necessary for a complete = end-to-end exchange to run to completion for the DNS lookup to happen = (consider firewall/ACL rules with logging) And so will continue even if = the protocol itself is deprecated, for some time. 6to4-historic has the following in the IANA considerations section: IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as "deprecated", pointing to this document. Redelegation of the domain for any usage requires justification via an IETF Standards Action [RFC5226]. are you happy with that text or would you rather that the document was = silent on the issue of the 6to4 reverse zone? cheers, Ole= From fred@cisco.com Tue Apr 19 11:13:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 118B8E0845 for ; Tue, 19 Apr 2011 11:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLO9V0NczAit for ; Tue, 19 Apr 2011 11:13:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 2BC8EE07FB for ; Tue, 19 Apr 2011 11:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2248; q=dns/txt; s=iport; t=1303236791; x=1304446391; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=3HeTzPhLQLInCCX5rsTcibv+8Z9CqmU9dpku3xlg/ys=; b=khTnwtgPGHw6QaucMd1jpukWVE4PHMwYwMdGMJVDEmCVrbTLeaSjlAED PrBcVR5VRC50+S1tN/p0ZR/o+PdUwwaWpwPQUyjbU4JgPxOG79eH9dOLl LfOeGmnx+SR7dC3DvfogEr7LVl9We/UGJjmatQRbGYu+uEG1Lvz/rMdEK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI7QrU2tJV2Z/2dsb2JhbACkTV93iG+fXY8nAY1GhXEEhWeIIIN8 X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="684024576" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 18:13:10 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JICw7n006399; Tue, 19 Apr 2011 18:13:05 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 19 Apr 2011 11:13:07 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 19 Apr 2011 11:13:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 19 Apr 2011 11:12:42 -0700 Message-Id: <7D72FFC5-9144-44D1-BBE6-CC35ED771190@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> To: Ole Troan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, George Michaelson , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:13:12 -0000 On Apr 19, 2011, at 10:39 AM, Ole Troan wrote: > George, >=20 >> There are ancillary services associated with 2.0.0.2.ip6.arpa which = are provided by APNIC under the auspices of RFC5158. >>=20 >> I just want to confirm to people that irrespective of this proposed = change, APNIC intends to continue to provide reverse-DNS delegation, = until its clear the community at large doesn't require the service. >>=20 >> Should de-delegation of the space be intended, can I please suggest = that this is done via an instruction in dnsop which re-delegates to the = AS112 service, since there exists a substantial volume of reverse-DNS in = 6to4 already, and having it delegated removes this NXDOMAIN load from = the root. >>=20 >> This traffic exists as a consequence of packets being seen to come = from 2002::/16 source IP. It is not actually necessary for a complete = end-to-end exchange to run to completion for the DNS lookup to happen = (consider firewall/ACL rules with logging) And so will continue even if = the protocol itself is deprecated, for some time. >=20 > 6to4-historic has the following in the IANA considerations section: >=20 > IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as > "deprecated", pointing to this document. Redelegation of the domain > for any usage requires justification via an IETF Standards Action > [RFC5226]. >=20 > are you happy with that text or would you rather that the document was = silent on the issue of the 6to4 reverse zone? >=20 > cheers, > Ole To my way of thinking, it makes a lot of sense to tell people that 6to4 = has problems and probably isn't a great thing to use, and to recommend = that products disable it by default. I worry about playing too quickly = with the prefix. My biggest worry is that it will get put into a filter = somewhere and then get re-delegated for some other use. If you have = watched the behavior of reputation services ("address <> appears to do = bad things, we suggest you filter it") and people's antics getting off = them, you can imagine the scenarios I envision. I think pointing to the prefix as "deprecated" makes sense. I seriously = hope it is never re-delegated.= From ichiroumakino@gmail.com Tue Apr 19 11:18:30 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F32DE0865 for ; Tue, 19 Apr 2011 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzFH3wKUUHIt for ; Tue, 19 Apr 2011 11:18:29 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 0C26BE0860 for ; Tue, 19 Apr 2011 11:18:25 -0700 (PDT) Received: by eye13 with SMTP id 13so2291123eye.31 for ; Tue, 19 Apr 2011 11:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=XiqXO4nCTa80bhuTOhpm6jHPxSCMz3ywoS+0kpY1Bxc=; b=hWB+6u+1vjLKhy2vSIhJqtwpSRlaEwXU0WWTft5WKdwi5ypvplV0riADDDafXslOhB cV0yUkKzmiho0JgvetigjVCEc6nrPgL+gl27SRH4EYdyt5qZMeUAbi+okpZzdysdNDJc dy8rApY7ZnOQivL+OKd8uRAk631Wr5F1vJ4MI= 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=E/YHtBBaq9JDsAWTLJelTBEtZRV2gjB3lSgIOGLC4A/qyu22JKx/7NvFVbGD9kg4LD k3dB1k3KQV6c+Tgi7e6yNnK67TPyJM/rwwfunirNnvQz214ilEOrMXmbm5CWM2VjxI7j HOoekv/qPQSlkDbnHZlFprkd/H6CWKn8xDUws= Received: by 10.213.113.204 with SMTP id b12mr1270995ebq.104.1303237104318; Tue, 19 Apr 2011 11:18:24 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id k51sm107628eei.3.2011.04.19.11.18.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 11:18:23 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <7D72FFC5-9144-44D1-BBE6-CC35ED771190@cisco.com> Date: Tue, 19 Apr 2011 20:18:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> <7D72FFC5-9144-44D1-BBE6-CC35ED771190@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, George Michaelson , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:18:30 -0000 Fred, >>> There are ancillary services associated with 2.0.0.2.ip6.arpa which = are provided by APNIC under the auspices of RFC5158. >>>=20 >>> I just want to confirm to people that irrespective of this proposed = change, APNIC intends to continue to provide reverse-DNS delegation, = until its clear the community at large doesn't require the service. >>>=20 >>> Should de-delegation of the space be intended, can I please suggest = that this is done via an instruction in dnsop which re-delegates to the = AS112 service, since there exists a substantial volume of reverse-DNS in = 6to4 already, and having it delegated removes this NXDOMAIN load from = the root. >>>=20 >>> This traffic exists as a consequence of packets being seen to come = from 2002::/16 source IP. It is not actually necessary for a complete = end-to-end exchange to run to completion for the DNS lookup to happen = (consider firewall/ACL rules with logging) And so will continue even if = the protocol itself is deprecated, for some time. >>=20 >> 6to4-historic has the following in the IANA considerations section: >>=20 >> IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as >> "deprecated", pointing to this document. Redelegation of the domain >> for any usage requires justification via an IETF Standards Action >> [RFC5226]. >>=20 >> are you happy with that text or would you rather that the document = was silent on the issue of the 6to4 reverse zone? >>=20 >> cheers, >> Ole >=20 >=20 > >=20 > To my way of thinking, it makes a lot of sense to tell people that = 6to4 has problems and probably isn't a great thing to use, and to = recommend that products disable it by default. I worry about playing too = quickly with the prefix. My biggest worry is that it will get put into a = filter somewhere and then get re-delegated for some other use. If you = have watched the behavior of reputation services ("address <> appears to = do bad things, we suggest you filter it") and people's antics getting = off them, you can imagine the scenarios I envision. >=20 > I think pointing to the prefix as "deprecated" makes sense. I = seriously hope it is never re-delegated. indeed, and as the proposed says that would require IETF standards = action. cheers, Ole From Wesley.E.George@sprint.com Tue Apr 19 11:23:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C513FE0856 for ; Tue, 19 Apr 2011 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZHwoO0QJrrp for ; Tue, 19 Apr 2011 11:23:01 -0700 (PDT) Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfc.amsl.com (Postfix) with ESMTP id 99A6CE0685 for ; Tue, 19 Apr 2011 11:23:00 -0700 (PDT) Received: from mail89-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.8; Tue, 19 Apr 2011 18:22:59 +0000 Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id 9DEAA3B0075; Tue, 19 Apr 2011 18:22:59 +0000 (UTC) X-SpamScore: -46 X-BigFish: VS-46(zz9371O1521M542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1303237364685841_19118; Tue, 19 Apr 2011 18:22:44 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.240]) by mail89-am1.bigfish.com (Postfix) with ESMTP id A2F866D8050; Tue, 19 Apr 2011 18:22:44 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 19 Apr 2011 18:22:42 +0000 Received: from PLSWEH01.ad.sprint.com (PLSWEH01.corp.sprint.com [144.226.242.129]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3JIMeVo009368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Apr 2011 13:22:41 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH01.ad.sprint.com ([2002:90e2:f281::90e2:f281]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 13:22:40 -0500 From: "George, Wes E IV [NTK]" To: james woodyatt , IPv6 Ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/qlzoEc7TLmsTU2A3R9TUuPEIZRlXLhQ Date: Tue, 19 Apr 2011 18:22:38 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> In-Reply-To: <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0089_01CBFE9D.41E55420" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:23:01 -0000 ------=_NextPart_000_0089_01CBFE9D.41E55420 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 james woodyatt Sent: Tuesday, April 19, 2011 11:48 AM To: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 18, 2011, at 7:10 PM, Brian E Carpenter wrote: > > There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers... I wonder if the operator community shares this assessment of their situation. ______ [WEG] The premise that providers aren't deploying IPv6 (especially due to lack of content) is a faulty one. I believe that you'll find nearly every operator represented here is in the process of deploying IPv6 within the capabilities of their infrastructure and limits of their capital budgets. May not be rapid enough for your liking, but it is definitely happening. Every major consumer ISP serving my metropolitan area today has one very good reason for not deploying native IPv6 yet, i.e. there is negligible market demand for it, because there is no content to speak of that requires it, and there won't be any such content until more enterprises are shut out of IPv4 by address exhaustion at the RIRs. ______ [WEG] Keeping 6to4 around actually makes this worse, not better. It's not as much lack of content as it is that content providers are reluctant to enable IPv6 without a url hack or a whitelist because of concerns over customer experience due to evident brokenness. 6to4 (and teredo) is a major item that they blame for such. Several major content providers who do support IPv6 have explicitly said that they will continue to blacklist 6to4 because it has such a non-deterministic and mostly poor customer experience. Any application that requires IPv6 is extremely unlikely to hang that upon something as unreliable as 6to4. Regarding whether there is market demand for IPv6 in the consumer space, as I said above, most providers are deploying IPv6 whether there are demands or not because IPv4 is exhausting. Customers don't care what protocol is used to deliver their bits, they care that it works. So if we wait for consumers to ask for IPv6, we're waiting for Godot. Also, most consumer ISPs have the excuse that too many of their provider-provisioned CPE gateways do not support native IPv6 routing. ______ [WEG] There is a solution for that, and it's not 6to4. 6rd is one option if it's actually the provider's CPE infra (modems, DSLAM/CMTS) that doesn't support IPv6. If it's the CPE router (which may be customer-owned) that doesn't support IPv6, the solution is for the CPE gateway vendors to provide software updates with IPv6 support to ALL of their hardware regardless of age unless it's technically impossible on a given device, so that operators aren't limited to the single option of "sorry, you'll have to replace your equipment" in order to roll out IPv6 widely. This is *especially* true for devices which support 6to4 but not native IPv6 today. Wes George ------=_NextPart_000_0089_01CBFE9D.41E55420 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxOTE4 MjI0N1owIwYJKoZIhvcNAQkEMRYEFCiaMZ8l67KYZ3yOLsf99I3p4s9bMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgCl+mMKXe60dEiU2powdBIISftuf2zr4F1Z0ju7t65ErVDPpXCUbYvmPq/SzZxe0kA2U ZzHOKw27szdd8ZN4H8dBLz7chSIlbyM5GJ8eZqH3rb85h7msCJPYLyAxkIsIDsJe+CtN/tOnpQx5 Xu+/2BWa5OjCjuXkVgh0HsdNjhTfAAAAAAAA ------=_NextPart_000_0089_01CBFE9D.41E55420-- From newbery@gmail.com Tue Apr 19 14:30:54 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B46DEE06DE for ; Tue, 19 Apr 2011 14:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaZUo1XWqfWd for ; Tue, 19 Apr 2011 14:30:53 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id A4C43E06BE for ; Tue, 19 Apr 2011 14:30:53 -0700 (PDT) Received: by pxi20 with SMTP id 20so92530pxi.27 for ; Tue, 19 Apr 2011 14:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=/qc95AQDIO5qQfF5kVjByUZoUMOfeyERog394cF3vQ8=; b=UY30elzfBHc6X3vU/A/8yew/TjDEBaTqTT8IRVFm8pYRY1B1W5ZnXihvHGT7/99kQu JCgtjApb4XJpEz38IaRo9v3z78L23UnOlOacm0QwkQHfydjwp0169mDc0zShrFNAb9Sm /I7p5iXEuYparQ+TcoK9r5n74mRngQ2ZJzZdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=p+SKB9GDwix5PQ5JyR7rlxtMtDHVNrQgJIRvXKaUC/nqi4eLwzszrvkPhVnwkV8ehC Jz5cPmh1feaoejN1gi6a+oZP31WwCvUiVXzw4+BdywP16aNK6sTy/uR6V8yF1uGtDUWR 2V9Ap/oTsH5XHEgjOkU0BgP6c1QyWgxOPqK4o= Received: by 10.68.33.42 with SMTP id o10mr9304028pbi.90.1303248653102; Tue, 19 Apr 2011 14:30:53 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id u3sm177791pbh.8.2011.04.19.14.30.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 14:30:51 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2-671413953; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 20 Apr 2011 09:30:40 +1200 In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> To: IPv6 Ops WG References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:30:54 -0000 --Apple-Mail-2-671413953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20/04/2011, at 6:22 AM, George, Wes E IV [NTK] wrote: >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of james woodyatt >=20 > Also, most consumer ISPs have the excuse that too many of their = provider-provisioned CPE gateways do not support native IPv6 > routing. > ______ > [WEG] There is a solution for that, and it's not 6to4. 6rd is one = option if it's actually the provider's CPE infra (modems, > DSLAM/CMTS) that doesn't support IPv6. If it's the CPE router (which = may be customer-owned) that doesn't support IPv6, the solution > is for the CPE gateway vendors to provide software updates with IPv6 = support to ALL of their hardware regardless of age unless it's > technically impossible on a given device, so that operators aren't = limited to the single option of "sorry, you'll have to replace > your equipment" in order to roll out IPv6 widely. This is *especially* = true for devices which support 6to4 but not native IPv6 > today.=20 My discussions with vendors however indicate that in general it IS = technically impossible. Certainly there is a large amount of gear out = there that has no IPv6 support, not even 6to4. This is generally made = very cheaply, usually based on a reference design or chipset and using = firmware and operating system provided by the chipset manufacturer. The = OEM adds a little value, but mostly they have no ability to add = significant extra functionality. It is likely for instance that there is = just insufficient memory to add native IPv6 support. At the low end, = only very recent equipment has sufficient capacity. I know of one low = end CPE vendor that is adding all the right stuff, and their most recent = gateway CAN be upgraded. But their previous model simply lacks the = ability (in their opinion). Furthermore, getting most CPE gateway vendors to expend the considerable = effort---and money---to enable native IPv6 support on their already sold = hardware would bring them in how much revenue? The CPE situation may be shameful, and one might be justifiably grumpy = with (most of) the CPE vendors for not having shipped suitable equipment = for YEARS now, but dealing with the world as it is, I don't see any = realistic alternative for most customers who own their own RGs apart = from having to buy new ones.=20 Where the provider supplies the gateway, it is the provider who is faced = with the prospect of physically replacing hundreds of thousands of = pieces of equipment. Apart from the cost of the equipment, the cost of = the truck rolls will cause the CFO to go pale. Again, the provider = SHOULD have chosen better equipment, assuming that it was in fact = available (in practice, it wasn't, because enough of the SPs didn't = insist on it, so the CPE manufacturers didn't do it), but regardless, = this is the situation faced by many providers. We can argue about how we = got into this situation: I'm only interested in figuring out how we get = out of it.= --Apple-Mail-2-671413953 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNDE5MjEzMDQ1 WjAjBgkqhkiG9w0BCQQxFgQUsyQmd4ftp+6jDvooFoaqZFW4zlwwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBAHKzLZb2/FrZcPd3bXlUZ7TCsjc+sFewqlh4+P5VRsbLSGUsOXQWsovz6mkH DiXP4YTOg+4WzJyzo7rNxLxhac9v9WCMjBwiTPQHcreMgeF3lrTEZ/qIaX6L/RoSRDDubb2cppF1 NvsbVBzTML+w/hxqME6MLAMSOJ3DyRT/51Jdg8krVeUkX3BbMHS9bk6vVbasjuJddl0aE2fDofDG F1A9fW5sH4lnwscKoxdL7wbQOEZTGuxeRLeuOJf1+cILXcAr/BmPst49TqTsvt38asEXOsoEJdVf LgybyziOLN2gI4T6CzeVa7oaO2foDGzm9IApVSukdJrEhg43AqKSOlEAAAAAAAA= --Apple-Mail-2-671413953-- From brian.e.carpenter@gmail.com Tue Apr 19 14:33:40 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F67AE07B4 for ; Tue, 19 Apr 2011 14:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtHUFQUPsFJ6 for ; Tue, 19 Apr 2011 14:33:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id EF665E06BE for ; Tue, 19 Apr 2011 14:33:39 -0700 (PDT) Received: by pwi5 with SMTP id 5so95989pwi.31 for ; Tue, 19 Apr 2011 14:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wuq96dWyc6cncLn5AAQpLYOP2B3whtIYCmfdJbAgLB8=; b=NKVMgnPLOmv0wyeNwVtZIJS6b4mdD8fLNeGpEPI5TnX5FYfOW0IHgCepdkYiGAuXC8 nVhNy7En2Kqujad7DYYgUHDlhEYbllt7eNHw/hy2dLJsi3KfCJdpPTq4t1ODqoaLpa3s ACzGh69zAflKB6qPVJsb0XHJrUgkLIyoTAimI= 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=vdrBF0PU3aHbYC99wJN8284643cVATZtkdv7tzCoIHbd9v+K3ferOwN8F44XIBdp3R NArYmC7s8Jl7KisoLnHiXuq4VyTPlfc/qTiX7fhtO0ud7Merb6Q+AmshfeqS+JivCEMU SxmYcUd7tqGL0BHckTt0leeM4pitzhbwy/2+Y= Received: by 10.68.27.100 with SMTP id s4mr8706662pbg.491.1303248819383; Tue, 19 Apr 2011 14:33:39 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id a4sm177708pbs.25.2011.04.19.14.33.36 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 14:33:38 -0700 (PDT) Message-ID: <4DADFFAE.5060603@gmail.com> Date: Wed, 20 Apr 2011 09:33:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> In-Reply-To: <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:33:40 -0000 Others have answered, so I will only add a few remarks: On 2011-04-20 03:47, james woodyatt wrote: > On Apr 18, 2011, at 7:10 PM, Brian E Carpenter wrote: >> There is now no reason or excuse for a consumer ISP to fail >> to deploy IPv6 for customers... > > I wonder if the operator community shares this assessment of > their situation. > > Every major consumer ISP serving my metropolitan area today > has one very good reason for not deploying native IPv6 yet, > i.e. there is negligible market demand for it, because there > is no content to speak of that requires it, and there won't > be any such content until more enterprises are shut out of > IPv4 by address exhaustion at the RIRs. Yes, short term thinking will cause you long term business problems every time. ISPs have been ignoring this problem for 15 years, but the time when that was in their shareholders' long term interests is clearly past. > Also, most consumer ISPs have the excuse that too many of > their provider-provisioned CPE gateways do not support native > IPv6 routing. That excuse is on the way out, however. Brian > > > -- james woodyatt member of technical staff, > core os networking > > > > _______________________________________________ v6ops mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Tue Apr 19 14:36:36 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 021C5E06BE for ; Tue, 19 Apr 2011 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuFv1OOVj2VD for ; Tue, 19 Apr 2011 14:36:35 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 58C41E07A4 for ; Tue, 19 Apr 2011 14:36:33 -0700 (PDT) Received: by pwi5 with SMTP id 5so97348pwi.31 for ; Tue, 19 Apr 2011 14:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vbUAwp/VHWwy9LEWIdir7JroRLaLoPoAEdp4yklDBro=; b=J6x2UyD4sGL83VEZlopc5kjs7XyiN6bSBHWow+9GXtlnnXg6CzAJRVAe/sXt76Y5r/ 36DWKCmXN5WjDTXKXjD2lk4bC/k6BABJJmKx7ZF6ElM+FU8xcHoRBm27W8lMr9ZxQh3S oEqk80wv148Ha4j0fPnJNRtR1NerV1If0IsmU= 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=CJ0FS72Kvfgwb4tMt/YbJxdAJWx7FimvyJE2f30MYN1XhQkWMJeNGTRjSkOR0lBm1k ypIp8epnFdxd8nJcSJRowExlhydJFwat4VUZ1Al1RHXTW3GUmmxuxIdWklJtINeau2jc XYaFgWSdyQJwQjGT++Z8v+qTs1uISscwYsI4o= Received: by 10.68.44.74 with SMTP id c10mr9504743pbm.441.1303248992749; Tue, 19 Apr 2011 14:36:32 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k1sm178041pbh.34.2011.04.19.14.36.30 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 14:36:32 -0700 (PDT) Message-ID: <4DAE005C.5080005@gmail.com> Date: Wed, 20 Apr 2011 09:36:28 +1200 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: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DACFA45.2020806@lahai.com> <4DACFDBB.3090001@gmail.com> <4DAD0EFA.4060508@lahai.com> <4DAD32BC.6040708@geier.ne.tz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:36:36 -0000 On 2011-04-19 20:20, Randy Bush wrote: >>>> FWIW, I know do not know of any IXP, that provide L3 services in >>>> general. What can those be ? May be you can give some examples, if I >>>> am missing something there. >>> ntp, name servers, ... >> Randy: >> s/provide L3 services/provide L3 transit services/ > > i strongly agree that, if the IX provider offers transit, then they are > not an IX provider, they are a transit provider with a switch. Fair enough. I will rephrase this accordingly. Brian From rogerj@gmail.com Tue Apr 19 14:57:37 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0C62E07EA for ; Tue, 19 Apr 2011 14:57:37 -0700 (PDT) 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.278, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0ZoixvqcKrb for ; Tue, 19 Apr 2011 14:57:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id E077BE06C7 for ; Tue, 19 Apr 2011 14:57:36 -0700 (PDT) Received: by iwn39 with SMTP id 39so119860iwn.31 for ; Tue, 19 Apr 2011 14:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PDGC4PzRgHvhLO8nZbYJ/au1HR+JGTOQPTbXSgnZy5c=; b=WlICe7vqFXks1bhS3jcXgqW31jqx95KOSTWGlGTyT3uTP9mc/iJdYBlWJOdCi0jic/ ypjAtjv4/PpGZuwxUuIrq7sBnWNa+VOo5HkAGa0LnjWbm00QVv4urBTEurMYx0cA7OyA ixuAFLJ2dpxXdSjEeRjYbC6MGFY2hUpUZ5yoM= 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=DRohmC/db8gCODxUk+4q5/ifcac/qO0aB3QA33vk2NVDf9Jo4n7A0SmvaWmt0bFB/K dqV/i2zIPNf4cNEwURYyHvVV99mjcjnnKoJ2L+TNFGn0l6hN/hdS5CJ9l+GKbfbjTOov NTT/ody8PGygTp32P+q2bQRqhFxJdR70BcWSQ= MIME-Version: 1.0 Received: by 10.231.184.156 with SMTP id ck28mr734278ibb.141.1303250255330; Tue, 19 Apr 2011 14:57:35 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Tue, 19 Apr 2011 14:57:35 -0700 (PDT) In-Reply-To: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> Date: Tue, 19 Apr 2011 23:57:35 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Michael Newbery Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:57:38 -0000 On Tue, Apr 19, 2011 at 11:30 PM, Michael Newbery wrote= : > Furthermore, getting most CPE gateway vendors to expend the considerable = effort---and money---to enable native IPv6 support on their already sold ha= rdware would bring them in how much revenue? Think you are forgetting that people actual likely is going to buy new equipment _if_ there is something in it for them. Like a complete new series of CPEs out late 2011 or early 2012 which enable them to access something they can't today, like a new "version" of Internet or however you can put it. .... other thing that can trigger people to replace "old" equipment is thing like the new equipment also will be more eco-friendly, more greenish... In short, don't underestimate that people might replace their "old" (even only 1-2 years) equipment if there is something in it for them. --=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 newbery@gmail.com Tue Apr 19 15:15:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DEAD8E07D2 for ; Tue, 19 Apr 2011 15:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.146 X-Spam-Level: X-Spam-Status: No, score=-3.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LopUvpbPGKjJ for ; Tue, 19 Apr 2011 15:15:29 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id D8A5DE0816 for ; Tue, 19 Apr 2011 15:15:28 -0700 (PDT) Received: by pxi20 with SMTP id 20so115551pxi.27 for ; Tue, 19 Apr 2011 15:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=WlNRulDqVGqTXzxc12TBRqA/W+1wo1pQyJjAcVkl6ic=; b=sJw/Aj+U9bDJU/Xo7xE5GjjkPR2heYpF1u6rjIRnwsduLVWwJdHEBalCsmBngRqUtU yBrrOxX3plOebUGpumSE/esK+GXcwCD0vzfCKYQEvoPnLSsYt+lCmJaM8O9h0CQ46MJe +RSaelTiTVrKKzighPfVjNwQ+tRi0k2TBbzvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=PA/Ye1sC+q33dVYDQDSpahtGv6QlUsOmVCrzpe2+fZwtD7Jop64XZSfYJ5owbAZO5a xassjhCIOZIvTFY0810INbOAaeCdqRfM4LqqK+MBeUrtWlbMghZlbuoW7funDWsV0osn LjHkP5hByha2R0Zq61ThjFrNcFQ7mHORGf76Y= Received: by 10.68.63.164 with SMTP id h4mr1877444pbs.149.1303251327919; Tue, 19 Apr 2011 15:15:27 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id l8sm195013pbg.54.2011.04.19.15.15.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 15:15:26 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-3-674091519; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 20 Apr 2011 10:15:12 +1200 In-Reply-To: To: IPv6 Ops WG References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:15:30 -0000 --Apple-Mail-3-674091519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 20/04/2011, at 9:57 AM, Roger J=F8rgensen wrote: > On Tue, Apr 19, 2011 at 11:30 PM, Michael Newbery = wrote: > >> Furthermore, getting most CPE gateway vendors to expend the = considerable effort---and money---to enable native IPv6 support on their = already sold hardware would bring them in how much revenue? >=20 > Think you are forgetting that people actual likely is going to buy new > equipment _if_ there is something in it for them. Not at all. Getting people to upgrade is obviously attractive to the CPE = vendors. I was responding to the suggestion that these vendors would = upgrade EXISTING equipment, even if they could, and pointing out that = there doesn't seem to be any obvious financial incentive for the CPE = vendors to do so. Certainly over the next few years we can hope that new equipment will do = the right thing. Having said which, if you were to go out to the store = RIGHT NOW and buy a residential gateway that does native IPv6, how easy = would that be?= --Apple-Mail-3-674091519 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNDE5MjIxNTIy WjAjBgkqhkiG9w0BCQQxFgQUZnPZCue/FegY2o8PHJfUB0D7bi8wgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBAB1+yYPauZDvdjuDCG4vPYcDVzPOBUg6jOMTqOfP2Sd/+CV5VcxlscFDbaPE ekKI19DSnifgJH99oWz1fIn1qvRjE4ZNSPBhNQL8jjPj5vbznmA9YSulOMrIhmwsyZj5FJ4asp77 5+ROFwqvvaG6VlwM7Jaby5dVpBlGY8Dwl7ECGGIHOgXf7ndDWTOadFFxwvlz8Ugy/YxFW5zQyus7 c5QvPHQjkj1yhdQXshUMRo4gZ8ZHvMPOBjykCpTdShHXhh1ziJIeQYSjBYZwdkQDtHtj2U8Q3wHM PU+LT+di+Bd+Y5umQHVCukFlUNCbyUboo/x81Ts0MSAhpxHEMrYonUsAAAAAAAA= --Apple-Mail-3-674091519-- From swmike@swm.pp.se Tue Apr 19 15:34:30 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ECA33E06BB for ; Tue, 19 Apr 2011 15:34:30 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11f0omOSNIir for ; Tue, 19 Apr 2011 15:34:30 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 3A259E0673 for ; Tue, 19 Apr 2011 15:34:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 407C29C; Wed, 20 Apr 2011 00:34:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3BE909A; Wed, 20 Apr 2011 00:34:27 +0200 (CEST) Date: Wed, 20 Apr 2011 00:34:27 +0200 (CEST) From: Mikael Abrahamsson To: Michael Newbery In-Reply-To: Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:34:31 -0000 On Wed, 20 Apr 2011, Michael Newbery wrote: > Certainly over the next few years we can hope that new equipment will do > the right thing. Having said which, if you were to go out to the store > RIGHT NOW and buy a residential gateway that does native IPv6, how easy > would that be? Not very, but there are those that work fairly well. D-link 815 is one example. D-link is actually doing a fairly good job with some of their series, but one has to watch out very carefully for what hw revisions one gets. The 815 and 655 rev B1 does 6RD, DHCPv6-PD, SLAAC etc. It also does 6to4, but all IPv6 is off by default. I have tried 6RD, DHCPv6-PD and SLAAC and there are rough edges to smoothen, but the basic function is there. I have high hopes that we'll see more vendors release well working code during the year (first revisions seem to be understandably rough but basic functions ar ethere). -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=10900b2d70=jordi.palet@consulintel.es Tue Apr 19 15:36:24 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4CF6FE0675 for ; Tue, 19 Apr 2011 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sMvys5tUCo2 for ; Tue, 19 Apr 2011 15:36:22 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id D1EC6E0673 for ; Tue, 19 Apr 2011 15:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303252164; x=1303856964; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=EUjtoyxhcB2zaFs9XXsSnid/q /qXL5CtC/GXHrLpPbc=; b=NigKZ2PPJx3M3Uxzm/hYXtOcjAKZhczP7tAhC+Kcj PVbrCJInyAr9vo/3d9A5m5sZw4DFnTK4fM1Qf0rZbbX4Xkr0XS2w8EZs+UUh7CMJ dCz3EBSbIygGyR+da9bVNTJQGF6tkpSOMovdhlUZRp6rkPR0e+l4Gabu1sczN4BP 9s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=q9Cs4fAwfgEYhtcY4TTGSG1a4St1XPxkAd3VamhcMAj9xF8mnxaSFZ+OMHHm 4mIe2ilKpeUvM0YkbqyWll959VoUts9aj+ochVSBIsL7UImkmQrsay9cj scqCyhp4QNfS23IDlhpmchNq2tnq858ZmEsqDckDWdFfrQJN/wXLCs=; X-MDAV-Processed: consulintel.es, Wed, 20 Apr 2011 00:29:23 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003876811.msg for ; Wed, 20 Apr 2011 00:29:22 +0200 X-Spam-Processed: consulintel.es, Wed, 20 Apr 2011 00:29:22 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110419:md50003876811::Fe3HjYOkB5DYcazP:00003nbz X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=10900b2d70=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 20 Apr 2011 00:36:02 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E5037FC873@XMB-AMS-101.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:36:24 -0000 Hi Gunter, Is not what I want is what is already there and we better provide better support to it, instead of killing it, because unfortunately, the ideal situation (the one I will like, native IPv6 tomorrow) will not be there soon. If we kill 6to4, instead of provide guidance about hot to fix it, then we will have more delays for the IPv6 deployment. You could tell me to use 6rd, however, is LESS supported than 6to4, and we can't ask ISP to replace the CPEs to go to 6rd, in that case native IPv6 is the way forward, the investment is the same. 6rd will avoid native IPv6 deployment at least for some time. By the way, read the recent message form Comcast in NANOG mail exploder: http://mailman.nanog.org/pipermail/nanog/2011-April/035380.html May be the problem is that some of people trying to kill 6to4 has not actively deployed by themselves 6to4 and 6to4 relays ? I think there has been enough examples and discussions not to accept the Last Call at least in the current version of this document, which clearly has, at least, text to be updated to reflect a better reality. Consensus can't be declared in this situation, when the draft is broken, at least in some parts of the text. If we believe that 6to4 is the last resort, then make it clear that way: Make mandatory the use of RFC3484 (default address selection), drop the 6to4 anycast, but don't kill 6to4 itself. This document send the wrong signal to the market. If we want to signal the market and the ISPs that 6to4 is a temporary measure, say it should be implemented in conjunction with RFC3484, and even state a time frame for dropping it. Regards, Jordi -----Mensaje original----- De: "Gunter Van de Velde (gvandeve)" Responder a: Fecha: Tue, 19 Apr 2011 16:04:13 +0200 Para: "George, Wes E IV [NTK]" , Jordi Palet Martinez , CC: Ron Bonica Asunto: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >Jordi> >I oppose to a deprecation of 6to4. >It is already the last resort, and I will be happy if the anycast is by >default configured off. This way, 6to4 is still useful peer-to-peer. >_______ > >GV> If it is v6 you want over v4 in a dynamic 'managed' tunnel >infrastructure, then go to your favourite vendor and ask them about >this. I am sure they have a solution for that. No need to have 6to4 for >this at all. > >G/ > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From swmike@swm.pp.se Tue Apr 19 15:40:21 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A304E06F9 for ; Tue, 19 Apr 2011 15:40:21 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E7rOWU0ORXy for ; Tue, 19 Apr 2011 15:40:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id D6D0BE0673 for ; Tue, 19 Apr 2011 15:40:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 57B909C; Wed, 20 Apr 2011 00:40:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 525F09A; Wed, 20 Apr 2011 00:40:20 +0200 (CEST) Date: Wed, 20 Apr 2011 00:40:20 +0200 (CEST) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:40:21 -0000 On Wed, 20 Apr 2011, JORDI PALET MARTINEZ wrote: > May be the problem is that some of people trying to kill 6to4 has not > actively deployed by themselves 6to4 and 6to4 relays ? My employer has run globally reachable 6to4 and teredo relays for the last 2+ years. I want it to go away asap. Right now it causes more problems than it solves. It was nice to get initial testing for IPv6 but just like 6bone it should go away. -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=10900b2d70=jordi.palet@consulintel.es Tue Apr 19 15:40:40 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C56B7E071B for ; Tue, 19 Apr 2011 15:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkxszObBU8wC for ; Tue, 19 Apr 2011 15:40:39 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 4D666E0673 for ; Tue, 19 Apr 2011 15:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303252426; x=1303857226; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=SmrnHRV7+EzPuW5DxL7BTLSe4 MDtEeFUkKbsjg12xAk=; b=LVEo9IJ+igaNCg5n0ACwt0CMGq087KiFlT6hVBrAH xtbceGD/4A1ZuY/VLWO386S53H5VoTZIKcnY2VLjiqau/mlsS1pH1uCG3YIQmjXq ZntTjpUcn/JscUCU/Q6g/j5aA/uWVxbnxYG/rK4Fn+0Mc5XqLpIc5msb0Ur6XNEN Ok= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=OKPyQy1V3mC1VBjQEZ+mH8MDmH2ZAD/zLCaFu17+PirMRBm8M9aVkxtQX0P5 seI+H+MLnqVxN4hUZ2ZQr712klD+h19hugl7W4i3OvIz64TTgfMlpC8pm fY0NV3zb41+FILJk1GwGozOcKRUKJySIMV/aLgmVL+aA2vo+4yWxlU=; X-MDAV-Processed: consulintel.es, Wed, 20 Apr 2011 00:33:44 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003876814.msg for ; Wed, 20 Apr 2011 00:33:43 +0200 X-Spam-Processed: consulintel.es, Wed, 20 Apr 2011 00:33:43 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110419:md50003876814::kq1jGzmCaxyDfigw:00000vLV X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=10900b2d70=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 20 Apr 2011 00:40:23 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7309D@PLSWM12A.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:40:40 -0000 Ok, so let's go for the draft-ietf-v6ops-6to4-advisory, as we seem to have agreement on that, but not on 6to4-to-historic. In my context and the context of my customers, where 6to4 works much better than what is being reported, having some IPv6 support is much better than not having it. Regards, Jordi -----Mensaje original----- De: "George, Wes E IV [NTK]" Responder a: Fecha: Mon, 18 Apr 2011 13:57:23 +0000 Para: Jordi Palet Martinez , "v6ops@ietf.org" CC: "ron@bonica.org" Asunto: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >-----Original Message----- >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >JORDI PALET MARTINEZ >Sent: Sunday, April 17, 2011 3:09 PM >To: v6ops@ietf.org >Cc: ron@bonica.org >Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >There are two ways of doing this: > >1) Killing all the protocols that may not work because some operators >don't know how to configure filters >______ >[WEG] Gross oversimplification. This isn't just about filters, and it >certainly isn't just about operators' filters. Even at best, >6to4 is degraded because of all of the other things discussed in >draft-ietf-v6ops-6to4-advisory > >2) Making sure that protocols are better, for example by means of >ensuring mechanisms such as "happy eyeballs" make a smart decision >about what to use >______ >[WEG] So... assuming we get critical mass on implementing happy eyeballs >in a reasonable timeframe (which in and of itself is a >stretch), it tests, confirms what we already know, which is that 6to4 is >not really a viable option for a large portion of the users >when compared with IPv4 or with native IPv6, and it never or almost never >uses 6to4. Exactly how does that improve the situation and >justify keeping 6to4 alive? > >Wes George ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From prvs=10900b2d70=jordi.palet@consulintel.es Tue Apr 19 15:48:24 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 58160E07B7 for ; Tue, 19 Apr 2011 15:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rcGDMcaT4oG for ; Tue, 19 Apr 2011 15:48:23 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 1D0ECE06F9 for ; Tue, 19 Apr 2011 15:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303252864; x=1303857664; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=rh+eFzzrBsuQztwbn5BFmF+S1 jCitcTFyZsJ1HoU5WE=; b=I45wZIpE256+zUh9EaqDl498IgZpVfAgMQLJ99n9z G5Bg5KFWZ7XET+ruDsIUfTtA0OLsU0EgPIJbggMEl66fP8xoDcmEIvy4vKvYikcp N8sCyhvLdCa4RiSgP8o+zJfS4wSKaiWFYOe8P72w3Qlo9hYlSwSX031iQBiLfixU GM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rwZbF+7LO27fQaCeJ06to4d5+QiGmmQQS39uRjYJ6FH5ysUHepGt1lHufGRy 2ptTUVuT4e4J69WNA9p80dtgQq80zNeJc8WlhiYS7IVt6wZ3kmkX8oufr +0vgM7stPypEd9bbROoiAcZ0pjElbtBzEDAPJOdl55lO4mAsA1Jaao=; X-MDAV-Processed: consulintel.es, Wed, 20 Apr 2011 00:41:04 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003876817.msg for ; Wed, 20 Apr 2011 00:41:04 +0200 X-Spam-Processed: consulintel.es, Wed, 20 Apr 2011 00:41:04 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110419:md50003876817::otEj4VLCLVrR29hq:00000IOH X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=10900b2d70=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 20 Apr 2011 00:47:40 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:48:24 -0000 And like 6bone, then stamp a phase-out plan, which has been suggested already. Regards, Jordi -----Mensaje original----- De: Mikael Abrahamsson Organizaci=F3n: People's Front Against WWW Responder a: Fecha: Wed, 20 Apr 2011 00:40:20 +0200 (CEST) Para: Jordi Palet Martinez CC: , Ron Bonica Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >On Wed, 20 Apr 2011, JORDI PALET MARTINEZ wrote: > >> May be the problem is that some of people trying to kill 6to4 has not >> actively deployed by themselves 6to4 and 6to4 relays ? > >My employer has run globally reachable 6to4 and teredo relays for the >last=20 >2+ years. I want it to go away asap. > >Right now it causes more problems than it solves. It was nice to get >initial testing for IPv6 but just like 6bone it should go away. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From ggm+ietf@apnic.net Tue Apr 19 15:48:25 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A17EAE0660 for ; Tue, 19 Apr 2011 15:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.304 X-Spam-Level: X-Spam-Status: No, score=-101.304 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+Wc1WtB6y9n for ; Tue, 19 Apr 2011 15:48:25 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfc.amsl.com (Postfix) with ESMTP id 1B99CE075E for ; Tue, 19 Apr 2011 15:48:18 -0700 (PDT) Received: from dynamic186.apnic.net (dynamic186.apnic.net [203.119.42.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4C276B66E3; Wed, 20 Apr 2011 08:48:16 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 20 Apr 2011 08:47:08 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <1BE24E4C-0848-4958-A2CF-955E00853A34@apnic.net> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:48:25 -0000 On 20/04/2011, at 3:39 AM, Ole Troan wrote: > George, >>=20 >> This traffic exists as a consequence of packets being seen to come = from 2002::/16 source IP. It is not actually necessary for a complete = end-to-end exchange to run to completion for the DNS lookup to happen = (consider firewall/ACL rules with logging) And so will continue even if = the protocol itself is deprecated, for some time. >=20 > 6to4-historic has the following in the IANA considerations section: >=20 > IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as > "deprecated", pointing to this document. Redelegation of the domain > for any usage requires justification via an IETF Standards Action > [RFC5226]. >=20 > are you happy with that text or would you rather that the document was = silent on the issue of the 6to4 reverse zone? > =20 I should learn to read better.=20 I am happy with that text. I think it covers the situation pretty well = exactly. -george= From fred@cisco.com Tue Apr 19 15:51:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 382DBE0673 for ; Tue, 19 Apr 2011 15:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.536 X-Spam-Level: X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfw+nLvw6Klv for ; Tue, 19 Apr 2011 15:51:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 44D4FE0660 for ; Tue, 19 Apr 2011 15:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2000; q=dns/txt; s=iport; t=1303253460; x=1304463060; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=JJtEVl5XR02AztSS8y/VouGruXqzSlyIen/7y/AaI1k=; b=eyg+av279h5tNlmN/J42I/nwm2Z5MhRdJZZ/vtCEmHtxWTYsECFwJtmH hguuWNIqThkycupMjc15JOqco3n83W97sPAJBrJBwm3f+4DoOov+Cz6Qg 5V6o10l92EcLAUvSujH2UGvIhU9t+/JTLvIpT+6yO7HbX02GWPnhQzNLj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAURrk2rRDoH/2dsb2JhbAClOHeIb55+nQ2DGYJYBIVniCCDfA X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208";a="684196467" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 22:50:58 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JMorYk020335 for ; Tue, 19 Apr 2011 22:50:58 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 19 Apr 2011 15:50:58 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 19 Apr 2011 15:50:58 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 19 Apr 2011 15:50:40 -0700 Message-Id: References: To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Comcast's 6to4 Relays X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:51:01 -0000 John made the following comment on NANOG, and thought that this working = group might find the observation relevant.=20 On Apr 19, 2011, at 2:38 PM, Brzozowski, John wrote: > FYI - in case you think your WG will find this of interest. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski@cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > On 4/19/11 4:44 PM, "John Jason Brzozowski" > wrote: >=20 >> Folks, >>=20 >> Since deploying our 6to4 relays, Comcast has observed a substantial >> reduction in the latency associated with the use of 6to4. As such we = are >> contemplating further opening our relays for use by others. The >> availability of our 6to4 relays should improve the experience of = others >> using 6to4 as a means to access content and services over IPv6. >>=20 >> We have been open about our IPv6 activities and wanted to follow suit = by >> reaching out to the community and soliciting feedback before moving >> forward. As always we wish to continue to advocate and support the >> universal deployment of IPv6. >>=20 >> Please send any comments or questions to the list or if you wish to = me >> directly. >>=20 >> John >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski@cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >=20 From joelja@bogus.com Tue Apr 19 15:55:08 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BCFC3E0673 for ; Tue, 19 Apr 2011 15:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov4rLnjx7Bkf for ; Tue, 19 Apr 2011 15:55:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id C6618E0660 for ; Tue, 19 Apr 2011 15:55:07 -0700 (PDT) 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 p3JMsRJX020544 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Apr 2011 22:54:28 GMT (envelope-from joelja@bogus.com) Message-ID: <4DAE129E.4030702@bogus.com> Date: Tue, 19 Apr 2011 15:54:22 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: jordi.palet@consulintel.es References: 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]); Tue, 19 Apr 2011 22:54:29 +0000 (UTC) Cc: "v6ops@ietf.org" , "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:55:08 -0000 On 4/19/11 3:40 PM, JORDI PALET MARTINEZ wrote: > Ok, so let's go for the draft-ietf-v6ops-6to4-advisory, as we seem to have > agreement on that, but not on 6to4-to-historic. This is your opinion. Articulating the sense of the group is not your responsibility. we have 2418/3934 to instruct us for that, the WGLC ends 5/1/2011. I think we can be assured that the chairs will attempt to account for the diversity of opinions that have and have yet to be expressed on this issue. thanks joel > In my context and the context of my customers, where 6to4 works much > better than what is being reported, having some IPv6 support is much > better than not having it. > > Regards, > Jordi > > > > > > > -----Mensaje original----- > De: "George, Wes E IV [NTK]" > Responder a: > Fecha: Mon, 18 Apr 2011 13:57:23 +0000 > Para: Jordi Palet Martinez , "v6ops@ietf.org" > > CC: "ron@bonica.org" > Asunto: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> JORDI PALET MARTINEZ >> Sent: Sunday, April 17, 2011 3:09 PM >> To: v6ops@ietf.org >> Cc: ron@bonica.org >> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> >> There are two ways of doing this: >> >> 1) Killing all the protocols that may not work because some operators >> don't know how to configure filters >> ______ >> [WEG] Gross oversimplification. This isn't just about filters, and it >> certainly isn't just about operators' filters. Even at best, >> 6to4 is degraded because of all of the other things discussed in >> draft-ietf-v6ops-6to4-advisory >> >> 2) Making sure that protocols are better, for example by means of >> ensuring mechanisms such as "happy eyeballs" make a smart decision >> about what to use >> ______ >> [WEG] So... assuming we get critical mass on implementing happy eyeballs >> in a reasonable timeframe (which in and of itself is a >> stretch), it tests, confirms what we already know, which is that 6to4 is >> not really a viable option for a large portion of the users >> when compared with IPv4 or with native IPv6, and it never or almost never >> uses 6to4. Exactly how does that improve the situation and >> justify keeping 6to4 alive? >> >> Wes George > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Wesley.E.George@sprint.com Tue Apr 19 16:20:25 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63D4EE088D for ; Tue, 19 Apr 2011 16:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.838 X-Spam-Level: X-Spam-Status: No, score=-4.838 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF8BQht+Cogy for ; Tue, 19 Apr 2011 16:20:24 -0700 (PDT) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfc.amsl.com (Postfix) with ESMTP id E343EE089E for ; Tue, 19 Apr 2011 16:20:23 -0700 (PDT) Received: from mail78-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.8; Tue, 19 Apr 2011 23:20:22 +0000 Received: from mail78-db3 (localhost.localdomain [127.0.0.1]) by mail78-db3-R.bigfish.com (Postfix) with ESMTP id 6193C1760131; Tue, 19 Apr 2011 23:20:22 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz9371O542M1414Jzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail78-db3 (localhost.localdomain [127.0.0.1]) by mail78-db3 (MessageSwitch) id 1303255213437094_24904; Tue, 19 Apr 2011 23:20:13 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.254]) by mail78-db3.bigfish.com (Postfix) with ESMTP id E9BE51C80051; Tue, 19 Apr 2011 23:19:02 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 19 Apr 2011 23:19:01 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3JNIxDD028321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Apr 2011 18:19:00 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 18:18:56 -0500 From: "George, Wes E IV [NTK]" To: Michael Newbery , IPv6 Ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AQHL/tkdKOTkW+5A0E6soOJI+P4v4JRlzxyA Date: Tue, 19 Apr 2011 23:18:57 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7F13B@PLSWM12A.ad.sprint.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0156_01CBFEC6.A6E730E0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:20:25 -0000 ------=_NextPart_000_0156_01CBFEC6.A6E730E0 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 Michael Newbery Sent: Tuesday, April 19, 2011 5:31 PM To: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC My discussions with vendors however indicate that in general it IS technically impossible. Certainly there is a large amount of gear out there that has no IPv6 support, not even 6to4. This is generally made very cheaply, usually based on a reference design or chipset and using firmware and operating system provided by the chipset manufacturer. The OEM adds a little value, but mostly they have no ability to add significant extra functionality. It is likely for instance that there is just insufficient memory to add native IPv6 support. At the low end, only very recent equipment has sufficient capacity. I know of one low end CPE vendor that is adding all the right stuff, and their most recent gateway CAN be upgraded. But their previous model simply lacks the ability (in their opinion). [WEG] 5 letters... DDWRT. It shows as proof positive that there is a MUCH wider variety of hardware that CAN support IPv6 that DOESN'T due to a specific choice on the part of the OEM vendor. Yes, there are going to be some that actually can't, and "support" means different things on different hardware, but assuming that most of the ones that don't is due to hardware limitations is being quite generous. Furthermore, getting most CPE gateway vendors to expend the considerable effort---and money---to enable native IPv6 support on their already sold hardware would bring them in how much revenue? [WEG] Absolutely true. Doesn't make it any less the right thing to do. I've said before that perhaps it's time for the hardware vendors to embrace the open source market to continue support for devices that they no longer can/want to write software updates for themselves. Not just pointing to the DD-WRT page and saying "have fun" but actually pulling an image and supporting it - in other words, just saving yourself the code work, not necessarily the certification. The CPE situation may be shameful, and one might be justifiably grumpy with (most of) the CPE vendors for not having shipped suitable equipment for YEARS now, but dealing with the world as it is, I don't see any realistic alternative for most customers who own their own RGs apart from having to buy new ones. [WEG] Also true. Doesn't make it suck any less. Another commenter implied that people would be willing to buy new gear if there's something in it for them - if we could have convinced people that there was something in it for them with IPv6, we would have done it years ago. As it is, the best chance we have is that CGN/NAT444 will suck so much that moving to IPv6 will actually represent "something in it for them" Wes George ------=_NextPart_000_0156_01CBFEC6.A6E730E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxOTIz MTkwNlowIwYJKoZIhvcNAQkEMRYEFKlpsqS2Si3YkEe70CL+wuzfZtn2MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgI+d0juyW/XVsU0+46KOIqkQ1WNrnZXB6lvOe4jjTGBgciRsoPOE+eUkdeu8VSQH60Nf /J14zhbPbSR78SIvUj+57cjFS8d9o8feVQMI23oawvPG8C5XvChCBi5s/ml5OFthJjKR5Wi2SFER JoAlavZ5RTBENyQn7DkO7qNkvXa9AAAAAAAA ------=_NextPart_000_0156_01CBFEC6.A6E730E0-- From newbery@gmail.com Tue Apr 19 16:51:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9A613E075C for ; Tue, 19 Apr 2011 16:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[AWL=1.378, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS4Ai3J6yvtW for ; Tue, 19 Apr 2011 16:51:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9117EE0715 for ; Tue, 19 Apr 2011 16:51:06 -0700 (PDT) Received: by pzk30 with SMTP id 30so139228pzk.31 for ; Tue, 19 Apr 2011 16:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=JLV35223JDGy2joS7qK+8OMvFWwa27ypOrlMEaoOhL0=; b=YyFxsV/4Z781mSPnPNhsOaCqZ4dORjFMoxQxPXsPbCiPJ5lAdODacoTv2PoONO6IiV xBKVysIOs4XD7/t6uSDVCz10odLpden534O9n9FASoQdyV6Lt6cUJETdUPACk1l46Mff vmMLo6AtffHjz2FZ/EGmxeJaEgKbkYhOY+qvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=aCvxAL/36KOK8WZ9YJfWDQ+EQIC2ZeV/CR3vG5CVtINXGgEqVTxYXUF/s3DZJAR8oR vTo5L7mFUJ9ksDEZuqFUL2Gh8JiwzQdJw0JrJvNSyKSvW+yOhlP0igPz5GyxZvlAI6Do kcW18DW5k26qttSN9D1HVzkxQ1UrKennxRlx4= Received: by 10.68.40.65 with SMTP id v1mr9809744pbk.154.1303257065868; Tue, 19 Apr 2011 16:51:05 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id d9sm243389pba.16.2011.04.19.16.51.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 16:51:05 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-4-679829607; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 20 Apr 2011 11:50:56 +1200 In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7F13B@PLSWM12A.ad.sprint.com> To: IPv6 Ops WG References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7F13B@PLSWM12A.ad.sprint.com> Message-Id: <39F82D4C-7757-450F-B486-FA2B0363436C@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:51:07 -0000 --Apple-Mail-4-679829607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20/04/2011, at 11:18 AM, George, Wes E IV [NTK] wrote: > [WEG] 5 letters... DDWRT. It shows as proof positive that there is a = MUCH wider variety of hardware that CAN support IPv6 that > DOESN'T due to a specific choice on the part of the OEM vendor. Yes, = there are going to be some that actually can't, and "support" > means different things on different hardware, but assuming that most = of the ones that don't is due to hardware limitations is being > quite generous.=20 DDWRT runs on a relatively high end piece of equipment, namely a 802.11 = router. There are a lot of plain old WAN-LAN routers though, especially = in the xDSL world. It was to them that I was referring. I estimate that = the majority of our xDSL customers have gateways that are incapable of = being firmware upgraded to IPv6. Even if they have a DDWRT capable = router at home that does them no good if the WAN/LAN router can't do = IPv6 native. =20 Cable is slightly different, with the cable modem typically being = (mostly) layer 2. I estimate that about 50% of our cable customers run = some sort of RG and that the other 50% currently have a single PC = directly connected. Of the 50% that have RGs, I would estimate that the = majority are not capable of being firmware upgraded to IPv6 native. = Fortunately, the 50% that have directly connected PCs *are* mostly = capable, via an OS upgrade. And lest anyone misunderstand, I am trying as hard as I can, as fast as = I can, to roll out native IPv6 support. I consider tunnels a stopgap and = LSN an ineffective abomination (to which I fortunately don't have to = resort.)= --Apple-Mail-4-679829607 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNDE5MjM1MTAw WjAjBgkqhkiG9w0BCQQxFgQUlmkFexUDcyJl8KvhkN8WzZuSPT4wgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBAFx4Xu5qpKvqbGknMewae6snHlF1J32BDvh/Kk65c6UWKHHWaKJ3eF4QAz28 +jQKo1dXw5vHV45YRfgEiba8E0Pf2TMnOFoKApDWHSmj5zhmTrYPpDN+DWNIpH7P0ag9tRjAgEaU BB0ktsaCqITCCBdL6TTNLMquRFUstLa7c8z+deN16HcRllJAa+9p4LueGEOk6LPbRdPj3OQwki9R UQVNO/3m0sRhrRYFpFggKRIJzTEj5bzJNfNbwWHg0ROuT2mD3XTDuybrnkI2PCHj+eYjcWtk/eXz P4r3/Vlec5IIFI2pS3NrjH7K3BLyVAdVSzLyZs45u03WhmWUUxfdDmcAAAAAAAA= --Apple-Mail-4-679829607-- From fred@cisco.com Tue Apr 19 17:13:00 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4A98FE075C for ; Tue, 19 Apr 2011 17:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.537 X-Spam-Level: X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKYvM0Fa5Fll for ; Tue, 19 Apr 2011 17:12:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id EDA41E0715 for ; Tue, 19 Apr 2011 17:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2359; q=dns/txt; s=iport; t=1303258378; x=1304467978; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=lbDtdw1QuMlcdxhF8IOjf8ftWE7GPYwyjbFj2+4IBFA=; b=dztju/TZ2hYMa7MwBspB5bSkqMZakDVTw7xw5eDiNmEqJySFDlMaPM6r cGJBZs/xsfW6ggpk4XVF/67oCWDecZH/FabO583UbtiUHEAtBG4ni7vau LTIENvYsEypF4ydYZTBwRn74eIKOA49RfuCRhZwxZV1FNIFUETygNXLjf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOAkrk2rRDoI/2dsb2JhbAAlpRd3iG+fQZ0YgneCegSFaYgng34 X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="433187878" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 20 Apr 2011 00:12:58 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3K0CpAW007221; Wed, 20 Apr 2011 00:12:57 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 19 Apr 2011 17:12:57 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 19 Apr 2011 17:12:57 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> Date: Tue, 19 Apr 2011 17:12:40 -0700 Message-Id: <89410FED-6AD3-441B-8163-9214BC196823@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> To: "George, Wes E IV [NTK]" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 00:13:00 -0000 On Apr 19, 2011, at 11:22 AM, George, Wes E IV [NTK] wrote: > On Apr 18, 2011, at 7:10 PM, Brian E Carpenter wrote: >> There is now no reason or excuse for a consumer ISP to fail to deploy = IPv6 for customers... >=20 > I wonder if the operator community shares this assessment of their = situation. > ______ > [WEG] The premise that providers aren't deploying IPv6 (especially due = to lack of content) is a faulty one. I believe that you'll find nearly = every operator represented here is in the process of deploying IPv6 = within the capabilities of their infrastructure and limits of their = capital budgets. May not be rapid enough for your liking, but it is = definitely happening. I think there are two sides to that question, both valid. I'll refer you to comments on this list, and to the year-old OECD report = at http://www.oecd.org/dataoecd/48/8/44961688.pdf, and specifically = slide 16 of that report. Any statement that service providers are not = implementing IPv6 certainly isn't reflected in the statistics, nor is it = representative in the statements of the operators. What I think was being asked was not whether the operators are deploying = the technology, but to what extent it was available to their customers - = the general public. Comcast has been fairly forward about their trials = with the public, but that's not universal. I suspect that we have three = issues between us and wide-scale IPv6 usage: - content provider capabilities, including folks like Google, Akamai, = and Youtube, but also including your favorite bank, your church, and = other web sites you use. - CPE router deployment, which today is almost universally IPv4-only = and acts as a diode preventing general IPv6 access. - enterprise/smb network deployment, which is generally throttled by = business case questions - "I understand why <> needs to deploy it, but I = have enough addresses for my own use for the immediate future". What I think Brian is looking for is for the industry to overcome those = issues, and as a result give the end user a felt need to deploy. Not = just a "Fred Baker would be happier if you did" or "Wes George would be = happier if you did" kind of reason, but a "You will be happier if you = deploy" kind of reason. ftp://ftpeng.cisco.com/fred/v6ops/Nightmare.pdf From gvandeve@cisco.com Wed Apr 20 01:09:02 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A794E067C for ; Wed, 20 Apr 2011 01:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.636 X-Spam-Level: X-Spam-Status: No, score=-9.636 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAI7+EQAoXx0 for ; Wed, 20 Apr 2011 01:09:02 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id C39E5E0668 for ; Wed, 20 Apr 2011 01:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=651; q=dns/txt; s=iport; t=1303286941; x=1304496541; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Uu4QT16AICoIMCwaYsXc9XgfeCAYzaeBsNj5cfnc31Y=; b=ktEE7FjMP7Wtn00J7feXphz/yHWWdOBSlYHe1FMBx1MV/3HSSQXownhC hpLorOn6z3TbpJVpvb2Y5EPW2kj9g2Rvzqzh1hqMx7UTsknYkgIy5g8Pl sUzd9W+89L00QlCKSBS2UYrmfGbODX5ntadNGrAV0mI8zpw6sssJJHewZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIDAJWTrk2Q/khRgWdsb2JhbAClPBQBARYmJaoNnQWFcQSSKA X-IronPort-AV: E=Sophos;i="4.64,245,1301875200"; d="scan'208";a="26400055" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Apr 2011 08:09:01 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3K891S6005719; Wed, 20 Apr 2011 08:09:01 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 10:09:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 10:08:58 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FCA15@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv960vdlWVOILOJRmeAL/NrWdhgygBRpeKQ References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DABE200.3040504@redpill-linpro.com> From: "Gunter Van de Velde (gvandeve)" To: "Philip Homburg" , =?iso-8859-1?Q?Roger_J=F8rgensen?= X-OriginalArrivalTime: 20 Apr 2011 08:09:00.0966 (UTC) FILETIME=[34CF9C60:01CBFF32] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:09:02 -0000 That depends on your role. From ISP perspective, 6to4 doesn't make a lot = of sense. But for end users, sometimes a tunnel is all you can get. = Sometimes,=20 tunnels offer even a more complete IPv6 experience than native. GV> I guess you are speaking for the simple home-user. In that case what = limits a user from obtaining a managed commercial service for IPv6? That = way he gets at least SLA like commitments from his favourite services = provider. GV> If its an enterprise there are better solutions out there that = deliver managed tunneling services.. pick your preferred vendor and they = will give you some options. G/ From gvandeve@cisco.com Wed Apr 20 01:12:08 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7F3EFE069C for ; Wed, 20 Apr 2011 01:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.533 X-Spam-Level: X-Spam-Status: No, score=-9.533 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPBSBCw7HyKU for ; Wed, 20 Apr 2011 01:12:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 9D5C1E0689 for ; Wed, 20 Apr 2011 01:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1281; q=dns/txt; s=iport; t=1303287127; x=1304496727; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AfCJvPm+cWwuoUZHmroM9GxmNYZ1aYDELGk3qAaEWcA=; b=cFJuz92r6t7ffbcOjZZXvgIuuV0vUby6D/S3ThmLKRcmqagDIhOfcLff Fu+XDBRA/JCheat+F/ywkikmruoXz445uYjQ27kZeg66710pqpf3lVheo aYtRRlkBKNXYI8eZkYPKkj1Jf+lEMUKNHVrp7CiOPATB/NWtTsceKFM3X k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIDADaVrk2Q/khLgWdsb2JhbAClPBQBARYmJaofnHyFcQSSKA X-IronPort-AV: E=Sophos;i="4.64,245,1301875200"; d="scan'208";a="84343891" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2011 08:12:00 +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 p3K8C0kr008913; Wed, 20 Apr 2011 08:12:00 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 10:12:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 10:11:57 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv98e8EavyW24RmS4q3oX8uTlFP0wBQG6RQ References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> From: "Gunter Van de Velde (gvandeve)" To: "james woodyatt" , "Nick Hilliard" X-OriginalArrivalTime: 20 Apr 2011 08:12:00.0014 (UTC) FILETIME=[9F882AE0:01CBFF32] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:12:08 -0000 I think that a signal like '6to4' is now historical is a quite clear headliner... why keep a technology, which gives grief for the Internet due to bad connectivity alive? G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: 18 April 2011 19:56 To: Nick Hilliard Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 18, 2011, at 06:56 , Nick Hilliard wrote: >=20 > James: if this document were to explicitly set a phaseout date for 2002::/16 some time in the future, would this work for you? Yes. I cannot support this draft unless it has an explicit phaseout plan for 2002::/16 included. If you want to send a signal to equipment makers that they should remove 6to4 routing functions from their future product plans, then you need to include a phaseout plan for it. Otherwise, you are engaging in a pointless exercise, and it won't happen. Am I making myself clear? Because I really can't be more explicit than that. -- james woodyatt member of technical staff, core os networking _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Wed Apr 20 01:15:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4311DE069C for ; Wed, 20 Apr 2011 01:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.864 X-Spam-Level: X-Spam-Status: No, score=-9.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDZHwFDKyyCh for ; Wed, 20 Apr 2011 01:15:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 8A591E0689 for ; Wed, 20 Apr 2011 01:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=936; q=dns/txt; s=iport; t=1303287354; x=1304496954; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UHiqoTLJFBjDmXfPWmGJeQsFwM5jmz3P5+4rt2m5440=; b=WA8MkJ/KQRXej8l973ctaA9d6ubj/PPD52n7Iobw4sDTAHX4EDKrGQpc 5IZbYhjlEyWJVUXjKWF1iyGG3TL3FqH9PTkh7ZJslTLy8iPokMIoIq8R3 4CC/W8OE1RpAk20FLd+U5Zlezlpv9l2QrA0jiOmmLsFrPQ7jqfgOeREau E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIDADaVrk2Q/khNgWdsb2JhbAClPBQBARYmJaofnHyFcQSSKA X-IronPort-AV: E=Sophos;i="4.64,245,1301875200"; d="scan'208";a="84344541" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2011 08:15:53 +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 p3K8FrNX027119; Wed, 20 Apr 2011 08:15:53 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); Wed, 20 Apr 2011 10:15:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 10:15:51 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FCA26@XMB-AMS-101.cisco.com> In-Reply-To: <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv99XY4z8ccTGEWRcW1w03WY097nABPTrPQ References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <08B3077E-07C9-4F5B-8282-DEAD67DCBA97@apple.com> From: "Gunter Van de Velde (gvandeve)" To: "james woodyatt" , "Mikael Abrahamsson" X-OriginalArrivalTime: 20 Apr 2011 08:15:53.0496 (UTC) FILETIME=[2AB2B180:01CBFF33] Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:15:55 -0000 James, <>start snip<> Too many service providers today have not announced any IPv6 transition plans, leaving our customers with only 6to4 as their only hope for acquiring even marginally acceptable IPv6 services with a reasonable level of configuration human interface burden. Until this changes, I doubt Apple and other equipment makers will stop supporting 6to4 routing in their products, and people will continue to use it despite the IETF deprecation, and IPv6 brokenness related to 6to4 will probably remain at the unacceptable levels that operators and content providers hope to address with the publication of this draft. <> end snip<> It will be apple choice to follow RFC or not. It would not be the first time a big user OS does not follow an RFC intentionally. It would be pitty and provide some bad karma for people and organizations indeed, however, as mentioned it wouldn't be the first time G/ From pekkas@netcore.fi Wed Apr 20 01:27:18 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1A32E0756 for ; Wed, 20 Apr 2011 01:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.767 X-Spam-Level: X-Spam-Status: No, score=-101.767 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9aptUVTcRfF for ; Wed, 20 Apr 2011 01:27:17 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfc.amsl.com (Postfix) with ESMTP id 89EEFE06A4 for ; Wed, 20 Apr 2011 01:27:17 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3K8RECm018314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Apr 2011 11:27:14 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3K8REeX018311 for ; Wed, 20 Apr 2011 11:27:14 +0300 Date: Wed, 20 Apr 2011 11:27:14 +0300 (EEST) From: Pekka Savola To: v6ops@ietf.org In-Reply-To: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> Message-ID: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-730767136-1303288034=:17113" X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:27:18 -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-730767136-1303288034=:17113 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 17 Apr 2011, Fred Baker wrote: > 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. I suppose publishing this document but not in its current form; some changes are needed (below). .... Section 2.1 on Router 6to4 should be trimmed down, one page is excessive. 6to4 was never deployed as it was initially devised by Carpenter, so text on that is not very useful (most of 1st paragraph of Section 3 should also go away). The key point is that 6to4 hosts or routers may either configure the relay router IP address or use anycast. In S 3: "The inference from these experiments is that one likely reason for the high connection failure rate for 6to4 connections is the use of local filters close to the end-user that block incoming packets with protocol 41." .. it was not described if the return path relay used 192.88.99.1 as the source address of packets or the non-anycast address. I would expect significantly more breakage when 192.88.99.1 is NOT used as the source address. Firewalls in residential case are rarely an issue based on my experience if the relay uses 192.88.99.1 as the source address. 5. PMTUD Failure: ...Path MTU Discovery does not always work, and this can lead to connectivity failures. Even if a TCP SYN/ACK exchange works, TCP packets with full size payloads may simply be lost. .. due to MSS negotiation this is not a problem if 6to4 is set up on a host because it will set MSS lower than 1500-40=1460B. This however could be a problem if 6to4 is enabled on a router and it advertises the prefix on a LAN, because if it doesn't also advertise a smaller MTU, hosts on the LAN will use MSS=1460 and TCP MSS negotiation will fail. The practical impact of the above problems, which are by no means universal as there is considerable successful use of Anycast 6to4, has been measured at a fraction of 1% loss of attempted connections to content servers (see ). .. for more balanced discussion, this discussion should be moved up, next to the two researches on "very broken 6to4". Section 4.1 is out of place here. Remove or broaden the scope of the document to include vendors. S 4.2: 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. .. this must be removed unless there is more operational experience with this approach. Hinting at the ISPs that this could be a good approach is very wrong if we don't know that it is actually the case. editorial: - references to labs.ripe.net, www.potaroo.net etc. should be filed as informative references not direct URLs in text. - S 4.2 is almost two pages long. It would be better focused with subsections. - S 4.4: as already commented by others, remove IXP - S 4.5: s/suceeds/succeeds/; s/firewallls/firewalls/ -- 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-730767136-1303288034=:17113-- From mohacsi@niif.hu Wed Apr 20 01:36:37 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DA5DE0668 for ; Wed, 20 Apr 2011 01:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QUGkTviCA+u for ; Wed, 20 Apr 2011 01:36:36 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfc.amsl.com (Postfix) with ESMTP id BB617E0655 for ; Wed, 20 Apr 2011 01:36:36 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id BFCC087324; Wed, 20 Apr 2011 10:36:35 +0200 (CEST) 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 DlB8Zi5cdYMY; Wed, 20 Apr 2011 10:36:20 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 40F7B87253; Wed, 20 Apr 2011 10:36:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 3E0F085049; Wed, 20 Apr 2011 10:36:20 +0200 (CEST) Date: Wed, 20 Apr 2011 10:36:20 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Gunter Van de Velde (gvandeve)" In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E5037FCA15@XMB-AMS-101.cisco.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DABE200.3040504@redpill-linpro.com> <4269EA985EACD24987D82DAE2FEC62E5037FCA15@XMB-AMS-101.cisco.com> 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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:36:37 -0000 On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > > That depends on your role. From ISP perspective, 6to4 doesn't make a lot of > sense. But for end users, sometimes a tunnel is all you can get. Sometimes, > tunnels offer even a more complete IPv6 experience than native. > > GV> I guess you are speaking for the simple home-user. In that case what > limits a user from obtaining a managed commercial service for IPv6? That > way he gets at least SLA like commitments from his favourite services > provider. > > GV> If its an enterprise there are better solutions out there that > deliver managed tunneling services.. pick your preferred vendor and they > will give you some options. In reality the situation slightly worse, let me cite our example: 1. NIIF/Hungarnet started to provide native IPv6 DSL service around 2008 - we wanted to do it earlier, but due to a bug in DSLAM equipment stopped us to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We had to wait the telecom operator (1.5 years) to fix the problem. As an interim solution we started experimenting with 6to4 and Teredo. It was working reasonably well. 2. After fixing the DSLAM bug in the provider network and deployment of native IPv6 DSL service we considered switching 6to4 relay off. But there was a demand from administrators of our users (Universities, Research Institutes, Libraries) to let it run for further experimenting: There is only one other provider started provide native IPv6 DSL. The two big DSL player in Hungary is still testing and piloting their (for at least another year) IPv6 DSL services. In my opinion tend to be similar to Jordi's. 6to4 is good for experimenting with IPv6. If you need IPv6 service use native solution. But if there no solution on the market what to do? According to our policy our 6to4 relay is only for experimenting with IPv6 technology..... What about 6to4 relabeled to experimental? Best Regards, Janos Mohacsi > > G/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gvandeve@cisco.com Wed Apr 20 01:39:45 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B0ABE0668 for ; Wed, 20 Apr 2011 01:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.61 X-Spam-Level: X-Spam-Status: No, score=-9.61 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb105zm4EuXu for ; Wed, 20 Apr 2011 01:39:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 1522BE0655 for ; Wed, 20 Apr 2011 01:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2729; q=dns/txt; s=iport; t=1303288784; x=1304498384; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oAjXPTbTOnDay3HPebuy3ObOkCqGSELXEg2rdMktzrk=; b=CPqn/nlgel9DoCtLQFGXShbRQQCdcV55/w5xPN+LiG4l/B/9AkOU4Obe azC+vO4qk2OEyQJ3A+jLbvl++bDhYLifuxyUuBL462EdJLZ9vYK3//Ry5 kaePH/3xTJm43mNGMpkifN9FKd+MNiW7Ej8tu/KlYxm1KKEmnZNLB9WFb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIDAIyark2Q/khLgWdsb2JhbAClPBQBARYmJYhvoWecfIVxBJIo X-IronPort-AV: E=Sophos;i="4.64,245,1301875200"; d="scan'208";a="26405335" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Apr 2011 08:39:43 +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 p3K8dhHA016816; Wed, 20 Apr 2011 08:39:43 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 10:39:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 10:39:41 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FCA55@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/NhVfAXq70qg6R0CIXoIRSdpUUAAADj6A References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DABE200.3040504@redpill-linpro.com> <4269EA985EACD24987D82DAE2FEC62E5037FCA15@XMB-AMS-101.cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Mohacsi Janos" X-OriginalArrivalTime: 20 Apr 2011 08:39:43.0072 (UTC) FILETIME=[7ECAAE00:01CBFF36] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:39:45 -0000 For experiments, why not use IPv6 over IPsec, or manual tunnels or DMVPN = or.... All managed solutions, that work pretty well and none have the downside = negative side-impacts of 6to4. G/ -----Original Message----- From: Mohacsi Janos [mailto:mohacsi@niif.hu]=20 Sent: 20 April 2011 10:36 To: Gunter Van de Velde (gvandeve) Cc: Philip Homburg; Roger J=F8rgensen; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > > That depends on your role. From ISP perspective, 6to4 doesn't make a = lot of > sense. But for end users, sometimes a tunnel is all you can get. = Sometimes, > tunnels offer even a more complete IPv6 experience than native. > > GV> I guess you are speaking for the simple home-user. In that case = what=20 > limits a user from obtaining a managed commercial service for IPv6? = That=20 > way he gets at least SLA like commitments from his favourite services=20 > provider. > > GV> If its an enterprise there are better solutions out there that=20 > deliver managed tunneling services.. pick your preferred vendor and = they=20 > will give you some options. In reality the situation slightly worse, let me cite our example: 1. NIIF/Hungarnet started to provide native IPv6 DSL service around 2008 = -=20 we wanted to do it earlier, but due to a bug in DSLAM equipment stopped = us=20 to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We = had=20 to wait the telecom operator (1.5 years) to fix the problem. As an = interim=20 solution we started experimenting with 6to4 and Teredo. It was working=20 reasonably well. 2. After fixing the DSLAM bug in the provider network and deployment of=20 native IPv6 DSL service we considered switching 6to4 relay off. But = there=20 was a demand from administrators of our users (Universities, Research=20 Institutes, Libraries) to let it run for further experimenting: There is = only one other provider started provide native IPv6 DSL. The two big DSL = player in Hungary is still testing and piloting their (for at least = another=20 year) IPv6 DSL services. In my opinion tend to be similar to Jordi's. 6to4 is good for=20 experimenting with IPv6. If you need IPv6 service use native solution. = But=20 if there no solution on the market what to do? According to our policy our 6to4 relay is only for experimenting with = IPv6=20 technology..... What about 6to4 relabeled to experimental? Best Regards, Janos Mohacsi > > G/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mohacsi@niif.hu Wed Apr 20 01:57:47 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A3EDE07A9 for ; Wed, 20 Apr 2011 01:57:47 -0700 (PDT) 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.150, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBWk1i1KhyZF for ; Wed, 20 Apr 2011 01:57:46 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfc.amsl.com (Postfix) with ESMTP id 9538BE06C1 for ; Wed, 20 Apr 2011 01:57:46 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id EE489873E2; Wed, 20 Apr 2011 10:57:45 +0200 (CEST) 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 kwN31mZlwDCe; Wed, 20 Apr 2011 10:57:30 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 5D2DB87253; Wed, 20 Apr 2011 10:57:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 598F4871F7; Wed, 20 Apr 2011 10:57:30 +0200 (CEST) Date: Wed, 20 Apr 2011 10:57:30 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Gunter Van de Velde (gvandeve)" In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E5037FCA55@XMB-AMS-101.cisco.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DABE200.3040504@redpill-linpro.com> <4269EA985EACD24987D82DAE2FEC62E5037FCA15@XMB-AMS-101.cisco.com> <4269EA985EACD24987D82DAE2FEC62E5037FCA55@XMB-AMS-101.cisco.com> 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-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:57:47 -0000 On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > For experiments, why not use IPv6 over IPsec, or manual tunnels or DMVPN or.... > All managed solutions, that work pretty well and none have the downside negative side-impacts of 6to4. > Dear Gunter, All the methods, you mentioned is requires some form of management on providers side. Can you list the devices/softwares supporting the methods you have mentioned? Best Regards, Janos Mohacsi > G/ > > -----Original Message----- > From: Mohacsi Janos [mailto:mohacsi@niif.hu] > Sent: 20 April 2011 10:36 > To: Gunter Van de Velde (gvandeve) > Cc: Philip Homburg; Roger J?rgensen; v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > > > > On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > >> >> That depends on your role. From ISP perspective, 6to4 doesn't make a lot of >> sense. But for end users, sometimes a tunnel is all you can get. Sometimes, >> tunnels offer even a more complete IPv6 experience than native. >> >> GV> I guess you are speaking for the simple home-user. In that case what >> limits a user from obtaining a managed commercial service for IPv6? That >> way he gets at least SLA like commitments from his favourite services >> provider. >> >> GV> If its an enterprise there are better solutions out there that >> deliver managed tunneling services.. pick your preferred vendor and they >> will give you some options. > > > In reality the situation slightly worse, let me cite our example: > > 1. NIIF/Hungarnet started to provide native IPv6 DSL service around 2008 - > we wanted to do it earlier, but due to a bug in DSLAM equipment stopped us > to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We had > to wait the telecom operator (1.5 years) to fix the problem. As an interim > solution we started experimenting with 6to4 and Teredo. It was working > reasonably well. > > 2. After fixing the DSLAM bug in the provider network and deployment of > native IPv6 DSL service we considered switching 6to4 relay off. But there > was a demand from administrators of our users (Universities, Research > Institutes, Libraries) to let it run for further experimenting: There is > only one other provider started provide native IPv6 DSL. The two big DSL > player in Hungary is still testing and piloting their (for at least another > year) IPv6 DSL services. > > In my opinion tend to be similar to Jordi's. 6to4 is good for > experimenting with IPv6. If you need IPv6 service use native solution. But > if there no solution on the market what to do? > > According to our policy our 6to4 relay is only for experimenting with IPv6 > technology..... What about 6to4 relabeled to experimental? > > Best Regards, > Janos Mohacsi > > > >> >> G/ >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From gvandeve@cisco.com Wed Apr 20 02:06:45 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 48954E07AF for ; Wed, 20 Apr 2011 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.633 X-Spam-Level: X-Spam-Status: No, score=-9.633 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZxvdeIYVSfn for ; Wed, 20 Apr 2011 02:06:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 254F1E07A9 for ; Wed, 20 Apr 2011 02:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=3873; q=dns/txt; s=iport; t=1303290404; x=1304500004; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=2t4Uo4a2992L+XCfiQ0OYXvnletLBSRcg1G6HFkUJRY=; b=EnglLN4TZ61X6P2ZgjT4m1RGKN7iJeqHHoHnDuJIqwzDuPYxM3bzI+E5 ta9wBb/3TyhqSfSDt0oZu7rsClMalsDimYNTmK1UDoLQs9265ad/RBLV9 hZOcbAjhwy9Uy2LmWL2jD7Cpcbzc24YwGTKxMPuDbxRtKV39bzD5uxceN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIDAJahrk2Q/khMgWdsb2JhbAClPBQBARYmJYhvoiOdAYVxBJIo X-IronPort-AV: E=Sophos;i="4.64,245,1301875200"; d="scan'208";a="26410694" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 20 Apr 2011 09:06:43 +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 p3K96hVb012295; Wed, 20 Apr 2011 09:06:43 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 11:06:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 11:04:38 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FCA87@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/OQ0ypAdQ5GQWQFGv1uW9DkjUTwAAFxxw References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DABE200.3040504@redpill-linpro.com> <4269EA985EACD24987D82DAE2FEC62E5037FCA15@XMB-AMS-101.cisco.com> <4269EA985EACD24987D82DAE2FEC62E5037FCA55@XMB-AMS-101.cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Mohacsi Janos" X-OriginalArrivalTime: 20 Apr 2011 09:06:43.0145 (UTC) FILETIME=[446E3390:01CBFF3A] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:06:45 -0000 Management on SP side? Not really as they do go end-2-end. Manual tunnels can be used when deploying a tunnel broker for example = which can be=20 semi automated, IPvx over IPsec is the base of some other dynamic tunnel = mechanisms=20 like DMVPN, which can cary v6 over a v4 infrastructure for enterprise = customers (DMVPN is=20 a Cisco solution, but I am sure there are others more open like openVPN = I believe). Having an unmanaged service will ofcours require less management then a = managed solution. G/ -----Original Message----- From: Mohacsi Janos [mailto:mohacsi@niif.hu]=20 Sent: 20 April 2011 10:58 To: Gunter Van de Velde (gvandeve) Cc: Philip Homburg; Roger J=F8rgensen; v6ops@ietf.org Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > For experiments, why not use IPv6 over IPsec, or manual tunnels or = DMVPN or.... > All managed solutions, that work pretty well and none have the = downside negative side-impacts of 6to4. > Dear Gunter, All the methods, you mentioned is requires some form of management=20 on providers side. Can you list the devices/softwares supporting the methods you have=20 mentioned? Best Regards, Janos Mohacsi > G/ > > -----Original Message----- > From: Mohacsi Janos [mailto:mohacsi@niif.hu] > Sent: 20 April 2011 10:36 > To: Gunter Van de Velde (gvandeve) > Cc: Philip Homburg; Roger J?rgensen; v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > > > > On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > >> >> That depends on your role. From ISP perspective, 6to4 doesn't make a = lot of >> sense. But for end users, sometimes a tunnel is all you can get. = Sometimes, >> tunnels offer even a more complete IPv6 experience than native. >> >> GV> I guess you are speaking for the simple home-user. In that case = what >> limits a user from obtaining a managed commercial service for IPv6? = That >> way he gets at least SLA like commitments from his favourite services >> provider. >> >> GV> If its an enterprise there are better solutions out there that >> deliver managed tunneling services.. pick your preferred vendor and = they >> will give you some options. > > > In reality the situation slightly worse, let me cite our example: > > 1. NIIF/Hungarnet started to provide native IPv6 DSL service around = 2008 - > we wanted to do it earlier, but due to a bug in DSLAM equipment = stopped us > to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We = had > to wait the telecom operator (1.5 years) to fix the problem. As an = interim > solution we started experimenting with 6to4 and Teredo. It was working > reasonably well. > > 2. After fixing the DSLAM bug in the provider network and deployment = of > native IPv6 DSL service we considered switching 6to4 relay off. But = there > was a demand from administrators of our users (Universities, Research > Institutes, Libraries) to let it run for further experimenting: There = is > only one other provider started provide native IPv6 DSL. The two big = DSL > player in Hungary is still testing and piloting their (for at least = another > year) IPv6 DSL services. > > In my opinion tend to be similar to Jordi's. 6to4 is good for > experimenting with IPv6. If you need IPv6 service use native solution. = But > if there no solution on the market what to do? > > According to our policy our 6to4 relay is only for experimenting with = IPv6 > technology..... What about 6to4 relabeled to experimental? > > Best Regards, > Janos Mohacsi > > > >> >> G/ >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From tjc@ecs.soton.ac.uk Wed Apr 20 02:21:48 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18BE1E0689 for ; Wed, 20 Apr 2011 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtKCPnv92MBj for ; Wed, 20 Apr 2011 02:21:47 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfc.amsl.com (Postfix) with ESMTP id 24E2FE0670 for ; Wed, 20 Apr 2011 02:21:46 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p3K9Li5p010916 for ; Wed, 20 Apr 2011 10:21:44 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p3K9Li5p010916 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1303291305; bh=c9LTiOLNYg8uvqYaOL3kx34jL5o=; h=From:Subject:Date:To:Mime-Version:References; b=VOwbMRFQTt271dCK0/fc3EQyWYRSjhEBmX0r+OoiB/Jmr76J3qMk2BMXt4htBECjT 1Bm1zZvMPWBT/vcgKVVznOOmpGGVmVRBThU6hMXfPrqBol50iBcNH/mTAzCfgpMcGI pMWdjsYBoHSJetsWLrQSxessP1RXZ+cmLAimXp4g= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n3JALi0035613491n9 ret-id none; Wed, 20 Apr 2011 10:21:44 +0100 Received: from [IPv6:2a00:1a80:1::6233:4bff:fe11:a753] ([IPv6:2a00:1a80:1:0:6233:4bff:fe11:a753]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p3K9LdRK021204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Apr 2011 10:21:40 +0100 From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 10:21:38 +0100 Message-ID: To: IPv6 Ops WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n3JALi003561349100; tid=n3JALi0035613491n9; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p3K9Li5p010916 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [v6ops] IPv6 call to arms draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:21:48 -0000 Hi, An updated version of this is now available including feedback from = IETF80 and other lists. http://tools.ietf.org/html/draft-chown-v6ops-call-to-arms-02 The primary focus remains documenting common causes of connectivity = issues (with an end site focus) and methods that might be used to gather = measurements of traffic and 'IPv6 brokenness' through the ISOC IPv6 Day. Tim= From nick@inex.ie Wed Apr 20 02:36:37 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 73321E06A0 for ; Wed, 20 Apr 2011 02:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e5e0hPlWmc0 for ; Wed, 20 Apr 2011 02:36:36 -0700 (PDT) Received: from mail.acquirer.com (unknown [IPv6:2001:1bb8:2004:150::2]) by ietfc.amsl.com (Postfix) with ESMTP id 96237E0695 for ; Wed, 20 Apr 2011 02:36:35 -0700 (PDT) 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 p3K9aMJ2013489 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 10:36:22 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DAEA916.90908@inex.ie> Date: Wed, 20 Apr 2011 10:36:22 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110314 Thunderbird/3.3a3 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.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] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:36:37 -0000 On 20/04/2011 09:11, Gunter Van de Velde (gvandeve) wrote: > I think that a signal like '6to4' is now historical is a quite clear > headliner... why keep a technology, which gives grief for the Internet > due to bad connectivity alive? No-one's disputing the intent. What's at issue here is whether vendors will act on a generic recommendation to deprecate the protocol (which is what's being proposed), or whether they need a concrete plan for service termination before they will pull support from their routing stacks (which is what at least one vendor is suggesting). Problem is, if some sort of compromise isn't reached, then in a couple of years time, the v6ops WG is going to stick its hand up and say honestly, "we've deprecated 6to4", and the vendors are going to stick their hands up and say honestly, "we're fully compliant with all the relevant RFCs". Both will be technically correct, and the end result will be that 6to4 will never, ever die. Meanwhile, operators will froth at the mouth and end-users will wonder why their v6 connectivity is broken. It's not really in anyone's interest to have an argument about due process which ends up with Internet end-users getting the bum deal. As an end-user and operator, I'm sick and tired of being at the receiving end of this sort of thing from vendors due to internal political wrangling. I suggest that if Ole feels that a formal end-date for removal of 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we create a very small new ID which explicitly states a date on which IANA formally deregisters both prefixes and requests that operators filter them from the DFZ. It's not a biggie, but if it's what's needed to get vendors to ditch support, then let's just be pragmatic and do it. You can count this as a formal offer to write a very short draft specifying an specific end-date for 6to4, if this isn't going to appear in draft-ietf-v6ops-6to4-to-historic. Nick From ichiroumakino@gmail.com Wed Apr 20 03:57:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 439ECE0695 for ; Wed, 20 Apr 2011 03:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SmqLU6QcQyZ for ; Wed, 20 Apr 2011 03:57:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5C37FE0689 for ; Wed, 20 Apr 2011 03:57:00 -0700 (PDT) Received: by eye13 with SMTP id 13so220788eye.31 for ; Wed, 20 Apr 2011 03:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rc2yDOcCUXgYPshm8dRxnpZ/7xdM1BWFPNu6lcxDCXI=; b=swLtpXolvWS2e18o2ygEDBGD6xqtQSKtjaPf2THP2q6DpsyzUR08dliy2RFyaa3pKx XlKxV0pbcWp8dDXhOXDRuaUdG3emF+wYnqKbb/K7g72luN4nJVo9rpaOYaUQ072vgtON k2RWjfNDvP8ZO1pIGJOt0xAd8oq30UboORhf8= 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=eYySJ49n600G0E9hokKHDUYuqyeLM/u08BsWbT5xgFXC+c2F1qkanTHo0X6ZkWnxh4 7WfOMOJr0nEk88FxpZA5Ys70DIiLSlfUZcal3xMXKrrr2lfqfVvQnBdKIXSKLXh1i0Sc BIZVagJiX7ZWecJcbFY3qQPuhJQmYznNCR0OE= Received: by 10.213.7.72 with SMTP id c8mr1081433ebc.72.1303297019618; Wed, 20 Apr 2011 03:56:59 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id r48sm568697eei.2.2011.04.20.03.56.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 03:56:57 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4DAEA916.90908@inex.ie> Date: Wed, 20 Apr 2011 12:56:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:57:01 -0000 Nick, >> I think that a signal like '6to4' is now historical is a quite clear >> headliner... why keep a technology, which gives grief for the = Internet >> due to bad connectivity alive? >=20 > No-one's disputing the intent. What's at issue here is whether = vendors will act on a generic recommendation to deprecate the protocol = (which is what's being proposed), or whether they need a concrete plan = for service termination before they will pull support from their routing = stacks (which is what at least one vendor is suggesting). >=20 > Problem is, if some sort of compromise isn't reached, then in a couple = of years time, the v6ops WG is going to stick its hand up and say = honestly, "we've deprecated 6to4", and the vendors are going to stick = their hands up and say honestly, "we're fully compliant with all the = relevant RFCs". Both will be technically correct, and the end result = will be that 6to4 will never, ever die. Meanwhile, operators will froth = at the mouth and end-users will wonder why their v6 connectivity is = broken. >=20 > It's not really in anyone's interest to have an argument about due = process which ends up with Internet end-users getting the bum deal. As = an end-user and operator, I'm sick and tired of being at the receiving = end of this sort of thing from vendors due to internal political = wrangling. >=20 > I suggest that if Ole feels that a formal end-date for removal of = 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we = create a very small new ID which explicitly states a date on which IANA = formally deregisters both prefixes and requests that operators filter = them from the DFZ. It's not a biggie, but if it's what's needed to get = vendors to ditch support, then let's just be pragmatic and do it. >=20 > You can count this as a formal offer to write a very short draft = specifying an specific end-date for 6to4, if this isn't going to appear = in draft-ietf-v6ops-6to4-to-historic. I'd rather not specify an end date. I don't think the goal here is to make vendors remove the 6to4 code from = their implementations. and it isn't like we need to recycle the = 2002::/16 prefix any time soon. I personally don't think an end date would make any difference from a = vendor perspective. it isn't like we can upgrade all hardware and = software in the field anyway. what I hope this document can be used is as a strong encouragement to = vendors to not enable it by default, and at least make it break less. by = implementing RFC3484bis, implementing a reachability check for the = default gateway, not enable it if the IPv4 address is rfc1918 and I'm = sure a few more. (and yes, the fruity machine I'm sitting on right now = doesn't implement any of these).=20 cheers, Ole= From gert@space.net Wed Apr 20 05:08:26 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71D5BE0750 for ; Wed, 20 Apr 2011 05:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfMEz-9C5dL2 for ; Wed, 20 Apr 2011 05:08:25 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfc.amsl.com (Postfix) with ESMTP id D2C35E0742 for ; Wed, 20 Apr 2011 05:08:24 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id CD1DEF81B3 for ; Wed, 20 Apr 2011 14:08:23 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B958FF81C5 for ; Wed, 20 Apr 2011 14:08:23 +0200 (CEST) Received: (qmail 54456 invoked by uid 1007); 20 Apr 2011 14:08:23 +0200 Date: Wed, 20 Apr 2011 14:08:23 +0200 From: Gert Doering To: JORDI PALET MARTINEZ Message-ID: <20110420120823.GX30227@Space.Net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7309D@PLSWM12A.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:08:26 -0000 Hi, On Wed, Apr 20, 2011 at 12:40:23AM +0200, JORDI PALET MARTINEZ wrote: > Ok, so let's go for the draft-ietf-v6ops-6to4-advisory, as we seem to have > agreement on that, but not on 6to4-to-historic. We have rough consensus for 6to4-to-historic. > In my context and the context of my customers, where 6to4 works much > better than what is being reported, having some IPv6 support is much > better than not having it. Feel free to leave it enabled on your machines, nobody is yanking out the code from your implementations. But *listen* to folks like Tore who have had serious problems enabling content on IPv6 (and I assume this is what you also want to see!) *because* of 6to4. 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 prvs=1091e09317=jordi.palet@consulintel.es Wed Apr 20 05:14:24 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BDE4DE0655 for ; Wed, 20 Apr 2011 05:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIIChlVDlUBP for ; Wed, 20 Apr 2011 05:14:24 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfc.amsl.com (Postfix) with ESMTP id 80B7BE05F5 for ; Wed, 20 Apr 2011 05:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1303301245; x=1303906045; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=fKEyrW6TGCCLBIYlCM6HjTl4X 6e35RSFPc8s6+i1HqU=; b=km2hcrobd8YIFveu05PlSEBEKaoRo1uQ1lp+QigmP TIUE3Z+pJ6QuNzTqfc6VritPWlbZzLbnj4P+jQyNmr8QUChnSpZhJqmo13AMNMct SlNWgScZ+37uFk/uoA0vUrhxodq0bD3M1YgoHpLBgrCUqnHLQdpvqI5q8Ue+tKbA 24= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Js3MnCNoyaPEPcbX3Dego0lgS8pV1F8hQhz96MvfUE+lfoZ4Nm07uoV6VEdW X9fqYBRLriQ1UlH6ItBpcxsZVJ+FojqnVJFn8pbSLQmLx9haM/el2y3qy x0TJ7NKXHgZL/FJL9G+YEWfvsj43Mucm49U3MFB69VUB2CuokhZJ08=; X-MDAV-Processed: consulintel.es, Wed, 20 Apr 2011 14:07:25 +0200 Received: from [10.10.10.118] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50003877230.msg for ; Wed, 20 Apr 2011 14:07:25 +0200 X-Spam-Processed: consulintel.es, Wed, 20 Apr 2011 14:07:25 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=160.red-217-126-187.staticip.rima-tde.net (ip=217.126.187.160) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:110420:md50003877230::qTRI5GdpVVyspqDb:00004E40 X-MDRemoteIP: 217.126.187.160 X-Return-Path: prvs=1091e09317=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 20 Apr 2011 14:13:59 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC In-Reply-To: <20110420120823.GX30227@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:14:24 -0000 Hi Gert, I agree in the goal, we want IPv6 native being deployed and making sure to avoid failures, but not the way we are doing with this document. I think there has been enough voices in favour but also many against, so I don't think this is consensus. There have been major objections, such as some text in the draft which is not true or clear enough. This should be corrected at least, despite you still think there is consensus, we can't have consensus in a document that has inconsistencies such as "hasn't been deployed" (it reads as 6to4 itself, not a specific way to use it), which is not true, right ? Regards, Jordi -----Mensaje original----- De: Gert Doering Responder a: Fecha: Wed, 20 Apr 2011 14:08:23 +0200 Para: Jordi Palet Martinez CC: "v6ops@ietf.org" , "ron@bonica.org" Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >Hi, > >On Wed, Apr 20, 2011 at 12:40:23AM +0200, JORDI PALET MARTINEZ wrote: >> Ok, so let's go for the draft-ietf-v6ops-6to4-advisory, as we seem to >>have >> agreement on that, but not on 6to4-to-historic. > >We have rough consensus for 6to4-to-historic. > >> In my context and the context of my customers, where 6to4 works much >> better than what is being reported, having some IPv6 support is much >> better than not having it. > >Feel free to leave it enabled on your machines, nobody is yanking out >the code from your implementations. > >But *listen* to folks like Tore who have had serious problems enabling >content on IPv6 (and I assume this is what you also want to see!) >*because* of 6to4. > >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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From ek@google.com Wed Apr 20 05:16:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4BAB7E0655 for ; Wed, 20 Apr 2011 05:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.848 X-Spam-Level: X-Spam-Status: No, score=-107.848 tagged_above=-999 required=5 tests=[AWL=-1.871, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y219F9Fkq0Nd for ; Wed, 20 Apr 2011 05:16:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 5E7B0E0611 for ; Wed, 20 Apr 2011 05:16:37 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p3KCGZsh028793 for ; Wed, 20 Apr 2011 05:16:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303301796; bh=P5czndLj57IJ1k/okMapZG0AyhA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=pItLelAGsXCtvGqAprrYfd9XEX+yLpqwCxXM4JmmiCaFGh+JYvBIkGsDtfhZu0Xty BC3d0i8dAoGd5gy3UNBhg== Received: from qwf6 (qwf6.prod.google.com [10.241.194.70]) by hpaq6.eem.corp.google.com with ESMTP id p3KCGXX5028360 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Apr 2011 05:16:34 -0700 Received: by qwf6 with SMTP id 6so441551qwf.30 for ; Wed, 20 Apr 2011 05:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SxpJT1GuuJ0CJr5IFS8v+rhVWPrB6GiCmhTrGk77GSc=; b=BhTtMS9JWJ3Dn1ZSYrGIpPvWa+vUMl9FZ7cuRNo5gzmwlRfwRRlv+fPtNODZhLAfWG sBBM0h97WINof5eHOajQ== 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=SDmVwJxWFvL8oawe0nUHMfM5NUhTZNkv1sV5EEYWzLT5AzkvAeDGJek6m0wf2QC5XI UrNxfv0Ij6/pBowa6YUA== MIME-Version: 1.0 Received: by 10.224.71.74 with SMTP id g10mr5467438qaj.83.1303301793579; Wed, 20 Apr 2011 05:16:33 -0700 (PDT) Received: by 10.229.253.203 with HTTP; Wed, 20 Apr 2011 05:16:33 -0700 (PDT) In-Reply-To: <20110420120823.GX30227@Space.Net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7309D@PLSWM12A.ad.sprint.com> <20110420120823.GX30227@Space.Net> Date: Wed, 20 Apr 2011 21:16:33 +0900 Message-ID: From: Erik Kline To: Gert Doering Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org" , "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:16:38 -0000 > But *listen* to folks like Tore who have had serious problems enabling > content on IPv6 (and I assume this is what you also want to see!) > *because* of 6to4. +1 I, for one, really don't see us adding networks to the Google over IPv6 program that have a large 6to4-preferring population. From cb.list6@gmail.com Wed Apr 20 08:06:53 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D8DFE06F4 for ; Wed, 20 Apr 2011 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuBfKk4E4gRT for ; Wed, 20 Apr 2011 08:06:52 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 30F70E06E0 for ; Wed, 20 Apr 2011 08:06:52 -0700 (PDT) Received: by ewy19 with SMTP id 19so305650ewy.31 for ; Wed, 20 Apr 2011 08:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7jGLhiY1SMbfKONjwYIxjHvtqtRkDqqsHzYv2aVkxWA=; b=lavnDSBdyKh1BLByIqcPHCPnM5qvMDnwOwIHEm/VvnMurNpTc1Hp/Dy8dtiAW6pefR FJF8f+R6nVGG3luHUZYfMc5O4BcFupfXcnq4EnJH0/hHZ/O7/umQ4yJ8Mitw3qXjQQfz 7NgDz8WM3tCvjUHNVAJTEoWY9Gsuas+K3nOk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VT1uFh33cquHFHC963Gk3kZCC2SdPfpyX+dAxZm646PuxTRkpJm/9W8jR4oWE6Y80T bqYFxe0lrTaoc54+1Wov95P9LITIrlBeo+0fVNzylQmXys3pTXGubjZ895pEbfMpI7Fi ADiKKqXgRfXxQc9FglomP8NNrQrnXnx3mOEa8= MIME-Version: 1.0 Received: by 10.213.25.76 with SMTP id y12mr310520ebb.136.1303312010473; Wed, 20 Apr 2011 08:06:50 -0700 (PDT) Received: by 10.213.114.147 with HTTP; Wed, 20 Apr 2011 08:06:50 -0700 (PDT) Received: by 10.213.114.147 with HTTP; Wed, 20 Apr 2011 08:06:50 -0700 (PDT) Date: Wed, 20 Apr 2011 08:06:50 -0700 Message-ID: From: Cameron Byrne To: Mohacsi Janos Content-Type: multipart/alternative; boundary=0015174413846a714a04a15af9d7 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:06:53 -0000 --0015174413846a714a04a15af9d7 Content-Type: text/plain; charset=ISO-8859-1 On Apr 20, 2011 1:36 AM, "Mohacsi Janos" wrote: > > > > > On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote: > >> >> That depends on your role. From ISP perspective, 6to4 doesn't make a lot of >> sense. But for end users, sometimes a tunnel is all you can get. Sometimes, >> tunnels offer even a more complete IPv6 experience than native. >> >> GV> I guess you are speaking for the simple home-user. In that case what limits a user from obtaining a managed commercial service for IPv6? That way he gets at least SLA like commitments from his favourite services provider. >> >> GV> If its an enterprise there are better solutions out there that deliver managed tunneling services.. pick your preferred vendor and they will give you some options. > > > > In reality the situation slightly worse, let me cite our example: > > 1. NIIF/Hungarnet started to provide native IPv6 DSL service around 2008 - we wanted to do it earlier, but due to a bug in DSLAM equipment stopped us to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We had to wait the telecom operator (1.5 years) to fix the problem. As an interim solution we started experimenting with 6to4 and Teredo. It was working reasonably well. > > 2. After fixing the DSLAM bug in the provider network and deployment of native IPv6 DSL service we considered switching 6to4 relay off. But there was a demand from administrators of our users (Universities, Research Institutes, Libraries) to let it run for further experimenting: There is only one other provider started provide native IPv6 DSL. The two big DSL player in Hungary is still testing and piloting their (for at least another year) IPv6 DSL services. > > In my opinion tend to be similar to Jordi's. 6to4 is good for experimenting with IPv6. If you need IPv6 service use native solution. But if there no solution on the market what to do? > > According to our policy our 6to4 relay is only for experimenting with IPv6 technology..... What about 6to4 relabeled to experimental? > What good is this policy if the customer does not know they are using 6to4 because it is default on? If the customer NEEDS ipv6 (I wish I had these customers, I don't) then surely they would rather have a managed service like 6rd or ideally native Cb > Best Regards, > Janos Mohacsi > > > > >> >> G/ >> _______________________________________________ >> 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 --0015174413846a714a04a15af9d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 20, 2011 1:36 AM, "Mohacsi Janos" <mohacsi@niif.hu> wrote:
>
>
>
>
> On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote:
>
>>
>> That depends on your role. From ISP perspective, 6to4 doesn't = make a lot of
>> sense. But for end users, sometimes a tunnel is all you can get. S= ometimes,
>> tunnels offer even a more complete IPv6 experience than native. >>
>> GV> I guess you are speaking for the simple home-user. In that = case what limits a user from obtaining a managed commercial service for IPv= 6? That way he gets at least SLA like commitments from his favourite servic= es provider.
>>
>> GV> If its an enterprise there are better solutions out there t= hat deliver managed tunneling services.. pick your preferred vendor and the= y will give you some options.
>
>
>
> In reality the situation slightly worse, let me cite our example:
>
> 1. NIIF/Hungarnet started to provide native IPv6 DSL service around 20= 08 - we wanted to do it earlier, but due to a bug in DSLAM equipment stoppe= d us to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We= had to wait the telecom operator (1.5 years) to fix the problem. As an int= erim solution we started experimenting with 6to4 and Teredo. It was working= reasonably well.
>
> 2. After fixing the DSLAM bug in the provider network and deployment o= f native IPv6 DSL service we considered switching 6to4 relay off. But there= was a demand from administrators of our users (Universities, Research Inst= itutes, Libraries) to let it run for further experimenting: There is only o= ne other provider started provide native IPv6 DSL. The two big DSL player i= n Hungary is still testing and piloting their (for at least another year) I= Pv6 DSL services.
>
> In my opinion tend to be similar to Jordi's. 6to4 is good for expe= rimenting with IPv6. If you need IPv6 service use native solution. But if t= here no solution on the market what to do?
>
> According to our policy our 6to4 relay is only for experimenting with = IPv6 technology..... What about 6to4 relabeled to experimental?
>

What good is this policy if the customer does not know they are using 6t= o4 because it is default on?

If the customer NEEDS ipv6 (I wish I had these customers, I don't) t= hen surely they would rather have a managed service like 6rd or ideally nat= ive

Cb

> Best Regards,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Janos Mohacsi
>
>
>
>
>>
>> G/
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0015174413846a714a04a15af9d7-- From Dmitry.Anipko@microsoft.com Wed Apr 20 10:38:28 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 48489E06EE for ; Wed, 20 Apr 2011 10:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBJEGOWJsL+v for ; Wed, 20 Apr 2011 10:38:27 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 0B4D5E067D for ; Wed, 20 Apr 2011 10:38:27 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 10:38:20 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 10:38:20 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Wed, 20 Apr 2011 10:37:33 -0700 From: Dmitry Anipko To: Ole Troan , Nick Hilliard Date: Wed, 20 Apr 2011 10:37:32 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/SbqmYppH2878S8WptVxSoIqI3wANy2Sg Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> In-Reply-To: <4C603E97-C164-4426-8584-2A429FA41D35@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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:38:28 -0000 Hi Ole, >>I don't think the goal here is to make vendors remove the 6to4 code from = their implementations. and it isn't like we need to recycle the 2002::/16 p= refix any time soon. I personally don't think an end date would make any difference from a vendo= r perspective. it isn't like we can upgrade all hardware and software in th= e field anyway. what I hope this document can be used is as a strong encouragement to vendo= rs to not enable it by default, and at least make it break less. by impleme= nting RFC3484bis, implementing a reachability check for the default gateway= , not enable it if the IPv4 address is rfc1918 and I'm sure a few more. Shouldn't the focus then be on those specific recommendations which address= the specific known problems, rather than blanket deprecation, which enjoys= broad support of operators but doesn't have a clear meaning to vendors, as= you indicate above? I completely agree that all the example recommendations you listed are addr= essing specific problems (RFC 3484bis regarding 6to4, reachability check fo= r gateway, not enabling 6to4 for RFC 1918 addresses) and vendors should fol= low them, if they aren't already. But once they (and any other specific rec= ommendations, if there are any) are followed, from the current draft it is = not clear to me what the move to historic for RFC 3056 is trying to achieve= or why it is necessary. Thank you, Dmitry -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of O= le Troan Sent: Wednesday, April 20, 2011 3:57 AM To: Nick Hilliard Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Nick, >> I think that a signal like '6to4' is now historical is a quite clear >> headliner... why keep a technology, which gives grief for the Internet >> due to bad connectivity alive? >=20 > No-one's disputing the intent. What's at issue here is whether vendors w= ill act on a generic recommendation to deprecate the protocol (which is wha= t's being proposed), or whether they need a concrete plan for service termi= nation before they will pull support from their routing stacks (which is wh= at at least one vendor is suggesting). >=20 > Problem is, if some sort of compromise isn't reached, then in a couple of= years time, the v6ops WG is going to stick its hand up and say honestly, "= we've deprecated 6to4", and the vendors are going to stick their hands up a= nd say honestly, "we're fully compliant with all the relevant RFCs". Both = will be technically correct, and the end result will be that 6to4 will neve= r, ever die. Meanwhile, operators will froth at the mouth and end-users wi= ll wonder why their v6 connectivity is broken. >=20 > It's not really in anyone's interest to have an argument about due proces= s which ends up with Internet end-users getting the bum deal. As an end-us= er and operator, I'm sick and tired of being at the receiving end of this s= ort of thing from vendors due to internal political wrangling. >=20 > I suggest that if Ole feels that a formal end-date for removal of 2002::/= 16 and 192.88.99.0/24 is out of scope for this draft, that we create a very= small new ID which explicitly states a date on which IANA formally deregis= ters both prefixes and requests that operators filter them from the DFZ. I= t's not a biggie, but if it's what's needed to get vendors to ditch support= , then let's just be pragmatic and do it. >=20 > You can count this as a formal offer to write a very short draft specifyi= ng an specific end-date for 6to4, if this isn't going to appear in draft-ie= tf-v6ops-6to4-to-historic. I'd rather not specify an end date. I don't think the goal here is to make vendors remove the 6to4 code from th= eir implementations. and it isn't like we need to recycle the 2002::/16 pre= fix any time soon. I personally don't think an end date would make any difference from a vendo= r perspective. it isn't like we can upgrade all hardware and software in th= e field anyway. what I hope this document can be used is as a strong encouragement to vendo= rs to not enable it by default, and at least make it break less. by impleme= nting RFC3484bis, implementing a reachability check for the default gateway= , not enable it if the IPv4 address is rfc1918 and I'm sure a few more. (an= d yes, the fruity machine I'm sitting on right now doesn't implement any of= these).=20 cheers, Ole _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Wed Apr 20 10:46:22 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1E489E067D for ; Wed, 20 Apr 2011 10:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX8boVIAchxJ for ; Wed, 20 Apr 2011 10:46:21 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfc.amsl.com (Postfix) with ESMTP id 93136E0677 for ; Wed, 20 Apr 2011 10:46:20 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4B49BF81F7 for ; Wed, 20 Apr 2011 19:46:20 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 35F4CF8189 for ; Wed, 20 Apr 2011 19:46:20 +0200 (CEST) Received: (qmail 51709 invoked by uid 1007); 20 Apr 2011 19:46:20 +0200 Date: Wed, 20 Apr 2011 19:46:20 +0200 From: Gert Doering To: Dmitry Anipko Message-ID: <20110420174620.GA30227@Space.Net> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:46:22 -0000 Hi, On Wed, Apr 20, 2011 at 10:37:32AM -0700, Dmitry Anipko wrote: > it is not clear to me what the move to historic for RFC 3056 is trying to achieve or why it is necessary. What do you hope to achieve by *not* moving RFC 3056 to historic? 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 Dmitry.Anipko@microsoft.com Wed Apr 20 10:55:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A3AD4E0704 for ; Wed, 20 Apr 2011 10:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VswXwhn9Uo0f for ; Wed, 20 Apr 2011 10:55:55 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id AE1A1E0695 for ; Wed, 20 Apr 2011 10:55:55 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 10:55:54 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 10:55:55 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Wed, 20 Apr 2011 10:55:16 -0700 From: Dmitry Anipko To: Gert Doering Date: Wed, 20 Apr 2011 10:55:15 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/gt53ccsR3BvlTz2tZHvmVJ1P2QAAJMIA Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> <20110420174620.GA30227@Space.Net> In-Reply-To: <20110420174620.GA30227@Space.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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:55:56 -0000 Hi Gert, To answer your question - avoid breaking those end users for whom 6to4 curr= ently works and is the only available option for IPv6 connectivity, since i= t was stated on these WGLC threads that while many ISPs have deployment eff= orts under way, not that many ISPs already have *today* IPv6 offering to th= e end users. Thank you, Dmitry -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: Wednesday, April 20, 2011 10:46 AM To: Dmitry Anipko Cc: Ole Troan; Nick Hilliard; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Hi, On Wed, Apr 20, 2011 at 10:37:32AM -0700, Dmitry Anipko wrote: > it is not clear to me what the move to historic for RFC 3056 is trying to= achieve or why it is necessary. What do you hope to achieve by *not* moving RFC 3056 to historic? 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 From ichiroumakino@gmail.com Wed Apr 20 11:13:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2AFEEE06EB for ; Wed, 20 Apr 2011 11:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ClzlF5MDRsf for ; Wed, 20 Apr 2011 11:13:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 18BA3E073F for ; Wed, 20 Apr 2011 11:13:25 -0700 (PDT) Received: by wyb29 with SMTP id 29so939730wyb.31 for ; Wed, 20 Apr 2011 11:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=igHcr3axn6IIimalSsDNNvtse3v2QaXmgODJKgwmT3U=; b=iCKy/BCFeT+PeNhkouzZJdl2IcITFa3rOrdA/NChD5dhnyTORi6rGyKDdll03BQmX0 ityrkRV0tWjQqZkMJObS5piL3trbZAh+cviM0gJoU1NPa+U/81QdvbPo5SvSPuFPPE04 026ht+r7AObM1rmUjtGIlBDbUXyYTkl0xhCjQ= 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=Dghx6jj1R5/Fu8IU3eU1FvK45IftKvb2DFV5SV8U5Hr84NOM5JgpGUsyW5dnai+MEb DVc1y2VByq1DMkDIuYTkvIJwAbUtqJFKBDtK5V7tx4rsqDv+eml24XlYUKS3i7Lf/pCK t7g0oX5/AjZGAR32ctysBHG+F/gBqVgdm+QGo= Received: by 10.227.203.145 with SMTP id fi17mr7830654wbb.106.1303323205322; Wed, 20 Apr 2011 11:13:25 -0700 (PDT) Received: from dhcp-10-61-104-154.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id w25sm720080wbd.56.2011.04.20.11.13.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 11:13:24 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 20 Apr 2011 20:13:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A9470B0-5D3B-4080-A75D-5D28EE39CA91@employees.org> References: To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "ron@bonica.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:13:39 -0000 Jordi, > There have been major objections, such as some text in the draft which = is > not true or clear enough. This should be corrected at least, despite = you > still think there is consensus, we can't have consensus in a document = that > has inconsistencies such as "hasn't been deployed" (it reads as 6to4 > itself, not a specific way to use it), which is not true, right ? is the text in question this: "The managed IPv6 transition mechanism "Connection of IPv6 Domains via IPv4 Clouds (6to4)" described in [RFC3056] has rarely if ever been deployed." from the introduction? note that it reads "_managed_". then later in the document (section 3.) it has: "One model of 6to4 deployment as described in section 5.2, RFC3056, suggests that a 6to4 router should have a set of managed connections (via BGP connections) to a set of 6to4 relay routers. While this makes the forward path more controlled, it does not guarantee a functional reverse path. In any case this model has the same operational burden has manually configured tunnels and has seen no deployment in the public Internet." I think perhaps the confusion happens, because this deployment model of = 6to4 is so unfamiliar. the idea was for the 6to4 router to run BGP with a set of relay routers, = where each relay router would only advertise prefixes that it was = willing to relay for. if the introduction and the paragraph in section 3 isn't clear enough, = please provide improvements. what other major objections are you referring to? cheers, Ole= From Wesley.E.George@sprint.com Wed Apr 20 11:15:40 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA145E06C4 for ; Wed, 20 Apr 2011 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKYhWbDsOhVi for ; Wed, 20 Apr 2011 11:15:40 -0700 (PDT) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfc.amsl.com (Postfix) with ESMTP id 13348E067D for ; Wed, 20 Apr 2011 11:15:40 -0700 (PDT) Received: from mail40-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Wed, 20 Apr 2011 18:15:39 +0000 Received: from mail40-tx2 (localhost.localdomain [127.0.0.1]) by mail40-tx2-R.bigfish.com (Postfix) with ESMTP id 8D2E5E40413; Wed, 20 Apr 2011 18:15:39 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371O542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) 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 mail40-tx2 (localhost.localdomain [127.0.0.1]) by mail40-tx2 (MessageSwitch) id 1303323339213484_21296; Wed, 20 Apr 2011 18:15:39 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.249]) by mail40-tx2.bigfish.com (Postfix) with ESMTP id 2FB9517B804F; Wed, 20 Apr 2011 18:15:39 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 20 Apr 2011 18:15:35 +0000 Received: from PDAWEH01.ad.sprint.com (PDAWEH01.corp.sprint.com [144.226.110.69]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3KIFYph010710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Apr 2011 13:15:34 -0500 Received: from PLSWEH04.ad.sprint.com (144.226.251.22) by PDAWEH01.ad.sprint.com (144.226.110.69) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 20 Apr 2011 13:15:33 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH04.ad.sprint.com ([2002:90e2:fb16::90e2:fb16]) with mapi id 14.01.0270.001; Wed, 20 Apr 2011 13:15:33 -0500 From: "George, Wes E [NTK]" To: Dmitry Anipko , Gert Doering Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/gt53ccsR3BvlTz2tZHvmVJ1P2QAAJMIAAACjVNA= Date: Wed, 20 Apr 2011 18:15:32 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7F96C@PLSWM12A.ad.sprint.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> <20110420174620.GA30227@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.113] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0171_01CBFF65.67D1BED0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:15:41 -0000 ------=_NextPart_000_0171_01CBFF65.67D1BED0 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 Dmitry Anipko Sent: Wednesday, April 20, 2011 1:55 PM To: Gert Doering Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC To answer your question - avoid breaking those end users for whom 6to4 currently works and is the only available option for IPv6 connectivity, since it was stated on these WGLC threads that while many ISPs have deployment efforts under way, not that many ISPs already have *today* IPv6 offering to the end users. [WEG] Then I'd encourage you to reread the draft. Specifically this: It is expected that disabling 6to4 in the IPv6 Internet will take some time. The initial approach is to make the 6to4 a service of "last resort" in host implementations, ensure that the 6to4 service is disabled by default in 6to4 routers, and deploy native IPv6 service. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Then explain how this draft is going to break end users for whom 6to4 currently works. You should be far more worried about CGN + non 1918 internal NAT pools as a means to break currently working 6to4 users. Further, 6to4 is almost *never* the only option for IPv6 connectivity, even if the upstream is a laggard in deploying IPv6. Wes George ------=_NextPart_000_0171_01CBFF65.67D1BED0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyMDE4 MTUzMFowIwYJKoZIhvcNAQkEMRYEFB7vj1zoWtySSj2zXohLrkdWcRL7MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgEjYdI7PjZa38OozxVq3oDufEZAiZD3WBPAGCGNrA4NF2jwS5HuEyWguPd0/ZBa6sxOg ZV+WUwUvnY+8P4tqFteIeixIwnJYN1q6OMuqO6P2u6PSLn/l2f55vDu/gITa2m2fg5InJlZVESLL 3bmQRChHZ3D8PBdaSOo+1eusn/xpAAAAAAAA ------=_NextPart_000_0171_01CBFF65.67D1BED0-- From ichiroumakino@gmail.com Wed Apr 20 11:22:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A995BE073E for ; Wed, 20 Apr 2011 11:22:07 -0700 (PDT) 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.550, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1avMpp1dUxUw for ; Wed, 20 Apr 2011 11:22:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id BDB9FE0735 for ; Wed, 20 Apr 2011 11:22:06 -0700 (PDT) Received: by wwa36 with SMTP id 36so829971wwa.13 for ; Wed, 20 Apr 2011 11:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=scHo3ITcBDAbefx188rAJl8EYmxBhod1HVpr71KQt4c=; b=E32KJCiKpVWli9Mf2sch6IBv8R7XuniQbJ0HOWVlFuhYvGDm2k7hnuerOt93pt0SYc WYuljeRreK7fq44pEE6WIieUhBLriiQlhdWwlXZsPTho32lvSS+Gr96BkEdUbO0SBUEb fxO9mbgQjoYoq1s9hYFBJDV5bBnc6wR65mss8= 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=bb7SCYY9KuKBRJxOevEDjPd44chobVjddCC2YqFDt2sX+WP/Tou76ILPXOZpxywlom Te0PBkYPVTCXF0W9g6Yg7IH9kULD5HqvSwH0d/kCUBfp++nzTqXzAs9oMHgRUyQJV+F3 kpWlSnq0SXdrVmgw0WmN+5HwwE7iWDPJzwvmw= Received: by 10.227.197.201 with SMTP id el9mr128868wbb.22.1303323725932; Wed, 20 Apr 2011 11:22:05 -0700 (PDT) Received: from dhcp-10-61-104-154.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id z13sm725200wbd.46.2011.04.20.11.22.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 11:22:04 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 20 Apr 2011 20:22:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <280D9CD9-EC9C-400A-BDA5-C11A69A383E0@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:22:07 -0000 Dmitry, [...] > Shouldn't the focus then be on those specific recommendations which = address the specific known problems, rather than blanket deprecation, = which enjoys broad support of operators but doesn't have a clear meaning = to vendors, as you indicate above? I don't think we should take the users out of the equation either. with my user hat on I have tried 6to4 on numerous occasions, I have = _always_ been forced to turn it off. isn't there a clear meaning to vendors? I wrote this document in the = first place to be able to convince one part of our business that they = must stop shipping products with 6to4 enabled by default. > I completely agree that all the example recommendations you listed are = addressing specific problems (RFC 3484bis regarding 6to4, reachability = check for gateway, not enabling 6to4 for RFC 1918 addresses) and vendors = should follow them, if they aren't already. But once they (and any other = specific recommendations, if there are any) are followed, from the = current draft it is not clear to me what the move to historic for RFC = 3056 is trying to achieve or why it is necessary. sure, what does an IETF document ever achieve? ;-) make a clear statement from the IETF, that it does not consider 6to4 as = a valid mechanism to achieve IPv6 connectivity. remove that particular option from the table when a user, operator or = vendor is considering what should be deployed/implemented... a lot of people have stated how 6to4 is slowing down and hindering IPv6 = deployment rather than accelerating it. if this document can make = vendors stop contributing to the problem by exposing innocent bystanders = to a mechanism that doesn't work then a lot would be done. obviously = consenting adults can do what they like. cheers, Ole= From ichiroumakino@gmail.com Wed Apr 20 11:30:22 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7B432E0763 for ; Wed, 20 Apr 2011 11:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jtokq-bYWho6 for ; Wed, 20 Apr 2011 11:30:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id A4DC2E0750 for ; Wed, 20 Apr 2011 11:30:20 -0700 (PDT) Received: by wwa36 with SMTP id 36so835206wwa.13 for ; Wed, 20 Apr 2011 11:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=AOD6Rz7StH92jedbSBNvPxTlT3ZC3GJ4s5xEXd90Ogg=; b=JhYXtZNYZIVKjWb8nAMmk5frFzjosdxdqD0yabkTVOyTLQlrtScDvjTEg7wL6xdKpX PFwhVwS4TWQJo/ijUGdhrz4Y1jyoiTr5BzXV+ABKWA2pl3WOUp23Hxe+97apjZQ6LiVi 4HyfEwNfJmH1vIB66eZCwGPuOzNu6/y9Cl+Uc= 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=A8j+2sQlkBB2PgyDG7Cwe+0wRAUZO41hgnWzi21bLMHso9nNvaQIuVGF0rCeRSyNJ/ pXSV99BuquVknW2CAW7Pt8Lxk1L+g80wo1Vc7U9VUemKM/Ut58RG88Yuo+tGGdypPg0z 5MWQZVDSh8TOEarEj8uHRnz4eC2EaubtKNNqk= Received: by 10.216.59.146 with SMTP id s18mr6871117wec.50.1303324220014; Wed, 20 Apr 2011 11:30:20 -0700 (PDT) Received: from dhcp-10-61-104-154.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id g32sm601475wej.3.2011.04.20.11.30.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 11:30:19 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 20 Apr 2011 20:30:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7507261D-4533-441D-9BAF-F963B6AE8F63@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:30:22 -0000 Dmitry, >>> the "non deployed" reference is with regards to this RFC3056 = deployment model: > RFC3056, section 5.2: >>> I have never heard nor seen this model having been deployed. anyone? >=20 > RFC 3056 has other scenarios, such as e.g. in section 5.1 and 5.4. = While the statement in the draft-ietf-v6ops-6to4-to-historic that " IPv6 = transition mechanism... has rarely if ever been deployed" refers to the = whole RFC, and not to the specific section you're referring to. If the = scenarios relying on BGP haven't been deployed, should not that be = stated as such, instead of referring to the whole RFC? interesting point. 6to4 has basically 3 modes. 1) 6to4 only. a 6to4 node can only reach other 6to4 node. 2) 6to4 with managed set of relays (with BGP routing protocol between = 6to4 router and relays) 3) 6to4 with unmanaged relay and default route 2 has never seen deployment. would 1 by itself have value? and for what? cheers, Ole= From Dmitry.Anipko@microsoft.com Wed Apr 20 12:17:34 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9BCBE06F4 for ; Wed, 20 Apr 2011 12:17:34 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvciFwoJVU6j for ; Wed, 20 Apr 2011 12:17:34 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 14183E06A4 for ; Wed, 20 Apr 2011 12:17:33 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 12:17:33 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 12:17:33 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Wed, 20 Apr 2011 12:16:37 -0700 From: Dmitry Anipko To: Ole Troan Date: Wed, 20 Apr 2011 12:16:36 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/iQJA7GvNvc/VQJ6Iemx/QENhOQABK3RA Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> <7507261D-4533-441D-9BAF-F963B6AE8F63@employees.org> In-Reply-To: <7507261D-4533-441D-9BAF-F963B6AE8F63@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: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:17:35 -0000 Hello Ole, >> would 1 by itself have value? and for what? As far as I know - it does, for example, for peer to peer connectivity of a= pplications which can work better with not translated IPv6 rather than tran= slated IPv4 address. In addition, in scenarios which rely on IPv6 and need IPV6 addressing, but = do not necessarily need connectivity with the rest of IPv6 Internet (e.g. c= onnectivity of remote clients to corporate networks via managed tunnels), a= bility to have a globally unique address range without support from ISP is = also useful. For these scenarios, ULAs may also be used once 6to4 is retire= d at some point is future, but that would require renumbering of customer n= etwork from one temporary solution to another one (since in future they lik= ely would migrate from ULA to ISP provided prefix). Thanks, Dmitry -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Wednesday, April 20, 2011 11:30 AM To: Dmitry Anipko Cc: Fred Baker; v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Dmitry, >>> the "non deployed" reference is with regards to this RFC3056 deployment= model: > RFC3056, section 5.2: >>> I have never heard nor seen this model having been deployed. anyone? >=20 > RFC 3056 has other scenarios, such as e.g. in section 5.1 and 5.4. While = the statement in the draft-ietf-v6ops-6to4-to-historic that " IPv6 transiti= on mechanism... has rarely if ever been deployed" refers to the whole RFC, = and not to the specific section you're referring to. If the scenarios relyi= ng on BGP haven't been deployed, should not that be stated as such, instead= of referring to the whole RFC? interesting point. 6to4 has basically 3 modes. 1) 6to4 only. a 6to4 node can only reach other 6to4 node. 2) 6to4 with managed set of relays (with BGP routing protocol between 6to4 = router and relays) 3) 6to4 with unmanaged relay and default route 2 has never seen deployment. would 1 by itself have value? and for what? cheers, Ole From dougb@dougbarton.us Wed Apr 20 12:30:31 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9C36DE073B for ; Wed, 20 Apr 2011 12:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2+nZ4gb7C2k for ; Wed, 20 Apr 2011 12:30:30 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfc.amsl.com (Postfix) with ESMTP id A6668E075D for ; Wed, 20 Apr 2011 12:30:30 -0700 (PDT) Received: (qmail 2064 invoked by uid 399); 20 Apr 2011 19:30:26 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 20 Apr 2011 19:30:26 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DAF3451.4090107@dougbarton.us> Date: Wed, 20 Apr 2011 12:30:25 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nick Hilliard References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> In-Reply-To: <4DAEA916.90908@inex.ie> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:30:31 -0000 On 04/20/2011 02:36, Nick Hilliard wrote: > I suggest that if Ole feels that a formal end-date for removal of > 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we > create a very small new ID which explicitly states a date on which IANA > formally deregisters both prefixes and requests that operators filter > them from the DFZ. It's not a biggie, but if it's what's needed to get > vendors to ditch support, then let's just be pragmatic and do it. I would be supportive of such a draft. As an OS implementor I would find it very useful to have a clean, bright line. I disagree with those who have said that setting a date is not in IETF's purview, there are plenty of examples of "flag days" in the past (most relevant is likely 6bone). Meanwhile, in response to the argument that "We must preserve 6to4 at all costs because it may be some people's only access to IPv6" I say, "So what?" There is no IPv6-only content now, and in the short term there isn't going to be any. No content provider is going to risk cutting off 99.9% of the Internet from their content. Long before there is such a thing as "IPv6-only content" the transition to widely accessible native IPv6 will have been complete, so 6to4 will be irrelevant. For those tiny percentage of people who actually "need" IPv6 for some reason (now, or in the future), other valid tunneling protocols already exist, and don't show any signs of going away. To repeat myself (again), whatever benefits derive from 6to4 are so tiny, and the costs for keeping it around are so large, we should be doing everything we can to kill it off sooner rather than later. 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 Dmitry.Anipko@microsoft.com Wed Apr 20 12:42:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D08FE073B for ; Wed, 20 Apr 2011 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+pSlS7bU98R for ; Wed, 20 Apr 2011 12:42:37 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 15E24E06A4 for ; Wed, 20 Apr 2011 12:42:37 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 12:42:30 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 12:42:30 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Wed, 20 Apr 2011 12:40:55 -0700 From: Dmitry Anipko To: Ole Troan Date: Wed, 20 Apr 2011 12:40:53 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/h9wO6HoBmUHFT7e4ZfQnhlRXBAAB/VCw Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> <280D9CD9-EC9C-400A-BDA5-C11A69A383E0@employees.org> In-Reply-To: <280D9CD9-EC9C-400A-BDA5-C11A69A383E0@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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:42:38 -0000 Hello Ole, >> I don't think we should take the users out of the equation either. with my user hat on I have tried 6to4 on numerous occasions, I have _always= _ been forced to turn it off. I agree we should not take users out of the pictures, and I think no users = would be hurt if the vendors implemented the kind of specific recommendatio= ns you mentioned. >> isn't there a clear meaning to vendors?=20 Let me quote James Woodyatt from Apple: " leaving our customers with only 6= to4 as their only hope for acquiring even marginally acceptable IPv6 servic= es with a reasonable level of configuration human interface burden. Until t= his changes, I doubt Apple and other equipment makers will stop supporting = 6to4 routing in their products, and people will continue to use it despite = the IETF deprecation, and IPv6 brokenness related to 6to4 will probably rem= ain at the unacceptable levels that operators and content providers hope to= address with the publication of this draft. On the other hand, if IETF pub= lishes a standards track document with phaseout plan for 2002::/16, then pr= oduct managers can know with reasonable certainty when their 6to4 routing f= eature will no longer be useful to any of their customers, and they can pla= n accordingly." You also wrote " I don't think the goal here is to make vendors remove the = 6to4 code from their implementations. ", while from the many messages on th= is topic from operators it seems to me that something like this would be id= eal in their opinion. >> I wrote this document in the first place to be able to convince one part= of our business that they must stop shipping products with 6to4 enabled by= default. >> make a clear statement from the IETF, that it does not consider 6to4 as = a valid mechanism to achieve IPv6 connectivity. >> if this document can make vendors stop contributing to the problem by ex= posing innocent bystanders to a mechanism that doesn't work then a lot woul= d be done. I agree with the goal, but think essentially the same effect could be achie= ved by listing very specific recommendations to vendor implementations, suc= h as the ones you mentioned. >> remove that particular option from the table when a user, operator or ve= ndor is considering what should be deployed/implemented... I agree that once majority of customers indeed have a choice whether to sub= scribe to their ISP IPV6 offering, 6to4 will no longer be needed. But are w= e there yet?=20 Thank you, Dmitry -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Wednesday, April 20, 2011 11:22 AM To: Dmitry Anipko Cc: Nick Hilliard; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Dmitry, [...] > Shouldn't the focus then be on those specific recommendations which addre= ss the specific known problems, rather than blanket deprecation, which enjo= ys broad support of operators but doesn't have a clear meaning to vendors, = as you indicate above? I don't think we should take the users out of the equation either. with my user hat on I have tried 6to4 on numerous occasions, I have _always= _ been forced to turn it off. isn't there a clear meaning to vendors? I wrote this document in the first = place to be able to convince one part of our business that they must stop s= hipping products with 6to4 enabled by default. > I completely agree that all the example recommendations you listed are ad= dressing specific problems (RFC 3484bis regarding 6to4, reachability check = for gateway, not enabling 6to4 for RFC 1918 addresses) and vendors should f= ollow them, if they aren't already. But once they (and any other specific r= ecommendations, if there are any) are followed, from the current draft it i= s not clear to me what the move to historic for RFC 3056 is trying to achie= ve or why it is necessary. sure, what does an IETF document ever achieve? ;-) make a clear statement from the IETF, that it does not consider 6to4 as a v= alid mechanism to achieve IPv6 connectivity. remove that particular option from the table when a user, operator or vendo= r is considering what should be deployed/implemented... a lot of people have stated how 6to4 is slowing down and hindering IPv6 dep= loyment rather than accelerating it. if this document can make vendors stop= contributing to the problem by exposing innocent bystanders to a mechanism= that doesn't work then a lot would be done. obviously consenting adults ca= n do what they like. cheers, Ole From Wesley.E.George@sprint.com Wed Apr 20 14:09:21 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DF605E06A2 for ; Wed, 20 Apr 2011 14:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbkG7Q5W6g91 for ; Wed, 20 Apr 2011 14:09:21 -0700 (PDT) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfc.amsl.com (Postfix) with ESMTP id A58D6E0731 for ; Wed, 20 Apr 2011 14:09:20 -0700 (PDT) Received: from mail44-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.8; Wed, 20 Apr 2011 21:09:19 +0000 Received: from mail44-db3 (localhost.localdomain [127.0.0.1]) by mail44-db3-R.bigfish.com (Postfix) with ESMTP id 2108B1620330; Wed, 20 Apr 2011 21:09:19 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371O542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) 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 mail44-db3 (localhost.localdomain [127.0.0.1]) by mail44-db3 (MessageSwitch) id 1303333751662580_18505; Wed, 20 Apr 2011 21:09:11 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.247]) by mail44-db3.bigfish.com (Postfix) with ESMTP id 4B6D34280DB; Wed, 20 Apr 2011 21:08:35 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 20 Apr 2011 21:08:34 +0000 Received: from PDAWEH03.ad.sprint.com (PDAWEH03.corp.sprint.com [144.226.110.91]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3KL8UUD018247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Apr 2011 16:08:30 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH03.ad.sprint.com ([2002:90e2:6e5b::90e2:6e5b]) with mapi id 14.01.0270.001; Wed, 20 Apr 2011 16:08:30 -0500 From: "George, Wes E [NTK]" To: Dmitry Anipko , Ole Troan Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/iQJA7GvNvc/VQJ6Iemx/QENhOQABK3RAAAN0ktA= Date: Wed, 20 Apr 2011 21:08:29 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7FBB2@PLSWM12A.ad.sprint.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> <7507261D-4533-441D-9BAF-F963B6AE8F63@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.113] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_020E_01CBFF7D.91C31FF0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:09:22 -0000 ------=_NextPart_000_020E_01CBFF7D.91C31FF0 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 Dmitry Anipko Sent: Wednesday, April 20, 2011 3:17 PM To: Ole Troan Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Hello Ole, >> would 1 by itself have value? and for what? As far as I know - it does, for example, for peer to peer connectivity of applications which can work better with not translated IPv6 rather than translated IPv4 address. [WEG] If there's address translation happening for IPv4, it's a tenuous assumption at best that 6to4 will work at all, let alone better. In addition, in scenarios which rely on IPv6 and need IPV6 addressing, but do not necessarily need connectivity with the rest of IPv6 Internet (e.g. connectivity of remote clients to corporate networks via managed tunnels), [WEG] You really think that corporate networks will rely on 6to4 for a business-critical application when we can't even get content providers to serve IPv6 content via 6to4 due to concerns over a bad user experience? Even if you remove the relays from the picture, you still have to contend with the other ways that 6to4 breaks. Wes George ------=_NextPart_000_020E_01CBFF7D.91C31FF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw 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+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyMDIx MDgyOVowIwYJKoZIhvcNAQkEMRYEFC+xIZ8/AaKaTyOjKg8rPdhCOXKQMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgAX5Io+Dk0lO8qBwbEN/9mCCDx/kykxPMK8gXwiggapJyj/smVjaYXvWphUhYyD8x05c YNA4wDP+C75HG+UGuJ+/QquRPV+91v7pVxOLqJVjsdOJ2s16cggafG4UqKDvJt0RAdLhUVKnPt8T nDRgt/5Ia6VqgcnMAYU+uc0DwrfAAAAAAAAA ------=_NextPart_000_020E_01CBFF7D.91C31FF0-- From Dmitry.Anipko@microsoft.com Wed Apr 20 14:22:33 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72AB8E0773 for ; Wed, 20 Apr 2011 14:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjnGvGjZ3Iy6 for ; Wed, 20 Apr 2011 14:22:32 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id AAA82E0758 for ; Wed, 20 Apr 2011 14:22:32 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 14:22:31 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 14:22:31 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Wed, 20 Apr 2011 14:22:30 -0700 From: Dmitry Anipko To: "George, Wes E [NTK]" , Ole Troan Date: Wed, 20 Apr 2011 14:22:29 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/iQJA7GvNvc/VQJ6Iemx/QENhOQABK3RAAAN0ktAAAR+vwA== Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> <7507261D-4533-441D-9BAF-F963B6AE8F63@employees.org> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7FBB2@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7FBB2@PLSWM12A.ad.sprint.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" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:22:33 -0000 Hello Wes, Regarding corporate network scenarios: I think you may have missed "managed= tunnels" in the scenario description (and those tunnels may or may not be = 6to4), used together with 6to4 addressing - the managed tunnels alleviate t= he 6to4 tunnel QoS concerns in such deployments.=20 Thanks, Dmitry -----Original Message----- From: George, Wes E [NTK] [mailto:Wesley.E.George@sprint.com]=20 Sent: Wednesday, April 20, 2011 2:08 PM To: Dmitry Anipko; Ole Troan Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of D= mitry Anipko Sent: Wednesday, April 20, 2011 3:17 PM To: Ole Troan Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Hello Ole, >> would 1 by itself have value? and for what? As far as I know - it does, for example, for peer to peer connectivity of a= pplications which can work better with not translated IPv6 rather than translated IPv4 address. [WEG] If there's address translation happening for IPv4, it's a tenuous ass= umption at best that 6to4 will work at all, let alone better.=20 In addition, in scenarios which rely on IPv6 and need IPV6 addressing, but = do not necessarily need connectivity with the rest of IPv6 Internet (e.g. connectivity of remote clients to corporate networks vi= a managed tunnels),=20 [WEG] You really think that corporate networks will rely on 6to4 for a busi= ness-critical application when we can't even get content providers to serve IPv6 content via 6to4 due to concerns over a bad user ex= perience? Even if you remove the relays from the picture, you still have to contend with the other ways that 6to4 breaks. Wes George From ichiroumakino@gmail.com Wed Apr 20 14:38:21 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7FCD2E06DE for ; Wed, 20 Apr 2011 14:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqUWt1gztf7q for ; Wed, 20 Apr 2011 14:38:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7E684E0777 for ; Wed, 20 Apr 2011 14:38:20 -0700 (PDT) Received: by wyb29 with SMTP id 29so1084188wyb.31 for ; Wed, 20 Apr 2011 14:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=HUNY6/o2dZD46On+6hkaFkyghH/yHpjUxnx+WVNxpbc=; b=LReZItTUs18kaBmc6w/63vqRXKXZVFVAvo1dYOakYy3ibUmMW2azG9fFibXNPC1C/7 zGcO0koSwVO2by0bhFFQUtZi0tJq8oTPeW620gpqJV7bcck3Y7fcCT9i7aWkPIlGh9Jm wVXevEqG+Scj4xzuPXF9c9tiAxsph/gsgfcZA= 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=d+kV0284Bv6tAz4IzRZRvOEbTYH88ISHNnkY4vhMaEsivZ9pqq1I5HSihSc9ZfnF9G xwxHN8Yl+4dBHBDWxEOUvT5U8DY/tki8cumH5Q1eVHL9F/wFqYrY7vHcUHW5SRZiLehJ M8YesxpI12HT75qFfHgjzNO3artPbrcbW4q8s= Received: by 10.216.254.82 with SMTP id g60mr1276398wes.36.1303335499736; Wed, 20 Apr 2011 14:38:19 -0700 (PDT) Received: from dhcp-10-61-105-118.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id e13sm810710wbi.40.2011.04.20.14.38.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 14:38:18 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 20 Apr 2011 23:38:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <465A0DA0-5C36-4C96-ADD1-63E236C90046@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> <7507261D-4533-441D-9BAF-F963B6AE8F63@employees.org> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:38:21 -0000 Dmitry, >>> would 1 by itself have value? and for what? >=20 > As far as I know - it does, for example, for peer to peer connectivity = of applications which can work better with not translated IPv6 rather = than translated IPv4 address. >=20 > In addition, in scenarios which rely on IPv6 and need IPV6 addressing, = but do not necessarily need connectivity with the rest of IPv6 Internet = (e.g. connectivity of remote clients to corporate networks via managed = tunnels), ability to have a globally unique address range without = support from ISP is also useful. For these scenarios, ULAs may also be = used once 6to4 is retired at some point is future, but that would = require renumbering of customer network from one temporary solution to = another one (since in future they likely would migrate from ULA to ISP = provided prefix). on second thought I don't think 1 is a true 6to4 mode. how would a 6to4 = router function if it only had connectivity to the 6to4 network? if it = advertised itself as an IPv6 default router it would end up blackholing = any traffic to the native IPv6 Internet. it could use hacks like what we = put in for ULAs in RFC6204, but these aren't described anywhere. with regards to using the 6to4 prefix as a global unique address. given = that is/will become a last resort in the SAS/DAS policy table, is that = really what you want for a managed tunnel? yes, it does give a globally = unique address, but one that is based on the public IPv4 address = received from the ISP (without any NAT in between).=20 using the 2002::/16 address space outside the remit of 6to4 sounds very = dubious though... splendid that this draft gets such a thorough review. I had this nagging = doubt for a while that there was some use case for 6to4 somewhere, one = that could only be solved with 6to4. that I haven't seen and I'm pretty = confident that we aren't throwing out the baby with the bath water. cheers, Ole= From Dmitry.Anipko@microsoft.com Wed Apr 20 15:01:04 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 613E2E0728 for ; Wed, 20 Apr 2011 15:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m0vJIvBVOC4 for ; Wed, 20 Apr 2011 15:01:03 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 0298FE06DD for ; Wed, 20 Apr 2011 15:01:03 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 15:01:02 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 20 Apr 2011 15:01:02 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Wed, 20 Apr 2011 14:59:02 -0700 From: Dmitry Anipko To: Ole Troan Date: Wed, 20 Apr 2011 14:59:01 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/o0ViKb3wW1xkRG+yX4pNBXYNhgAAJOrw Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <074A75C3-C87A-445D-BAEF-3F39CA027A22@employees.org> <7507261D-4533-441D-9BAF-F963B6AE8F63@employees.org> <465A0DA0-5C36-4C96-ADD1-63E236C90046@employees.org> In-Reply-To: <465A0DA0-5C36-4C96-ADD1-63E236C90046@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: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:01:04 -0000 Hello Ole, >> if it advertised itself as an IPv6 default router it would end up blackh= oling any traffic to the native IPv6 Internet. it could use hacks like what= we put in for ULAs in RFC6204, but these aren't described anywhere. I assume you're referring to G-4 in section 4.1 RFC 6204? If so, I'm not su= re why that is called a hack. Per RFC 4861 an RA with router lifetime =3D 0= , but more specific route lifetime !=3D 0 is a valid RA as I understand. So= , unless there is some reason why it would not be a valid RA, yes, it will = work. I didn't test other OSes, but it does work fine for Windows. >> given that is/will become a last resort in the SAS/DAS policy table, is = that really what you want for a managed tunnel? Yes, because these corporate scenarios don't work with e.g. RFC 1918 IPv4 a= ddresses (or work much worse, than with IPv6 addresses, even if those are 6= to4 based), popular in corporate networks. >> using the 2002::/16 address space outside the remit of 6to4 sounds very = dubious though... >> I had this nagging doubt for a while that there was some use case for 6t= o4 somewhere, one that could only be solved with 6to4. that I haven't seen = and I'm pretty confident that we aren't throwing out the baby with the bath= water. Good that we made it here :), because on the baby statement, actually there= are DirectAccess customers who use 6to4 addressing in corporate scenarios,= who will be affected by this. And as James pointed out that until ISPs act= ually provide IPv6 to consumers, 6to4 seems to be the only viable alternati= ve for those. Thank you, Dmitry -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Wednesday, April 20, 2011 2:38 PM To: Dmitry Anipko Cc: Fred Baker; v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Dmitry, >>> would 1 by itself have value? and for what? >=20 > As far as I know - it does, for example, for peer to peer connectivity of= applications which can work better with not translated IPv6 rather than tr= anslated IPv4 address. >=20 > In addition, in scenarios which rely on IPv6 and need IPV6 addressing, bu= t do not necessarily need connectivity with the rest of IPv6 Internet (e.g.= connectivity of remote clients to corporate networks via managed tunnels),= ability to have a globally unique address range without support from ISP i= s also useful. For these scenarios, ULAs may also be used once 6to4 is reti= red at some point is future, but that would require renumbering of customer= network from one temporary solution to another one (since in future they l= ikely would migrate from ULA to ISP provided prefix). on second thought I don't think 1 is a true 6to4 mode. how would a 6to4 rou= ter function if it only had connectivity to the 6to4 network? if it adverti= sed itself as an IPv6 default router it would end up blackholing any traffi= c to the native IPv6 Internet. it could use hacks like what we put in for U= LAs in RFC6204, but these aren't described anywhere. with regards to using the 6to4 prefix as a global unique address. given tha= t is/will become a last resort in the SAS/DAS policy table, is that really = what you want for a managed tunnel? yes, it does give a globally unique add= ress, but one that is based on the public IPv4 address received from the IS= P (without any NAT in between).=20 using the 2002::/16 address space outside the remit of 6to4 sounds very dub= ious though... splendid that this draft gets such a thorough review. I had this nagging do= ubt for a while that there was some use case for 6to4 somewhere, one that c= ould only be solved with 6to4. that I haven't seen and I'm pretty confident= that we aren't throwing out the baby with the bath water. cheers, Ole From brian.e.carpenter@gmail.com Wed Apr 20 16:14:48 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80062E0781 for ; Wed, 20 Apr 2011 16:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.245 X-Spam-Level: X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFDfBqkoVceZ for ; Wed, 20 Apr 2011 16:14:47 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3C557E0724 for ; Wed, 20 Apr 2011 16:14:47 -0700 (PDT) Received: by pvh1 with SMTP id 1so784538pvh.31 for ; Wed, 20 Apr 2011 16:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lyv5pyY6QDHTChVJ82/pwLzr6MxoKjnDmsBpLKomURs=; b=aeID6xtOlP5oAQTkSOUbSqj6HNZGDCsM/1ADLP5yiLZXzEzaRq31dsEEoTTQfn1UNn m+hGW4Le63BS+7wvDlcemPqbwVOu52OO9uaHugN0rAbfgrewfC3nxDZNCBUXjAS0izt9 +2Udlw+b/XHXRc/LUPgqSynsLlW6tmEY2gc4E= 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=INgfQai3wUh1nKbnK+Jh6N3aJraEbLrTjmFxKUUFzKLKoCjO78T+V4d7gYA8z7Gidz ZSYP5M3djLys/6Kt5Kf2VZ7bc9O7rMeaDqCrwVRWp3Up8atoyx//RzK9Ziu0OzuBjgIG icx0rsubVDGaE7org6S/mvMA9LPf7i68azpfg= Received: by 10.68.5.225 with SMTP id v1mr11943457pbv.484.1303341286607; Wed, 20 Apr 2011 16:14:46 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id d9sm904515pba.16.2011.04.20.16.14.43 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 16:14:45 -0700 (PDT) Message-ID: <4DAF68E7.6000201@gmail.com> Date: Thu, 21 Apr 2011 11:14:47 +1200 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: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:14:48 -0000 Hi Pekka, Thanks for the review. On 2011-04-20 20:27, Pekka Savola wrote: > On Sun, 17 Apr 2011, Fred Baker wrote: >> 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. > > I suppose publishing this document but not in its current form; some > changes are needed (below). > > .... > > Section 2.1 on Router 6to4 should be trimmed down, one page is > excessive. 6to4 was never deployed as it was initially devised by > Carpenter, so text on that is not very useful (most of 1st paragraph of > Section 3 should also go away). The key point is that 6to4 hosts or > routers may either configure the relay router IP address or use anycast. You made this comment on an earlier version. I disagreed then and I disagree now. It's impossible to understand how the anycast version is supposed to work unless you understand how basic 6to4 is supposed to work, and the situation for the return relay is the same in both cases. I couldn't find anything redundant in the explanation. > In S 3: "The inference from > these experiments is that one likely reason for the high connection > failure rate for 6to4 connections is the use of local filters close > to the end-user that block incoming packets with protocol 41." > > .. it was not described if the return path relay used 192.88.99.1 as the > source address of packets or the non-anycast address. I would expect > significantly more breakage when 192.88.99.1 is NOT used as the source > address. Firewalls in residential case are rarely an issue based on my > experience if the relay uses 192.88.99.1 as the source address. It is mentioned somwhere that there is conflicting evidence on this point - actually it depends on whether the client is behind a stateful firewall or not. So I think this point is covered. > > 5. PMTUD Failure: ...Path MTU Discovery does not > always work, and this can lead to connectivity failures. Even if > a TCP SYN/ACK exchange works, TCP packets with full size payloads > may simply be lost. > > .. due to MSS negotiation this is not a problem if 6to4 is set up on a > host because it will set MSS lower than 1500-40=1460B. I have personally experienced MSS negotiation failing in exactly this case. Probably that is an implementation bug at the server side, and I agree this point should be mentioned. This however > could be a problem if 6to4 is enabled on a router and it advertises the > prefix on a LAN, because if it doesn't also advertise a smaller MTU, > hosts on the LAN will use MSS=1460 and TCP MSS negotiation will fail. Yes, certainly. > > The practical impact of the above problems, which are by no means > universal as there is considerable successful use of Anycast 6to4, > has been measured at a fraction of 1% loss of attempted connections > to content servers (see ). > > .. for more balanced discussion, this discussion should be moved up, > next to the two researches on "very broken 6to4". I'll have a look. > > Section 4.1 is out of place here. Remove or broaden the scope of the > document to include vendors. That's why the first sentence of this section says " Although this document is aimed principally at operators, there are some steps that implementers and vendors of 6to4 should take." > > S 4.2: > 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. > > .. this must be removed unless there is more operational experience with > this approach. Hinting at the ISPs that this could be a good approach > is very wrong if we don't know that it is actually the case. I don't see that. We know that it cannot make things worse and might make things better. > > editorial: > > - references to labs.ripe.net, www.potaroo.net etc. should be filed as > informative references not direct URLs in text. We can leave the RFC Editor to apply their preferred policy for this. > > - S 4.2 is almost two pages long. It would be better focused with > subsections. It's a bit of a laundry list, so I am not sure what logical groupings exist that could become subsections. > > - S 4.4: as already commented by others, remove IXP Text will be updated. > > - S 4.5: s/suceeds/succeeds/; s/firewallls/firewalls/ Ack. Thanks Brian From brian.e.carpenter@gmail.com Wed Apr 20 16:30:46 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E58FE0783 for ; Wed, 20 Apr 2011 16:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rc9bC5OxQvi for ; Wed, 20 Apr 2011 16:30:45 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9F005E06F9 for ; Wed, 20 Apr 2011 16:30:45 -0700 (PDT) Received: by pzk30 with SMTP id 30so796342pzk.31 for ; Wed, 20 Apr 2011 16:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4QuA9DxySqINAygzwNWUOTjOZK8xsJtz13kOqQ+QjTs=; b=CrRe/H9lszO8gIRcsaHxrcAdGlrC6lBK6b18hk+Nvtha5xKXn9tKdNJZqIYIiaQvkL BjsHlLFI/oig3njPdUvJ2MBVS9m9pSrloVI+gZeXalZ6g5T33z5TvePZrKgc4gEsMHiQ p3nMPnwd2VmAkbwKuMXuHC/AEkKZ4wwJGZwcA= 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=xi2SDX3HnzjJ7TwXbDvdv0YUvky4n85mDNI1im9WuDpbX7N2Sg+hJ6oUiHWPoOzlDG HHzP+UtX+b72dgrYiraH+2vr1R/JtLja/EML+E4GpbBr3vOrWRDXBBG5CHahhgKpHfBy fAvhVN5UxdMag0mnkHRJpkv3vbtkdE/rIEBzc= Received: by 10.68.31.34 with SMTP id x2mr5228710pbh.153.1303342245148; Wed, 20 Apr 2011 16:30:45 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id w2sm912280pbh.14.2011.04.20.16.30.43 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 16:30:44 -0700 (PDT) Message-ID: <4DAF6CA7.6030905@gmail.com> Date: Thu, 21 Apr 2011 11:30:47 +1200 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: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> In-Reply-To: <4DAEA916.90908@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:30:46 -0000 On 2011-04-20 21:36, Nick Hilliard wrote: ... > I suggest that if Ole feels that a formal end-date for removal of > 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we > create a very small new ID which explicitly states a date on which IANA > formally deregisters both prefixes and requests that operators filter > them from the DFZ. It's not a biggie, but if it's what's needed to get > vendors to ditch support, then let's just be pragmatic and do it. It would be a biggie and I would oppose it very strongly. This would break deployed systems and we should never, ever do that. It isn't the point - the point is to get rid of unintentional 6to4 deployed by default. "First, do no harm." [Hippocrates, attrib.] On 2011-04-21 06:30, Ole Troan wrote: ... > interesting point. > 6to4 has basically 3 modes. > > 1) 6to4 only. a 6to4 node can only reach other 6to4 node. > 2) 6to4 with managed set of relays (with BGP routing protocol between 6to4 router and relays) > 3) 6to4 with unmanaged relay and default route > > 2 has never seen deployment. > > would 1 by itself have value? and for what? Any form of closed user group that is not subject to NAT44. It's not for us to say whether that is a good or bad thing, but just as for successful users of 3), it's not for us to break it either. Hence, the current draft says exactly what should be said, and we should say no more. Brian From jhw@apple.com Wed Apr 20 17:19:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D505DE07F1 for ; Wed, 20 Apr 2011 17:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vhzc5KwsuDS for ; Wed, 20 Apr 2011 17:19:08 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id 34571E07ED for ; Wed, 20 Apr 2011 17:19:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJZ00DLA7JVDFC0@mail-out.apple.com> for v6ops@ietf.org; Wed, 20 Apr 2011 17:19:07 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-57-4daf77f9374b Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 34.49.20744.9F77FAD4; Wed, 20 Apr 2011 17:19:05 -0700 (PDT) Received: from [17.193.15.152] (unknown [17.193.15.152]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJZ00LO77JTDF90@cardamom.apple.com> for v6ops@ietf.org; Wed, 20 Apr 2011 17:19:05 -0700 (PDT) From: james woodyatt In-reply-to: <4DAF6CA7.6030905@gmail.com> Date: Wed, 20 Apr 2011 17:19:04 -0700 Message-id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4DAF6CA7.6030905@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:19:13 -0000 On Apr 20, 2011, at 4:30 PM, Brian E Carpenter wrote: > On 2011-04-20 21:36, Nick Hilliard wrote: > ... >> I suggest that if Ole feels that a formal end-date for removal of 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we create a very small new ID which explicitly states a date on which IANA formally deregisters both prefixes and requests that operators filter them from the DFZ. It's not a biggie, but if it's what's needed to get vendors to ditch support, then let's just be pragmatic and do it. > > It would be a biggie and I would oppose it very strongly. This would break deployed systems and we should never, ever do that. Alas, despite notable voices of opposition, I suspect that consensus can be formed in IETF around the swift and merciless breaking of all the deployed and otherwise working 6to4 systems in exchange for facilitating the rollout of more commercially viable IPv6 services. I plan to submit a draft soon that specifies a formal phaseout plan for 6to4, and we shall see how much opposition is really out there. If consensus can emerge in IETF around a formal phaseout plan, then we will all save a lot of time and energy that we would otherwise spend maintaining and improving support for 6to4 in forthcoming host and router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic is published in the RFC series or not. -- james woodyatt member of technical staff, core os networking From wwwrun@rfc-editor.org Wed Apr 20 22:14:27 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E53F0E07A3; Wed, 20 Apr 2011 22:14:27 -0700 (PDT) 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.268, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dOK2k+GNKk0; Wed, 20 Apr 2011 22:14:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id 1A209E0791; Wed, 20 Apr 2011 22:14:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A827DE077C; Wed, 20 Apr 2011 22:14:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110421051426.A827DE077C@rfc-editor.org> Date: Wed, 20 Apr 2011 22:14:26 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6169 on Security Concerns with IP Tunneling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:14:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6169 Title: Security Concerns with IP Tunneling Author: S. Krishnan, D. Thaler, J. Hoagland Status: Informational Stream: IETF Date: April 2011 Mailbox: suresh.krishnan@ericsson.com, dthaler@microsoft.com, Jim_Hoagland@symantec.com Pages: 20 Characters: 45018 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-tunnel-security-concerns-04.txt URL: http://www.rfc-editor.org/rfc/rfc6169.txt 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 and propose strategies for the mitigation of those issues. [STANDARDS-TRACK] 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 pekkas@netcore.fi Wed Apr 20 22:28:19 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57DBBE0660 for ; Wed, 20 Apr 2011 22:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSaU6OABokMo for ; Wed, 20 Apr 2011 22:28:18 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfc.amsl.com (Postfix) with ESMTP id 11F52E0791 for ; Wed, 20 Apr 2011 22:28:07 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3L5Rwmo008524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 08:27:59 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3L5RwSc008521; Thu, 21 Apr 2011 08:27:58 +0300 Date: Thu, 21 Apr 2011 08:27:58 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <4DAF68E7.6000201@gmail.com> Message-ID: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@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.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:28:19 -0000 On Thu, 21 Apr 2011, Brian E Carpenter wrote: >> Section 2.1 on Router 6to4 should be trimmed down, one page is >> excessive. 6to4 was never deployed as it was initially devised by >> Carpenter, so text on that is not very useful (most of 1st paragraph of >> Section 3 should also go away). The key point is that 6to4 hosts or >> routers may either configure the relay router IP address or use anycast. > > You made this comment on an earlier version. I disagreed then and I disagree > now. It's impossible to understand how the anycast version is supposed to > work unless you understand how basic 6to4 is supposed to work, and the > situation for the return relay is the same in both cases. I couldn't find > anything redundant in the explanation. You seem to be arguing that S 2.1 is an overview of 6to4 without anycast and that such an overview is essential. I'd argue that this document does not need to provide a description of how basic 6to4 or anycast 6to4 works; it is already described in those documents, and it is not essential in order to understand the rest of the document. The reader can get the message of the document even if (s)he isn't very familiar with rfc3056 or rfc3068 even without the details in Section 2. >> .. it was not described if the return path relay used 192.88.99.1 as the >> source address of packets or the non-anycast address. I would expect >> significantly more breakage when 192.88.99.1 is NOT used as the source >> address. Firewalls in residential case are rarely an issue based on my >> experience if the relay uses 192.88.99.1 as the source address. > > It is mentioned somwhere that there is conflicting evidence on this > point - actually it depends on whether the client is behind a stateful > firewall or not. So I think this point is covered. There are two different axes here - firewall and source address: 1. stateful firewall 2. stateless firewall a. relay uses 192.88.99.1 as source b. relay uses non-anycast as source I'm saying that 1.b) cannot work and this is likely causing bad figures in Geoff's study. 1.a) can work out of the box with zero configuration. Therefore the point is not (only) "stateful firewall" but also (or mainly) source aaddress. Both 2.a) and 2.b) are likely to work with roughly the same probability. There are actually more granularity in how firewalls work, but that shows that using 192.88.99.1 as source is _especially important_ for stateful firewalls. >> 5. PMTUD Failure: ...Path MTU Discovery does not >> always work, and this can lead to connectivity failures. Even if >> a TCP SYN/ACK exchange works, TCP packets with full size payloads >> may simply be lost. >> >> .. due to MSS negotiation this is not a problem if 6to4 is set up on a >> host because it will set MSS lower than 1500-40=1460B. > > I have personally experienced MSS negotiation failing in exactly this > case. Probably that is an implementation bug at the server side, and I > agree this point should be mentioned. I'd actually suspect that the issue is more at the client side, i.e., the client doesn't lower MSS based on where the default route points. >> Section 4.1 is out of place here. Remove or broaden the scope of the >> document to include vendors. > > That's why the first sentence of this section says > " Although this document is aimed principally at operators, there are > some steps that implementers and vendors of 6to4 should take." I read that. But it isn't written in the abstract or introduction. IMHO, either this needs to be made a first-class citizen in the document or it should be removed. >> S 4.2: >> 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. >> >> .. this must be removed unless there is more operational experience with >> this approach. Hinting at the ISPs that this could be a good approach >> is very wrong if we don't know that it is actually the case. > > I don't see that. We know that it cannot make things worse and might > make things better. Disagree. If the concerned ISP is able to ping 192.88.99.1 and the relay will forward traffic from the concerned ISP's IP addresses, it is "better than nothing". It is a working 3rd party service that the concerned ISP is disrupting. In some countries this can even be illegal unless a provision is made in the contract to allow such blocking. I agree only with the part that if: a) 192.88.99.1 address does not respond, b) does not provide 6to4 service that works, or c) the isp customers are all using bogonized addresses [you could think this as a special case of b)] .. then it is known that, at least at that particular moment, the concerned ISP is no worse off by returning ICMP unreachables. >> editorial: >> >> - references to labs.ripe.net, www.potaroo.net etc. should be filed as >> informative references not direct URLs in text. > > We can leave the RFC Editor to apply their preferred policy for this. I think you very well know that this is not RFC editor's preferred policy. I feel it is irresponsible to push out text (also to the IETF LC and IESG) that has known editorial irregularities. -- 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 v6ops@globis.net Thu Apr 21 00:46:09 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6182DE0716 for ; Thu, 21 Apr 2011 00:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX3QB-sbBsGb for ; Thu, 21 Apr 2011 00:46:08 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfc.amsl.com (Postfix) with ESMTP id 41AB1E0712 for ; Thu, 21 Apr 2011 00:46:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id EBD8F8700E0 for ; Thu, 21 Apr 2011 09:46:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXvjBenJEmMo for ; Thu, 21 Apr 2011 09:45:56 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id CF33187007D for ; Thu, 21 Apr 2011 09:45:56 +0200 (CEST) Message-ID: <4DAFE0B1.20009@globis.net> Date: Thu, 21 Apr 2011 09:45:53 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 07:46:09 -0000 [delurk] I have been lurking for quite a while around various IPv6 lists, and trying to get up to speed with the very latest developments in IPv6, especially regarding suitable transition mechanisms, or more to the point, the danger these mechanisms pose as defaults in a managed migration in a corporate environment. Hopefully I can add something positive to the debate. RFC 1958 (informational) states "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." Assumption 1: The only proven scalable solution that will facilitate long-term growth and stability of the Internet is to deploy native IPv6 end to end. Assumption 2: Transitional mechanisms may be useful in moving towards the end game of deploying native protocols end to end. They are a means to an end, and not a destination in themselves. Assumption 3: Transitional mechanisms that are no longer useful can die a natural death. The IETF does not need to take any action on these, as the market will come to their own conclusion and take the desired actions themselves without any further intervention. However, transitional mechanisms that are actively preventing a further move towards deploying native end to end protocols could and should be clearly deprecated. Assumption 4: 6to4 has not proven itself as a good transition mechanism as it is not widely used (no reason to deprecate). Assumption 5: 6to4 may actually be preventing deployment of native IPv6 (good reason to deprecate) Assumption 6: I see text in http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00. stating that the protocol "6to4" is deprecated as well as the address "2002::/16" I had to search for quite a while before I could find out what it actually meant for a protocol to be deprecated (as opposed for use of an IPV6 address to be deprecated, which is clearly defined in the existing RFC3484). The mechanism suggested for actually implementing the deprecation seems to be via amending the source and destination address selection mechanism as defined in RFC3484 and proposed to be amended as in http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 . However, this is only a recommendation for a default policy table, and people may not have used this particular table in their implementations. It is also unclear how often people will update their local policy table on their local host. To me, deprecating use of a protocol, and suggesting it should only be used as a protocol of "last resort" are two different things. If you deprecate a protocol, it shouldn't be used any more. Assumption 7: Since the mechanism for implementing deprecation will certainly be implemented on a per host basis, there is a clear danger that if the implementation of the choice of 6to4 as a "last resort" protocol as suggested in the revised RFC3484 policy table is not widely synchronized, that when a node A contacts host B it will use protocol X, but when host B contacts host A it will use protocol Y. Assumption 8: Asymmetric protocol use is an extremely undesirable phenomenon that could actually make matters far worse operationally than a single not-so-great protocol communicating in both directions. Assumption 9: Deprecation of a transitional mechanism should not lead to an extended period where the implementation of the deprecation may actually make the Internet worse operationally. My opinion: There needs to be a clear motivation for why 6to4 is actively preventing 6to4 roll out. I think this clear motivation is somewhat lacking in the current text. The current focus, the way I read it, is on why 6to4 isn't a great protocol, rather a clear description of why 6to4 is actively preventing native IPv6 roll out. There also needs to be a clear end date for implementation of the deprecation, to avoid a transition on a transition. So I can't agree with the text as-is. But I would suggest that the authors amend the text so that it: i) better motivates that use of 6to4 is actively preventing roll out of native IPv6 ii) includes a clear date for full deprecation (perhaps immediately), and iii) clarifies what it means to deprecate a protocol whilst still allowing it as a "last resort" (or indeed consider changing it to straight deprecation) Thank you for your attention and patience. Ray H [lurk] From rogerj@gmail.com Thu Apr 21 01:04:39 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63D93E0716 for ; Thu, 21 Apr 2011 01:04:39 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BsnLE1qUHQm for ; Thu, 21 Apr 2011 01:04:38 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5D29BE0661 for ; Thu, 21 Apr 2011 01:04:38 -0700 (PDT) Received: by iwn39 with SMTP id 39so1564351iwn.31 for ; Thu, 21 Apr 2011 01:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=r9wou1r89EBZiIgVV2rWXDCCn39gBog98E4HEm/bgxE=; b=uRLnxg/1Kp5sJQlfi782KoljlhZYOOzbFqnaOgAnGLApM9hSS6vX5V8N0iTc/QLUC1 2XnEhlz1KtxJh44TE1/aoaLp44jcZwUWCHCvT4UMl1bf2lUuLTonwejY93rih7woviln BAUhewsJRU8aLoO+J5WIr40Ha0ce0VJtBOo7Q= 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=iqNp//gmW255o50Vw+AcJmeL1jcbEd3KaBzngONP/fkCcBpI6Wet4nKRKEZ2jSBZB1 YlD0uq0AtaobAUSE2wBVOmJ55CCXH59eFuHzXCcgQRNIy1mWIou+5dlUs7oI6ZXTYn41 BKpz0+sa52D2B8K8giyXWyDrFjMaWGexVAMJM= MIME-Version: 1.0 Received: by 10.43.53.132 with SMTP id vq4mr10300782icb.472.1303373077549; Thu, 21 Apr 2011 01:04:37 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Thu, 21 Apr 2011 01:04:37 -0700 (PDT) In-Reply-To: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> <280D9CD9-EC9C-400A-BDA5-C11A69A383E0@employees.org> Date: Thu, 21 Apr 2011 10:04:37 +0200 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-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 08:04:39 -0000 On Wed, Apr 20, 2011 at 9:40 PM, Dmitry Anipko wrote: >>> remove that particular option from the table when a user, operator or v= endor is considering what should be deployed/implemented... > > I agree that once majority of customers indeed have a choice whether to s= ubscribe to their ISP IPV6 offering, 6to4 will no longer be needed. But are= we there yet? The interesting thing about this entire 6to4 discussing is that there is pretty much two sides * Those that wish 6to4 gone because it cause more problem than it solve, they also consider it too costly to fix considering other options. * Then there is the "other" side that is interesting... that is MS and Apple which want to give their customer IPv6 which is great, I can't praise those companies enough for their effort on IPv6. Espesial Microsoft and their efford over the last 10+ years. But, isn't it time to move on, beyond IPv6 access for any cost and to a place where we say either Good IPv6 access or none? --=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 gvandeve@cisco.com Thu Apr 21 02:06:32 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B3C4E076E for ; Thu, 21 Apr 2011 02:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.953 X-Spam-Level: X-Spam-Status: No, score=-9.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DPri128L60 for ; Thu, 21 Apr 2011 02:06:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 25575E0752 for ; Thu, 21 Apr 2011 02:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1952; q=dns/txt; s=iport; t=1303376791; x=1304586391; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8z0wfwnul+tTDAtu0FA6zkOWxJODD28WFrNkNzAjRwU=; b=PluT2Z74pUAgsRh+g7SVWbuxTvqIj5XMBNODdlY3fgiIe01ZJzsTTuMt j9o5Jlzx42U9DLmm6jjEDhC2jQaSKh5VW/ChxbnItOPLFc4oAvKotEyP6 q8eeBi/ixPoVkNxm/vAwOweq+zmw5faohcRcAb8qKw/aIM7g4s+MrAe4/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEEAFTyr02Q/khRgWdsb2JhbAClSBQBARYmJagsnFiFdgSSNw X-IronPort-AV: E=Sophos;i="4.64,250,1301875200"; d="scan'208";a="84542111" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 09:06:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3L96UnW030220; Thu, 21 Apr 2011 09:06:30 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); Thu, 21 Apr 2011 11:06:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 11:06:28 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FCE5F@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: Acv/uc9bCzWxV/BJRQmEeu+B1uEBFwASVFHQ References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie><4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com><4DAEA916.90908@inex.ie> <4DAF6CA7.6030905@gmail.com> From: "Gunter Van de Velde (gvandeve)" To: "james woodyatt" , "Brian E Carpenter" X-OriginalArrivalTime: 21 Apr 2011 09:06:30.0177 (UTC) FILETIME=[671D3110:01CC0003] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 09:06:32 -0000 Inline: GV> -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: 21 April 2011 02:19 To: Brian E Carpenter Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 20, 2011, at 4:30 PM, Brian E Carpenter wrote: > On 2011-04-20 21:36, Nick Hilliard wrote: > ... >> I suggest that if Ole feels that a formal end-date for removal of 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we create a very small new ID which explicitly states a date on which IANA formally deregisters both prefixes and requests that operators filter them from the DFZ. It's not a biggie, but if it's what's needed to get vendors to ditch support, then let's just be pragmatic and do it. >=20 > It would be a biggie and I would oppose it very strongly. This would break deployed systems and we should never, ever do that. Alas, despite notable voices of opposition, I suspect that consensus can be formed in IETF around the swift and merciless breaking of all the deployed and otherwise working 6to4 systems in exchange for facilitating the rollout of more commercially viable IPv6 services. GV> making a technology historic doesn't break it. The guidelines in the -advisory- draft is what make this not happen and actually improve the quality of the user experience for the existing user base. I plan to submit a draft soon that specifies a formal phaseout plan for 6to4, and we shall see how much opposition is really out there. If consensus can emerge in IETF around a formal phaseout plan, then we will all save a lot of time and energy that we would otherwise spend maintaining and improving support for 6to4 in forthcoming host and router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic is published in the RFC series or not. GV> not sure a phase-out plan will bring additional value. G/ From v6ops@globis.net Thu Apr 21 03:16:44 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6CBF2E06BB for ; Thu, 21 Apr 2011 03:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcMm-30YcUpK for ; Thu, 21 Apr 2011 03:16:43 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfc.amsl.com (Postfix) with ESMTP id BB7F7E06B6 for ; Thu, 21 Apr 2011 03:16:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0AF548700EA for ; Thu, 21 Apr 2011 12:16:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SYsT22mMT-O for ; Thu, 21 Apr 2011 12:16:37 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 829AA8700B1 for ; Thu, 21 Apr 2011 12:16:37 +0200 (CEST) Message-ID: <4DB00401.8080003@globis.net> Date: Thu, 21 Apr 2011 12:16:33 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 10:16:44 -0000 [delurk] One thing that may be obvious to everyone on this list, but that is certainly worth pointing out for mere mortals like myself who took several days to work out the preference order of the rules governing selection of an IPv6 transition mechanism for a windows 7 box that had a public IPv4 address and was connected to a corporate network, but which also took part in Active Directory, but also had an IPv4 firewall between itself and the public Internet, and which was communicating with a Windows Server 2003 box that was going to be upgraded to Windows 2008, and where there was network intrusion detection in the path, and MPLS WRED QoS ....... http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 suggests (with some valid argument) that Teredo is worse than 6to4, because it uses tunnels (over UDP). 2.1.2. Teredo in the policy table Teredo's priority should be less than or equal to 6to4, considering its characteristic of being a transitional tunnel mechanism. Windows already implements this. "bad," "worse," "worst." There's only one worst. So 6to4 and Teredo can't both be equally so bad that they're both "last resort." And at the risk of repeating myself, not having any timetable for transition of the transition mechanism, or defining an extended period for the transition of a transition mechanism, is unlikely to make the average network administrators' life any easier. Once again, thank you for your attention and patience. Ray H [lurk] From pekkas@netcore.fi Thu Apr 21 04:17:27 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F39BE06CF for ; Thu, 21 Apr 2011 04:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HAt2s5VeNDo for ; Thu, 21 Apr 2011 04:17:26 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfc.amsl.com (Postfix) with ESMTP id 39529E06C8 for ; Thu, 21 Apr 2011 04:17:26 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3LBHNnU015012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Apr 2011 14:17:23 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3LBHNwA015009 for ; Thu, 21 Apr 2011 14:17:23 +0300 Date: Thu, 21 Apr 2011 14:17:22 +0300 (EEST) From: Pekka Savola To: v6ops@ietf.org In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-418216310-1303384643=:14690" X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:17:27 -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-418216310-1303384643=:14690 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 17 Apr 2011, Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-to-historic. 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. I oppose this document and moving 6to4 to historic just yet. No IETF document requires 6to4, and therefore there is nothing the IETF needs to do to allow vendors to turn it off. "Deprecation by standardization body decree" when vendors still continue shipping it will cause a mismatch between operational reality and the IETF. It's futile. We should first convince the (major) vendors that this what they want to do, wait that they start to do it, and then begin the deprecation. If we want to give advisories to the vendors or users, we can put those to the advisory draft. I however do agree that the following subset deprecation described in Section 4 makes sense: 1. IPv6 nodes SHOULD treat 6to4 as a service of "last resort" as recommended in [I-D.ietf-6man-rfc3484-revise] 2. Implementations capable of acting as 6to4 routers SHOULD NOT enable 6to4 without explicit user configuration. In particular, enabling IPv6 forwarding on a device, SHOULD NOT automatically enable 6to4. 3. If implemented in future products 6to4 SHOULD be disabled by default. This is internally inconsistent with S 1: "Declaring the mechanism historic is not expected to have immediate product implications." What's the point if the goal is not to have immediate product implications? I'd say that the best approach is likely to just discontinue this document. After we've gotten major vendors on board with the subset deprecation, we can start working on the rest. Editorial: Many things I object to, but listing these is not worth the effort. Some specifics though: - First sentence of S 1 is misleading as already discussed and should be removed/rephrased. No need to even mention the BGP model. -- 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-418216310-1303384643=:14690-- From gih@apnic.net Thu Apr 21 04:43:13 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D81EE0689 for ; Thu, 21 Apr 2011 04:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.944 X-Spam-Level: X-Spam-Status: No, score=-96.944 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEJHJ2EF211A for ; Thu, 21 Apr 2011 04:43:12 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfc.amsl.com (Postfix) with ESMTP id 2E382E06CF for ; Thu, 21 Apr 2011 04:43:12 -0700 (PDT) Received: from gih-mpro.westell.com (pool-72-70-247-79.spfdma.east.verizon.net [72.70.247.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4D325B681F; Thu, 21 Apr 2011 21:43:06 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <20110407000752.6C6DEDE2FEB@drugs.dv.isc.org> Date: Thu, 21 Apr 2011 21:43:03 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <20110407000752.6C6DEDE2FEB@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , Carlos Martinez-Cagnazzo Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:43:13 -0000 On 07/04/2011, at 10:07 AM, Mark Andrews wrote: >=20 > In message , Erik = Kline wri > tes: >> I would refer specifically to the numbers for 6to4 customers where = the >> return path was directly on the server, i.e. the client-to-server = relay was >> not a problem (because the SYN packet reached the servers) and the >> server-to-client relay was not a problem (because the server was >> encapsulating directly). Even in that scenario the connection = completion >> rate was abysmal, IIRC. >>=20 >> All of which reinforces the notion that it's not a valuable = transition >> mechanism. It's a experimental thing, and plenty useful as such. = But it's >> not production quality unless it's fully managed (i.e. it can be = confirmed >> that no proto41 blocking is going on, etc). In which case it's = basically >> 6rd or static tunnels. >=20 > I suspect that a lot of the problem isn't 6to4 but rather just IPv6. The experimental data does not appear to support this hypothesis. The evidence points strongly to protocol 41 filters at the boundary of customer nets, as the connection drop rates for 6to4 are between 15% to = 20% of connections where the 1st SYN is seen, while the connection drop = rates for unicast V6 is around 2%. This significant disparity in failure rates = points to specific issues surrounding auto-tunnelling from the end host, and = the most logical issue is proto 41 filtering. Geoff From gih@apnic.net Thu Apr 21 05:05:58 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB050E070F for ; Thu, 21 Apr 2011 05:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.644 X-Spam-Level: X-Spam-Status: No, score=-96.644 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_62=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9A1coWDy2Ck for ; Thu, 21 Apr 2011 05:05:58 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfc.amsl.com (Postfix) with ESMTP id AF015E06DA for ; Thu, 21 Apr 2011 05:05:57 -0700 (PDT) Received: from gih-mpro.westell.com (pool-72-70-247-79.spfdma.east.verizon.net [72.70.247.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3B80AB6840; Thu, 21 Apr 2011 22:05:53 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> Date: Thu, 21 Apr 2011 22:05:50 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <025E990A-E483-4A69-988E-BB1E714EFAB2@apnic.net> References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4D9D2D50.4040801@dougbarton.us> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ADF2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <1E6D3A8E-D2EC-4281-86D6-FA334781F6F2@apple.com> <4D9EB2FF.2060900@gmail.com> <3D3EE2CF-76F5-4D36-BFB8-ADEC127F155C@apple.com> <4DA00BC6.4090705@gmail.com> <4DA00CDA.4030508@gmail.com> <5D32B7A5-BE7D-4170-BF79-BA2289DCFD74@dragondata.com> To: Kevin Day X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:05:59 -0000 On 11/04/2011, at 12:50 PM, Kevin Day wrote: >=20 > On Apr 9, 2011, at 10:05 AM, Cameron Byrne wrote: >=20 >>=20 >> On Apr 9, 2011 12:38 AM, "Brian E Carpenter" = wrote: >>>=20 >>> P.S. The phaseout plan is to wait until existing hosts and CPEs that >>> do 6to4 by default go to landfill or e-cycling. So we need to = operate >>> relays for another ten years. >>=20 >> This is a tall ask from someone, with all due respect for your = contributions, does not run a network or support desk. >>=20 >> Do you happen to have a supporting business case or are we making = proclamations that are not really intended for reality? >>=20 >> I believe the sp consensus is turn 6to4 off by default asap. It's = more trouble than it is worth and will get worse with cgn >=20 >=20 > We run a public 6to4 relay announced to the world. >=20 > Despite its problems, we're seeing overall usage on it go up, with an = overall trend of around a 5% increase each month. >=20 > I don't know if this is because others are shutting their relays down, = more people are using 6to4, other providers are forcing a selection onto = our relay because we go through great pains to make sure it's actually = working, or there's just more v6 content out there. >=20 > If the argument isn't "Even if 6to4 is your only option, you're better = off not having v6 at all", has anyone else looked at statistics on = public 6to4 relays to see what kind of usage growth/loss is happening = lately? I have no personal stake in what happens to 6to4, but if there = actually is a pattern of growth with it now, we probably should be = looking at why that's happening before discussions of pulling the plug = get too far. >=20 > Another single-datapoint anecdote: We used to receive at least one = complaint a month about our 6to4 relay not working (which pretty much = always was traced down to the reverse path being broken, not us), but = those complaints have pretty much stopped entirely in the last year. I = don't know if this is because people are getting better at deploying = 6to4, or if people know enough to switch to another option if it's = broken. I could offer a possible explanation here - there is some evidence in = the collected data sets to suggest that the peer-to-peer applications = are making use of IPv6, and there is some considerable amount of 6to4 = and teredo traffic as a result of this. However most peer-to-peer = application rely on massive redundancy in the assembled infrastructure, = and if one peer is not responsive the application simply (and generally = silently) just moves on. So when the browsers and the OSes depref'ed 6to4 for dual stack over the = past 12 months, the level of use of 6to4 in a point-to-point scenario = waned, and the relative incidence of clients who use 6to4 in a dual = stack continues to wane - its around 0.02% as far as I can see at = present (http://www.potaroo.net/stats/1x1/sitec/6v6dspref.png). But the = failure rate has been between 15% and 20% (higher on weekdays), where = "failure" is defined as the remove V6 end seeing the initial SYN packet, = but nothing more. So the pool folk who were likely to notice the failure and complain have = been, in relative terms at any rate, falling. While the pool of folk = using 6to4 are rising, but their manner of use is such that failure is = largely ignored. Geoff =20= From cb.list6@gmail.com Thu Apr 21 07:40:54 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1CA7E065A for ; Thu, 21 Apr 2011 07:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsKMb2vw0WdZ for ; Thu, 21 Apr 2011 07:40:49 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id 51582E00BE for ; Thu, 21 Apr 2011 07:40:49 -0700 (PDT) Received: by eye13 with SMTP id 13so653623eye.31 for ; Thu, 21 Apr 2011 07:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sbl/hoo3N1B4Ci/YYYcDPKVqHcJufsx8AW1EePsas8w=; b=TD6GoLSL27sFe7Gf0wzQdo4TVuwQhwYekFpRvH3Xoz0O12isT+kDIRC6Nzb2+F2Ggl rZarNFpSPhyddvi04JugDQkz3se9OV+AjsmpuPqIk45exPZW4sOvU6WpC+yxQGa6Pizg 8rflXhxbZHnUnvwzIxlhS8tv/+roaBQEMKr1k= 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=YmaoVkzwO48ZhKW18vXkQF0NT6GibihNL01l/hFcDmM+XihJH+jcdFQ65Nef82t9v/ WHnamJtcRmoPuYcrQ6kjEUYjjhCEm0g4+OF4Ejz3l9bx1GiLlwqephMk7Kwfh/+cCzP6 JSoIqCJXa5LeuKxD51uNGvYJT3IEvf8AwQWLA= MIME-Version: 1.0 Received: by 10.14.9.165 with SMTP id 37mr2154eet.209.1303396848550; Thu, 21 Apr 2011 07:40:48 -0700 (PDT) Received: by 10.14.126.210 with HTTP; Thu, 21 Apr 2011 07:40:47 -0700 (PDT) Received: by 10.14.126.210 with HTTP; Thu, 21 Apr 2011 07:40:47 -0700 (PDT) In-Reply-To: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> <280D9CD9-EC9C-400A-BDA5-C11A69A383E0@employees.org> Date: Thu, 21 Apr 2011 07:40:47 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Content-Type: multipart/alternative; boundary=001485f2710628c1c804a16eba05 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:40:54 -0000 --001485f2710628c1c804a16eba05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 21, 2011 1:04 AM, "Roger J=F8rgensen" wrote: > > On Wed, Apr 20, 2011 at 9:40 PM, Dmitry Anipko > wrote: > > > >>> remove that particular option from the table when a user, operator or vendor is considering what should be deployed/implemented... > > > > I agree that once majority of customers indeed have a choice whether to subscribe to their ISP IPV6 offering, 6to4 will no longer be needed. But ar= e we there yet? > > > The interesting thing about this entire 6to4 discussing is that there > is pretty much two sides > > > * Those that wish 6to4 gone because it cause more problem than it > solve, they also consider it too costly to fix considering other > options. > > > * Then there is the "other" side that is interesting... that is MS and > Apple which want to give their customer IPv6 which is great, I can't > praise those companies enough for their effort on IPv6. Espesial > Microsoft and their efford over the last 10+ years. > > > > But, isn't it time to move on, beyond IPv6 access for any cost and to > a place where we say either Good IPv6 access or none? > > Interesting observation. I believe nearly all the folks who run eyeball networks and content networks support the historic work since they staff Helpdesk and have to earn the customer's business everyday by providing reliable service. If the value chain fails, we know the consequences. It is an interesting perversion that you believe msft or apple are providin= g ipv6 service. I don't believe they run 6to4 relays or even have ipv6 conten= t today. Not to diminish the work they have done to advance v6 ...but let's just be clear on who is providing the network services and who wants v6 to move forward the most Cb > > -- > > 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 --001485f2710628c1c804a16eba05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 21, 2011 1:04 AM, "Roger J=F8rgensen" <rogerj@gmail.com> wrote:
>
> On Wed, Apr 20, 2011 at 9:40 PM, Dmitry Anipko
> <Dmitry.Anipko@micro= soft.com> wrote:
> <snip>
>
> >>> remove that particular option from the table when a user,= operator or vendor is considering what should be deployed/implemented... > >
> > I agree that once majority of customers indeed have a choice whet= her to subscribe to their ISP IPV6 offering, 6to4 will no longer be needed.= But are we there yet?
>
>
> The interesting thing about this entire 6to4 discussing is that there<= br> > is pretty much two sides
>
>
> * Those that wish 6to4 gone because it cause more problem than it
> solve, they also consider it too costly to fix considering other
> options.
>
>
> * Then there is the "other" side that is interesting... that= is MS and
> Apple which want to give their customer IPv6 which is great, I can'= ;t
> praise those companies enough for their effort on IPv6. Espesial
> Microsoft and their efford over the last 10+ years.
>
>
>
> But, isn't it time to move on, beyond IPv6 access for any cost and= to
> a place where we say either Good IPv6 access or none?
>
>

Interesting observation. I believe nearly all the folks who run eyeball = networks and content networks support the historic work since they staff He= lpdesk and have to earn the customer's business everyday by providing r= eliable service.

If the value chain fails, we know the consequences.

It is an interesting perversion that you believe msft or apple are provi= ding ipv6 service. I don't believe they run 6to4 relays or even have ip= v6 content today.=A0 Not to diminish the work they have done to advance v6 = ...but let's just be clear on who is providing the network services and= who wants v6 to move forward the most

Cb

>
> --
>
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001485f2710628c1c804a16eba05-- From fred@cisco.com Thu Apr 21 07:42:01 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E57C8E06B0 for ; Thu, 21 Apr 2011 07:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.25 X-Spam-Level: X-Spam-Status: No, score=-110.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTABShnchwnd for ; Thu, 21 Apr 2011 07:42:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id E0B7BE00BE for ; Thu, 21 Apr 2011 07:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3496; q=dns/txt; s=iport; t=1303396921; x=1304606521; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=KvBO+gfPOkq309EUKs9t8B4x7kT/WcCoQlN+a9OAXsw=; b=XwLL3+syStmgTrMsuxuLtTaPpyqEVW8x93BkgLOFhZ/uG5CTC2IhQymq G8aGrmWw6fYdW97ZUVfgXwmMcdqYTdd5mzhLZGRf3piG1cnV5u4tDoaKo ddQmX1lTPKm3MB3F22znUFW0O7shEbNrYirfOk/sAE39njwiC5v3E+vw9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANpBsE2rRDoJ/2dsb2JhbAClR3eIcJ8QnGGFdgSFdIg3hAU X-IronPort-AV: E=Sophos;i="4.64,251,1301875200"; d="scan'208";a="342092197" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2011 14:41:58 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3LEfrUA017379; Thu, 21 Apr 2011 14:41:58 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 21 Apr 2011 07:41:58 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 21 Apr 2011 07:41:58 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 21 Apr 2011 07:41:37 -0700 Message-Id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:42:02 -0000 On Apr 21, 2011, at 4:17 AM, Pekka Savola wrote: > On Sun, 17 Apr 2011, Fred Baker wrote: >> This is to initiate a two week working group last call of = draft-ietf-v6ops-6to4-to-historic. 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. >=20 > I oppose this document and moving 6to4 to historic just yet. >=20 > No IETF document requires 6to4, and therefore there is nothing the = IETF needs to do to allow vendors to turn it off. >=20 > "Deprecation by standardization body decree" when vendors still = continue shipping it will cause a mismatch between operational reality = and the IETF. It's futile. We should first convince the (major) = vendors that this what they want to do, wait that they start to do it, = and then begin the deprecation. I understand what you're trying to do, and that's fine, but... posting a = document declaring the protocol to have been "declared historic" is our = mechanism to do that.=20 > If we want to give advisories to the vendors or users, we can put = those to the advisory draft. >=20 > I however do agree that the following subset deprecation described in = Section 4 makes sense: >=20 > 1. IPv6 nodes SHOULD treat 6to4 as a service of "last resort" as > recommended in [I-D.ietf-6man-rfc3484-revise] > 2. Implementations capable of acting as 6to4 routers SHOULD NOT > enable 6to4 without explicit user configuration. In particular, > enabling IPv6 forwarding on a device, SHOULD NOT automatically > enable 6to4. > 3. If implemented in future products 6to4 SHOULD be disabled by > default. >=20 > This is internally inconsistent with S 1: "Declaring the mechanism = historic is not expected to have immediate product implications." It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying to be pragmatic - "we = understand that all software in the world isn't going to change = overnight; as it changes, this is the direction we'd like it to go". > What's the point if the goal is not to have immediate product = implications? >=20 > I'd say that the best approach is likely to just discontinue this = document. After we've gotten major vendors on board with the subset = deprecation, we can start working on the rest. How do you plan to get the major vendors onboard without a specification = for them to react to? > Editorial: >=20 > Many things I object to, but listing these is not worth the effort. = Some specifics though: > - First sentence of S 1 is misleading as already discussed and should > be removed/rephrased. No need to even mention the BGP model. >=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_______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Thu Apr 21 08:08:57 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DD1EFE0663 for ; Thu, 21 Apr 2011 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmvkB1NjD7QB for ; Thu, 21 Apr 2011 08:08:57 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id 0FADAE06B0 for ; Thu, 21 Apr 2011 08:08:56 -0700 (PDT) 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 p3LF8qLE077246 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 21 Apr 2011 15:08:52 GMT (envelope-from joelja@bogus.com) Message-ID: <4DB0487F.4080605@bogus.com> Date: Thu, 21 Apr 2011 08:08:47 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Cameron Byrne References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com> <4DAEA916.90908@inex.ie> <4C603E97-C164-4426-8584-2A429FA41D35@employees.org> <280D9CD9-EC9C-400A-BDA5-C11A69A383E0@employees.org> 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]); Thu, 21 Apr 2011 15:08:53 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 15:08:58 -0000 On 4/21/11 7:40 AM, Cameron Byrne wrote: > It is an interesting perversion that you believe msft or apple are > providing ipv6 service. I don't believe they run 6to4 relays or even > have ipv6 content today. Not to diminish the work they have done to > advance v6 ...but let's just be clear on who is providing the network > services and who wants v6 to move forward the most It can't possibly be overstated the importance of the inclusion of ipv6 in released consumer operating systems for close to the last decade. Those systems perform just peachy when provided with native v6... > Cb > >> >> -- >> >> 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 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Marcus.Williams@ed.gov Thu Apr 21 10:42:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0AC0E06E6 for ; Thu, 21 Apr 2011 10:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhlJqd7HX13G for ; Thu, 21 Apr 2011 10:42:55 -0700 (PDT) Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by ietfc.amsl.com (Postfix) with ESMTP id BB008E065C for ; Thu, 21 Apr 2011 10:42:54 -0700 (PDT) Received: from eduptcexmr04.ed.gov ([160.109.63.137]) (using TLSv1) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKTbBsnZx2wBRM1M9kOgHf8XOyZl+6qBel@postini.com; Thu, 21 Apr 2011 10:42:54 PDT Received: from eduptcexhb01.ed.gov (eduptcexhb01.ed.gov [165.224.52.29]) by eduptcexmr04.ed.gov (8.13.8/8.13.8) with ESMTP id p3LHgjQq012617 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 21 Apr 2011 12:42:53 -0500 Received: from EDUPTCEXMB02.ed.gov ([165.224.52.20]) by eduptcexhb01.ed.gov ([165.224.52.29]) with mapi; Thu, 21 Apr 2011 12:42:45 -0500 From: "Williams, Marcus (Contractor)" To: "v6ops@ietf.org" Date: Thu, 21 Apr 2011 12:42:43 -0500 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AcwAFceRU2ZQEjZlSH2CwQibr46y7gANaadw Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@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 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 17:42:56 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Pekka Savola > Sent: Thursday, April 21, 2011 7:17 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > > I however do agree that the following subset deprecation described in Sec= tion 4 makes sense: > > 1. IPv6 nodes SHOULD treat 6to4 as a service of "last resort" as > recommended in [I-D.ietf-6man-rfc3484-revise] > 2. Implementations capable of acting as 6to4 routers SHOULD NOT > enable 6to4 without explicit user configuration. In particular, > enabling IPv6 forwarding on a device, SHOULD NOT automatically > enable 6to4. > 3. If implemented in future products 6to4 SHOULD be disabled by > default. It seems ironic to be protecting the end user's control of the network. Marcus Williams From pekkas@netcore.fi Thu Apr 21 11:01:50 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6DBD0E081F for ; Thu, 21 Apr 2011 11:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.124 X-Spam-Level: X-Spam-Status: No, score=-102.124 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lo6joz0ZX-K for ; Thu, 21 Apr 2011 11:01:49 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfc.amsl.com (Postfix) with ESMTP id 7BF31E06E6 for ; Thu, 21 Apr 2011 11:01:49 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3LI1c9D022602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 21:01:38 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3LI1cTE022599; Thu, 21 Apr 2011 21:01:38 +0300 Date: Thu, 21 Apr 2011 21:01:38 +0300 (EEST) From: Pekka Savola To: Fred Baker In-Reply-To: Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:01:50 -0000 On Thu, 21 Apr 2011, Fred Baker wrote: > I understand what you're trying to do, and that's fine, but... > posting a document declaring the protocol to have been "declared > historic" is our mechanism to do that. The IETF can certainly post documents if it wishes. I'm saying that it is not a constructive thing to do unless we know that the major vendors are on board to follow that advice. I'm saying that we should first get those vendors on board, not try to use "publish an RFC" as a hammer. At best, the hammer makes them change their minds. At worst, they laugh at the hammer and do nothing. The IETF looks silly, and the users who read RFCs get confused. > It might make sense, if that statement is confusing, to remove the > statement. I think the authors are trying to be pragmatic - "we > understand that all software in the world isn't going to change > overnight; as it changes, this is the direction we'd like it to go". Then what is the point of this document again? James said it pretty well [1] "When I briefed my managers about this draft, I told them that it currently requires us to do absolutely nothing in the foreseeable future, and it explicitly permits us to continue doing what we are doing today. My reading of the document suggests that you can safely ignore its current form as well." [1] http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html > How do you plan to get the major vendors onboard without a > specification for them to react to? The major vendors who are the main target of this document are be already present on the mailing list. Just as an observation: People from Microsoft are arguing against it. James from Apple is arguing against it from a different angle. Are you hoping that even if they don't change their opinion, they will conform to the RFC? I don't. -- 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 Apr 21 11:18:16 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A228E06C9 for ; Thu, 21 Apr 2011 11:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAkmYMWt8u2k for ; Thu, 21 Apr 2011 11:18:15 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id 875D6E06A0 for ; Thu, 21 Apr 2011 11:18:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK000D2DLC5DFI1@mail-out.apple.com> for v6ops@ietf.org; Thu, 21 Apr 2011 11:18:14 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-ea-4db074e54a2a Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 00.89.20744.6E470BD4; Thu, 21 Apr 2011 11:18:14 -0700 (PDT) Received: from [17.193.13.64] by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LK000FZDLIDZO60@koseret.apple.com> for v6ops@ietf.org; Thu, 21 Apr 2011 11:18:13 -0700 (PDT) From: james woodyatt In-reply-to: Date: Thu, 21 Apr 2011 11:18:14 -0700 Message-id: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:18:16 -0000 On Apr 21, 2011, at 11:01 , Pekka Savola wrote: > > Are you hoping that even if they don't change their opinion, they will conform to the RFC? I'd like to note here that all of Apple's currently shipping products expressly require human intervention to enable 6to4 tunneling. About three years ago, for a brief period of time, Apple sold a few hundred thousand AirPort Extreme base stations that enabled 6to4 tunneled IPv6 routing in their default configuration. Apple didn't need an RFC to figure out precisely how and why this wasn't a very good idea, and changed the default configuration. Until a few months ago, the only way it was possible for an Apple product to be configured into a 6to4 tunneling mode without express human intervention was by inadvertently importing a saved configuration from one of those older AirPort Extreme base stations into a newer AirPort product. With the latest 7.5.2 release of AirPort/TimeCapsule firmware, even *that* isn't possible anymore. Apple is already in absolute total conformance with the language in this draft. I still oppose its publication for the reasons I've already stated, which have nothing to do with any implications of the recommendations it contains on Apple's business plans. -- james woodyatt member of technical staff, core os networking From fred@cisco.com Thu Apr 21 11:25:16 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA9E2E07AC for ; Thu, 21 Apr 2011 11:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcLFQia2ZC+C for ; Thu, 21 Apr 2011 11:25:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id D9CECE0717 for ; Thu, 21 Apr 2011 11:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2528; q=dns/txt; s=iport; t=1303410315; x=1304619915; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=V7t0Fi2VSC3XERFjwPLf3fOdlxbN45fZlfkW8E6tU7Q=; b=OUSbxlBGI8WeJ/IC9e/itCktkzA4k/UVSxFQGj140j5E7Xf72aBepUA9 Wlus8YCwsUwSQ63Q5TCSBPg/LFYxFDTkssNgQBtyHw1Fh3Ag0x68mZzat Uzqlcaz9wLXK8C3uoQ/dYyb+rbSFyTPDoOJ13tLr35+rwXCrtYavXVv5q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG91sE2rRDoG/2dsb2JhbAClUXeIcJ8YnFaFdgSFdIg3hAU X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="342250634" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2011 18:25:15 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3LIPA3k027304; Thu, 21 Apr 2011 18:25:15 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 21 Apr 2011 11:25:15 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 21 Apr 2011 11:25:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 21 Apr 2011 11:24:53 -0700 Message-Id: <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:25:17 -0000 On Apr 21, 2011, at 11:01 AM, Pekka Savola wrote: > On Thu, 21 Apr 2011, Fred Baker wrote: >> I understand what you're trying to do, and that's fine, but... = posting a document declaring the protocol to have been "declared = historic" is our mechanism to do that. >=20 > The IETF can certainly post documents if it wishes. > I'm saying that it is not a constructive thing to do unless we know = that the major vendors are on board to follow that advice. >=20 > I'm saying that we should first get those vendors on board, not try to = use "publish an RFC" as a hammer. >=20 > At best, the hammer makes them change their minds. > At worst, they laugh at the hammer and do nothing. The IETF looks = silly, and the users who read RFCs get confused. So, rather than follow our own processes as described in RFC 2026 and = specifically http://tools.ietf.org/html/rfc2026#section-4.2.4, as we did = with RIPv1 and NAT-PT among other things, you would like us to do = something undefined and different. >> It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying to be pragmatic - "we = understand that all software in the world isn't going to change = overnight; as it changes, this is the direction we'd like it to go". >=20 > Then what is the point of this document again? >=20 > James said it pretty well [1] >=20 > "When I briefed my managers about this draft, I told them that it = currently requires us to do absolutely nothing in the foreseeable = future, and it explicitly permits us to continue doing what we are doing = today. My reading of the document suggests that you can safely ignore = its current form as well." >=20 > [1] > http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html >=20 >> How do you plan to get the major vendors onboard without a = specification for them to react to? >=20 > The major vendors who are the main target of this document are be = already present on the mailing list. >=20 > Just as an observation: >=20 > People from Microsoft are arguing against it. James from Apple is = arguing against it from a different angle. >=20 > Are you hoping that even if they don't change their opinion, they will = conform to the RFC? >=20 > I don't. >=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 pekkas@netcore.fi Thu Apr 21 11:30:53 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85326E07E4 for ; Thu, 21 Apr 2011 11:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.183 X-Spam-Level: X-Spam-Status: No, score=-102.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwOz1zHgD685 for ; Thu, 21 Apr 2011 11:30:52 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfc.amsl.com (Postfix) with ESMTP id 87364E06CE for ; Thu, 21 Apr 2011 11:30:52 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3LIUfFB023159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 21:30:42 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3LIUfnb023156; Thu, 21 Apr 2011 21:30:41 +0300 Date: Thu, 21 Apr 2011 21:30:41 +0300 (EEST) From: Pekka Savola To: Fred Baker In-Reply-To: <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:30:53 -0000 On Thu, 21 Apr 2011, Fred Baker wrote: > So, rather than follow our own processes as described in RFC 2026 > and specifically http://tools.ietf.org/html/rfc2026#section-4.2.4, > as we did with RIPv1 and NAT-PT among other things, you would like > us to do something undefined and different. > > NAT-PT deprecation could have been done better. It was done similarly as we're doing 6to4 deprecation. There are still NAT-PT products out there, with no intention to remove the code. Maybe it would a good time to learn something here. I'm not saying 6to4 RFCs must never be made Historic. I'm just saying doing it right now, without sufficiently solid consensus especially with those vendors who have shipped a hundred million implementations of it, is premature. -- 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 Dmitry.Anipko@microsoft.com Thu Apr 21 11:38:24 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCA54E0804 for ; Thu, 21 Apr 2011 11:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JwXOhH4GAKf for ; Thu, 21 Apr 2011 11:38:24 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id E4CA2E07AC for ; Thu, 21 Apr 2011 11:38:23 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 11:38:22 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 11:38:23 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Thu, 21 Apr 2011 11:38:22 -0700 From: Dmitry Anipko To: Fred Baker , Pekka Savola Date: Thu, 21 Apr 2011 11:38:18 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AcwAUYFlgxcfT2qGSWO9HPueHHG2NwAACTRw Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> In-Reply-To: <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@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" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:38:25 -0000 Hi Fred, The BCP section quoted below says: " A specification that has been superseded by a more recent specification o= r is for any other reason considered to be obsolete is assigned to the "His= toric" level." The draft does not seem to say that there is a more recent specification su= perseding the standard.=20 As to "any other reason" clause, I tried to communicate in my feedback, in = my opinion, the draft doesn't state clearly the reasons which would require= moving RFC 3056 to historic. It quotes 2 issues: 1. One is issue with protocol 41, and not RFC 3056 (so if it is an issue in= deed, I think appropriate action could be deprecating protocol 41 - but int= erestingly no one seems to be arguing for that). 2. The other issue applies to implementations already not compliant with RF= C 3056, or to networks where administrator usually have control to disable = 6to4 if they choose to deploy public IPV4 addresses behind NATs. So this doesn't look to me that the required conditions, per the BCP defini= tion of historic, are met for move of RFC 3056 to historic. Thank you, Dmitry -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Thursday, April 21, 2011 11:25 AM To: Pekka Savola Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 21, 2011, at 11:01 AM, Pekka Savola wrote: > On Thu, 21 Apr 2011, Fred Baker wrote: >> I understand what you're trying to do, and that's fine, but... posting a= document declaring the protocol to have been "declared historic" is our me= chanism to do that. >=20 > The IETF can certainly post documents if it wishes. > I'm saying that it is not a constructive thing to do unless we know that = the major vendors are on board to follow that advice. >=20 > I'm saying that we should first get those vendors on board, not try to us= e "publish an RFC" as a hammer. >=20 > At best, the hammer makes them change their minds. > At worst, they laugh at the hammer and do nothing. The IETF looks silly, = and the users who read RFCs get confused. So, rather than follow our own processes as described in RFC 2026 and speci= fically http://tools.ietf.org/html/rfc2026#section-4.2.4, as we did with RI= Pv1 and NAT-PT among other things, you would like us to do something undefi= ned and different. >> It might make sense, if that statement is confusing, to remove the state= ment. I think the authors are trying to be pragmatic - "we understand that = all software in the world isn't going to change overnight; as it changes, t= his is the direction we'd like it to go". >=20 > Then what is the point of this document again? >=20 > James said it pretty well [1] >=20 > "When I briefed my managers about this draft, I told them that it current= ly requires us to do absolutely nothing in the foreseeable future, and it e= xplicitly permits us to continue doing what we are doing today. My reading= of the document suggests that you can safely ignore its current form as we= ll." >=20 > [1] > http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html >=20 >> How do you plan to get the major vendors onboard without a specification= for them to react to? >=20 > The major vendors who are the main target of this document are be already= present on the mailing list. >=20 > Just as an observation: >=20 > People from Microsoft are arguing against it. James from Apple is arguing= against it from a different angle. >=20 > Are you hoping that even if they don't change their opinion, they will co= nform to the RFC? >=20 > I don't. >=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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Apr 21 11:40:32 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E54AE0826 for ; Thu, 21 Apr 2011 11:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raavubl-g+CK for ; Thu, 21 Apr 2011 11:40:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id DBDFBE07AC for ; Thu, 21 Apr 2011 11:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1012; q=dns/txt; s=iport; t=1303411231; x=1304620831; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=cw7ZclHU8Lkf86IXGS3zUUm/fwEJ4sLyDaK6wDYSVOQ=; b=bQCbj0iKI7JiZJdqvMvEPIMYgZtOu527eC2NE95UdOfUQZ399haEVs7z +BcujlMVsD9Y183pKbCAuYgT+mEPwMmNoAo4SzSKvLS3WI9lWcN+k+b45 O7QA4gAHuvsfAzx164O3z4jZJ0v2eGb5mPZEpPwKXL7nbMbSPnLd687aK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK15sE2tJXG//2dsb2JhbAClVHeIcJ8LnFSFdgSFdIg3hAU X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="299475559" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2011 18:40:31 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3LIePcZ019084; Thu, 21 Apr 2011 18:40:30 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 21 Apr 2011 11:40:30 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 21 Apr 2011 11:40:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 21 Apr 2011 11:40:14 -0700 Message-Id: <0491BAF6-9C9C-49E8-BB80-9A7C5ED58069@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:40:32 -0000 On Apr 21, 2011, at 11:30 AM, Pekka Savola wrote: > On Thu, 21 Apr 2011, Fred Baker wrote: >> So, rather than follow our own processes as described in RFC 2026 and = specifically http://tools.ietf.org/html/rfc2026#section-4.2.4, as we did = with RIPv1 and NAT-PT among other things, you would like us to do = something undefined and different. >>=20 >> >=20 > NAT-PT deprecation could have been done better. It was done similarly = as we're doing 6to4 deprecation. There are still NAT-PT products out = there, with no intention to remove the code. Yes, one of them comes from Cisco. The important point there isn't that = NAT-PT isn't being removed, although I'd be in favor of that. It's that = people that were using it and getting frustrated got an explanation that = didn't involved vendor-bash-finger-point, and in response to operator = demand the IETF started working on a viable replacement, which is now in = active product in the field and in use in networks. From jhw@apple.com Thu Apr 21 11:44:29 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADD99E06A1 for ; Thu, 21 Apr 2011 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ5cMDJ0-laO for ; Thu, 21 Apr 2011 11:44:28 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id B52BCE065F for ; Thu, 21 Apr 2011 11:44:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK0004YOMN3LD90@mail-out.apple.com> for v6ops@ietf.org; Thu, 21 Apr 2011 11:44:28 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-ab-4db07b0c942e Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id D4.74.20744.C0B70BD4; Thu, 21 Apr 2011 11:44:28 -0700 (PDT) Received: from [17.193.15.152] (unknown [17.193.15.152]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LK000F7XMQ32670@cardamom.apple.com> for v6ops@ietf.org; Thu, 21 Apr 2011 11:44:28 -0700 (PDT) From: james woodyatt In-reply-to: Date: Thu, 21 Apr 2011 11:44:27 -0700 Message-id: <1CD641BB-2AE5-471F-8556-B004322E8E84@apple.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:44:29 -0000 On Apr 21, 2011, at 11:18 AM, james woodyatt wrote: > Apple sold a few hundred thousand AirPort Extreme base stations I should correct myself immediately. I actually don't know how many base stations were sold with firmware that enabled 6to4 tunneled routing by default. They were the first draft-802.11n products Apple sold, so there was high demand, but they were on sale for less than six months before the firmware was changed at the factory. -- james woodyatt member of technical staff, core os networking From fred@cisco.com Thu Apr 21 11:52:07 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7F5AE06C9 for ; Thu, 21 Apr 2011 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.246 X-Spam-Level: X-Spam-Status: No, score=-110.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDmAbPromtYB for ; Thu, 21 Apr 2011 11:52:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 8751EE06A3 for ; Thu, 21 Apr 2011 11:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4459; q=dns/txt; s=iport; t=1303411926; x=1304621526; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=or6JeLpYtFrXlny0HADM83rlOhvG/EixeXoSZCMm+aY=; b=mDExybi/2iTHfybzGGT/5DL+LN1O62Sqw0LNmJWP8HYX0xogAIbEw2Tf 0mm+TExZzj29QnSK5Nj08OiWYJ1y1+gfmVHHjYMF9HvYDijKG/1k0r4m7 Do3zU9Xgdh2hSMgEJiwPnFV8JL5DPR+y3Zy5vdxyRMNAQCCDWIs4GobE+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAMR7sE2rRDoJ/2dsb2JhbACXTI4Jd4hwnwacVYV2BIV0iDeEBQ X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="434440542" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2011 18:52:05 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3LIq0QS001963; Thu, 21 Apr 2011 18:52:05 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 21 Apr 2011 11:52:05 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 21 Apr 2011 11:52:05 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 21 Apr 2011 11:51:47 -0700 Message-Id: <4FCC2593-E742-42AA-9ADE-DEE1CC9577EF@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:52:07 -0000 On Apr 21, 2011, at 11:38 AM, Dmitry Anipko wrote: > Hi Fred, >=20 > The BCP section quoted below says: >=20 > " A specification that has been superseded by a more recent = specification or is for any other reason considered to be obsolete is = assigned to the "Historic" level." >=20 > The draft does not seem to say that there is a more recent = specification superseding the standard.=20 Well, yes, it's not updating the standard. It's saying that the standard = should be superseded by native deployment. > As to "any other reason" clause, I tried to communicate in my = feedback, in my opinion, the draft doesn't state clearly the reasons = which would require moving RFC 3056 to historic. It quotes 2 issues: >=20 > 1. One is issue with protocol 41, and not RFC 3056 (so if it is an = issue indeed, I think appropriate action could be deprecating protocol = 41 - but interestingly no one seems to be arguing for that). >=20 > 2. The other issue applies to implementations already not compliant = with RFC 3056, or to networks where administrator usually have control = to disable 6to4 if they choose to deploy public IPV4 addresses behind = NATs. >=20 > So this doesn't look to me that the required conditions, per the BCP = definition of historic, are met for move of RFC 3056 to historic. I'll leave that discussion to the authors and other commentators. > Thank you, > Dmitry >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker > Sent: Thursday, April 21, 2011 11:25 AM > To: Pekka Savola > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >=20 >=20 > On Apr 21, 2011, at 11:01 AM, Pekka Savola wrote: >=20 >> On Thu, 21 Apr 2011, Fred Baker wrote: >>> I understand what you're trying to do, and that's fine, but... = posting a document declaring the protocol to have been "declared = historic" is our mechanism to do that. >>=20 >> The IETF can certainly post documents if it wishes. >> I'm saying that it is not a constructive thing to do unless we know = that the major vendors are on board to follow that advice. >>=20 >> I'm saying that we should first get those vendors on board, not try = to use "publish an RFC" as a hammer. >>=20 >> At best, the hammer makes them change their minds. >> At worst, they laugh at the hammer and do nothing. The IETF looks = silly, and the users who read RFCs get confused. >=20 > So, rather than follow our own processes as described in RFC 2026 and = specifically http://tools.ietf.org/html/rfc2026#section-4.2.4, as we did = with RIPv1 and NAT-PT among other things, you would like us to do = something undefined and different. >=20 > >=20 >>> It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying to be pragmatic - "we = understand that all software in the world isn't going to change = overnight; as it changes, this is the direction we'd like it to go". >>=20 >> Then what is the point of this document again? >>=20 >> James said it pretty well [1] >>=20 >> "When I briefed my managers about this draft, I told them that it = currently requires us to do absolutely nothing in the foreseeable = future, and it explicitly permits us to continue doing what we are doing = today. My reading of the document suggests that you can safely ignore = its current form as well." >>=20 >> [1] >> http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html >>=20 >>> How do you plan to get the major vendors onboard without a = specification for them to react to? >>=20 >> The major vendors who are the main target of this document are be = already present on the mailing list. >>=20 >> Just as an observation: >>=20 >> People from Microsoft are arguing against it. James from Apple is = arguing against it from a different angle. >>=20 >> Are you hoping that even if they don't change their opinion, they = will conform to the RFC? >>=20 >> I don't. >>=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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From Dmitry.Anipko@microsoft.com Thu Apr 21 12:30:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E129AE07E2 for ; Thu, 21 Apr 2011 12:30:38 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUEmeK8cmNi5 for ; Thu, 21 Apr 2011 12:30:38 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 1A174E00BE for ; Thu, 21 Apr 2011 12:30:38 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 12:30:36 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 12:30:36 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Thu, 21 Apr 2011 12:30:30 -0700 From: Dmitry Anipko To: Fred Baker Date: Thu, 21 Apr 2011 12:30:26 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AcwAVTmdVn0HJKCXTHy7uS8bi+Oi2QAA+N7g Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> <4FCC2593-E742-42AA-9ADE-DEE1CC9577EF@cisco.com> In-Reply-To: <4FCC2593-E742-42AA-9ADE-DEE1CC9577EF@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" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 19:30:39 -0000 Hello Fred, >> Well, yes, it's not updating the standard. It's saying that the standard= should be superseded by native deployment. As far as I see you agree that that particular BCP wording doesn't apply th= ere, since there is no superseding specification. So I fail to see how that= wording can be used to support moving RFC 3056 to historic status.=20 But even if that wording did apply, and native deployment could be consider= ed as superseding 6to4 (and IPv6 offering apparently is not yet widely avai= lable to customers), then from that prospective I think native deployment w= ould also supersede Teredo as well as other automatic IPv6 over IPv4 tunnel= s - but the draft doesn't propose that (perhaps there are other drafts I'm = not aware of), and moving only 6to4 to historic would not be consistent. Thank you, Dmitry -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Thursday, April 21, 2011 11:52 AM To: Dmitry Anipko Cc: Pekka Savola; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 21, 2011, at 11:38 AM, Dmitry Anipko wrote: > Hi Fred, >=20 > The BCP section quoted below says: >=20 > " A specification that has been superseded by a more recent specification= or is for any other reason considered to be obsolete is assigned to the "H= istoric" level." >=20 > The draft does not seem to say that there is a more recent specification = superseding the standard.=20 Well, yes, it's not updating the standard. It's saying that the standard sh= ould be superseded by native deployment. > As to "any other reason" clause, I tried to communicate in my feedback, i= n my opinion, the draft doesn't state clearly the reasons which would requi= re moving RFC 3056 to historic. It quotes 2 issues: >=20 > 1. One is issue with protocol 41, and not RFC 3056 (so if it is an issue = indeed, I think appropriate action could be deprecating protocol 41 - but i= nterestingly no one seems to be arguing for that). >=20 > 2. The other issue applies to implementations already not compliant with = RFC 3056, or to networks where administrator usually have control to disabl= e 6to4 if they choose to deploy public IPV4 addresses behind NATs. >=20 > So this doesn't look to me that the required conditions, per the BCP defi= nition of historic, are met for move of RFC 3056 to historic. I'll leave that discussion to the authors and other commentators. > Thank you, > Dmitry >=20 From fred@cisco.com Thu Apr 21 12:38:42 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75056E0754 for ; Thu, 21 Apr 2011 12:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4uchkPQble7 for ; Thu, 21 Apr 2011 12:38:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 755C0E0707 for ; Thu, 21 Apr 2011 12:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3332; q=dns/txt; s=iport; t=1303414721; x=1304624321; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=3aYsdltRB57W8TKIt1+oQyEpk8roQ+axeiKN8XTLxoQ=; b=ZuEjavHGADV0PDOz9UAnbGHwVWbmpyIFewzRC3gVV9iACYF6dK2i+6Vu CULjS6zb5SM+3/4J9A7SqevybNkgJ/WZW6iz55yWIifWG2orr/+qppJM6 /JdcWtWPVaE0fR4q0bfIr0klyKX5R82x9ngseaZHIIh1r0MSH8yvmEjdq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAAeHsE2rRDoI/2dsb2JhbACXS44Jd4hwnwOcWIV2BIV0iDeEBQ X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="342295993" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2011 19:38:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LJcZMg031491; Thu, 21 Apr 2011 19:38:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 21 Apr 2011 12:38:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 21 Apr 2011 12:38:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 21 Apr 2011 12:38:20 -0700 Message-Id: <3E88D92A-242A-4E76-8E83-D66D3D31EAAB@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> <4FCC2593-E742-42AA-9ADE-DEE1CC9577EF@cisco.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 19:38:42 -0000 On Apr 21, 2011, at 12:30 PM, Dmitry Anipko wrote: > Hello Fred, >=20 >>> Well, yes, it's not updating the standard. It's saying that the = standard should be superseded by native deployment. >=20 > As far as I see you agree that that particular BCP wording doesn't = apply there, since there is no superseding specification. So I fail to = see how that wording can be used to support moving RFC 3056 to historic = status.=20 I'm hard pressed to see what "BCP" has to do with this. Are you = referring to RFC 2026 as a BCP? > But even if that wording did apply, and native deployment could be = considered as superseding 6to4 (and IPv6 offering apparently is not yet = widely available to customers), then from that prospective I think = native deployment would also supersede Teredo as well as other automatic = IPv6 over IPv4 tunnels - but the draft doesn't propose that (perhaps = there are other drafts I'm not aware of), and moving only 6to4 to = historic would not be consistent. I personally would be very much in favor of making the same statement = about Teredo. You might read = http://www.potaroo.net/ispcol/2011-04/teredo.html, and specifically the = portions on measuring Teredo behavior and performance. That said, I = think it's a separate decision than the 6to4 decision. I wouldn't want = to, for example, discover that there was consensus to take one to = Historic and not the other, and as a result of having them in the same = draft find that we couldn't do that which we actually had consensus to = do. > Thank you, > Dmitry >=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Thursday, April 21, 2011 11:52 AM > To: Dmitry Anipko > Cc: Pekka Savola; v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >=20 >=20 > On Apr 21, 2011, at 11:38 AM, Dmitry Anipko wrote: >=20 >> Hi Fred, >>=20 >> The BCP section quoted below says: >>=20 >> " A specification that has been superseded by a more recent = specification or is for any other reason considered to be obsolete is = assigned to the "Historic" level." >>=20 >> The draft does not seem to say that there is a more recent = specification superseding the standard.=20 >=20 > Well, yes, it's not updating the standard. It's saying that the = standard should be superseded by native deployment. >=20 >> As to "any other reason" clause, I tried to communicate in my = feedback, in my opinion, the draft doesn't state clearly the reasons = which would require moving RFC 3056 to historic. It quotes 2 issues: >>=20 >> 1. One is issue with protocol 41, and not RFC 3056 (so if it is an = issue indeed, I think appropriate action could be deprecating protocol = 41 - but interestingly no one seems to be arguing for that). >>=20 >> 2. The other issue applies to implementations already not compliant = with RFC 3056, or to networks where administrator usually have control = to disable 6to4 if they choose to deploy public IPV4 addresses behind = NATs. >>=20 >> So this doesn't look to me that the required conditions, per the BCP = definition of historic, are met for move of RFC 3056 to historic. >=20 > > I'll leave that discussion to the authors and other commentators. >=20 >> Thank you, >> Dmitry >>=20 From Dmitry.Anipko@microsoft.com Thu Apr 21 12:50:12 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E91A6E07C7 for ; Thu, 21 Apr 2011 12:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7AgkozJHHNd for ; Thu, 21 Apr 2011 12:50:12 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id E7053E076C for ; Thu, 21 Apr 2011 12:50:11 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 12:50:11 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 12:50:11 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Thu, 21 Apr 2011 12:49:37 -0700 From: Dmitry Anipko To: Fred Baker Date: Thu, 21 Apr 2011 12:49:35 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AcwAW70caCXQtNQ8RkexPCH1MBlXUgAAFUzw Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> <4FCC2593-E742-42AA-9ADE-DEE1CC9577EF@cisco.com> <3E88D92A-242A-4E76-8E83-D66D3D31EAAB@cisco.com> In-Reply-To: <3E88D92A-242A-4E76-8E83-D66D3D31EAAB@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" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 19:50:13 -0000 Hello Fred, >> Are you referring to RFC 2026 as a BCP? Yes, since it has category " Category: Best Current Practice". Sorry if thi= s was confusing, I should have used RFC 2026 as a pointer. >> I wouldn't want to, for example, discover that there was consensus to ta= ke one to Historic and not the other, and as a result of having them in the= same draft find that we couldn't do that which we actually had consensus t= o do. I don't know if there is consensus on moving 6to4 to historic, but to comme= nt on your point: if one follows the justification you suggested (native su= persedes tunnels), as I understand, that justification would equally apply = to 6to4 and Teredo. And if that's not the case and there are some reasons w= hy it doesn't apply to Teredo, I'd like to see analysis of why it doesn't, = and whether those reasons apply to 6to4.=20 That is what my feedback was - I think the current draft lacks listing of s= pecific reasons what's wrong with RFC 3056 as a whole. Once such analysis i= s added, and the draft shows why those issues aren't mitigated by other pro= posals, which already exist (such as e.g. RFC 3484 revision), I think it wo= uld gain broader support. Thank you, Dmitry -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Thursday, April 21, 2011 12:38 PM To: Dmitry Anipko Cc: Pekka Savola; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 21, 2011, at 12:30 PM, Dmitry Anipko wrote: > Hello Fred, >=20 >>> Well, yes, it's not updating the standard. It's saying that the standar= d should be superseded by native deployment. >=20 > As far as I see you agree that that particular BCP wording doesn't apply = there, since there is no superseding specification. So I fail to see how th= at wording can be used to support moving RFC 3056 to historic status.=20 I'm hard pressed to see what "BCP" has to do with this. Are you referring t= o RFC 2026 as a BCP? > But even if that wording did apply, and native deployment could be consid= ered as superseding 6to4 (and IPv6 offering apparently is not yet widely av= ailable to customers), then from that prospective I think native deployment= would also supersede Teredo as well as other automatic IPv6 over IPv4 tunn= els - but the draft doesn't propose that (perhaps there are other drafts I'= m not aware of), and moving only 6to4 to historic would not be consistent. I personally would be very much in favor of making the same statement about= Teredo. You might read http://www.potaroo.net/ispcol/2011-04/teredo.html, = and specifically the portions on measuring Teredo behavior and performance.= That said, I think it's a separate decision than the 6to4 decision. I woul= dn't want to, for example, discover that there was consensus to take one to= Historic and not the other, and as a result of having them in the same dra= ft find that we couldn't do that which we actually had consensus to do. > Thank you, > Dmitry >=20 From brian.e.carpenter@gmail.com Thu Apr 21 17:48:02 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76431E0673 for ; Thu, 21 Apr 2011 17:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id najtKACN354d for ; Thu, 21 Apr 2011 17:48:01 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 0D09DE06F2 for ; Thu, 21 Apr 2011 17:48:00 -0700 (PDT) Received: by pxi20 with SMTP id 20so170875pxi.27 for ; Thu, 21 Apr 2011 17:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3Tj82HDcabvcQunl1OF0bbxfaUhxsaxlR/y7gjXp2yI=; b=QdVVH3+p+KIiAimOUXhLw3wruxK6C9AQa6dCORYtQ3dTVqAgt3+I+NHicdxrXxGwjt woTe/FuOOt2hapzRD5qqihnjmsfuPJxhWlcrNItnHlkUTvsGC5Q17zK/Y7c4JFTO6D34 EKfCmEBeFaOQsE1/oN3GgW7RwjdHEAhghkk3A= 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=rK6sX7NFhbPnsFFyjlQVlqAkp7vGLrG/khYsScSrFKh8M12aKS6/60PehbuuWHRcUM rGlUvwAXYBhkgWq+aTznsZDiuyXsm0Z0Kkc478BOx8tWiMxGeAQygiIb4LmvbqItutjS yEXydX8lhg2q0eXckngwBcElPlab+InalP2j8= Received: by 10.68.66.66 with SMTP id d2mr810669pbt.73.1303433280417; Thu, 21 Apr 2011 17:48:00 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id g3sm1628083pbl.92.2011.04.21.17.47.58 (version=SSLv3 cipher=OTHER); Thu, 21 Apr 2011 17:47:59 -0700 (PDT) Message-ID: <4DB0D038.6050503@gmail.com> Date: Fri, 22 Apr 2011 12:47:52 +1200 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: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 00:48:02 -0000 Hi Pekka, On 2011-04-21 17:27, Pekka Savola wrote: > On Thu, 21 Apr 2011, Brian E Carpenter wrote: >>> Section 2.1 on Router 6to4 should be trimmed down, one page is >>> excessive. 6to4 was never deployed as it was initially devised by >>> Carpenter, so text on that is not very useful (most of 1st paragraph of >>> Section 3 should also go away). The key point is that 6to4 hosts or >>> routers may either configure the relay router IP address or use anycast. >> >> You made this comment on an earlier version. I disagreed then and I >> disagree >> now. It's impossible to understand how the anycast version is supposed to >> work unless you understand how basic 6to4 is supposed to work, and the >> situation for the return relay is the same in both cases. I couldn't find >> anything redundant in the explanation. > > You seem to be arguing that S 2.1 is an overview of 6to4 without anycast > and that such an overview is essential. Yes, exactly. > > I'd argue that this document does not need to provide a description of > how basic 6to4 or anycast 6to4 works; it is already described in those > documents, and it is not essential in order to understand the rest of > the document. The reader can get the message of the document even if > (s)he isn't very familiar with rfc3056 or rfc3068 even without the > details in Section 2. Well, we disagree, so we'd better see what the WG Chairs think. > > >>> .. it was not described if the return path relay used 192.88.99.1 as the >>> source address of packets or the non-anycast address. I would expect >>> significantly more breakage when 192.88.99.1 is NOT used as the source >>> address. Firewalls in residential case are rarely an issue based on my >>> experience if the relay uses 192.88.99.1 as the source address. >> >> It is mentioned somwhere that there is conflicting evidence on this >> point - actually it depends on whether the client is behind a stateful >> firewall or not. So I think this point is covered. > > There are two different axes here - firewall and source address: > > 1. stateful firewall > 2. stateless firewall > > a. relay uses 192.88.99.1 as source > b. relay uses non-anycast as source > > I'm saying that 1.b) cannot work and this is likely causing bad figures > in Geoff's study. 1.a) can work out of the box with zero configuration. > Therefore the point is not (only) "stateful firewall" but also (or > mainly) source aaddress. Both 2.a) and 2.b) are likely to work with > roughly the same probability. > > There are actually more granularity in how firewalls work, but that > shows that using 192.88.99.1 as source is _especially important_ for > stateful firewalls. I agree with your analysis, but of course there can also be situations where ingress filtering could cause source=192.88.99.1 to be blackholed. So unfortunately there is no single correct answer here. I will try to ensure that the text is clear about this. > >>> 5. PMTUD Failure: ...Path MTU Discovery does not >>> always work, and this can lead to connectivity failures. Even if >>> a TCP SYN/ACK exchange works, TCP packets with full size payloads >>> may simply be lost. >>> >>> .. due to MSS negotiation this is not a problem if 6to4 is set up on a >>> host because it will set MSS lower than 1500-40=1460B. >> >> I have personally experienced MSS negotiation failing in exactly this >> case. Probably that is an implementation bug at the server side, and I >> agree this point should be mentioned. > > I'd actually suspect that the issue is more at the client side, i.e., > the client doesn't lower MSS based on where the default route points. In the case of my own client (XP) it did seem to be signaling a smaller MSS but the server insisted on the higher value. > >>> Section 4.1 is out of place here. Remove or broaden the scope of the >>> document to include vendors. >> >> That's why the first sentence of this section says >> " Although this document is aimed principally at operators, there are >> some steps that implementers and vendors of 6to4 should take." > > I read that. But it isn't written in the abstract or introduction. > IMHO, either this needs to be made a first-class citizen in the document > or it should be removed. Well, I really think that is a matter of taste. > >>> S 4.2: >>> 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. >>> >>> .. this must be removed unless there is more operational experience with >>> this approach. Hinting at the ISPs that this could be a good approach >>> is very wrong if we don't know that it is actually the case. >> >> I don't see that. We know that it cannot make things worse and might >> make things better. > > Disagree. > > If the concerned ISP is able to ping 192.88.99.1 and the relay will > forward traffic from the concerned ISP's IP addresses, it is "better > than nothing". It is a working 3rd party service that the concerned ISP > is disrupting. In some countries this can even be illegal unless a > provision is made in the contract to allow such blocking. You're saying that if the service is unstable or has a large latency, the user might still be better off than using IPv4? I think there has been a very strong consensus on the list against that view. Again, we'd better see what the WG Chairs think. > > I agree only with the part that if: > a) 192.88.99.1 address does not respond, > b) does not provide 6to4 service that works, or > c) the isp customers are all using bogonized addresses [you could think > this as a special case of b)] > > .. then it is known that, at least at that particular moment, the > concerned ISP is no worse off by returning ICMP unreachables. > >>> editorial: >>> >>> - references to labs.ripe.net, www.potaroo.net etc. should be filed as >>> informative references not direct URLs in text. >> >> We can leave the RFC Editor to apply their preferred policy for this. > > I think you very well know that this is not RFC editor's preferred policy. Really? They raised no objection to the embedded URLs in RFC 5887, for example. Actually the style guide discourages URLs in general, not URLs in the main text specifically, so I only use URLs when there is no alternative. Brian > > I feel it is irresponsible to push out text (also to the IETF LC and > IESG) that has known editorial irregularities. > From brian.e.carpenter@gmail.com Thu Apr 21 18:06:23 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3DD05E074D for ; Thu, 21 Apr 2011 18:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB2BepGbcpNl for ; Thu, 21 Apr 2011 18:06:22 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 9796BE0718 for ; Thu, 21 Apr 2011 18:06:22 -0700 (PDT) Received: by pxi20 with SMTP id 20so177423pxi.27 for ; Thu, 21 Apr 2011 18:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bhs4Or/pzDuR1yT82+NcFMlr73stTRGE2lGV9rw+Hn8=; b=YZJFF/kKCoigjzZgAfSq2NMteAEomSSxAbjLxu9kCxYE+JRCxioVn2kzbAOqT6OoUl tp67joKtnYMTOSqzcrrtI/pWv7V19VPfBlrF7MCv3KPo9ORm4dd608GjU99XjmQlFP1u 5+nW8CeE+mvjvnF1ZmZl9kGaFY70vnqSg+sak= 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=pQ0LJCSNO8cQqD4P4fwfN6HfWnftO3ro+zY8tSR2UdZgzthpzyszTK7LDxWYDE/pGq fzpxUfSRVaK0i4yq4gJxA0VbkSPFL/wPUAuCDR7JlepRyXK9XpQl06xIygN33H107K/3 e4Wg3HvtLxDfOFI3c59oCBjqz1+qNcRFd74MY= Received: by 10.68.29.104 with SMTP id j8mr783726pbh.448.1303434382065; Thu, 21 Apr 2011 18:06:22 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id g4sm1638028pbt.79.2011.04.21.18.06.19 (version=SSLv3 cipher=OTHER); Thu, 21 Apr 2011 18:06:21 -0700 (PDT) Message-ID: <4DB0D485.1000900@gmail.com> Date: Fri, 22 Apr 2011 13:06:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dmitry Anipko References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:06:23 -0000 On 2011-04-22 06:38, Dmitry Anipko wrote: > Hi Fred, > > The BCP section quoted below says: > > " A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level." > I don't see any qualification of the word "any" in that sentence. So, if the rough consensus here is that it's obsolete, because there are now better ways of obtaining IPv6 connectivity, we could certainly count that as a valid reason for historicisation. As has been made clear, this doesn't cause existing deployments to stop working. Brian From newbery@gmail.com Thu Apr 21 18:06:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2670E0768 for ; Thu, 21 Apr 2011 18:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrXix2KIJxgz for ; Thu, 21 Apr 2011 18:06:55 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 29B15E0766 for ; Thu, 21 Apr 2011 18:06:55 -0700 (PDT) Received: by pzk30 with SMTP id 30so161290pzk.31 for ; Thu, 21 Apr 2011 18:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=+oENP0fkwMIogcoYBppJSo/SA2QB/IsKvzsETF1YeYQ=; b=Wb8OM5p0iUhbj8Iot7giDeqlejx/99wrRorZVmyeQVXEldfHp/bNNkZnrArQIraygX gvJeSwfx99FkKYRUDr3auVj+xx1PxHI8ak3rIxHHMMDmZY3vNDAQRnKLN0tb3JXWfF8q pvuXIDSsMAlHZtZyo9SE1n8VfmjoymL3JT0AM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=IeZbMoIY6o9usyqgQfd1uBOiGsB1Y0By/awsw9//ThTLCXQUepdUKEGtIzNPeOy/7u pjO/QWfUupsqUqQnxPFZt8EWM02bagDWIsHz5JnVWfUSqqPO+ewy/2Agozep28mClULx ISyWTXze6X7tl5QLd98qYHHgW2gbp6Ndc3Inw= Received: by 10.142.173.5 with SMTP id v5mr325593wfe.66.1303434414494; Thu, 21 Apr 2011 18:06:54 -0700 (PDT) Received: from downstairs.internal ([202.37.62.4]) by mx.google.com with ESMTPS id 25sm3208578wfb.22.2011.04.21.18.06.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2011 18:06:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Michael Newbery In-Reply-To: Date: Fri, 22 Apr 2011 13:06:46 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:06:56 -0000 On 21/04/2011, at 5:27 PM, Pekka Savola wrote: > On Thu, 21 Apr 2011, Brian E Carpenter wrote: >>> Section 2.1 on Router 6to4 should be trimmed down, one page is >>> excessive. 6to4 was never deployed as it was initially devised by >>> Carpenter, so text on that is not very useful (most of 1st paragraph = of >>> Section 3 should also go away). The key point is that 6to4 hosts or >>> routers may either configure the relay router IP address or use = anycast. >>=20 >> You made this comment on an earlier version. I disagreed then and I = disagree >> now. It's impossible to understand how the anycast version is = supposed to >> work unless you understand how basic 6to4 is supposed to work, and = the >> situation for the return relay is the same in both cases. I couldn't = find >> anything redundant in the explanation. >=20 > You seem to be arguing that S 2.1 is an overview of 6to4 without = anycast and that such an overview is essential. >=20 > I'd argue that this document does not need to provide a description of = how basic 6to4 or anycast 6to4 works; it is already described in those = documents, and it is not essential in order to understand the rest of = the document. The reader can get the message of the document even if = (s)he isn't very familiar with rfc3056 or rfc3068 even without the = details in Section 2. That way lies madness and ITU standards documentation :) As a personal preference, I VERY much prefer to have a short summary = inline rather than having to jump to a linked document, or worse yet a = chain of linked documents.= From brian.e.carpenter@gmail.com Thu Apr 21 18:23:30 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0282DE0721 for ; Thu, 21 Apr 2011 18:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9iq8YOw-hd5 for ; Thu, 21 Apr 2011 18:23:29 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 26239E0718 for ; Thu, 21 Apr 2011 18:23:29 -0700 (PDT) Received: by pvh1 with SMTP id 1so167914pvh.31 for ; Thu, 21 Apr 2011 18:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CxHkXaFAzi21hYOMlElv5jK8vhIajsndawi3L20bYjA=; b=d7Wfg/I8NbDMMXyXVFou8Zt1tPrUAxCeBqIPChG++XPpsfCbc2Sv95254yfbw67BrK 76kp3bG3L5FkHm+wBAUHhuUV26ShKr3CvYfnRaHEvxAwkGAom3znkV6qgkeaEYbrrAnn YD1zbYHjXgk0Aro24ObfsQUpGrKD2In1aH758= 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=NCsZCN5Dw2GmyemmTPlut88mS84r4yyqp2ECk3Xxsxhy5GtcaamcVvuJC9jMFYvuNQ IdvL+IudV30NPwxWU4zEbjWOEeLC1w9rbdfIGZXVlyqB3IXGSzO35ivyhBYP0OQiwwM5 PqHAjDavKTY1o8mZHQQZJ9CgM2bHI2KctZvcc= Received: by 10.142.150.27 with SMTP id x27mr321082wfd.221.1303435408222; Thu, 21 Apr 2011 18:23:28 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id k6sm3231803wfa.5.2011.04.21.18.23.26 (version=SSLv3 cipher=OTHER); Thu, 21 Apr 2011 18:23:27 -0700 (PDT) Message-ID: <4DB0D889.2060309@gmail.com> Date: Fri, 22 Apr 2011 13:23:21 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie><4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com><4DAEA916.90908@inex.ie> <4DAF6CA7.6030905@gmail.com> <4269EA985EACD24987D82DAE2FEC62E5037FCE5F@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E5037FCE5F@XMB-AMS-101.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:23:30 -0000 On 2011-04-20 21:36, Nick Hilliard wrote: ... >>> I suggest that if Ole feels that a formal end-date for removal of >>> 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we >>> create a very small new ID which explicitly states a date on which IANA >>> formally deregisters both prefixes and requests that operators filter >>> them from the DFZ. It's not a biggie, but if it's what's needed to get >>> vendors to ditch support, then let's just be pragmatic and do it. >> It would be a biggie and I would oppose it very strongly. This would >> break deployed systems and we should never, ever do that. > Alas, despite notable voices of opposition, I suspect that consensus can > be formed in IETF around the swift and merciless breaking of all the > deployed and otherwise working 6to4 systems in exchange for facilitating > the rollout of more commercially viable IPv6 services. I think you will be surprised. However, I realised that we are arguing about very little. From the very beginning of 6to4, it has been stated that great care is needed in scoping announcements of 2002::/16 (i.e. the route to a return relay). In fact, this in effect an anycast prefix. I quote from RFC 3056: It is a matter of routing policy how far this routing advertisement of 2002::/16 is propagated in the native IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require to filter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns. In other words, it has always been the case that 2002::/16 should not be propagated blindly across the DFZ and should be filtered accordingly. Nothing new here. As far as a route to 192.88.99.1 goes, the same applies - as for any anycast address, it should not be propagated blindly outside the scope of its intended users. Anyone injecting it into the DFZ is asking for trouble. I hope that the guidance in -historic already makes this clear. Brian > > I plan to submit a draft soon that specifies a formal phaseout plan for > 6to4, and we shall see how much opposition is really out there. If > consensus can emerge in IETF around a formal phaseout plan, then we will > all save a lot of time and energy that we would otherwise spend > maintaining and improving support for 6to4 in forthcoming host and > router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic > is published in the RFC series or not. From fred@cisco.com Thu Apr 21 19:22:19 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26D42E0756 for ; Thu, 21 Apr 2011 19:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.546 X-Spam-Level: X-Spam-Status: No, score=-110.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD0OCH+mflvw for ; Thu, 21 Apr 2011 19:22:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 68496E0753 for ; Thu, 21 Apr 2011 19:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=623; q=dns/txt; s=iport; t=1303438938; x=1304648538; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=5xqGMwuzcaXLur88iUo1nWc4LGQlU9liepxmAUfFxtQ=; b=TteFScYDFBkdcoNWtn6aK8B8U50flcqzBIz1AgO0J8AHXZ4Oxdh295Ut WPcqmXTykEDAcv45IyACbAg11V7EB+Pnf5HIXueNHGJc2sOLVXJvLNCHw FtqfjA5wdHpU+67tPvUN97aEHRvzGKuTbIq5SmuZ4YcRr/9i6y/TR7gcB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKnlsE2rRDoJ/2dsb2JhbAClXHeIcJ5CnGOFdgSFdIg4hAc X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="299726618" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2011 02:22:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3M2MCCJ031715; Fri, 22 Apr 2011 02:22:17 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 21 Apr 2011 19:22:17 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 21 Apr 2011 19:22:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DB0D038.6050503@gmail.com> Date: Thu, 21 Apr 2011 19:22:01 -0700 Message-Id: <78B8C302-2066-42D8-B298-BAE6FDA1F1FA@cisco.com> References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> <4DB0D038.6050503@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:22:19 -0000 On Apr 21, 2011, at 5:47 PM, Brian E Carpenter wrote: >> I'd argue that this document does not need to provide a description = of >> how basic 6to4 or anycast 6to4 works; it is already described in = those >> documents, and it is not essential in order to understand the rest of >> the document. The reader can get the message of the document even if >> (s)he isn't very familiar with rfc3056 or rfc3068 even without the >> details in Section 2. >=20 > Well, we disagree, so we'd better see what the WG Chairs think. Speaking for myself, I have no issue in this regard with the document as = it stands.= From brian.e.carpenter@gmail.com Thu Apr 21 19:23:45 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0A2C9E0753 for ; Thu, 21 Apr 2011 19:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMYBL3j3wl3t for ; Thu, 21 Apr 2011 19:23:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 37615E06E2 for ; Thu, 21 Apr 2011 19:23:44 -0700 (PDT) Received: by pvh1 with SMTP id 1so190132pvh.31 for ; Thu, 21 Apr 2011 19:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TMyJlf0Bw0A0byD+52mVm2Vgk5cnvFfKEUfggJ88ofA=; b=E/uE4itr+J7jm1TgYJ1AEy2UaZnEiNhY5nIzln1+pMMwjYXkbkbYKZdcyBT5wYQtRh QOXZrKuNutdWhA9RgiH3JZfjSFM5oXW44A5ix0MJ/0a5gpCFQ4LTK1Jsn4fp521oWKXb RYt49OeyGb9D8HMsQl4q+1er7Vg2CeMtycLPw= 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=n1tLKSx/OsJadsIIh3gwBuJIirqZjpygpd0XsmoNdrgGIoZTehuIOKf07ScSJYbYLm m9X2img7/CqVDFORfJfceqh6XCC/FMDB+6T1ONNTgkIOdzm0n5XwMO9uqdHGZx5Rojg6 gOujL3scg8d7K9dg1w9titOOMS3jkzuggrz70= Received: by 10.68.65.199 with SMTP id z7mr927856pbs.341.1303439023589; Thu, 21 Apr 2011 19:23:43 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id j3sm1677540pbb.83.2011.04.21.19.23.40 (version=SSLv3 cipher=OTHER); Thu, 21 Apr 2011 19:23:42 -0700 (PDT) Message-ID: <4DB0E6A7.4080505@gmail.com> Date: Fri, 22 Apr 2011 14:23:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><4DAC432B.90403@inex.ie><4269EA985EACD24987D82DAE2FEC62E5037FCA1D@XMB-AMS-101.cisco.com><4DAEA916.90908@inex.ie> <4DAF6CA7.6030905@gmail.com> <4269EA985EACD24987D82DAE2FEC62E5037FCE5F@XMB-AMS-101.cisco.com> <4DB0D889.2060309@gmail.com> In-Reply-To: <4DB0D889.2060309@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:23:45 -0000 Oops... silly mistake below: On 2011-04-22 13:23, Brian E Carpenter wrote: > On 2011-04-20 21:36, Nick Hilliard wrote: > ... > >>>> I suggest that if Ole feels that a formal end-date for removal of >>>> 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we >>>> create a very small new ID which explicitly states a date on which IANA >>>> formally deregisters both prefixes and requests that operators filter >>>> them from the DFZ. It's not a biggie, but if it's what's needed to get >>>> vendors to ditch support, then let's just be pragmatic and do it. > >>> It would be a biggie and I would oppose it very strongly. This would >>> break deployed systems and we should never, ever do that. > > >> Alas, despite notable voices of opposition, I suspect that consensus can >> be formed in IETF around the swift and merciless breaking of all the >> deployed and otherwise working 6to4 systems in exchange for facilitating >> the rollout of more commercially viable IPv6 services. > > I think you will be surprised. However, I realised that we are arguing > about very little. From the very beginning of 6to4, it has been stated > that great care is needed in scoping announcements of 2002::/16 (i.e. the > route to a return relay). In fact, this in effect an anycast prefix. > I quote from RFC 3056: > > It is a matter of routing policy how > far this routing advertisement of 2002::/16 is propagated in the > native IPv6 routing system. Since there will in general be multiple > relay routers advertising it, network operators will require to > filter it in a managed way. Incorrect policy in this area will lead > to potential unreachability or to perverse traffic patterns. > > In other words, it has always been the case that 2002::/16 should not > be propagated blindly across the DFZ and should be filtered accordingly. > Nothing new here. > > As far as a route to 192.88.99.1 goes, the same applies - as for > any anycast address, it should not be propagated blindly outside the > scope of its intended users. Anyone injecting it into the DFZ is > asking for trouble. > > I hope that the guidance in -historic already makes this clear. s/-historic/-advisory/ > > Brian > > > > >> I plan to submit a draft soon that specifies a formal phaseout plan for >> 6to4, and we shall see how much opposition is really out there. If >> consensus can emerge in IETF around a formal phaseout plan, then we will >> all save a lot of time and energy that we would otherwise spend >> maintaining and improving support for 6to4 in forthcoming host and >> router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic >> is published in the RFC series or not. > From gvandeve@cisco.com Fri Apr 22 02:14:42 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A903E0692 for ; Fri, 22 Apr 2011 02:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.987 X-Spam-Level: X-Spam-Status: No, score=-9.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noWYNpSbVbol for ; Fri, 22 Apr 2011 02:14:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 4C8B4E0661 for ; Fri, 22 Apr 2011 02:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1832; q=dns/txt; s=iport; t=1303463681; x=1304673281; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+3nzHkVpNwCeZ6DXy0MbgWuNtyhFXMVdZNknF5+xWBU=; b=mFJPoUPpYDJjTRXO7EX7iKwbxF6ekBnLMDP75sXU3M3TiZG+D+M51J5N 8PiXoTDVE7OoulBKT88p3nnVyiu6MMhQLZyQUjo2nExAzv1v+w6fdvflo s0/P/Ra7j58lanmJ6kSiKlBO68KFZPC1siqa2hVCEJj+aYIPDWBqBWVpu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcEAEVGsU2Q/khLgWdsb2JhbAClXhQBARYmJYhwnUGcXoV2BJI7 X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="84708112" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2011 09:14:40 +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 p3M9Eeeh023294; Fri, 22 Apr 2011 09:14:40 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); Fri, 22 Apr 2011 11:14:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 11:14:38 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FD0C5@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC Thread-Index: AcwAia7epPLwyvl9Tcy61BPvzSL11AAQ/ZbA References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com><4DAF68E7.6000201@gmail.com> From: "Gunter Van de Velde (gvandeve)" To: "Michael Newbery" , X-OriginalArrivalTime: 22 Apr 2011 09:14:40.0188 (UTC) FILETIME=[B598AFC0:01CC00CD] Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 09:14:42 -0000 Inline: GV>=20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Michael Newbery Sent: 22 April 2011 03:07 To: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC On 21/04/2011, at 5:27 PM, Pekka Savola wrote: > On Thu, 21 Apr 2011, Brian E Carpenter wrote: >>> Section 2.1 on Router 6to4 should be trimmed down, one page is >>> excessive. 6to4 was never deployed as it was initially devised by >>> Carpenter, so text on that is not very useful (most of 1st paragraph of >>> Section 3 should also go away). The key point is that 6to4 hosts or >>> routers may either configure the relay router IP address or use anycast. >>=20 >> You made this comment on an earlier version. I disagreed then and I disagree >> now. It's impossible to understand how the anycast version is supposed to >> work unless you understand how basic 6to4 is supposed to work, and the >> situation for the return relay is the same in both cases. I couldn't find >> anything redundant in the explanation. >=20 > You seem to be arguing that S 2.1 is an overview of 6to4 without anycast and that such an overview is essential. >=20 > I'd argue that this document does not need to provide a description of how basic 6to4 or anycast 6to4 works; it is already described in those documents, and it is not essential in order to understand the rest of the document. The reader can get the message of the document even if (s)he isn't very familiar with rfc3056 or rfc3068 even without the details in Section 2. That way lies madness and ITU standards documentation :) As a personal preference, I VERY much prefer to have a short summary inline rather than having to jump to a linked document, or worse yet a chain of linked documents. GV> +1 From gvandeve@cisco.com Fri Apr 22 02:25:56 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C977E0661 for ; Fri, 22 Apr 2011 02:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.718 X-Spam-Level: X-Spam-Status: No, score=-9.718 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1aQ1UQidF8k for ; Fri, 22 Apr 2011 02:25:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id E1AF2E071F for ; Fri, 22 Apr 2011 02:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=3787; q=dns/txt; s=iport; t=1303464355; x=1304673955; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qdOH3Zpxm3Y0osz0jlHgvaNVcmLhwFQZ4gaMzUPVmO8=; b=hLrntpcRp5sP2jWibmOgvMplssy+6nQZ3cAcMBenM9QgU0SIUKuNRBCO vL7B0KqB/R2Yx+Ws8/sMUHTztQgLp9lqyidq1NZPWRVgRjoPliLxezd3E yK1y+3rvrnsLLw0t1BNfsS99EcRGLXAFHqu3f6sGrAY7SIEywT9FlKknQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAKVIsU2Q/khMgWdsb2JhbACXU44LFAEBFiYliHCdMZxfhXYEkjs X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="84709224" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2011 09:25:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3M9Ps9l013064; Fri, 22 Apr 2011 09:25:54 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:25:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 11:25:51 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5037FD0CB@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AcwAW70caCXQtNQ8RkexPCH1MBlXUgAAFUzwABywzNA= References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com><2FCA592C-C56E-4368-A1C6-3AC0E43A28AA@cisco.com><4FCC2593-E742-42AA-9ADE-DEE1CC9577EF@cisco.com><3E88D92A-242A-4E76-8E83-D66D3D31EAAB@cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Dmitry Anipko" , "Fred Baker (fred)" X-OriginalArrivalTime: 22 Apr 2011 09:25:54.0119 (UTC) FILETIME=[474A6570:01CC00CF] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 09:25:56 -0000 There is indeed a plan to boil TEREDO in similar matter, but as its less used at this point in time as 6to4 and mainly by particular OS's its of slightly lower priority to write a draft about it. In general same rules apply for both advisory and deprecation for TEREDO as is there for 6to4. (Dave T. might disagree though as he mentioned something about that during last IETF meeting)=20 G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Dmitry Anipko Sent: 21 April 2011 21:50 To: Fred Baker (fred) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Hello Fred, >> Are you referring to RFC 2026 as a BCP? Yes, since it has category " Category: Best Current Practice". Sorry if this was confusing, I should have used RFC 2026 as a pointer. >> I wouldn't want to, for example, discover that there was consensus to take one to Historic and not the other, and as a result of having them in the same draft find that we couldn't do that which we actually had consensus to do. I don't know if there is consensus on moving 6to4 to historic, but to comment on your point: if one follows the justification you suggested (native supersedes tunnels), as I understand, that justification would equally apply to 6to4 and Teredo. And if that's not the case and there are some reasons why it doesn't apply to Teredo, I'd like to see analysis of why it doesn't, and whether those reasons apply to 6to4.=20 That is what my feedback was - I think the current draft lacks listing of specific reasons what's wrong with RFC 3056 as a whole. Once such analysis is added, and the draft shows why those issues aren't mitigated by other proposals, which already exist (such as e.g. RFC 3484 revision), I think it would gain broader support. Thank you, Dmitry -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Thursday, April 21, 2011 12:38 PM To: Dmitry Anipko Cc: Pekka Savola; v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Apr 21, 2011, at 12:30 PM, Dmitry Anipko wrote: > Hello Fred, >=20 >>> Well, yes, it's not updating the standard. It's saying that the standard should be superseded by native deployment. >=20 > As far as I see you agree that that particular BCP wording doesn't apply there, since there is no superseding specification. So I fail to see how that wording can be used to support moving RFC 3056 to historic status.=20 I'm hard pressed to see what "BCP" has to do with this. Are you referring to RFC 2026 as a BCP? > But even if that wording did apply, and native deployment could be considered as superseding 6to4 (and IPv6 offering apparently is not yet widely available to customers), then from that prospective I think native deployment would also supersede Teredo as well as other automatic IPv6 over IPv4 tunnels - but the draft doesn't propose that (perhaps there are other drafts I'm not aware of), and moving only 6to4 to historic would not be consistent. I personally would be very much in favor of making the same statement about Teredo. You might read http://www.potaroo.net/ispcol/2011-04/teredo.html, and specifically the portions on measuring Teredo behavior and performance. That said, I think it's a separate decision than the 6to4 decision. I wouldn't want to, for example, discover that there was consensus to take one to Historic and not the other, and as a result of having them in the same draft find that we couldn't do that which we actually had consensus to do. > Thank you, > Dmitry >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From sthaug@nethelp.no Sat Apr 23 09:08:31 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7888CE0714 for ; Sat, 23 Apr 2011 09:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB3GE4e6j0po for ; Sat, 23 Apr 2011 09:08:31 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfc.amsl.com (Postfix) with SMTP id 78D69E0706 for ; Sat, 23 Apr 2011 09:08:30 -0700 (PDT) Received: (qmail 68908 invoked from network); 23 Apr 2011 16:08:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 23 Apr 2011 16:08:28 -0000 Date: Sat, 23 Apr 2011 18:08:28 +0200 (CEST) Message-Id: <20110423.180828.74727913.sthaug@nethelp.no> To: pekkas@netcore.fi From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 16:08:31 -0000 > > It might make sense, if that statement is confusing, to remove the > > statement. I think the authors are trying to be pragmatic - "we > > understand that all software in the world isn't going to change > > overnight; as it changes, this is the direction we'd like it to go". > > Then what is the point of this document again? > > James said it pretty well [1] > > "When I briefed my managers about this draft, I told them that it > currently requires us to do absolutely nothing in the foreseeable > future, and it explicitly permits us to continue doing what we are > doing today. My reading of the document suggests that you can safely > ignore its current form as well." The reference to James Woodyatt's statement has been used multiple times as an argument for why this draft is unnecessary. Howeve, he has also stated that current Apple products do *not* come with 6to4 enabled by default. Both draft-ietf-v6ops-6to4-to-historic and -advisory say that 6to4 should not be enabled by default. Maybe a manufacturer shipping products with 6to4 enabled by default would feel differently about these documents than a manufacturer where the default is off? In any case, I think it's quite clear that we need to get a document out which says in no uncertain terms that 6to4 should not be enabled by default. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From joelja@bogus.com Sat Apr 23 10:48:13 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1EE85E072C for ; Sat, 23 Apr 2011 10:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vUE8METy5cs for ; Sat, 23 Apr 2011 10:48:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id 86EA5E0680 for ; Sat, 23 Apr 2011 10:47:53 -0700 (PDT) Received: from [192.168.43.44] (m340536d0.tmodns.net [208.54.5.52]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p3NHliNc093202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 23 Apr 2011 17:47:48 GMT (envelope-from joelja@bogus.com) Message-ID: <4DB3086E.5070205@bogus.com> Date: Sat, 23 Apr 2011 10:12:14 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mikael Abrahamsson References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> 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]); Sat, 23 Apr 2011 17:47:50 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 17:48:13 -0000 On 4/18/11 11:04 AM, Mikael Abrahamsson wrote: > On Mon, 18 Apr 2011, james woodyatt wrote: > >> Yes. I cannot support this draft unless it has an explicit phaseout >> plan for 2002::/16 included. If you want to send a signal to >> equipment makers that they should remove 6to4 routing functions from >> their future product plans, then you need to include a phaseout plan >> for it. Otherwise, you are engaging in a pointless exercise, and it >> won't happen. > > Could you please elaborate as to why? Not working for an equipment > vendor, I don't get why there needs to be a firm phaseout plan. I never > saw a phaseout plan for RIPv1. The idea of a a point as which the numbering resources enter a different state than the one that they currently have is plausible and perhaps reasonable to stake out... As with ripv1 to keep using that example however some set of devices currently using it will continue to do so until they can't anymore... That number may be vanishingly small ultimately (there are still devices doing ripv1). From dougb@dougbarton.us Sat Apr 23 11:03:25 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F31E3E0680 for ; Sat, 23 Apr 2011 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtIc8v3Ojauy for ; Sat, 23 Apr 2011 11:03:24 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfc.amsl.com (Postfix) with ESMTP id 44FC9E067C for ; Sat, 23 Apr 2011 11:03:24 -0700 (PDT) Received: (qmail 8270 invoked by uid 399); 23 Apr 2011 18:03:18 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 23 Apr 2011 18:03:18 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DB31464.7010602@dougbarton.us> Date: Sat, 23 Apr 2011 11:03:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Joel Jaeggli References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DAC432B.90403@inex.ie> <4DB3086E.5070205@bogus.com> In-Reply-To: <4DB3086E.5070205@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: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 18:03:25 -0000 On 04/23/2011 10:12, Joel Jaeggli wrote: > As with ripv1 to keep using that example however some set of devices > currently using it will continue to do so until they can't anymore... > That number may be vanishingly small ultimately (there are still devices > doing ripv1). Isn't 6bone a better example? -- 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 rogerj@gmail.com Sat Apr 23 12:10:38 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0F798E072E for ; Sat, 23 Apr 2011 12:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDvUwazdcyZG for ; Sat, 23 Apr 2011 12:10:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id B8789E06A8 for ; Sat, 23 Apr 2011 12:10:36 -0700 (PDT) Received: by iyn15 with SMTP id 15so617410iyn.31 for ; Sat, 23 Apr 2011 12:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=1SrvD1ZiFWaYtER6Zs41I++Myldisrl610Kz4jk8oqw=; b=cdcCf3ErS4rbEi175oH0KlFkphoaLgq5LONzbZT328m/bbcKWDzRrXAZcp26RFUH1V oMIxniI6CV6iDCCF5xjm0ZuzQma0FHGgUIeIpw8I4ToVCzXZ3Wic7Wc4/5XukkRJd/RT X0Fqm8QD0ZQj40TifZDmKEn7Fm70hjvQid4R8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=OWjHmtTrxVZcVtHarw3aLjuDad8c6W35AgPaTSRcFHqaBkyNtjO/g0Gz5HzjrneW79 yBmWcnnVj6ErnbtSpWP26pdSy124ZFBMnL4cvzggHUYMPINntirU/PPQaZVEksvPElHH b88OFdwWEUjHGKIuRr5qwIK3U5euUqxmZAgEU= MIME-Version: 1.0 Received: by 10.231.79.131 with SMTP id p3mr1688463ibk.191.1303585835863; Sat, 23 Apr 2011 12:10:35 -0700 (PDT) Received: by 10.231.19.141 with HTTP; Sat, 23 Apr 2011 12:10:35 -0700 (PDT) Date: Sat, 23 Apr 2011 21:10:35 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Fred Baker , v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Problem with delivering of mail - Fwd: Undelivered Mail Returned to Sender X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 19:10:38 -0000 seems like there was something up with the mail for a while... ---------- Forwarded message ---------- From: Mail Delivery System Date: Sat, Apr 23, 2011 at 7:22 PM Subject: Undelivered Mail Returned to Sender To: rogerj@gmail.com This is the mail system at host ietfc.amsl.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The mail system : mail forwarding loop for v6ops@ietfc.amsl.com Final-Recipient: rfc822; v6ops@ietfc.amsl.com Original-Recipient: rfc822;v6ops@ietf.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for v6ops@ietfc.amsl.com ---------- Forwarded message ---------- From:=A0"Roger J=F8rgensen" To:=A0"v6ops@ietf.org" Date:=A0Thu, 21 Apr 2011 10:04:37 +0200 Subject:=A0Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC On Wed, Apr 20, 2011 at 9:40 PM, Dmitry Anipko wrote: >>> remove that particular option from the table when a user, operator or v= endor is considering what should be deployed/implemented... > > I agree that once majority of customers indeed have a choice whether to s= ubscribe to their ISP IPV6 offering, 6to4 will no longer be needed. But are= we there yet? The interesting thing about this entire 6to4 discussing is that there is pretty much two sides * Those that wish 6to4 gone because it cause more problem than it solve, they also consider it too costly to fix considering other options. * Then there is the "other" side that is interesting... that is MS and Apple which want to give their customer IPv6 which is great, I can't praise those companies enough for their effort on IPv6. Espesial Microsoft and their efford over the last 10+ years. But, isn't it time to move on, beyond IPv6 access for any cost and to a place where we say either Good IPv6 access or none? -- 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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --=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 jhw@apple.com Sat Apr 23 15:48:08 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F027DE0663 for ; Sat, 23 Apr 2011 15:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.678 X-Spam-Level: X-Spam-Status: No, score=-106.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm5BYeD7kOoE for ; Sat, 23 Apr 2011 15:48:08 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 73D32E0613 for ; Sat, 23 Apr 2011 15:48:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK400MI7NC0DAV0@mail-out.apple.com> for v6ops@ietf.org; Sat, 23 Apr 2011 15:48:07 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-c4-4db357273e2f Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id C6.59.29082.72753BD4; Sat, 23 Apr 2011 15:48:07 -0700 (PDT) Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LK4007BKNC6WT70@cardamom.apple.com> for v6ops@ietf.org; Sat, 23 Apr 2011 15:48:07 -0700 (PDT) From: james woodyatt In-reply-to: <20110423.180828.74727913.sthaug@nethelp.no> Date: Sat, 23 Apr 2011 15:48:07 -0700 Message-id: <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com> References: <20110423.180828.74727913.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1216) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 22:48:09 -0000 On Apr 23, 2011, at 9:08 AM, sthaug@nethelp.no wrote: > In any case, I think it's quite clear that we need to get a document > out which says in no uncertain terms that 6to4 should not be enabled > by default. I thought 6to4-advisory already said that. If it doesn't perhaps Brain could be persuaded to amend it. It's good advice for all the reasons described in that document. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Sat Apr 23 16:08:02 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DB4DE0701 for ; Sat, 23 Apr 2011 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.146 X-Spam-Level: X-Spam-Status: No, score=-103.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+ZG2G1hxd0c for ; Sat, 23 Apr 2011 16:08:02 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id D572AE06F9 for ; Sat, 23 Apr 2011 16:07:59 -0700 (PDT) Received: by pzk30 with SMTP id 30so1037111pzk.31 for ; Sat, 23 Apr 2011 16:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JJWpMjrqpcJ8/R3YnBcJCRUZQZJ7vaAZBVTBlvLukpM=; b=lx/ycK6IrFH1PcQXuI2SyZt7kwcfCnwMm4mit1IIQOhnMagXUu57X7G5izc4COHo/g /vTQlfjTWsknKNuTNzvIx772gCX6ZKlsDyHsfXBik6J0vFPcOWozH1h/UT9VB9kvm2VA 6laVV7Blb1vQJEhIJLaiOzLvXZsy9mnpIfrTk= 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=TtAGLhDgPIEqbdUrl1Iw3UAcnw+10F973yUMtvnNxg/n6UD/X5xfDA2b/1kzLU5aC9 VS8MXXp/gwcy3VRF7nLfPpHzJkZSbeA8+zKA0cL+eLVPm80ghgBmH0gnKg24Z8Gz966W tXcTnGSuI8384rSnIo1qf84qV0OL1qFeCdtPM= Received: by 10.143.20.3 with SMTP id x3mr1483945wfi.159.1303600077098; Sat, 23 Apr 2011 16:07:57 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id j2sm637687pbo.79.2011.04.23.16.07.54 (version=SSLv3 cipher=OTHER); Sat, 23 Apr 2011 16:07:56 -0700 (PDT) Message-ID: <4DB35BC7.8090807@gmail.com> Date: Sun, 24 Apr 2011 11:07:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <20110423.180828.74727913.sthaug@nethelp.no> <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com> In-Reply-To: <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 23:08:02 -0000 On 2011-04-24 10:48, james woodyatt wrote: > On Apr 23, 2011, at 9:08 AM, sthaug@nethelp.no wrote: > >> In any case, I think it's quite clear that we need to get a document >> out which says in no uncertain terms that 6to4 should not be enabled >> by default. > > I thought 6to4-advisory already said that. Yes, but it's not a normative document and by its nature can't be. In my experience, some product managers rely on formal normative language rather than engaging their Brain. Brian If it doesn't perhaps Brain could be persuaded to amend it. It's good advice for all the reasons described in that document. > > > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From martin@millnert.se Sat Apr 23 16:14:55 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7D34E0613 for ; Sat, 23 Apr 2011 16:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8A-KVXJ7JTw for ; Sat, 23 Apr 2011 16:14:55 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfc.amsl.com (Postfix) with ESMTP id F0A2CE0611 for ; Sat, 23 Apr 2011 16:14:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 29CB777F0; Sun, 24 Apr 2011 01:30:05 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVaq6mnjeKgT; Sun, 24 Apr 2011 01:30:05 +0200 (CEST) Received: from [192.168.8.9] (unknown [76.14.60.12]) by ncis.csbnet.se (Postfix) with ESMTPSA id ED68E771E; Sun, 24 Apr 2011 01:30:03 +0200 (CEST) From: Martin Millnert To: james woodyatt In-Reply-To: <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com> References: <20110423.180828.74727913.sthaug@nethelp.no> <04463D0E-CE36-4A40-8273-72EB61D3DE6C@apple.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 23 Apr 2011 19:14:46 -0400 Message-ID: <1303600486.3205.10.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 23:14:55 -0000 Some short-circuiting below. On Sat, 2011-04-23 at 15:48 -0700, james woodyatt wrote: > On Apr 23, 2011, at 9:08 AM, sthaug@nethelp.no wrote: > > > In any case, I think it's quite clear that we need to get a document > > out which says in no uncertain terms that 6to4 should not be enabled > > by default. > > I thought 6to4-advisory already said that. If it doesn't perhaps Brain could be persuaded to amend it. It's good advice for all the reasons described in that document. > On Thu, 2011-04-14 at 19:30 +1200, Brian E Carpenter wrote: > On 2011-04-14 08:48, Martin Millnert wrote: > > > > > 3. Disabling automatic 6to4-enabling on hosts would be good, too, > > like you say (virtually everyone seems to agree about this?). > > > > Brian, 4.1 in draft-ietf-v6ops-6to4-advisory-00: "This is bad > > practice - it should always be a conscious decision by a user to > > enable 6to4." > > Would you have a comment on increasing the usage of 2119-wording in > > the draft? Is a change of the above "should" to "MUST" > > inappropriate, the draft being a advisory text, and all? > > Well, it will get published a lot quicker if it is kept as an > Informational draft without formal language. > > I think you should raise this comment against > draft-ietf-v6ops-6to4-to-historic-00.txt, which says: > > "2. Implementations capable of acting as 6to4 routers SHOULD NOT > enable 6to4 without explicit user configuration. > ... > 3. If implemented in future products 6to4 SHOULD be disabled by > default" > > Brian Regards, Martin From tjc@ecs.soton.ac.uk Sun Apr 24 09:06:21 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96101E0699 for ; Sun, 24 Apr 2011 09:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VixTtXyYdLFU for ; Sun, 24 Apr 2011 09:06:20 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfc.amsl.com (Postfix) with ESMTP id 3BFB2E0674 for ; Sun, 24 Apr 2011 09:06:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p3OG6HOl003907 for ; Sun, 24 Apr 2011 17:06:17 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p3OG6HOl003907 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1303661178; bh=4i6zzmToJ7SvGak1hElkoWFOBTg=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Z2u1bZYy6NCJoaDyHE86nr9xqcoIvZLCsJEB2Ny7ZkJpdsOQy5acqqsPj+TjyuOdf 5axsrA9OaYIlmJWKeRCIq+btpz3L5PTA5BzmNTRa1Q7rF+hf5M5d3XTLio/Ll2V2ae HiGOrD9ToaXsbeUitZTKqZdQIDs7coK1udd2BTXE= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n3NH6H0035631597YX ret-id none; Sun, 24 Apr 2011 17:06:17 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p3OG4tmf017927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 24 Apr 2011 17:04:55 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) From: Tim Chown In-Reply-To: Date: Sun, 24 Apr 2011 17:04:54 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <31219CFD-340E-49B7-ABEF-66A76CEC857F@ecs.soton.ac.uk> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n3NH6H003563159700; tid=n3NH6H0035631597YX; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p3OG6HOl003907 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Problem with delivering of mail - Fwd: Undelivered Mail Returned to Sender X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 16:06:21 -0000 I dropped off a few iETF lists last week due - I was told by the = ietf-action people - to an IPv6-specific problem on the list server. = We have dual-stack MXs and this is the first significant mail problem = we've experienced due to IPv6 (that we know about at least :) However, it's good that the IETF lists do run IPv6; I'd rather have the = occasional minor inconvenience than the IETF turning IPv6 off. Tim On 23 Apr 2011, at 20:10, Roger J=F8rgensen wrote: > seems like there was something up with the mail for a while... >=20 >=20 > ---------- Forwarded message ---------- > From: Mail Delivery System > Date: Sat, Apr 23, 2011 at 7:22 PM > Subject: Undelivered Mail Returned to Sender > To: rogerj@gmail.com >=20 >=20 > This is the mail system at host ietfc.amsl.com. >=20 > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. >=20 > For further assistance, please send mail to postmaster. >=20 > If you do so, please include this problem report. You can > delete your own text from the attached returned message. >=20 > The mail system >=20 > : mail forwarding loop for v6ops@ietfc.amsl.com >=20 > Final-Recipient: rfc822; v6ops@ietfc.amsl.com > Original-Recipient: rfc822;v6ops@ietf.org > Action: failed > Status: 5.4.6 > Diagnostic-Code: X-Postfix; mail forwarding loop for = v6ops@ietfc.amsl.com >=20 >=20 > ---------- Forwarded message ---------- > From: "Roger J=F8rgensen" > To: "v6ops@ietf.org" > Date: Thu, 21 Apr 2011 10:04:37 +0200 > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC > On Wed, Apr 20, 2011 at 9:40 PM, Dmitry Anipko > wrote: > >=20 >>>> remove that particular option from the table when a user, operator = or vendor is considering what should be deployed/implemented... >>=20 >> I agree that once majority of customers indeed have a choice whether = to subscribe to their ISP IPV6 offering, 6to4 will no longer be needed. = But are we there yet? >=20 >=20 > The interesting thing about this entire 6to4 discussing is that there > is pretty much two sides >=20 >=20 > * Those that wish 6to4 gone because it cause more problem than it > solve, they also consider it too costly to fix considering other > options. >=20 >=20 > * Then there is the "other" side that is interesting... that is MS and > Apple which want to give their customer IPv6 which is great, I can't > praise those companies enough for their effort on IPv6. Espesial > Microsoft and their efford over the last 10+ years. >=20 >=20 >=20 > But, isn't it time to move on, beyond IPv6 access for any cost and to > a place where we say either Good IPv6 access or none? >=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 >=20 >=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 joelja@bogus.com Sun Apr 24 14:01:08 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F20DDE06D3 for ; Sun, 24 Apr 2011 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2h9PWNaRYUT for ; Sun, 24 Apr 2011 14:01:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfc.amsl.com (Postfix) with ESMTP id 566C4E0613 for ; Sun, 24 Apr 2011 14:01:08 -0700 (PDT) Received: from 23173jjaeggli.local (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 p3OL13Fr001691 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 24 Apr 2011 21:01:04 GMT (envelope-from joelja@bogus.com) Message-ID: <4DB48F8F.9070207@bogus.com> Date: Sun, 24 Apr 2011 14:01:03 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Michael Newbery References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.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]); Sun, 24 Apr 2011 21:01:05 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 21:01:09 -0000 On 4/19/11 3:15 PM, Michael Newbery wrote: > > Not at all. Getting people to upgrade is obviously attractive to the > CPE vendors. I was responding to the suggestion that these vendors > would upgrade EXISTING equipment, even if they could, and pointing > out that there doesn't seem to be any obvious financial incentive for > the CPE vendors to do so. The actual rate at which people upgrade the software on their cpe is pretty much down in the weeds... Embedded devices are out of site /mind and don't get attention until something is geniunely wrong with them... if you're lucky the uptake on software updates is maybe 5% (speaking from the experience of working for a mobile phone vendor) until you deploy automated mechanisms that don't require much (or anything) in the way of prompting, that has it's own perils of course (just ask microsoft or nokia what happens when you brick some fraction of the devices in the field) > Certainly over the next few years we can hope that new equipment will > do the right thing. Having said which, if you were to go out to the > store RIGHT NOW and buy a residential gateway that does native IPv6, > how easy would that be? look for the logo... if you go to frys, you'll see a few, they aren't the $49 one on the endcap, but there are other reasons to upgrade, e.g. gigabit ethernet, 802.11n, print server, wap2 etc. > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From newbery@gmail.com Sun Apr 24 16:06:02 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B81DE06C8 for ; Sun, 24 Apr 2011 16:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI3+uNf6LJil for ; Sun, 24 Apr 2011 16:06:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 68B6FE0679 for ; Sun, 24 Apr 2011 16:06:01 -0700 (PDT) Received: by pzk30 with SMTP id 30so1379454pzk.31 for ; Sun, 24 Apr 2011 16:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=+6fn65P2SFjfn/5DTG8C3ok25Qiu2JbmUhIAy1+I9AU=; b=QxFJUnYdSpnhLKcs8AV6Bx+ieXgKqr42YINNpx+bmsvl2VMoe6RX+N1kQH0GhmtNAS MtVdqZhCrp798tDSeKO5FJb0YZUATollfrZsd5Gf+oTKTXCPx2svdAft5J4xsN+4+Zs/ JNnFaGN6z5rcSNR2y/fhnGmcwnCibYANp8UQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=G0Mb1FXRp54ryKBurRKX4VhLlTkF2UgrwAE5pAkNZxnB2+NISQHIRLWGFD8jMiZhNL kriGojtzfbKTMOhlWbX2tLHdL/8PhnkvDPtusyI+Sa+kjFMC8y4jnie5utXoUO8uxrrQ HPgT3uCEZ3lnHKyCmPFGk+7TywPvuWP+5hzQU= Received: by 10.68.41.67 with SMTP id d3mr5064225pbl.287.1303686360672; Sun, 24 Apr 2011 16:06:00 -0700 (PDT) Received: from downstairs.internal ([202.37.62.4]) by mx.google.com with ESMTPS id a6sm379572pbt.36.2011.04.24.16.05.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Apr 2011 16:05:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Michael Newbery In-Reply-To: <4DB48F8F.9070207@bogus.com> Date: Mon, 25 Apr 2011 11:05:53 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E34C684-E4A4-4C29-AEAB-B03CA16A7A45@gmail.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> <4DB48F8F.9070207@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 23:06:02 -0000 On 25/04/2011, at 9:01 AM, Joel Jaeggli wrote: > On 4/19/11 3:15 PM, Michael Newbery wrote: >=20 >> Certainly over the next few years we can hope that new equipment will >> do the right thing. Having said which, if you were to go out to the >> store RIGHT NOW and buy a residential gateway that does native IPv6, >> how easy would that be? >=20 > look for the logo... if you go to frys, you'll see a few, they aren't > the $49 one on the endcap, but there are other reasons to upgrade, = e.g. > gigabit ethernet, 802.11n, print server, wap2 etc. (Caution, the following may contain rhetoric...) BUt, perhaps more importantly, how would you even know that it did IPv6? = How would the average person know? Since IPv6 is essentially just = network hygiene, most people are going to be unaware of it. If they know = anything, they've heard that IPv4 is about to run out and they need an = IPv6 address? Are they going to look for an "IPv6 Ready" sticker? Are = they going to ask if the new router they purchased does IPv6---or can be = upgraded to IPv6? Are they going to INSIST on support for TR-124, issue = 2? Yes, you can buy IPv6 capable routers right now, but it's not easy. And = it should be. Most people don't want IPv6. Most people don't want IPv4. They don't = want Ethernet or RFC2882 or G.711. They want to connect to the Internet. = And, RIGHT NOW, that includes IPv6. Oh, only a little bit. We can = pretend that it doesn't really exist, that it's coming soon, but no need = to worry yet. We can eke out the remaining IPv4 address space and point = out that all IMPORTANT hosts have IPv4 addresses. Well NEARLY all. = Mostly. At the moment... Stay calm citizens! There is no need to panic. = But all the while, that tide of IPv6 only space is rising. In a very = short amount of time we won't be able to ignore it, we won't be able to = pretend that an IPv4 connection means connection to the Internet but = acknowledge that it means connection to a sub-set of the Internet. How = long was the last IPv4 allocation supposed to last APNIC? Now, do we = really think we have plenty of time? How do we enable our existing customers to access the IPv6 Internet? Do we really tell them to throw out all their existing equipment and buy = new stuff? How do we explain that for some strange reason THEIR = equipment that used to work fine, strangely doesn't any more? (Doesn't = work, as in no longer access the entire Internet). Yes, it's the = Internet that has changed, not their equipment, but that won't lessen = the blow. How do we explain to them that the equipment they bought = YESTERDAY is unfit for purpose? I really don't want to have that = conversation with my customers, or their lawyers. Now, looking at this landscape, bleak though it may be, we note that = there are quite a large number of 6to4 capable devices out there in our = customers' hands. Experience has shown that 6to4 is flawed, hence = draft-ietf-v6ops-6to4-to-historic, but it's probably still better than = nothing (draft-ietf-v6ops-6to4-advisory).= From marka@isc.org Sun Apr 24 17:51:00 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 562F7E062B for ; Sun, 24 Apr 2011 17:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUroef2dTtPt for ; Sun, 24 Apr 2011 17:50:59 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfc.amsl.com (Postfix) with ESMTP id 8AD60E0613 for ; Sun, 24 Apr 2011 17:50:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id C879A5F983B; Mon, 25 Apr 2011 00:50:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 DAC8D216C31; Mon, 25 Apr 2011 00:50:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D88FFE3810B; Mon, 25 Apr 2011 10:50:38 +1000 (EST) To: Joel Jaeggli From: Mark Andrews References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> <4DB48F8F.9070207@bogus.com> In-reply-to: Your message of "Sun, 24 Apr 2011 14:01:03 MST." <4DB48F8F.9070207@bogus.com> Date: Mon, 25 Apr 2011 10:50:38 +1000 Message-Id: <20110425005038.D88FFE3810B@drugs.dv.isc.org> Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 00:51:00 -0000 In message <4DB48F8F.9070207@bogus.com>, Joel Jaeggli writes: > On 4/19/11 3:15 PM, Michael Newbery wrote: > > > > Not at all. Getting people to upgrade is obviously attractive to the > > CPE vendors. I was responding to the suggestion that these vendors > > would upgrade EXISTING equipment, even if they could, and pointing > > out that there doesn't seem to be any obvious financial incentive for > > the CPE vendors to do so. I would pay a reasonable percentage of the original price to get a IPv6 image. > The actual rate at which people upgrade the software on their cpe is > pretty much down in the weeds... Embedded devices are out of site /mind > and don't get attention until something is geniunely wrong with them... Which there will be once the ISP starts deploying CGNs. Adding 6rd to a 6to4 image should be posssible. Recieving a DHCP 6rd option reponse should disable 6to4. It would also help if CPE vendors actually updated there web sites to have the latest images. I've got CPE devices which have newer images (as shipped) than those available on the web site. > if you're lucky the uptake on software updates is maybe 5% (speaking > from the experience of working for a mobile phone vendor) until you > deploy automated mechanisms that don't require much (or anything) in the > way of prompting, that has it's own perils of course (just ask microsoft > or nokia what happens when you brick some fraction of the devices in the > field) And my wife, who definitely meets the average user definition for this, has upgraded her iPhone twice in the last year. iTunes nags. > > Certainly over the next few years we can hope that new equipment will > > do the right thing. Having said which, if you were to go out to the > > store RIGHT NOW and buy a residential gateway that does native IPv6, > > how easy would that be? > > look for the logo... if you go to frys, you'll see a few, they aren't > the $49 one on the endcap, but there are other reasons to upgrade, e.g. > gigabit ethernet, 802.11n, print server, wap2 etc. > > > _______________________________________________ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Sun Apr 24 21:42:48 2011 Return-Path: X-Original-To: v6ops@ietfc.amsl.com Delivered-To: v6ops@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 334B7E0673 for ; Sun, 24 Apr 2011 21:42:48 -0700 (PDT) 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.013, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWOJ8c85tKo6 for ; Sun, 24 Apr 2011 21:42:47 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 8B37FE00BE for ; Sun, 24 Apr 2011 21:42:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 10AC49C; Mon, 25 Apr 2011 06:42:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0D07F9A; Mon, 25 Apr 2011 06:42:45 +0200 (CEST) Date: Mon, 25 Apr 2011 06:42:45 +0200 (CEST) From: Mikael Abrahamsson To: Michael Newbery In-Reply-To: <3E34C684-E4A4-4C29-AEAB-B03CA16A7A45@gmail.com> Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <4DACEF1F.8060608@gmail.com> <600F516F-8A57-48E2-8CD7-AD2611E9D5DA@apple.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EBDF@PLSWM12A.ad.sprint.com> <4DB48F8F.9070207@bogus.com> <3E34C684-E4A4-4C29-AEAB-B03CA16A7A45@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 04:42:48 -0000 On Mon, 25 Apr 2011, Michael Newbery wrote: > Do we really tell them to throw out all their existing equipment and buy > new stuff? How do we explain that for some strange reason THEIR > equipment that used to work fine, strangely doesn't any more? This happens all the time, and it seems to be fine. I have a color laser printer that worked fine in XP, but the vendor decided not to create drivers for Vista and Win7 (and installing the XP drivers doesn't work). So I went from only being able to use it in Windows (because my Ubuntu laptop didn't support it) to only being able to use it in Ubuntu (because Windows stopped supporting it and Ubuntu started). Sometimes it's a strange world. Our users know it, this happens to them with a lot of devices (their cars need replacement parts over the lifecycle of the unit). I know your opinion is very common, but when grandma hears that to view her grandchildren on that new video application that needs IPv6, she's needs to call her ISP and ask for it and they'll send her a new router, this is something that is going to happen. I just wish the makers of these applications understood that :( -- Mikael Abrahamsson email: swmike@swm.pp.se From pekkas@netcore.fi Mon Apr 25 22:58:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0101E06FA for ; Mon, 25 Apr 2011 22:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG-iFZCxS8Sn for ; Mon, 25 Apr 2011 22:58:23 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21CE067C for ; Mon, 25 Apr 2011 22:58:22 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3Q5wEjd017650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 08:58:14 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3Q5wE2W017647; Tue, 26 Apr 2011 08:58:14 +0300 Date: Tue, 26 Apr 2011 08:58:14 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <4DB0D038.6050503@gmail.com> Message-ID: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> <4DB0D038.6050503@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.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:58:24 -0000 On Fri, 22 Apr 2011, Brian E Carpenter wrote: >> If the concerned ISP is able to ping 192.88.99.1 and the relay will >> forward traffic from the concerned ISP's IP addresses, it is "better >> than nothing". It is a working 3rd party service that the concerned ISP >> is disrupting. In some countries this can even be illegal unless a >> provision is made in the contract to allow such blocking. > > You're saying that if the service is unstable or has a large latency, > the user might still be better off than using IPv4? I think there has been > a very strong consensus on the list against that view. > > Again, we'd better see what the WG Chairs think. Let's take a step back. You're arguing that in such a case, the user is better off if the ISP returns an ICMP unreachable in response to packets sent to 192.88.99.1, even though we don't even have practical experience if that even works (i.e. disables 6to4). I would object to this regardless, because you're recommending bit-pipe ISPs to start doing things on behalf of their end-customers perceived best interests. "The middle" mucking in end-to-end communication is a big no-no in my book. But I have double objection to this because we don't even know if the scheme you propose works and that it doesn't cause unintentional side-effects. I'd like to see where is this mythical unstable or large latency 6to4 relay? I haven't seen any in my vantage point. Those that suffer from one could just set up a working one per the instructions in the draft and their customers' perceived problems (with this regard) would go away. -- 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 randy@psg.com Mon Apr 25 23:50:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC46E06FA for ; Mon, 25 Apr 2011 23:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.975 X-Spam-Level: X-Spam-Status: No, score=-4.975 tagged_above=-999 required=5 tests=[AWL=1.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW3DC-A9ylOc for ; Mon, 25 Apr 2011 23:50:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFE3E06F5 for ; Mon, 25 Apr 2011 23:50:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEc6F-000I4M-O1; Tue, 26 Apr 2011 06:50:20 +0000 Date: Tue, 26 Apr 2011 15:51:05 +0900 Message-ID: From: Randy Bush To: Pekka Savola In-Reply-To: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> <4DB0D038.6050503@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: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 06:50:25 -0000 > I would object to this regardless, because you're recommending > bit-pipe ISPs to start doing things on behalf of their end-customers > perceived best interests. "The middle" mucking in end-to-end > communication is a big no-no in my book. are you speaking of 6to4 relays? From pekkas@netcore.fi Mon Apr 25 23:57:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B779AE06FA for ; Mon, 25 Apr 2011 23:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lifjgnKEITbp for ; Mon, 25 Apr 2011 23:57:02 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id E393AE06EA for ; Mon, 25 Apr 2011 23:57:01 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3Q6upj9019941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 09:56:51 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3Q6upBo019937; Tue, 26 Apr 2011 09:56:51 +0300 Date: Tue, 26 Apr 2011 09:56:51 +0300 (EEST) From: Pekka Savola To: Randy Bush In-Reply-To: Message-ID: References: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> <4DB0D038.6050503@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.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 06:57:02 -0000 On Tue, 26 Apr 2011, Randy Bush wrote: >> I would object to this regardless, because you're recommending >> bit-pipe ISPs to start doing things on behalf of their end-customers >> perceived best interests. "The middle" mucking in end-to-end >> communication is a big no-no in my book. > > are you speaking of 6to4 relays? No, I'm speaking of ISPs returning ICMP unreachables or blackholing destination IPs of their own choosing. I'd assume most users expect that the ISP is not in the business of filtering content and whatnot. -- 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 brian.e.carpenter@gmail.com Tue Apr 26 00:16:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38163E0700 for ; Tue, 26 Apr 2011 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXtAFH1FwpjE for ; Tue, 26 Apr 2011 00:16:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9AE067C for ; Tue, 26 Apr 2011 00:16:46 -0700 (PDT) Received: by fxm15 with SMTP id 15so266021fxm.31 for ; Tue, 26 Apr 2011 00:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=46YO8Ht00iDzHPJx47M36Tf9oYOqXkec+rIRFQrZktA=; b=xvjPDGX4ZA1PnzdH86dgnVWV6vZO9pE7UvXHJEu0UpaydZ3AdIYlCQ10LsSDT86Flb QXCZYOC3ceGy8v/+BX5SExAHiwYfn1L3LPzpThDzhR/amV/BoZb9Tr/9EmJvHNREY6pG T0qg1y4pD73TloQ6CBIgaBZwBNdzbhSNFqfDo= 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=eODkWR3AB/Su+lpFk4GkF+x+6AO7pkgCUH1z4RzMqOhBiWi46WHjx7U3jtHWlNjeW1 UcXh+gcgw5+z9C12sY506FaU8hSNSLi17xcTqvIk3inXRoJgLBqkzDveck3Yi4ftIa1K 75HfRovOghCiE2GodWNB44YYjvDEB+DS16vHE= Received: by 10.223.1.76 with SMTP id 12mr410546fae.118.1303802205931; Tue, 26 Apr 2011 00:16:45 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id j12sm1891505fax.9.2011.04.26.00.16.42 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 00:16:45 -0700 (PDT) Message-ID: <4DB67154.1060902@gmail.com> Date: Tue, 26 Apr 2011 19:16:36 +1200 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: <2BA56AC2-E076-40C7-9AA0-FFD55E93C9AA@cisco.com> <4DAF68E7.6000201@gmail.com> <4DB0D038.6050503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:16:48 -0000 On 2011-04-26 17:58, Pekka Savola wrote: > On Fri, 22 Apr 2011, Brian E Carpenter wrote: >>> If the concerned ISP is able to ping 192.88.99.1 and the relay will >>> forward traffic from the concerned ISP's IP addresses, it is "better >>> than nothing". It is a working 3rd party service that the concerned ISP >>> is disrupting. In some countries this can even be illegal unless a >>> provision is made in the contract to allow such blocking. >> >> You're saying that if the service is unstable or has a large latency, >> the user might still be better off than using IPv4? I think there has >> been >> a very strong consensus on the list against that view. >> >> Again, we'd better see what the WG Chairs think. > > Let's take a step back. You're arguing that in such a case, the user is > better off if the ISP returns an ICMP unreachable in response to packets > sent to 192.88.99.1, even though we don't even have practical experience > if that even works (i.e. disables 6to4). > > I would object to this regardless, because you're recommending bit-pipe > ISPs to start doing things on behalf of their end-customers perceived > best interests. "The middle" mucking in end-to-end communication is a > big no-no in my book. > > But I have double objection to this because we don't even know if the > scheme you propose works and that it doesn't cause unintentional > side-effects. > > I'd like to see where is this mythical unstable or large latency 6to4 > relay? I haven't seen any in my vantage point. I have. Those that suffer from > one could just set up a working one per the instructions in the draft > and their customers' perceived problems (with this regard) would go away. Yes, but if they don't want to do that, I believe we should suggest an alternative approach. I have tuned the language in response to your comments, to make it clear that it's an individual ISP's choice. The IETF has never done well by *telling* ISPs what to do... Brian From brian.e.carpenter@gmail.com Tue Apr 26 00:33:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AE1E071A for ; Tue, 26 Apr 2011 00:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 719HlV3oQGto for ; Tue, 26 Apr 2011 00:33:13 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D806E069B for ; Tue, 26 Apr 2011 00:33:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so273928fxm.31 for ; Tue, 26 Apr 2011 00:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=guPbBYNQwaVZS1NR3GaB+8nScWshacMf3ML2wZXZmnI=; b=l5WZUqtbeX9vTzI4hKrI1KpTHwawwTiuebVr2+VxqNamO08YZ0+5DmJCKCrgRR23kG +DC809vMtisyXQTmmVQvi6iCcYkgXqlWJnT17/8dawfD93wB9cvqK/+XRSibW5h06ExU /Nk/CGUMutG7Fm8QPOwWZJDaykA5SoGezNHW0= 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=lDH4z961LXXU5tJsayCJdglVIGvQmVTtiV2axiNYp/FmLAG5ZboINwyeBWd7JnRa25 iTuRQsGWhniuYSZhsXIdWoVW3fUXQjeZsuN3i+biY9sTW9e/7lchI9cu8ewpaut+qt+6 NajGm094Tl4BH+j98p5IVKR2wKMDZEwbgJF1E= Received: by 10.223.97.142 with SMTP id l14mr432933fan.111.1303803192349; Tue, 26 Apr 2011 00:33:12 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id p16sm1894267fax.21.2011.04.26.00.33.08 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 00:33:11 -0700 (PDT) Message-ID: <4DB6752F.6070101@gmail.com> Date: Tue, 26 Apr 2011 19:33:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-ietf-v6ops-6to4-advisory-01 posted X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:33:14 -0000 I've posted a new version: http://www.ietf.org/id/draft-ietf-v6ops-6to4-advisory-01.txt All the WG last call comments so far have been attended to, I think, except for two points where Pekka and I are not in agreement: 1. The summary of 6to4 operation is still included, as other people seem to agree with it being there. 2. I've modified but not removed the suggestion that some IPv4-only ISPs may choose to block routing to the 6to4 anycast address. More comments are welcome, of course. -- Regards Brian Carpenter From pekkas@netcore.fi Tue Apr 26 02:51:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F001E06B2; Tue, 26 Apr 2011 02:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GC5sDMnIG2H; Tue, 26 Apr 2011 02:51:17 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA583E06B1; Tue, 26 Apr 2011 02:51:16 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p3Q9p6pl023739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 12:51:06 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p3Q9p5i1023735; Tue, 26 Apr 2011 12:51:06 +0300 Date: Tue, 26 Apr 2011 12:51:05 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: <20110415205113.13704.48681.idtracker@ietfc.amsl.com> Message-ID: References: <20110415205113.13704.48681.idtracker@ietfc.amsl.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, draft-ietf-v6ops-v6-aaaa-whitelisting-implications@tools.ietf.org Subject: Re: [v6ops] Last Call: (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 09:51:18 -0000 On Fri, 15 Apr 2011, The IESG wrote: > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'IPv6 AAAA DNS Whitelisting Implications' > as an > Informational RFC This is an ops-dir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03. The document is readable and could be published as-is. I share some of the concerns already expressed in the document, but I think the doc strikes a reasonable balance between the concerns and practical points. One bigger comment: ------------------- Section 6 on deployment scenarios seems too black and white: either it is done ad-hoc or (completely) universally. The latter is unfeasible. The document should cover a middle ground which is already discussed in [NW-Article-DNS-WL], i.e., one or more whitelisting information providers would be used by multiple content networks. This has many benefits compared to completely ad-hoc model, and is feasible compared to universal model. The "universal deployment model" proposition has created ripples throughout the document (one such place is S 7.3.7), and I think the document might have been clearer if that was taken out completely -- or at least, issues related to each deployment model would be more clearly separated. ...... 8.3.1. Solving Current End User IPv6 Impairments ... One challenge with this option is the potential difficulty of motivating members of the Internet community to work collectively towards this goal, sharing the labor, time, and costs related to such an effort. Of course, since just such a community effort is now underway for IPv6, it is possible that this would call for only a moderate amount of additional work. ... I would observe that ad-hoc whitelisting is already requiring a lot of work from each of whitelisting providers. Would this require more than that? If the alternative is to do nothing (no whitelisting, no user impairment notification) that is clear the winner from the selfish POV. But if the choice is between whitelisting and alerting, I don't see much difference between the two. Both could benefit from joint activities, but both can also be operated in an ad-hoc fashion. editorial: ---------- 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis Additional implications, should this be deployed on an ad hoc basis, could include scalability problems relating to operational processes, monitoring, and ACL updates. ... this could be read to imply that S 7.3.1-6 would be applicable to universal deployment. This is not what is meant. Maybe clarify somewhat like as follows: Previous subsections described implications that apply to both ad-hoc and universal deployment models. Some additional implications are specific to ad-hoc deployment models, namely ... S 7.5 governmental, and/or cultural conflicts, given the new control point which has be established with DNS whitelisting. For example, in one s/be/been/ [IPv6 Brokenness] Anderson, T., "Measuring and Combating IPv6 Brokenness", Reseaux IP Europeens (RIPE) 61st Meeting, November 2011, . s/2011/2010/ From ichiroumakino@gmail.com Tue Apr 26 04:29:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6498AE0703 for ; Tue, 26 Apr 2011 04:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrtH+SxS6D8z for ; Tue, 26 Apr 2011 04:29:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88394E06ED for ; Tue, 26 Apr 2011 04:29:21 -0700 (PDT) Received: by wwa36 with SMTP id 36so356401wwa.13 for ; Tue, 26 Apr 2011 04:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=grE1Vwt1eVfMsVNJrKNnc+rJ6NmbgHptH2ZBd9CrgiA=; b=lEcHnIWwbDWfGXk2TwW3JLHsVgJz90+Ik6MJUEjH1mJ+L+KZC0NIQ35LVVjuLShPqT Koimq2GTHUeiDZker8ADhtbp2P0kEkqJfCRZ7NjIiYCU9Q3a81GUNG+N36cS9N3Td4Jt EsGHj2ABnMPuzCPi2wJOX1ifkxc6luvk3zYo0= 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=mmK6QeDX/jcpmZNQFGCD+orwu1+gYKSnfcwtV+Xukn8mV6i8sW0RHvdgp0BAEmc2im /zJgVYnBqjejKTH6efahmEZH9b0vNTDa0yPDsE7cz1S9vjbcIDGu5zoIz/wOvjommLeu epg0FRCUwYhDimlBJ8taSh+gz3BLFzqEA+pFU= Received: by 10.227.149.142 with SMTP id t14mr648631wbv.170.1303817360273; Tue, 26 Apr 2011 04:29:20 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-242.cisco.com (dhcp-osl-vl300-64-103-53-242.cisco.com [64.103.53.242]) by mx.google.com with ESMTPS id x1sm3780569wbh.53.2011.04.26.04.29.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 04:29:17 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 26 Apr 2011 13:29:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00AA4415-A5F2-4AD7-AA2B-04062647C558@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:29:22 -0000 Pekka, [...] > Editorial: >=20 > Many things I object to, but listing these is not worth the effort. = Some specifics though: > - First sentence of S 1 is misleading as already discussed and should > be removed/rephrased. No need to even mention the BGP model. why not? there seems to be a lot of confusion about this exact point and = how 6to4 was originally intended to be deployed. appreciated if you could list some of your other objections too. cheers, Ole= From ichiroumakino@gmail.com Tue Apr 26 04:44:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D711DE072E for ; Tue, 26 Apr 2011 04:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oExWerLpi1Lv for ; Tue, 26 Apr 2011 04:44:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2012E0703 for ; Tue, 26 Apr 2011 04:44:31 -0700 (PDT) Received: by wwa36 with SMTP id 36so367783wwa.13 for ; Tue, 26 Apr 2011 04:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=3Uu/nROaNXk0PeiZSDM9DbiQZT6iD1xplet0I6uPR2Q=; b=j+J5OTw7atdI9CZ/JeeI3szSgGQJpbRabqLoWcTT0lDimbA86wFLXE7Sn9eDtn75bx A0ZRG67hKnU1Xa9jZpQ84a8QCd2yQw7ubCI1Ld4YwAMzewqe4I2RI0a7kXIkXRD1l5rM U3rPGIRqVebyL1o+Dv0lqSvmQ598abpGkyhSs= 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=VZHG0ImWEuKTAniT88ERfLfRsSIoxK/VNzrDWHDJmuDdsk7nUiq+evqbF1OuZcsMAK 1E0gemVd/Wj5r2/qqifd+iWE0Nz+PhdcduythJV8G9/mUJY9r4L/CcO+zcFiDRIOahaa YhHz99zHXNfyFt1jDyZ/culYd5NyM5emrh908= Received: by 10.216.61.9 with SMTP id v9mr4551552wec.67.1303818270826; Tue, 26 Apr 2011 04:44:30 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-242.cisco.com (dhcp-osl-vl300-64-103-53-242.cisco.com [64.103.53.242]) by mx.google.com with ESMTPS id n2sm2964654wej.46.2011.04.26.04.44.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 04:44:29 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 26 Apr 2011 13:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <417B289E-5C50-471E-A86D-1455D13F1D84@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:44:32 -0000 >> I understand what you're trying to do, and that's fine, but... = posting a document declaring the protocol to have been "declared = historic" is our mechanism to do that. >=20 > The IETF can certainly post documents if it wishes. > I'm saying that it is not a constructive thing to do unless we know = that the major vendors are on board to follow that advice. >=20 > I'm saying that we should first get those vendors on board, not try to = use "publish an RFC" as a hammer. >=20 > At best, the hammer makes them change their minds. > At worst, they laugh at the hammer and do nothing. The IETF looks = silly, and the users who read RFCs get confused. >=20 >> It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying to be pragmatic - "we = understand that all software in the world isn't going to change = overnight; as it changes, this is the direction we'd like it to go". >=20 > Then what is the point of this document again? >=20 > James said it pretty well [1] >=20 > "When I briefed my managers about this draft, I told them that it = currently requires us to do absolutely nothing in the foreseeable = future, and it explicitly permits us to continue doing what we are doing = today. My reading of the document suggests that you can safely ignore = its current form as well." >=20 > [1] > http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html >=20 >> How do you plan to get the major vendors onboard without a = specification for them to react to? >=20 > The major vendors who are the main target of this document are be = already present on the mailing list. >=20 > Just as an observation: >=20 > People from Microsoft are arguing against it. James from Apple is = arguing against it from a different angle. >=20 > Are you hoping that even if they don't change their opinion, they will = conform to the RFC? >=20 > I don't. this isn't the IVTF? I think the vendors you mentioned above already comply with the draft. this isn't meant as a hammer to force vendors to do anything by decree. = the IETF has standardised a mechanism that has been shown to not work = well in the Internet, it is our responsibility to clean up that = particular mess. with _my_ vendor hat on, I need this document to justify to our product = people to not enable 6to4 by default.=20 cheers, Ole= From Dmitry.Anipko@microsoft.com Tue Apr 26 10:21:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C895E0805 for ; Tue, 26 Apr 2011 10:21:53 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5+ThOtei8EO for ; Tue, 26 Apr 2011 10:21:51 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7C1E07A8 for ; Tue, 26 Apr 2011 10:21:51 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 26 Apr 2011 10:21:51 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 26 Apr 2011 10:21:51 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Tue, 26 Apr 2011 10:21:25 -0700 From: Dmitry Anipko To: Ole Troan , Pekka Savola Date: Tue, 26 Apr 2011 10:21:23 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC Thread-Index: AcwEB14Sas1cr9MsTTmPgtJZ35/IRQALldRg Message-ID: References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <417B289E-5C50-471E-A86D-1455D13F1D84@employees.org> In-Reply-To: <417B289E-5C50-471E-A86D-1455D13F1D84@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: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:21:53 -0000 Hello Ole, >> with _my_ vendor hat on, I need this document to justify to our product = people to not enable 6to4 by default. Why isn't http://www.ietf.org/id/draft-ietf-v6ops-6to4-advisory-01.txt suff= icient for that? It seems to have a clear guidance to avoid unintentional d= eployment (and hence not to enable by default), and lists reasons for that.= =20 Thanks, Dmitry -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of O= le Troan Sent: Tuesday, April 26, 2011 4:44 AM To: Pekka Savola Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC >> I understand what you're trying to do, and that's fine, but... posting a= document declaring the protocol to have been "declared historic" is our me= chanism to do that. >=20 > The IETF can certainly post documents if it wishes. > I'm saying that it is not a constructive thing to do unless we know that = the major vendors are on board to follow that advice. >=20 > I'm saying that we should first get those vendors on board, not try to us= e "publish an RFC" as a hammer. >=20 > At best, the hammer makes them change their minds. > At worst, they laugh at the hammer and do nothing. The IETF looks silly, = and the users who read RFCs get confused. >=20 >> It might make sense, if that statement is confusing, to remove the state= ment. I think the authors are trying to be pragmatic - "we understand that = all software in the world isn't going to change overnight; as it changes, t= his is the direction we'd like it to go". >=20 > Then what is the point of this document again? >=20 > James said it pretty well [1] >=20 > "When I briefed my managers about this draft, I told them that it current= ly requires us to do absolutely nothing in the foreseeable future, and it e= xplicitly permits us to continue doing what we are doing today. My reading= of the document suggests that you can safely ignore its current form as we= ll." >=20 > [1] > http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html >=20 >> How do you plan to get the major vendors onboard without a specification= for them to react to? >=20 > The major vendors who are the main target of this document are be already= present on the mailing list. >=20 > Just as an observation: >=20 > People from Microsoft are arguing against it. James from Apple is arguing= against it from a different angle. >=20 > Are you hoping that even if they don't change their opinion, they will co= nform to the RFC? >=20 > I don't. this isn't the IVTF? I think the vendors you mentioned above already comply with the draft. this isn't meant as a hammer to force vendors to do anything by decree. the= IETF has standardised a mechanism that has been shown to not work well in = the Internet, it is our responsibility to clean up that particular mess. with _my_ vendor hat on, I need this document to justify to our product peo= ple to not enable 6to4 by default.=20 cheers, Ole _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Tue Apr 26 12:58:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EFAE07E3 for ; Tue, 26 Apr 2011 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB81-q+LWl0U for ; Tue, 26 Apr 2011 12:58:14 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2B3E07C5 for ; Tue, 26 Apr 2011 12:58:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C8AFF87006A for ; Tue, 26 Apr 2011 21:58:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzktCsvQSdBp for ; Tue, 26 Apr 2011 21:58:06 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1739B870002 for ; Tue, 26 Apr 2011 21:58:06 +0200 (CEST) Message-ID: <4DB723C7.1090905@globis.net> Date: Tue, 26 Apr 2011 21:57:59 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080408000900070402070204" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 19:58:15 -0000 This is a multi-part message in MIME format. --------------080408000900070402070204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit RE: obsoleting RFC 3056 via draft-ietf-v6ops-6to4-to-historic-00 Would marking RFC3056 6to4 as "historic" as per the proposed text have any negative knock-on consequences for 6rd? RFC 5969 quote "builds on 6to4 [RFC3056 ]" and refers to improvements of the 6to4 mechanisms. 2nd Quote from RFC 5659: "6rd utilizes the same encapsulation and base mechanism as 6to4 and could be viewed as a superset of 6to4" That would certainly be undesirable IMHO, as 6rd is one of the few transition mechanisms that seems to be scalable and explicitly designed with the aim of delivering a reliable and managed native IPv6 service as quickly as possible to end users. Just asking as a naive end user. regards, --------------080408000900070402070204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit RE: obsoleting RFC 3056 via draft-ietf-v6ops-6to4-to-historic-00

Would marking RFC3056 6to4 as "historic" as per the proposed text have any negative knock-on consequences for 6rd?

RFC 5969 quote "builds on 6to4 [RFC3056]" and refers to improvements of the 6to4 mechanisms.

2nd Quote from RFC 5659: "6rd utilizes the same encapsulation and base mechanism as 6to4 and could be viewed as a superset of 6to4"

That would certainly be undesirable IMHO, as 6rd is one of the few transition mechanisms that seems to be scalable and explicitly designed with the aim of delivering a reliable and managed native IPv6 service as quickly as possible to end users.

Just asking as a naive end user.

regards,
--------------080408000900070402070204-- From ek@google.com Tue Apr 26 16:56:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3B7E07DD for ; Tue, 26 Apr 2011 16:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.94 X-Spam-Level: X-Spam-Status: No, score=-105.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpXxDpjmNiY9 for ; Tue, 26 Apr 2011 16:55:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A6027E07DA for ; Tue, 26 Apr 2011 16:55:59 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p3QNtwCN025067 for ; Tue, 26 Apr 2011 16:55:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303862158; bh=mCYKVriEQ3TMHD8ixZAbPah2XWM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=WH5qV5oe7iSbGPFjNwJ3UL3JDss5ZnhrlSxk/giHJe039AHSyYxQsj28ln3S0lbaF Eyt/yYzFYiXeJoPJA4JFQ== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by hpaq2.eem.corp.google.com with ESMTP id p3QNtP6F004175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 26 Apr 2011 16:55:56 -0700 Received: by pzk28 with SMTP id 28so779535pzk.8 for ; Tue, 26 Apr 2011 16:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xoq4Cfqds/QPjhHF55vLXGyqEq6nLTOAQpwFTYDSsHc=; b=bXKVWdAqk6VpdWFhR3bofm06gbRUDWjLSTrx0icWVrGEzWjWdjNrXMMzp2zcZN2E3V 8/H4EwalE3vUtJKMox2A== 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=At69AotABU5rpN6ANN5fZOlQGH6MiWOg1n/YbkKu0dj7zC6EwbrFeUTuI935mGh4+u 3heY8MUNSxVnRrQGXacg== MIME-Version: 1.0 Received: by 10.68.23.98 with SMTP id l2mr1441675pbf.404.1303862156424; Tue, 26 Apr 2011 16:55:56 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Tue, 26 Apr 2011 16:55:56 -0700 (PDT) In-Reply-To: <4DB723C7.1090905@globis.net> References: <4DB723C7.1090905@globis.net> Date: Wed, 27 Apr 2011 08:55:56 +0900 Message-ID: From: Erik Kline To: Ray Hunter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 23:56:00 -0000 would it suffice if 6rd were to refer to 4213 instead? i think much of what it really needs is actually there. but perhaps there's something it currently only gets from 3056. :/ From mark@townsley.net Tue Apr 26 23:37:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B08E06CB for ; Tue, 26 Apr 2011 23:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAJKmM3SM9Cx for ; Tue, 26 Apr 2011 23:37:00 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64F35E06C4 for ; Tue, 26 Apr 2011 23:37:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so1168382wyb.31 for ; Tue, 26 Apr 2011 23:36:59 -0700 (PDT) Received: by 10.227.55.68 with SMTP id t4mr1729258wbg.78.1303886217434; Tue, 26 Apr 2011 23:36:57 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id bd8sm248071wbb.14.2011.04.26.23.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 23:36:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 27 Apr 2011 08:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73193DD9-0213-42D7-A490-CEB3C8CF4C79@townsley.net> References: <4DB723C7.1090905@globis.net> To: Erik Kline X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 06:37:04 -0000 Given we cannot change the text in RFC5969 without a full rev of the = document, perhaps we should make it clear in the 6to4-historic document = that while 6rd was based on 6to4, it does not share the same problems = leading us to make 6to4 historic and why.=20 - Mark On Apr 27, 2011, at 1:55 AM, Erik Kline wrote: > would it suffice if 6rd were to refer to 4213 instead? i think much > of what it really needs is actually there. but perhaps there's > something it currently only gets from 3056. :/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Tue Apr 26 23:50:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612D6E06C9 for ; Tue, 26 Apr 2011 23:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTIlEWjwN4cK for ; Tue, 26 Apr 2011 23:50:24 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D549E06AF for ; Tue, 26 Apr 2011 23:50:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D3E6287007F for ; Wed, 27 Apr 2011 08:50:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0jFSGdRBNcg for ; Wed, 27 Apr 2011 08:50:14 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 99636870067 for ; Wed, 27 Apr 2011 08:50:14 +0200 (CEST) Message-ID: <4DB7BC9F.9000604@globis.net> Date: Wed, 27 Apr 2011 08:50:07 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org References: <4DB723C7.1090905@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030100040604050006050103" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 06:50:32 -0000 This is a multi-part message in MIME format. --------------030100040604050006050103 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Erik Kline wrote: > would it suffice if 6rd were to refer to 4213 instead? i think much > of what it really needs is actually there. but perhaps there's > something it currently only gets from 3056. :/ > That's exactly what I'm wondering, myself. Which is why I asked in question form whether anyone would find this a problem. I read RFC5969 once again and I find it difficult to put my finger on anything that will directly break. So what does 6rd actually really inherit from 6to4 via RFC3056? As opposed to general methods, and inherited references. p1 lots of intro text looks harmless enough p2 the anycast failover references RFC3068, which in turn references RFC3056 Could be an issue? http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also move RFC 3068 to historic. p2 reference to being a superset of 6to4 harmless text? p2 6to4 could be achieved by setting the 6rd prefix to 2002::/16 Clearly that wouldn't be desirable any more, but wouldn't break 6to4. p11: encapsulation as in [RFC4213 ], which is the same mechanism used by 6to4 [RFC3056 ]. so that looks safe enough, as it also names the original reference p14 security discussion compares and contrasts but does not rely on 6to4 p15 RFC3056 is named as a normative reference p16 RFC3068 is named as a informative reference So it all seems pretty indirect, apart from the use of anycast failover, which could be a problem. But it's still not exactly clear to me even at a second read how people would interpret 6rd (with anycast failover) if the underlying normative and informative RFC has been marked historic. So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could include some clarification that although 6to4 itself is considered historic, 6rd is most certainly not. Best regards, RayH --------------030100040604050006050103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Erik Kline wrote: 
would it suffice if 6rd were to refer to 4213 instead?  i think much
of what it really needs is actually there.  but perhaps there's
something it currently only gets from 3056.  :/
That's exactly what I'm wondering, myself. Which is why I asked in question form whether anyone would find this a problem.

I read RFC5969 once again and I find it difficult to put my finger on anything that will directly break.

So what does 6rd actually really inherit from 6to4 via RFC3056?
As opposed to general methods, and inherited references.

p1 lots of intro text
looks harmless enough

p2 the anycast failover references RFC3068, which in turn references RFC3056
Could be an issue? http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also move RFC 3068 to historic.

p2 reference to being a superset of 6to4
harmless text?

p2 6to4 could be achieved by setting the 6rd prefix to 2002::/16
Clearly that wouldn't be desirable any more, but wouldn't break 6to4.

p11: encapsulation as in [RFC4213], which is the same mechanism used by 6to4 [RFC3056].
so that looks safe enough, as it also names the original reference

p14 security discussion
compares and contrasts but does not rely on 6to4

p15 RFC3056 is named as a normative reference
p16 RFC3068 is named as a informative reference

So it all seems pretty indirect, apart from the use of anycast failover, which could be a problem.

But it's still not exactly clear to me even at a second read how people would interpret 6rd (with anycast failover) if the underlying normative and informative RFC has been marked historic.

So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could include some clarification that although 6to4 itself is considered historic, 6rd is most certainly not.

Best regards,
RayH
--------------030100040604050006050103-- From ichiroumakino@gmail.com Wed Apr 27 00:14:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B0E06CC for ; Wed, 27 Apr 2011 00:14:37 -0700 (PDT) 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.549, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+D1dSueXmLm for ; Wed, 27 Apr 2011 00:14:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB1E06DA for ; Wed, 27 Apr 2011 00:14:32 -0700 (PDT) Received: by wwa36 with SMTP id 36so1029652wwa.13 for ; Wed, 27 Apr 2011 00:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=AFXoGPeN+72po3ZZJMLGuCQv2A8cbF0JwhLoKjq6Iso=; b=aGLcLH/F5z0zwZv9wVIB9dczBBX8cAwa0J0ExEo5MB+d23HK8EpnuveulvgKqcsxYz fL2pCpQI4LhPQ0oyb/mC2zfpvcpfA/Ck/lMvT/8B9QMlATwzQ4BEmyQ0IghOdg1qcnvB HS4N/8C3ErmzTbNuBqbciJVIA+80bjZDNKWLg= 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=AmfgmCGV7XCk4kf0/T04+m5/t/tLhubEpXW4nCdmz3L2MifAySkb7Ay7odrYiuPF0Z dxrcPIKfNNxmsiaUQZpqTPVx/s9QAx4PHWI8D5PzVoxI6GF8kz/c2Z/Q4De4kc8Dhezg 0yj//rfI70uK4tLpifSX7F+vNV8mccxIHqgGQ= Received: by 10.227.202.15 with SMTP id fc15mr1772351wbb.214.1303888470578; Wed, 27 Apr 2011 00:14:30 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-242.cisco.com (dhcp-osl-vl300-64-103-53-242.cisco.com [64.103.53.242]) by mx.google.com with ESMTPS id y29sm263611wbd.21.2011.04.27.00.14.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 00:14:29 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> Date: Wed, 27 Apr 2011 09:14:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <200E8BFC-3E30-400C-B49B-283F7D973592@employees.org> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] Summary: draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:14:38 -0000 hi, you haven't given me an easy job trying to summarize the 150+ mail = thread the last call has generated so far. ;-) I have tried to collect and itemize the issues with the draft raised on = the thread. I have discarded the "support/no support" messages. please let me know if there are issues I have missed and if you are = happy with the proposed actions. 1. "has rarely if ever been deployed" ------------------------------------- - Furthermore, is not true the text in the document that indicates = that this mechanism is unsuitable for widespread deployment and the same = applies to "has rarely if ever been deployed". - I couldn't find a reference in the draft which would support = statement (1). If there has been some study showing that 6to4 deployment, by some quantifiable metric, = is indeed many times lower than deployment of other tunnels (for example, Teredo), then I think = having a reference to such data would make statement (1) more justified.=20 Action: clarify the text in the introduction to avoid impression that = 6to4 as a whole has never been deployed. 2. "protocol 41" ---------------- - Specifically, the issue (A) states that "6to4 has no specified = mechanism to handle the case where protocol 41 is blocked...". Do other tunneling mechanisms using = protocol 41 have such mechanism? If they don't, then should usage of protocol 41 be moved to = historic, because the stated filtering/PMTUD problems are then not specific to RFC 3056? If they do, then having = a brief overview of those and how/why they don't apply to 6to4 would help to strengthen the statement. Action: None 3. "non-RFC1918 addresses" -------------------------- - The issue (B), if I understand correctly, it is essentially about = usage of non-RFC1918 addresses in networks, connected to Internet e.g. using a NAT. There are existing = mitigations to this problem (e.g. Windows implementation will not configure 6to4 interface if = there is other IPv6 connectivity in the network; depending on particular implementation, in managed = environments administrators may have control whether to enable or disable 6to4 on hosts). But even = leaving those mitigations aside, it seems that the de-prioritization of 6to4 in prefix policy table = below IPv4 in the proposed RFC 3484 revision would take care of this issue, and moving RFC 3056 is a = much stronger measure, which doesn't seem to be necessary, as far as the issue (B) is concerned. With = the revised RFC 3484, 6to4 will be one of the "last resort" mechanisms, which will essentially be used = only if nothing else can, so it won't be harmful. Reply: with the introduction of CGNs non-RFC1918 addresses may have = limited topological span making them unsuitable for 6to4. So to summarize, in my opinion, in the current draft there seem to = be sufficient arguments to move RFC 3068 to historic, but not RFC 3056. There may be such arguments for RFC = 3056, but if there are, I think they are not sufficiently reflected in the draft.=20 Reply: Current text states: - Not deployed - Same problems as 3068 for the reverse path - Same problem with filtering - Not working with non-1918 addresses with topologically limited = span Actions: Suggestions for text to make it even clearer why also 3056 = needs to be deprecated? 4. "Phase out plan" ------------------- - Now that we have an official WGLC, I'm going to repeat what I wrote = in a previous thread: this draft should not published in its current form because it sets no standard for = network operations without 6to4. A phaseout plan for RFC 3056 and RFC 3068 would be required before = I could drop my objections to this draft. Action: None. 5. "Clarifications" ------------------- > The approach that's most likely to get widespread support is: >=20 > 1. make it not be on by default > 2. make noise about it being A Bad Thing > 3. deprioritise 2002::/16 addresses in resolver libs > 4. then make the option hard to find on operating systems / CPEs > 5. then remove the option on operating systems > 6. then slowly decommission 6to4 relays over many years >=20 > draft-ietf-v6ops-6to4-to-historic deals with steps 1-3.=20 I do think it would be useful to elaborate on the arguments Tore = just provided to Dmitry for deprecation of 3056 in the draft, as a form = of history writing for the archives. Actions: Proposed text? 6. "Keep peer to peer 6to4" --------------------------- - There are parts which mention relays, and parts which don't. I = think draft-ietf-v6ops-6to4-to-historic=20 fairly well explains what's wrong with relays, but it doesn't = address what's wrong with 6to4-6to4 communication. And if there is not much wrong with 6to4-6to4 = scenario (either between the nodes or between nodes and islands), why should that part be moved to = historic. Action: Unsure. 6to4 is useful for e.g. BGP tunneling, as a way of = getting "globally" scoped addresses without an ISP, can be used for IPv6 transport over other managed = tunnels... none of these uses are described in 3056, 3068. comments? 7. "2.0.0.2.ip6.arpa" - There are ancillary services associated with 2.0.0.2.ip6.arpa which = are provided by APNIC under=20 the auspices of RFC5158. - I just want to confirm to people that irrespective of this proposed = change, APNIC intends to continue=20 to provide reverse-DNS delegation, until its clear the community at = large doesn't require the service. Action: Issue closed. 8. "6to4 to experimental instead of historical" ----------------------------------------------- - In my opinion tend to be similar to Jordi's. 6to4 is good for = experimenting with IPv6. If you need IPv6 service use native solution. But if there no = solution on the market what to do? - According to our policy our 6to4 relay is only for experimenting = with IPv6 technology..... What about 6to4 relabeled to experimental? Reply: If we postulate that 6to4 is harmful to the deployment of IPv6 in = the Internet then I don't see any other choice than deprecating it. 9. "why 6to4 is preventing 6to4 roll out" ----------------------------------------- - My opinion: There needs to be a clear motivation for why 6to4 is = actively preventing 6to4 roll out. I think this clear motivation is somewhat lacking in the current = text. The current focus, the way I read it, is on why 6to4 isn't a great protocol, rather a clear = description of why 6to4 is actively preventing native IPv6 roll out. There also needs to be a clear end = date for implementation of the deprecation, to avoid a transition on a transition.=20 - But I would suggest that the authors amend the text so that it: i) better motivates that use of 6to4 is actively preventing roll = out of native IPv6 ii) includes a clear date for full deprecation (perhaps = immediately), iii) clarifies what it means to deprecate a protocol whilst still = allowing it as a "last resort" (or indeed consider changing it to straight deprecation) Action: I'll try to word smith some descriptive text. Appreciate some = help Erik/Tore? 10. "This is internally inconsistent with S 1: "Declaring the mechanism = historic is not expected to have immediate product implications."" = --------------------------------------------------------------------------= ------------------------------- - What's the point if the goal is not to have immediate product = implications? - First sentence of S 1 is misleading as already discussed and should be removed/rephrased. No need to even mention the BGP model. - It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying to be pragmatic - "we understand that all software in the world = isn't going to change overnight; as it changes, this is the direction we'd like it to go". Action: Remove statement. cheers, Ole From ichiroumakino@gmail.com Wed Apr 27 00:26:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE576E067B for ; Wed, 27 Apr 2011 00:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9xCbTy-4pBK for ; Wed, 27 Apr 2011 00:26:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7947DE06D9 for ; Wed, 27 Apr 2011 00:26:50 -0700 (PDT) Received: by wwa36 with SMTP id 36so1035994wwa.13 for ; Wed, 27 Apr 2011 00:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=aAmWCB3wGiA8TIs4sU0djFnfc2Q7rnxpgJ4jopHWw2A=; b=ja3fVAT2Gw/Wj94gc8odFZRSdVILKh8Gr6I+k56gXUWOKXfIQyODg4bbvBwRj07rmq FKhwa9bYHm7XIJm5EKI10QervCWGUtubqNL1Ah83CTZRii+4+0MUD4Z4PsiKvmn4OWlS sAmZ7EQRiSsLY/ybkblRIMgIYaEzuL46CHqU0= 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=PY9eg5Rgf5UI5PNuwFDERZ1yF7KKmvEd5Zzu429gZJTTKrh+HcgpvQJoNmJICVemJc HxrxTUtlmh/xG5o5LOu4j04POj0rsKntBcY+ypqcdwaDnYAdKE/KHQ2c8MBDP7fTeiTB gWHmmfylQ4HsnPIt577PzbpK5yxmps2ZlEXqs= Received: by 10.227.7.87 with SMTP id c23mr1754044wbc.108.1303889209315; Wed, 27 Apr 2011 00:26:49 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-242.cisco.com (dhcp-osl-vl300-64-103-53-242.cisco.com [64.103.53.242]) by mx.google.com with ESMTPS id y29sm265387wbd.55.2011.04.27.00.26.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 00:26:48 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4DB7BC9F.9000604@globis.net> Date: Wed, 27 Apr 2011 09:26:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <124BB081-7D4C-4C73-94F0-8E5C67A5B737@employees.org> References: <4DB723C7.1090905@globis.net> <4DB7BC9F.9000604@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:26:54 -0000 Ray, I don't think there is any text in 5969 that can't stand on its own = feet, even though 6to4 is deprecated. 5969 is the "fixed version of 6to4", so actually you could make the = argument that 6to4 is superseded by 6rd. I don't want to lose the historical reference. 6to4 invented the method = of creating an IPv6 prefix based on an IPv4 address. cheers, Ole >> would it suffice if 6rd were to refer to 4213 instead? i think much >> of what it really needs is actually there. but perhaps there's >> something it currently only gets from 3056. :/ >> =20 >>=20 > That's exactly what I'm wondering, myself. Which is why I asked in = question form whether anyone would find this a problem. >=20 > I read RFC5969 once again and I find it difficult to put my finger on = anything that will directly break. >=20 > So what does 6rd actually really inherit from 6to4 via RFC3056? > As opposed to general methods, and inherited references. >=20 > p1 lots of intro text > looks harmless enough >=20 > p2 the anycast failover references RFC3068, which in turn references = RFC3056 > Could be an issue? = http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also = move RFC 3068 to historic. >=20 > p2 reference to being a superset of 6to4 > harmless text? >=20 > p2 6to4 could be achieved by setting the 6rd prefix to 2002::/16 > Clearly that wouldn't be desirable any more, but wouldn't break 6to4. >=20 > p11: encapsulation as in [RFC4213], which is the same mechanism used = by 6to4 [RFC3056]. > so that looks safe enough, as it also names the original reference >=20 > p14 security discussion > compares and contrasts but does not rely on 6to4 >=20 > p15 RFC3056 is named as a normative reference > p16 RFC3068 is named as a informative reference >=20 > So it all seems pretty indirect, apart from the use of anycast = failover, which could be a problem. >=20 > But it's still not exactly clear to me even at a second read how = people would interpret 6rd (with anycast failover) if the underlying = normative and informative RFC has been marked historic. >=20 > So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could = include some clarification that although 6to4 itself is considered = historic, 6rd is most certainly not. >=20 > Best regards, > RayH > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Wed Apr 27 12:10:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB99E07EF for ; Wed, 27 Apr 2011 12:10:56 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30vB7J-uZTQM for ; Wed, 27 Apr 2011 12:10:54 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA04AE07EA for ; Wed, 27 Apr 2011 12:10:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9CE9F8700ED; Wed, 27 Apr 2011 21:10:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OioU2-dxXMd; Wed, 27 Apr 2011 21:10:46 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7F053870002; Wed, 27 Apr 2011 21:10:46 +0200 (CEST) Message-ID: <4DB86A2F.2040201@globis.net> Date: Wed, 27 Apr 2011 21:10:39 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Ole Troan References: <4DB723C7.1090905@globis.net> <4DB7BC9F.9000604@globis.net> <124BB081-7D4C-4C73-94F0-8E5C67A5B737@employees.org> In-Reply-To: <124BB081-7D4C-4C73-94F0-8E5C67A5B737@employees.org> Content-Type: multipart/alternative; boundary="------------000507020504000002020207" Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 19:10:56 -0000 This is a multi-part message in MIME format. --------------000507020504000002020207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I obviously defer to you as the co-author of RFC5969. Would it be possible to include some text in your proposal to clarify and encapsulate this view? e.g. "Historic Links between 6rd and 6to4 Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4." Ole Troan wrote: > Ray, > > I don't think there is any text in 5969 that can't stand on its own feet, even though 6to4 is deprecated. > 5969 is the "fixed version of 6to4", so actually you could make the argument that 6to4 is superseded by 6rd. > > I don't want to lose the historical reference. 6to4 invented the method of creating an IPv6 prefix based on an IPv4 address. > > cheers, > Ole > > > >>> would it suffice if 6rd were to refer to 4213 instead? i think much >>> of what it really needs is actually there. but perhaps there's >>> something it currently only gets from 3056. :/ >>> >>> >>> >> That's exactly what I'm wondering, myself. Which is why I asked in question form whether anyone would find this a problem. >> >> I read RFC5969 once again and I find it difficult to put my finger on anything that will directly break. >> >> So what does 6rd actually really inherit from 6to4 via RFC3056? >> As opposed to general methods, and inherited references. >> >> p1 lots of intro text >> looks harmless enough >> >> p2 the anycast failover references RFC3068, which in turn references RFC3056 >> Could be an issue? http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also move RFC 3068 to historic. >> >> p2 reference to being a superset of 6to4 >> harmless text? >> >> p2 6to4 could be achieved by setting the 6rd prefix to 2002::/16 >> Clearly that wouldn't be desirable any more, but wouldn't break 6to4. >> >> p11: encapsulation as in [RFC4213], which is the same mechanism used by 6to4 [RFC3056]. >> so that looks safe enough, as it also names the original reference >> >> p14 security discussion >> compares and contrasts but does not rely on 6to4 >> >> p15 RFC3056 is named as a normative reference >> p16 RFC3068 is named as a informative reference >> >> So it all seems pretty indirect, apart from the use of anycast failover, which could be a problem. >> >> But it's still not exactly clear to me even at a second read how people would interpret 6rd (with anycast failover) if the underlying normative and informative RFC has been marked historic. >> >> So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could include some clarification that although 6to4 itself is considered historic, 6rd is most certainly not. >> >> Best regards, >> RayH >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > --------------000507020504000002020207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I obviously defer to you as the co-author of RFC5969.

Would it be possible to include some text in your proposal to clarify and encapsulate this view?

 e.g.

"Historic Links between 6rd and 6to4

Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4."

Ole Troan wrote: 
Ray,

I don't think there is any text in 5969 that can't stand on its own feet, even though 6to4 is deprecated.
5969 is the "fixed version of 6to4", so actually you could make the argument that 6to4 is superseded by 6rd.

I don't want to lose the historical reference. 6to4 invented the method of creating an IPv6 prefix based on an IPv4 address.

cheers,
Ole


  
would it suffice if 6rd were to refer to 4213 instead?  i think much
of what it really needs is actually there.  but perhaps there's
something it currently only gets from 3056.  :/
  

      
That's exactly what I'm wondering, myself. Which is why I asked in question form whether anyone would find this a problem.

I read RFC5969 once again and I find it difficult to put my finger on anything that will directly break.

So what does 6rd actually really inherit from 6to4 via RFC3056?
As opposed to general methods, and inherited references.

p1 lots of intro text
looks harmless enough

p2 the anycast failover references RFC3068, which in turn references RFC3056
Could be an issue? http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also move RFC 3068 to historic.

p2 reference to being a superset of 6to4
harmless text?

p2 6to4 could be achieved by setting the 6rd prefix to 2002::/16
Clearly that wouldn't be desirable any more, but wouldn't break 6to4.

p11: encapsulation as in [RFC4213], which is the same mechanism used by 6to4 [RFC3056].
so that looks safe enough, as it also names the original reference

p14 security discussion
compares and contrasts but does not rely on 6to4

p15 RFC3056 is named as a normative reference
p16 RFC3068 is named as a informative reference

So it all seems pretty indirect, apart from the use of anycast failover, which could be a problem.

But it's still not exactly clear to me even at a second read how people would interpret 6rd (with anycast failover) if the underlying normative and informative RFC has been marked historic.

So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could include some clarification that although 6to4 itself is considered historic, 6rd is most certainly not.

Best regards,
RayH
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------000507020504000002020207-- From ichiroumakino@gmail.com Wed Apr 27 12:27:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC926E084B for ; Wed, 27 Apr 2011 12:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnKmbI85XhOt for ; Wed, 27 Apr 2011 12:27:49 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3175E081D for ; Wed, 27 Apr 2011 12:27:48 -0700 (PDT) Received: by ewy19 with SMTP id 19so755161ewy.31 for ; Wed, 27 Apr 2011 12:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=F3BKrYpw7sYXaGAvtxCaAOger0wmZ/YNMnGyGWfptw0=; b=UhiBGIiCxqVD96tiLDccfLjv1WZU7ZXuMg8pXImlf5UDTdpstLa9ALKNj+MKnJ6Twk mDNgnBO25hSRBKv0wBz0NsrejdWvuNgMduK/CTDadtbhrIBIcxkTeJnGgm0ehmcHgXXH 1J3EKFeJtRPB7nabAQTuV4eaGMOdmTETb6n08= 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=it2m0VtNAz9nbJetGxcDUAkhpWbOtMDjMgR8H4Ru4RP3h0Dioc5edlko7QAQUM4a78 pYbJ/glQCXRs8o37vJoJYY+HNO3S/CnvvLC7nes5BISB9SkRZ7JfZMJkmOH2gEnyXQoS RqRS9olu76lACCE+ddPQax/4MTzVdzpSOzxbQ= Received: by 10.213.20.69 with SMTP id e5mr440640ebb.15.1303932467530; Wed, 27 Apr 2011 12:27:47 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id u1sm754136eeh.13.2011.04.27.12.27.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 12:27:46 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4DB86A2F.2040201@globis.net> Date: Wed, 27 Apr 2011 21:27:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB723C7.1090905@globis.net> <4DB7BC9F.9000604@globis.net> <124BB081-7D4C-4C73-94F0-8E5C67A5B737@employees.org> <4DB86A2F.2040201@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 19:27:49 -0000 Ray, > I obviously defer to you as the co-author of RFC5969. >=20 > Would it be possible to include some text in your proposal to clarify = and encapsulate this view? >=20 > e.g. >=20 > "Historic Links between 6rd and 6to4 >=20 > Although 6rd has significant historic links with 6to4 (especially = because 6to4 invented the underlying method of creating an IPv6 prefix = based on an IPv4 address), 6rd was defined and improved in such ways = that it does not share the same shortcomings for which the 6to4 = transition mechanism is being moved to historic status. Furthermore, the = definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and = RFC3068 that 6rd may be considered as a stand alone protocol in and of = itself, independent of 6to4." revision 01 now has the following: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-01 6rd [RFC5969] utilizes the same encapsulation and base mechanism as 6to4, and could be viewed as a superset of 6to4 (6to4 could be achieved by setting the 6rd prefix to 2002::/16). However, the deployment model is such that 6rd can avoid the problems described here. In this sense, 6rd can be viewed as superseding 6to4 as described in section 4.2.4 of [RFC2026] is that better? cheers, Ole From v6ops@globis.net Wed Apr 27 12:38:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1C8E085C for ; Wed, 27 Apr 2011 12:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdGCTNxQ-9-3 for ; Wed, 27 Apr 2011 12:38:19 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 106DEE0859 for ; Wed, 27 Apr 2011 12:38:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1CC198700ED; Wed, 27 Apr 2011 21:38:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2WZcJKFpEWh; Wed, 27 Apr 2011 21:38:11 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 438E9870002; Wed, 27 Apr 2011 21:38:11 +0200 (CEST) Message-ID: <4DB8709B.7010909@globis.net> Date: Wed, 27 Apr 2011 21:38:03 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Ole Troan References: <4DB723C7.1090905@globis.net> <4DB7BC9F.9000604@globis.net> <124BB081-7D4C-4C73-94F0-8E5C67A5B737@employees.org> <4DB86A2F.2040201@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040808010906000801070906" Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 19:38:20 -0000 This is a multi-part message in MIME format. --------------040808010906000801070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, that's clear to me thanks. I think that also improves the overall proposal, which is obviously the prime objective. Ole Troan wrote: > Ray, > > >> I obviously defer to you as the co-author of RFC5969. >> >> Would it be possible to include some text in your proposal to clarify and encapsulate this view? >> >> e.g. >> >> "Historic Links between 6rd and 6to4 >> >> Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4." >> > > revision 01 now has the following: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-01 > > 6rd [RFC5969] utilizes the same encapsulation and base mechanism as > 6to4, and could be viewed as a superset of 6to4 (6to4 could be > achieved by setting the 6rd prefix to 2002::/16). However, the > deployment model is such that 6rd can avoid the problems described > here. In this sense, 6rd can be viewed as superseding 6to4 as > described in section 4.2.4 of [RFC2026] > > is that better? > > cheers, > Ole > > --------------040808010906000801070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, that's clear to me thanks. I think that also improves the overall proposal, which is obviously the prime objective.

Ole Troan wrote: 
Ray,

  
I obviously defer to you as the co-author of RFC5969.

Would it be possible to include some text in your proposal to clarify and encapsulate this view?

 e.g.

"Historic Links between 6rd and 6to4

Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4."
    

revision 01 now has the following:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-01

   6rd [RFC5969] utilizes the same encapsulation and base mechanism as
   6to4, and could be viewed as a superset of 6to4 (6to4 could be
   achieved by setting the 6rd prefix to 2002::/16).  However, the
   deployment model is such that 6rd can avoid the problems described
   here.  In this sense, 6rd can be viewed as superseding 6to4 as
   described in section 4.2.4 of [RFC2026]

is that better?

cheers,
Ole

--------------040808010906000801070906-- From fred@cisco.com Wed Apr 27 13:16:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D2DE07D0 for ; Wed, 27 Apr 2011 13:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRzIDRnj5sFQ for ; Wed, 27 Apr 2011 13:16:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id CF552E07F4 for ; Wed, 27 Apr 2011 13:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=9767; q=dns/txt; s=iport; t=1303935379; x=1305144979; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=FG0pYGqzPRWeW3Y3syVsQXh+AWMdyK+9MbRQamecV1c=; b=TotPSoSul3IgMl+a4aT2q9NHh77vjurcMpN2znStZ81mCu/g8etmhPo6 WYB6qdpCnTruUZtKz/Zd5KF0q8wEH5PF1bqnZ8Qt7/x4dQB8r7UV+9f+0 yjV5nda3DBQFoVs7XCjaLEWITsBUr7LHckxxkYpOtox5cX/J1+Iu4mu6/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFACJ5uE2rRDoH/2dsb2JhbAClL0F3iHCfCo8tAY1BhXYEhgOIToQSijo X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="303442625" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 20:16:19 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqn6027138; Wed, 27 Apr 2011 20:16:18 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:16:19 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:16:19 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <200E8BFC-3E30-400C-B49B-283F7D973592@employees.org> Date: Wed, 27 Apr 2011 13:16:18 -0700 Message-Id: <12E38698-CA80-4AC4-A39F-CAFEC3A9920F@cisco.com> References: <4984B8F2-AC42-491E-9C2B-BE999B279759@cisco.com> <200E8BFC-3E30-400C-B49B-283F7D973592@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Summary: draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:16:21 -0000 On Apr 27, 2011, at 12:14 AM, Ole Troan wrote: > hi, >=20 > you haven't given me an easy job trying to summarize the 150+ mail = thread the last call has generated so far. ;-) No, it's not an easy job. The chairs will have a similar job next week = sorting out consensus. What would be really nice would be if we could = get these changes edited into the draft and then do a one-week extension = of the WGLC next week; if the updated draft results in a clear = consensus, it will be a lot more straightforward. In the summary following, I take it that "Reply" or "Action" is your = comment; the preceding statement or paragraph summarizes or reports a = comment from the discussion thread. I'd appreciate comments on the = mailer. In order to simplify sorting out the discussion threads and make = sure each comes to closure, I'll repeat them as separate notes.=20 PROCESS NOTE TO THE WORKING GROUP: I will assume that silence indicates = consent. If Ole missed a point in this summary, please reply to this = email indicting the additional point. If you disagree with a point in = Ole's summary, please discuss in the thread "6to4-historic summary point = N". That will help us sort out the differences of opinion quickly. > I have tried to collect and itemize the issues with the draft raised = on the thread. I have discarded the "support/no support" messages. >=20 > please let me know if there are issues I have missed and if you are = happy with the proposed actions. >=20 > 1. "has rarely if ever been deployed" > ------------------------------------- > - Furthermore, is not true the text in the document that indicates = that this > mechanism is unsuitable for widespread deployment and the same = applies to > "has rarely if ever been deployed". > - I couldn't find a reference in the draft which would support = statement (1). If there has been some > study showing that 6to4 deployment, by some quantifiable metric, = is indeed many times lower than > deployment of other tunnels (for example, Teredo), then I think = having a reference to such data would > make statement (1) more justified.=20 >=20 > Action: clarify the text in the introduction to avoid impression that = 6to4 as a whole has never been deployed. >=20 > 2. "protocol 41" > ---------------- > - Specifically, the issue (A) states that "6to4 has no specified = mechanism to handle the case where > protocol 41 is blocked...". Do other tunneling mechanisms using = protocol 41 have such mechanism? > If they don't, then should usage of protocol 41 be moved to = historic, because the stated filtering/PMTUD > problems are then not specific to RFC 3056? If they do, then = having a brief overview of those and how/why > they don't apply to 6to4 would help to strengthen the statement. >=20 > Action: None >=20 > 3. "non-RFC1918 addresses" > -------------------------- > - The issue (B), if I understand correctly, it is essentially about = usage of non-RFC1918 addresses in networks, > connected to Internet e.g. using a NAT. There are existing = mitigations to this problem > (e.g. Windows implementation will not configure 6to4 interface if = there is other IPv6 connectivity > in the network; depending on particular implementation, in managed = environments administrators may > have control whether to enable or disable 6to4 on hosts). But even = leaving those mitigations aside, > it seems that the de-prioritization of 6to4 in prefix policy table = below IPv4 in the proposed RFC 3484 > revision would take care of this issue, and moving RFC 3056 is a = much stronger measure, which doesn't > seem to be necessary, as far as the issue (B) is concerned. With = the revised RFC 3484, 6to4 will be one > of the "last resort" mechanisms, which will essentially be used = only if nothing else can, so it won't > be harmful. >=20 > Reply: with the introduction of CGNs non-RFC1918 addresses may have = limited topological span making them > unsuitable for 6to4. >=20 > So to summarize, in my opinion, in the current draft there seem to = be sufficient arguments to move RFC 3068 > to historic, but not RFC 3056. There may be such arguments for RFC = 3056, but if there are, I think they > are not sufficiently reflected in the draft.=20 >=20 > Reply: Current text states: > - Not deployed > - Same problems as 3068 for the reverse path > - Same problem with filtering > - Not working with non-1918 addresses with topologically = limited span >=20 > Actions: Suggestions for text to make it even clearer why also 3056 = needs to be deprecated? >=20 > 4. "Phase out plan" > ------------------- > - Now that we have an official WGLC, I'm going to repeat what I = wrote in a previous thread: this draft should > not published in its current form because it sets no standard for = network operations without 6to4. > A phaseout plan for RFC 3056 and RFC 3068 would be required before = I could drop my objections to this draft. >=20 > Action: None. >=20 > 5. "Clarifications" > ------------------- >=20 >> The approach that's most likely to get widespread support is: >>=20 >> 1. make it not be on by default >> 2. make noise about it being A Bad Thing >> 3. deprioritise 2002::/16 addresses in resolver libs >> 4. then make the option hard to find on operating systems / CPEs >> 5. then remove the option on operating systems >> 6. then slowly decommission 6to4 relays over many years >>=20 >> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3.=20 >=20 > I do think it would be useful to elaborate on the arguments Tore = just > provided to Dmitry for deprecation of 3056 in the draft, as a form = of > history writing for the archives. >=20 > Actions: Proposed text? >=20 > 6. "Keep peer to peer 6to4" > --------------------------- > - There are parts which mention relays, and parts which don't. I = think draft-ietf-v6ops-6to4-to-historic=20 > fairly well explains what's wrong with relays, but it doesn't = address what's wrong with 6to4-6to4 > communication. And if there is not much wrong with 6to4-6to4 = scenario (either between the nodes or > between nodes and islands), why should that part be moved to = historic. >=20 > Action: Unsure. 6to4 is useful for e.g. BGP tunneling, as a way of = getting "globally" scoped addresses without an > ISP, can be used for IPv6 transport over other managed = tunnels... none of these uses are described in > 3056, 3068. comments? >=20 >=20 >=20 > 7. "2.0.0.2.ip6.arpa" >=20 > - There are ancillary services associated with 2.0.0.2.ip6.arpa = which are provided by APNIC under=20 > the auspices of RFC5158. > - I just want to confirm to people that irrespective of this = proposed change, APNIC intends to continue=20 > to provide reverse-DNS delegation, until its clear the community = at large doesn't require the service. >=20 > Action: Issue closed. >=20 > 8. "6to4 to experimental instead of historical" > ----------------------------------------------- >=20 > - In my opinion tend to be similar to Jordi's. 6to4 is good for = experimenting with IPv6. > If you need IPv6 service use native solution. But if there no = solution on the market what to do? > - According to our policy our 6to4 relay is only for experimenting = with IPv6 technology..... > What about 6to4 relabeled to experimental? >=20 > Reply: If we postulate that 6to4 is harmful to the deployment of IPv6 = in the Internet then I don't see any > other choice than deprecating it. >=20 > 9. "why 6to4 is preventing 6to4 roll out" > ----------------------------------------- > - My opinion: There needs to be a clear motivation for why 6to4 is = actively preventing 6to4 roll out. > I think this clear motivation is somewhat lacking in the current = text. The current focus, the way > I read it, is on why 6to4 isn't a great protocol, rather a clear = description of why 6to4 is actively > preventing native IPv6 roll out. There also needs to be a clear = end date for implementation of the > deprecation, to avoid a transition on a transition.=20 >=20 > - But I would suggest that the authors amend the text so that it: > i) better motivates that use of 6to4 is actively preventing roll = out of native IPv6 > ii) includes a clear date for full deprecation (perhaps = immediately), > iii) clarifies what it means to deprecate a protocol whilst still = allowing it as a "last resort" > (or indeed consider changing it to straight deprecation) >=20 > Action: I'll try to word smith some descriptive text. Appreciate some = help Erik/Tore? >=20 > 10. "This is internally inconsistent with S 1: "Declaring the = mechanism historic is not expected to have > immediate product implications."" > = --------------------------------------------------------------------------= ------------------------------- >=20 > - What's the point if the goal is not to have immediate product = implications? >=20 > - First sentence of S 1 is misleading as already discussed and = should > be removed/rephrased. No need to even mention the BGP model. >=20 > - It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying > to be pragmatic - "we understand that all software in the world = isn't going to change overnight; > as it changes, this is the direction we'd like it to go". >=20 > Action: Remove statement. >=20 > cheers, > Ole >=20 From fred@cisco.com Wed Apr 27 13:17:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61944E07FA for ; Wed, 27 Apr 2011 13:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.543 X-Spam-Level: X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5aqVJiLutgs for ; Wed, 27 Apr 2011 13:17:02 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id DC883E07C8 for ; Wed, 27 Apr 2011 13:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=967; q=dns/txt; s=iport; t=1303935422; x=1305145022; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=jcHlM+2gPRXr6ULqbJFgkfIWZ3CU/RETuC+L+Oz+gvE=; b=cydKa7DLyynp5P0PGac1XoL2jPOqoKyqLi4DYQBmKikkENUg/CauE2Hv L6N4yZPOCXY99ijtHc9fuUloA8RXIc5pHPDI7HOpjA1aHJ3GufT9+16R/ TWU1s2ZtjGZryzQ0d3TxHaupIMKeGlpaYDpCT/dXW0G36Au5nHbkiYl5k U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOd4uE2rRDoH/2dsb2JhbAClcHeIcJ8dnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="437636006" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 20:17:02 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqn7027138 for ; Wed, 27 Apr 2011 20:17:02 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:17:02 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:17:02 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:17:02 -0700 Message-Id: To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 1. "has rarely if ever been deployed" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:17:03 -0000 > 1. "has rarely if ever been deployed" > ------------------------------------- > - Furthermore, is not true the text in the document that indicates = that this > mechanism is unsuitable for widespread deployment and the same = applies to > "has rarely if ever been deployed". > - I couldn't find a reference in the draft which would support = statement (1). If there has been some > study showing that 6to4 deployment, by some quantifiable metric, = is indeed many times lower than > deployment of other tunnels (for example, Teredo), then I think = having a reference to such data would > make statement (1) more justified.=20 >=20 > Action: clarify the text in the introduction to avoid impression that = 6to4 as a whole has never been deployed. Does the working group agree with the summarization of the concern? Do = we agree with the proposed action? Reply if the answer is "no", and give a better suggestion.= From fred@cisco.com Wed Apr 27 13:17:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2EDE082A for ; Wed, 27 Apr 2011 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.546 X-Spam-Level: X-Spam-Status: No, score=-110.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR-Iayvf-898 for ; Wed, 27 Apr 2011 13:17:27 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 31992E0822 for ; Wed, 27 Apr 2011 13:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=759; q=dns/txt; s=iport; t=1303935439; x=1305145039; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=nUivVDeZe/155VZcAFX2zlj6pYDB5EtffLU674PXSmk=; b=RCZoy/qktAxn/NPhA2zuXHqjXTQWTrXE7X7i4TaWyrvES9mm5sG3alc0 gg4LUij8mPNmVh7R9ppBqJbmyf3kxP5jxlHtlQNyk1TYsMrz3U1E9O5cj zNYGWE9cyTsGJL+Ecz+jbJTDyjWQkrXfqn0FdceRcX80EAlL3ESoOCOW9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACJ5uE2rRDoH/2dsb2JhbAClcHeIcJ8KnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="303443298" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 20:17:15 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqn8027138 for ; Wed, 27 Apr 2011 20:17:15 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:17:15 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:17:15 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:17:15 -0700 Message-Id: To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:17:28 -0000 > 2. "protocol 41" > ---------------- > - Specifically, the issue (A) states that "6to4 has no specified = mechanism to handle the case where > protocol 41 is blocked...". Do other tunneling mechanisms using = protocol 41 have such mechanism? > If they don't, then should usage of protocol 41 be moved to = historic, because the stated filtering/PMTUD > problems are then not specific to RFC 3056? If they do, then = having a brief overview of those and how/why > they don't apply to 6to4 would help to strengthen the statement. >=20 > Action: None Does the working group agree with the summarization of the concern? Do = we agree with the proposed (in)action? Reply if the answer is "no", and give a better suggestion.= From fred@cisco.com Wed Apr 27 13:17:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32F4E0840 for ; Wed, 27 Apr 2011 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.548 X-Spam-Level: X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcg2At9lWrb2 for ; Wed, 27 Apr 2011 13:17:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 95B04E080C for ; Wed, 27 Apr 2011 13:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2036; q=dns/txt; s=iport; t=1303935442; x=1305145042; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=tHqow4z/vVJujMbbBzexd8tXC8gv65pIhc2j4N2ZrS4=; b=ei58wki+rTSreHqq3cJPLed2/qysFUQE5X5/ww5j6tIUQ+dLQFcsfh6F MqNe143b8DFbQy3rxfPvu7KeJarndaEZNh5F7UkTRW6dMW3gkVSf36OWK uKZzX/TMzQEiJAi/bpveI8db9Vbmvb8Y7pLbVBqrnP7X9sxqGv0niPOIQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOd4uE2rRDoH/2dsb2JhbAClcHeIcJ8dnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="437636274" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 20:17:22 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqn9027138 for ; Wed, 27 Apr 2011 20:17:22 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:17:22 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:17:22 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:17:21 -0700 Message-Id: <011CD3B0-3F46-4CA5-959B-E400EA13E0EE@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:17:28 -0000 > 3. "non-RFC1918 addresses" > -------------------------- > - The issue (B), if I understand correctly, it is essentially about = usage of non-RFC1918 addresses in networks, > connected to Internet e.g. using a NAT. There are existing = mitigations to this problem > (e.g. Windows implementation will not configure 6to4 interface if = there is other IPv6 connectivity > in the network; depending on particular implementation, in managed = environments administrators may > have control whether to enable or disable 6to4 on hosts). But even = leaving those mitigations aside, > it seems that the de-prioritization of 6to4 in prefix policy table = below IPv4 in the proposed RFC 3484 > revision would take care of this issue, and moving RFC 3056 is a = much stronger measure, which doesn't > seem to be necessary, as far as the issue (B) is concerned. With = the revised RFC 3484, 6to4 will be one > of the "last resort" mechanisms, which will essentially be used = only if nothing else can, so it won't > be harmful. >=20 > Reply: with the introduction of CGNs non-RFC1918 addresses may have = limited topological span making them > unsuitable for 6to4. >=20 > So to summarize, in my opinion, in the current draft there seem to = be sufficient arguments to move RFC 3068 > to historic, but not RFC 3056. There may be such arguments for RFC = 3056, but if there are, I think they > are not sufficiently reflected in the draft.=20 >=20 > Reply: Current text states: > - Not deployed > - Same problems as 3068 for the reverse path > - Same problem with filtering > - Not working with non-1918 addresses with topologically = limited span >=20 > Actions: Suggestions for text to make it even clearer why also 3056 = needs to be deprecated? Does the working group agree with the summarization of the concern? Do = we agree with the proposed action? Reply if the answer is "no", and give a better suggestion.= From fred@cisco.com Wed Apr 27 13:17:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80C1E0863 for ; Wed, 27 Apr 2011 13:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.551 X-Spam-Level: X-Spam-Status: No, score=-110.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu-8InDpUrY9 for ; Wed, 27 Apr 2011 13:17:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C6F16E0822 for ; Wed, 27 Apr 2011 13:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=596; q=dns/txt; s=iport; t=1303935452; x=1305145052; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=0xhi20aiBeJv5z3i5fnudeIAF6KUu0xm9IIanY5v5Hw=; b=bAv6fEIBIXnyj93ugO2hnULtuBT9Ws8q68vTxt6kXLOI589vOGnN8nTD XQYQ8G/r/rH5dfPLm1fScinPLb3M/W+7dsRS30enCeIiwOIxBpnJsotxV pa5sjy+oW2ouizb1KsgA+f3If6NjFt10ZrR6bWEg920MEqDmQ/2JF9N8z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACJ5uE2rRDoH/2dsb2JhbAClcHeIcJ8KnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="303443549" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 20:17:32 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnA027138 for ; Wed, 27 Apr 2011 20:17:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:17:32 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:17:32 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:17:32 -0700 Message-Id: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:17:33 -0000 > 4. "Phase out plan" > ------------------- > - Now that we have an official WGLC, I'm going to repeat what I = wrote in a previous thread: this draft should > not published in its current form because it sets no standard for = network operations without 6to4. > A phaseout plan for RFC 3056 and RFC 3068 would be required before = I could drop my objections to this draft. >=20 > Action: None. Does the working group agree with the summarization of the concern? Do = we agree with the proposed (in)action? Reply if the answer is "no", and give a better suggestion.= From fred@cisco.com Wed Apr 27 13:17:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DC2E086C for ; Wed, 27 Apr 2011 13:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2-SBVBTlaLR for ; Wed, 27 Apr 2011 13:17:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1B881E086A for ; Wed, 27 Apr 2011 13:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=859; q=dns/txt; s=iport; t=1303935461; x=1305145061; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=GnaUraRxPzDhsVXk7sD410X+8Ax2dRSqDCYMoi+aiXY=; b=j2uYCgSwOSvdACuiBGcUwMer4IRxjVoz8eLS2JR6uDHLhk4q/TpCGTqI s4HEgETHrmbBxD+O4Nl0I410MImqN+3ksawq0lR48ECie36gZxr7QpjLs S+drev9ltyrcCiH+UR1nc9m0LFU/ZI/9sSz/WJaQGtbvvzTvn7XBMzghN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGd5uE2rRDoH/2dsb2JhbAClcHeIcJ8JnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="688255900" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2011 20:17:40 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnB027138; Wed, 27 Apr 2011 20:17:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:17:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:17:40 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:17:40 -0700 Message-Id: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> To: Tore Anderson , Dmitry Anipko Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:17:41 -0000 > 5. "Clarifications" > ------------------- >=20 >> The approach that's most likely to get widespread support is: >>=20 >> 1. make it not be on by default >> 2. make noise about it being A Bad Thing >> 3. deprioritise 2002::/16 addresses in resolver libs >> 4. then make the option hard to find on operating systems / CPEs >> 5. then remove the option on operating systems >> 6. then slowly decommission 6to4 relays over many years >>=20 >> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3.=20 >=20 > I do think it would be useful to elaborate on the arguments Tore = just > provided to Dmitry for deprecation of 3056 in the draft, as a form = of > history writing for the archives. >=20 > Actions: Proposed text? Tore and Dmitry, this appears to be directed to you. Could you please = work with Ole on proposed text?= From fred@cisco.com Wed Apr 27 13:17:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B29E0872 for ; Wed, 27 Apr 2011 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyln+V7-yE51 for ; Wed, 27 Apr 2011 13:17:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id DDF47E0804 for ; Wed, 27 Apr 2011 13:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=806; q=dns/txt; s=iport; t=1303935469; x=1305145069; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=yZTaUWOcFJzoCS7Kc6H74cRC3BkiP6MilQpO9kP7GKY=; b=RWSlkMotCOjximMnGLRyotCCpUuuaf9EMiENBh6XGq/r3e5qC826CG7p eIW7MIlt3hY+mTFdoywVCDJAFSJuh7X4qLjxRS2Tm2I/Du3+YIMzF9syS KexG7p6ulC9U7XcfiPy6kWf/p9fM6sy5BLwMFH8T5obrn5UUi+e/3Qxzv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOd4uE2rRDoH/2dsb2JhbAClcHeIcJ8dnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="437636534" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 20:17:49 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnC027138 for ; Wed, 27 Apr 2011 20:17:49 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:17:49 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:17:49 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:17:49 -0700 Message-Id: To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 6. "Keep peer to peer 6to4" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:17:50 -0000 > 6. "Keep peer to peer 6to4" > --------------------------- > - There are parts which mention relays, and parts which don't. I = think draft-ietf-v6ops-6to4-to-historic=20 > fairly well explains what's wrong with relays, but it doesn't = address what's wrong with 6to4-6to4 > communication. And if there is not much wrong with 6to4-6to4 = scenario (either between the nodes or > between nodes and islands), why should that part be moved to = historic. >=20 > Action: Unsure. 6to4 is useful for e.g. BGP tunneling, as a way of = getting "globally" scoped addresses without an > ISP, can be used for IPv6 transport over other managed = tunnels... none of these uses are described in > 3056, 3068. comments? If you have an opinion in this area, please comment.= From fred@cisco.com Wed Apr 27 13:18:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DFEE0879 for ; Wed, 27 Apr 2011 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63likriHGb9s for ; Wed, 27 Apr 2011 13:18:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F3DD9E0877 for ; Wed, 27 Apr 2011 13:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=614; q=dns/txt; s=iport; t=1303935484; x=1305145084; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=EXubNOCQGsgwewGFz3fzZbe42rns+vN+Ibo2ED5Tjc4=; b=g6PbkduJ8Yp3jPyL16a+FDuuKC7xVE9o7ppyg4nEOB74UHSCOkxJhY5Z MG4BPdx97gv236DKCQLYlSZu2DOahuT7LXO04kVFQcLVRBQz0zGaw7avE 0dXK1ZKAkj3y9tjTYDAGBgijHua71EGD7kAUFo3IfNejn6upCOj/ow4ki A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFACJ5uE2rRDoH/2dsb2JhbAClL0F3iHCfCo8tAY1BhXYEhgOIToQSijo X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="303443906" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 20:18:04 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnD027138 for ; Wed, 27 Apr 2011 20:18:04 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:18:04 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:18:04 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:18:04 -0700 Message-Id: <01CE89BD-C2A8-4956-BB6B-3E3D55B3751B@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 7. "2.0.0.2.ip6.arpa" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:18:07 -0000 > 7. "2.0.0.2.ip6.arpa" >=20 > - There are ancillary services associated with 2.0.0.2.ip6.arpa = which are provided by APNIC under=20 > the auspices of RFC5158. > - I just want to confirm to people that irrespective of this = proposed change, APNIC intends to continue=20 > to provide reverse-DNS delegation, until its clear the community = at large doesn't require the service. >=20 > Action: Issue closed. Does the working group agree with the summarization of the concern? Do = we agree that the issue has been resolved? Reply if the answer is "no", and give a better suggestion.= From fred@cisco.com Wed Apr 27 13:18:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D317E087E for ; Wed, 27 Apr 2011 13:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.559 X-Spam-Level: X-Spam-Status: No, score=-110.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uxZFxvkPmG1 for ; Wed, 27 Apr 2011 13:18:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id C4CE8E087D for ; Wed, 27 Apr 2011 13:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1922; q=dns/txt; s=iport; t=1303935494; x=1305145094; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=j8tzu8/jZ9kJx6BSZdlij193cZedsjKHmABo3+lia1c=; b=SGiP8SvRoFAJzP33Eih51I896R00GdMi7l8HxvzyuclYD/GqIVTG2IDf TnpLBMVl0Rnw0pp3vUlo5yjfw2qf0XE+4jhq2sHnF4bSlh8dcvMsgCV2f 5JapZAdMlqkUgAgzbY2oh5kwYxw/jSOAzMImf53G5/nlKmgNI1rHTwAq5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOd4uE2rRDoH/2dsb2JhbAClcHeIcJ8dnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="437636769" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 20:18:14 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnE027138 for ; Wed, 27 Apr 2011 20:18:14 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:18:14 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:18:14 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:18:13 -0700 Message-Id: <921853D3-4FE7-488C-9B6F-0AD09AFA43FC@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 8. "6to4 to experimental instead of historical" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:18:15 -0000 On Apr 27, 2011, at 12:14 AM, Ole Troan wrote: > 8. "6to4 to experimental instead of historical" > ----------------------------------------------- >=20 > - In my opinion tend to be similar to Jordi's. 6to4 is good for = experimenting with IPv6. > If you need IPv6 service use native solution. But if there no = solution on the market what to do? > - According to our policy our 6to4 relay is only for experimenting = with IPv6 technology..... > What about 6to4 relabeled to experimental? >=20 > Reply: If we postulate that 6to4 is harmful to the deployment of IPv6 = in the Internet then I don't see any > other choice than deprecating it. Speaking for myself, I agree that the question is at least in part = whether "6to4 is a way to experiment" or "6to4 is directly harmful". = Geoff's remarks at IETF-80 supported the notion that 6to4 was actively = harmful, in that it sends traffic into his dark net, which is to say = "places that an intentional user didn't intend". Victor and John have = commented on the requirement for an ISP to divert energy from native = IPv6 deployment to 6to4 relay deployment in order to give their = customers a user experience that they consider acceptable. If the user = experience is unpredictable absent operational support, operational = support of 6to4 distracts from native deployment, and lack of = operational support leads users to conclude that "IPv6 doesn't work and = so should be turned off", the experiment seems a dubious luxury. We can either stay in the "experimentation" phase or move to the = "deployment" phase. It would appear from this discussion and many others = that operators are in the deployment phase. Does the working group agree = with that statement? Do we agree with reclassification of the facility = as historic? Reply if the answer is "no", and give a better suggestion.= From fred@cisco.com Wed Apr 27 13:18:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0A2E0805 for ; Wed, 27 Apr 2011 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.56 X-Spam-Level: X-Spam-Status: No, score=-110.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tZUiuIWcfzX for ; Wed, 27 Apr 2011 13:18:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C29FFE0882 for ; Wed, 27 Apr 2011 13:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1165; q=dns/txt; s=iport; t=1303935504; x=1305145104; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=1bZMoIDG9sfIKTszKYA6ENEQMPmYqArBWJbE0gBO21Y=; b=exENzZLunMwHEutIG6f6J7mb3KxfGTyfLeU0HKYcJhfNYiBuNHMJKlIa 0uEnmwA0In/N33K9vzjQtdfDN5wM12Pe+q8lyo+ziwblqVvpCPRs9240J OnmlQkaLZ/y4WcqV87/sm9xj3PB+NywXgAK0XI8rwzYzcI5swB3JWwN8X s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGd5uE2rRDoH/2dsb2JhbAClcHeneZxvhXYEhgOIToQSijo X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="345863129" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2011 20:18:24 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnF027138; Wed, 27 Apr 2011 20:18:24 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:18:24 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:18:24 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:18:24 -0700 Message-Id: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> To: Erik Kline , Tore Anderson Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:18:45 -0000 I think this should be reworded as " > 9. "why 6to4 is preventing IPv6 roll out" > ----------------------------------------- > - My opinion: There needs to be a clear motivation for why 6to4 is = actively preventing 6to4 roll out. > I think this clear motivation is somewhat lacking in the current = text. The current focus, the way > I read it, is on why 6to4 isn't a great protocol, rather a clear = description of why 6to4 is actively > preventing native IPv6 roll out. There also needs to be a clear = end date for implementation of the > deprecation, to avoid a transition on a transition.=20 >=20 > - But I would suggest that the authors amend the text so that it: > i) better motivates that use of 6to4 is actively preventing roll = out of native IPv6 > ii) includes a clear date for full deprecation (perhaps = immediately), > iii) clarifies what it means to deprecate a protocol whilst still = allowing it as a "last resort" > (or indeed consider changing it to straight deprecation) >=20 > Action: I'll try to word smith some descriptive text. Appreciate some = help Erik/Tore? Erik/Tore?= From fred@cisco.com Wed Apr 27 13:18:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A51E07F6 for ; Wed, 27 Apr 2011 13:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnMEd-cvruDO for ; Wed, 27 Apr 2011 13:18:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 827DEE07C8 for ; Wed, 27 Apr 2011 13:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1020; q=dns/txt; s=iport; t=1303935512; x=1305145112; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=35d6jIoVMAtXykgZ/wsPj2CfK89R4mkmNFHnypyrgVA=; b=jQxfq057fVsleltiGF/WbXHTBYhS/vEwv5ARnZ5ITVhxuxMWSH01svkj 2UH2ChcshOcvbwkk4SeJjjvc3gwAUDHrys+GvWrA/ygoGrYYju/1bztYC 7GBR8psXWiuzvUx+v1O7ZO3P5xvwco+f9+Dt2pYufvwQUyl2X6nk9n+6O A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGd5uE2rRDoH/2dsb2JhbAClcHeIcJ8JnG+FdgSGA4hOhBKKOg X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="688256453" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2011 20:18:32 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RKFqnG027138 for ; Wed, 27 Apr 2011 20:18:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Wed, 27 Apr 2011 13:18:32 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Wed, 27 Apr 2011 13:18:32 -0700 From: Fred Baker Date: Wed, 27 Apr 2011 13:18:31 -0700 Message-Id: <1DD8CFB9-59C0-4C2A-916B-1ABA9D16E9F8@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 6to4-historic summary point: 10. "This is internally inconsistent with S 1: "Declaring the mechanism historic is not expected to have immediate product implications."" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:18:46 -0000 > 10. "This is internally inconsistent with S 1: "Declaring the = mechanism historic is not expected to have > immediate product implications."" > = --------------------------------------------------------------------------= ------------------------------- >=20 > - What's the point if the goal is not to have immediate product = implications? >=20 > - First sentence of S 1 is misleading as already discussed and = should > be removed/rephrased. No need to even mention the BGP model. >=20 > - It might make sense, if that statement is confusing, to remove the = statement. I think the authors are trying > to be pragmatic - "we understand that all software in the world = isn't going to change overnight; > as it changes, this is the direction we'd like it to go". >=20 > Action: Remove statement. Does the working group agree with the summarization of the concern? Do = we agree with the proposed action? Reply if the answer is "no", and give a better suggestion.= From jouni.nospam@gmail.com Wed Apr 27 13:31:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0672CE07EB for ; Wed, 27 Apr 2011 13:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmj4ZDw7ZpB8 for ; Wed, 27 Apr 2011 13:31:01 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE40E072C for ; Wed, 27 Apr 2011 13:31:00 -0700 (PDT) Received: by eye13 with SMTP id 13so779302eye.31 for ; Wed, 27 Apr 2011 13:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=SHEBwNalptVJQ+QaTypTAdjT+uNnqekMaDD7W8c7lu4=; b=JWf74Zn+YF4GfDJqKhu4cUbzu5LWfyueZ6/Oyxusg3FwKL03XCkpfoqE5JA+DwUPdM jgxovBLzIkTAWvuka09R5mdLKDHAIBZzHg5Tbl2N3xefd5NZj6/a4HdbC2U3rdlZd79W 0rsf9kiWKuWAiSJ4tSs8rP3UbZh8Kutf9NjUc= 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=imbQV78LcbvXazwk/cbk/tsDzpZdv20K5oFJwsyrajb/4hSz2AE25uIljVQvm6nVWo 8UjtY7b//QzJ4rOodKXbVhBb8OUiXyIctzG6EtCIt3GPL+sbGjsF8O7xk+9OCkTrmAOV hmD89vxArv2oK+vcuJqhy0rZDgfiPypsP40z4= Received: by 10.213.97.3 with SMTP id j3mr1272212ebn.108.1303936260000; Wed, 27 Apr 2011 13:31:00 -0700 (PDT) Received: from a88-114-64-117.elisa-laajakaista.fi (a88-114-64-117.elisa-laajakaista.fi [88.114.64.117]) by mx.google.com with ESMTPS id y7sm784545eeh.21.2011.04.27.13.30.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 13:30:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <201104071411.p37EBPTN025009@irp-view13.cisco.com> Date: Wed, 27 Apr 2011 23:30:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3EDFD736-4E40-4E74-B368-481D424A600E@gmail.com> References: <201104071411.p37EBPTN025009@irp-view13.cisco.com> To: Fred Baker , IPv6 Operations X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-v6ops-3gpp-eps@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-3gpp-eps-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 20:31:02 -0000 Hi, As mentioned in Prague meeting presentation, the draft could have a = reference to RFC3316 and some text on related topics. Here's the = proposed text: 5.4. IPv6 Neighbor Discovery Considerations 3GPP link between the UE and the next hop router (e.g. GGSN) resemble a point to point (p2p) link, which has no link layer addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. The UE IP stack has to take this into consideration. When the 3GPP PDP Context appears as a PPP interface/link to the UE, the IP stack is usually prepared to handle Neighbor Discovery protocol and the related Neighbor Cache state machine transitions in an appropriate way, even thought Neighbor Discovery protocol messages contain no link layer address information. However, some operating systems discard Router Advertisements on their PPP interface/link as a default setting. This causes the SLAAC to fail when the 3GPP PDP Context gets established, thus stalling all IPv6 traffic. Currently several operating systems and their network drivers can make the 3GPP PDP Context to appear as an IEEE802 interface/link to the IP stack. This has few known issues, especially when the IP stack is made to believe the underlying link has link-layer addresses. First, the Neighbor Advertisement sent by a GGSN as a response to an address resolution triggered Neighbor Solicitation may not contain a Target Link-Layer address option (as suggested in [RFC4861] Section 4.4). Then it is possible that the address resolution never completes when the UE tries to resolve the link- layer address of the GGSN, thus stalling all IPv6 traffic. Second, the GGSN may simply discard all address resolution triggered Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1 that address resolution and next-hop determination are not needed). As a result the address resolution never completes when the UE tries to resolve the link-layer address of the GGSN, thus stalling all IPv6 traffic. - Jouni On Apr 7, 2011, at 5:11 PM, Fred Baker wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/draft-ietf-v6ops-3gpp-eps-00.txt. Please take a = look at it and comment. From brian.e.carpenter@gmail.com Wed Apr 27 14:02:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD302E07A0 for ; Wed, 27 Apr 2011 14:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tV6FCqPdpuD for ; Wed, 27 Apr 2011 14:02:45 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 577CDE062B for ; Wed, 27 Apr 2011 14:02:45 -0700 (PDT) Received: by pzk5 with SMTP id 5so1543843pzk.31 for ; Wed, 27 Apr 2011 14:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n/zMC8oZe2BEvK/a2cNEm8AccU1vCoqXzI/0q0PfnBQ=; b=uLm3WA3Gs+2CpnKjH94VaLq77Y+yK64+FhwrxjrJDUC4IVESAr9GGPEkSJXXCxOK44 guyOcpGTuH/+bW5chcfhT+ddiW2JAM0FZT+ge+zVRMR5O3CwHUPpXeVlV5UnYjH3k6WS ppuaOpI50BF518O1OPhZbfbuS2qvf6Pq9Fp5I= 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=LXJ6w7rlbQd/Z35oI86C5Lnd9QOo6BVzOPARxqSxCqPmy4sSTxMEnxrZVYo7tdJG8z NSFbgDfqaNk9fbN20UE00boFWLVxpTswJRTsmig9EMVQY7mX3x0j5y7hwOlVCRmdTuEV BPrUdMVo3x4wDhuzS4Db5O84v5hrldF3WFww8= Received: by 10.68.38.131 with SMTP id g3mr2662226pbk.516.1303938163088; Wed, 27 Apr 2011 14:02:43 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id x4sm764788pbr.71.2011.04.27.14.02.40 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 14:02:42 -0700 (PDT) Message-ID: <4DB8846B.4010004@gmail.com> Date: Thu, 28 Apr 2011 09:02:35 +1200 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: <4DB723C7.1090905@globis.net> <4DB7BC9F.9000604@globis.net> <124BB081-7D4C-4C73-94F0-8E5C67A5B737@employees.org> <4DB86A2F.2040201@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , v6ops@ietf.org Subject: [v6ops] 6rd and draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:02:46 -0000 On 2011-04-28 07:27, Ole Troan wrote: > Ray, > >> I obviously defer to you as the co-author of RFC5969. >> >> Would it be possible to include some text in your proposal to clarify and encapsulate this view? >> >> e.g. >> >> "Historic Links between 6rd and 6to4 >> >> Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4." > > revision 01 now has the following: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-01 > > 6rd [RFC5969] utilizes the same encapsulation and base mechanism as > 6to4, and could be viewed as a superset of 6to4 (6to4 could be > achieved by setting the 6rd prefix to 2002::/16). However, the > deployment model is such that 6rd can avoid the problems described > here. In this sense, 6rd can be viewed as superseding 6to4 as > described in section 4.2.4 of [RFC2026] > > is that better? Works for me. Also, there is no formal problem with RFC 5969 citing RFC 3056 even if the latter is made Historic. (It would be a wordsmithing problem if RFC 5969 was to be updated.) BTW, Section 5 of draft-ietf-v6ops-6to4-advisory also mentions this topic briefly. Brian > > cheers, > Ole > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Apr 27 14:07:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134E6E07A0 for ; Wed, 27 Apr 2011 14:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.261 X-Spam-Level: X-Spam-Status: No, score=-103.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG0vPyWlxHjM for ; Wed, 27 Apr 2011 14:07:27 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 850C9E072E for ; Wed, 27 Apr 2011 14:07:27 -0700 (PDT) Received: by pwi5 with SMTP id 5so1127931pwi.31 for ; Wed, 27 Apr 2011 14:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zeSjn3YPqHgioPWtxoF9ZtFN1jd9u5jtN6gYxe3XIiM=; b=flW5+PANWfKC0RGQRcJTQLtMk4/lfzqGjsHR4+Iqw0WT78o5D8C/ts2KGZghk8o3Wa 0DZzSIqfmKpaC903zumbUd0u6n5DxL1gEezfv8llegvBLwxTeTwlTsMyAoRuFsneJq3d pyqSswrz63uga3vXQyPhKURKGLsznBQQrIajU= 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=gViclFUPo+JPd6FfZwRAwfYt+18weY2hDzLTUl9crCJul9gtksV+RV6oPsDHNYiaNz m9mmzlQxtrKOvczh/DHR0nMV9PziFT7yGgIApxOUg0QeGMvt+7Gs1f7HHf807GpKOhBv Q7J/zLcSMjT8OwstqELSAtd1v19Y36iRDEJoc= Received: by 10.68.37.106 with SMTP id x10mr2795806pbj.346.1303938446691; Wed, 27 Apr 2011 14:07:26 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id u3sm766321pbn.77.2011.04.27.14.07.24 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 14:07:25 -0700 (PDT) Message-ID: <4DB88589.1020001@gmail.com> Date: Thu, 28 Apr 2011 09:07:21 +1200 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: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> In-Reply-To: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:07:28 -0000 On 2011-04-28 08:17, Fred Baker wrote: >> 5. "Clarifications" >> ------------------- >> >>> The approach that's most likely to get widespread support is: >>> >>> 1. make it not be on by default >>> 2. make noise about it being A Bad Thing >>> 3. deprioritise 2002::/16 addresses in resolver libs >>> 4. then make the option hard to find on operating systems / CPEs >>> 5. then remove the option on operating systems >>> 6. then slowly decommission 6to4 relays over many years >>> >>> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. >> I do think it would be useful to elaborate on the arguments Tore just >> provided to Dmitry for deprecation of 3056 in the draft, as a form of >> history writing for the archives. >> >> Actions: Proposed text? > > Tore and Dmitry, this appears to be directed to you. Could you please work with Ole on proposed text? I'd like to reiterate my view that points 4, 5 and 6 are none of the IETF's business and should not be mentioned in an IETF document. Brian From brian.e.carpenter@gmail.com Wed Apr 27 14:13:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71231E0763 for ; Wed, 27 Apr 2011 14:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.292 X-Spam-Level: X-Spam-Status: No, score=-103.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgBOEhqasdRU for ; Wed, 27 Apr 2011 14:13:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3949E06BC for ; Wed, 27 Apr 2011 14:13:57 -0700 (PDT) Received: by pzk5 with SMTP id 5so1550415pzk.31 for ; Wed, 27 Apr 2011 14:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SI4rq1Tr7YzoX3uNfZRETUKIIy+hTRGoNMsE8kVM7Ys=; b=N/MEnirsoagTutIGBeZ4JywFhwVcKkxRTp07hRAHykNoqzlKiCKDsHLWozdIKf6yEC zYycJTbcmhR0oNMg9z4dBc8UtIaS9ZRLeCmpF3Fk57efkjh25IOUs3qcb37MLflDOqu4 D5G4Xvq2lvmWxZ+wzAsrVdGFtr8tO6UejlIMk= 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=cTDJUZhBoW4Cha1IIKe0Tj81MUCcG3SC1qA1UvHQlk/aAYwnESqB3dcHCNX24XxPtg IrqK869U8pxg4NlnSHOf7/Zo6ypgQcQE0nHHP1IBxKt6kSHrmLFrcMeL8UwJbbEJuY9F YsQCY3v7DlXfL1yXDNokhFS+dIvLA9XvwXHOo= Received: by 10.142.178.14 with SMTP id a14mr743022wff.433.1303938837484; Wed, 27 Apr 2011 14:13:57 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id w14sm900999wfh.20.2011.04.27.14.13.55 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 14:13:57 -0700 (PDT) Message-ID: <4DB88711.6050205@gmail.com> Date: Thu, 28 Apr 2011 09:13:53 +1200 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: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 6. "Keep peer to peer 6to4" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:13:58 -0000 On 2011-04-28 08:17, Fred Baker wrote: >> 6. "Keep peer to peer 6to4" >> --------------------------- >> - There are parts which mention relays, and parts which don't. I think draft-ietf-v6ops-6to4-to-historic >> fairly well explains what's wrong with relays, but it doesn't address what's wrong with 6to4-6to4 >> communication. And if there is not much wrong with 6to4-6to4 scenario (either between the nodes or >> between nodes and islands), why should that part be moved to historic. >> >> Action: Unsure. 6to4 is useful for e.g. BGP tunneling, as a way of getting "globally" scoped addresses without an >> ISP, can be used for IPv6 transport over other managed tunnels... none of these uses are described in >> 3056, 3068. comments? > > If you have an opinion in this area, please comment. There's nothing wrong with a closed user group using 6to4 for p2p communication, just as there's nothing wrong with the managed-routing usage of 6to4 described in RFC3056 (although nobody has ever been reported to use it). But we are now moving from the era when the normal expectation was that ISPs were IPv4-only, so those modes of 6to4 had clear value, to an era when the normal expectation will be that ISPs support IPv6, so those modes of 6to4 will become pointless. Since we can't conveniently declare half an RFC historic, let's just declare the whole thing historic. This act will not cause p2p usage of 6to4 to break, so where's the harm? Brian From brian.e.carpenter@gmail.com Wed Apr 27 14:19:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018DBE07B2 for ; Wed, 27 Apr 2011 14:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.317 X-Spam-Level: X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2TFnFy0T6NC for ; Wed, 27 Apr 2011 14:19:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D920EE070B for ; Wed, 27 Apr 2011 14:19:05 -0700 (PDT) Received: by pzk5 with SMTP id 5so1553149pzk.31 for ; Wed, 27 Apr 2011 14:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eqmta2FOEDnVbYrSRZhfmSxv0Ro9FlLrqCN2gOOeMb4=; b=KXUfJCKdrxpJu7iTdX+0jlR446sba8AhGAnjHRsFjnhoyxWiquMdOKtPZ2OSD0EslE heb5GcKcaQ7Mn3cuZQwzoHDb+cbXnhTmM/CSFCFHF7SzBMR2YuihKpL/mLUdXy7h7waI QsDyDb7imXnMmJELOEhweQor1tZIQkKmNhiHo= 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=CJQZUyaC9j9kpRTzgUh/+4CeeSaqGcLWrQq6WeUhca2otBOwHSvwmAVfCtRRQVQsVc WveERxqbfOVvM3EHAqvKUfXNdK8Uc8RtYiTIb6RplesxgyXmmEdnO00a8S70YIf+25/x n0KqkjoWCiCXH7VJgaVpVCpQe5l/t5TSTP7k8= Received: by 10.68.44.227 with SMTP id h3mr2842028pbm.245.1303939145497; Wed, 27 Apr 2011 14:19:05 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id i7sm777055pbs.7.2011.04.27.14.19.02 (version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 14:19:04 -0700 (PDT) Message-ID: <4DB88844.4020308@gmail.com> Date: Thu, 28 Apr 2011 09:19:00 +1200 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: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> In-Reply-To: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:19:07 -0000 On 2011-04-28 08:18, Fred Baker wrote: > I think this should be reworded as " >> 9. "why 6to4 is preventing IPv6 roll out" > >> ----------------------------------------- >> - My opinion: There needs to be a clear motivation for why 6to4 is actively preventing 6to4 roll out. >> I think this clear motivation is somewhat lacking in the current text. The current focus, the way >> I read it, is on why 6to4 isn't a great protocol, rather a clear description of why 6to4 is actively >> preventing native IPv6 roll out. There also needs to be a clear end date for implementation of the >> deprecation, to avoid a transition on a transition. >> >> - But I would suggest that the authors amend the text so that it: >> i) better motivates that use of 6to4 is actively preventing roll out of native IPv6 >> ii) includes a clear date for full deprecation (perhaps immediately), >> iii) clarifies what it means to deprecate a protocol whilst still allowing it as a "last resort" >> (or indeed consider changing it to straight deprecation) >> >> Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore? > > Erik/Tore? Quoting the -advisory draft: "In many cases, the user may be quite unaware that 6to4 is in use, and when the user contacts a help desk, in all probability the help desk is unable to correctly diagnose the problem. Anecdotally, many help desks simply advise users to disable IPv6, thus defeating the whole purpose of the mechanism, which was to encourage early adoption of IPv6." As far as I can see the evidence *is* anecdotal, so I am not sure this whole point is strong enough for a normative document. The same goes for the assertion that 6to4 is diverting effort from real deployment. Brian From wwwrun@rfc-editor.org Wed Apr 27 16:34:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6EE08B0; Wed, 27 Apr 2011 16:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM6lVpX2A3+Q; Wed, 27 Apr 2011 16:34:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 52F53E08AF; Wed, 27 Apr 2011 16:34:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4415CE079D; Wed, 27 Apr 2011 16:34:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233440.4415CE079D@rfc-editor.org> Date: Wed, 27 Apr 2011 16:34:40 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6204 on Basic Requirements for IPv6 Customer Edge Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:34:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6204 Title: Basic Requirements for IPv6 Customer Edge Routers Author: H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed. Status: Informational Stream: IETF Date: April 2011 Mailbox: shemant@cisco.com, wbeebee@cisco.com, c.donley@cablelabs.com, barbara.stark@att.com, ot@cisco.com Pages: 17 Characters: 37026 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-cpe-router-09.txt URL: http://www.rfc-editor.org/rfc/rfc6204.txt This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. 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 randy@psg.com Thu Apr 28 01:08:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A60BE06C1 for ; Thu, 28 Apr 2011 01:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK9bHuRE7Ghl for ; Thu, 28 Apr 2011 01:08:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 27243E06A6 for ; Thu, 28 Apr 2011 01:08:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QFMFt-0002ID-6D; Thu, 28 Apr 2011 08:07:21 +0000 Date: Thu, 28 Apr 2011 17:08:08 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: References: 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 WG" Subject: Re: [v6ops] 6to4-historic summary point: 1. "has rarely if ever been deployed" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:08:37 -0000 >> 1. "has rarely if ever been deployed" should not have been deployed. same for teredo. they were obviously not really scalable operationally when proposed, and their failure has withstood the test of time very well. one view might be that if relays had been very widely deployed, 6to4 might have been almost usable. but that was not an operationally reasonable expectation. randy From dr@cluenet.de Thu Apr 28 01:29:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF0E06A6 for ; Thu, 28 Apr 2011 01:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF+nBxLq4pJJ for ; Thu, 28 Apr 2011 01:29:51 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF4FE06D6 for ; Thu, 28 Apr 2011 01:29:50 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 50E741080E8; Thu, 28 Apr 2011 10:29:48 +0200 (CEST) Date: Thu, 28 Apr 2011 10:29:48 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110428082948.GA14627@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: 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] 6to4-historic summary point: 1. "has rarely if ever been deployed" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:29:51 -0000 On Thu, Apr 28, 2011 at 05:08:08PM +0900, Randy Bush wrote: > >> 1. "has rarely if ever been deployed" > > should not have been deployed. same for teredo. they were obviously > not really scalable operationally when proposed, and their failure has > withstood the test of time very well. > > one view might be that if relays had been very widely deployed, 6to4 > might have been almost usable. but that was not an operationally > reasonable expectation. I think you are confusing anycast 6to4 (RFC3068) with the "original" 6to4 (RFC3056). The "rarely if ever deployed" comment is in respect to the latter, not the anycast variant. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From randy@psg.com Thu Apr 28 01:42:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BCEE06AD for ; Thu, 28 Apr 2011 01:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.188 X-Spam-Level: X-Spam-Status: No, score=-5.188 tagged_above=-999 required=5 tests=[AWL=1.411, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP5hLpeDt6xJ for ; Thu, 28 Apr 2011 01:42:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2592FE062A for ; Thu, 28 Apr 2011 01:42:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QFMnZ-0002Ne-Nl; Thu, 28 Apr 2011 08:42:10 +0000 Date: Thu, 28 Apr 2011 17:42:56 +0900 Message-ID: From: Randy Bush To: Daniel Roesen In-Reply-To: <20110428082948.GA14627@srv03.cluenet.de> References: <20110428082948.GA14627@srv03.cluenet.de> 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 Subject: Re: [v6ops] 6to4-historic summary point: 1. "has rarely if ever been deployed" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:42:11 -0000 > I think you are confusing anycast 6to4 (RFC3068) with the "original" > 6to4 (RFC3056). The "rarely if ever deployed" comment is in respect to > the latter, not the anycast variant. sigh. apologies. i should shut up when i do not have time to focus. randy From tore.anderson@redpill-linpro.com Thu Apr 28 02:05:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73121E06CA for ; Thu, 28 Apr 2011 02:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOKiPjFicyBj for ; Thu, 28 Apr 2011 02:05:54 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 04E17E06C1 for ; Thu, 28 Apr 2011 02:05:53 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id BB5FCDC1D5; Thu, 28 Apr 2011 11:05:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 IxGrHwchmbdh; Thu, 28 Apr 2011 11:05:52 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 28 Apr 2011 11:05:52 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 874DD170C00B; Thu, 28 Apr 2011 11:05:52 +0200 (CEST) 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 lqBpKkYzhgRh; Thu, 28 Apr 2011 11:05:52 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id F3558170C00A; Thu, 28 Apr 2011 11:05:51 +0200 (CEST) Message-ID: <4DB92DEF.6030008@redpill-linpro.com> Date: Thu, 28 Apr 2011 11:05:51 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Fred Baker References: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> In-Reply-To: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 09:05:55 -0000 * Fred Baker > Tore and Dmitry, this appears to be directed to you. Could you > please work with Ole on proposed text? OK: When 6to4 is used without the mechanism specified in [RFC3068], or as described in [RFC3056] section 5.2, it will operate in «Peer-to-Peer» mode where a 6to4-site/host can only communicate with other 6to4-sites/hosts and not with the global Internet. This is problematic in the situation where such 6to4 connectivity is provided to a site by a 6to4 router (or a 6to4 host with router-like functionality), as the hosts behind the 6to4 router will not be aware that its 6to4 connectivity is restricted in scope to other 6to4 sites, and could therefore attempt to use this connectivity for destinations on the global IPv6 Internet. Doing so will lead to timeouts and a bad user experience, potentially prompting the user to disable IPv6 entirely. While this problem could potentially have been mitigated by having the 6to4 router send RAs with a lifetime of 0 that carries a [RFC4191] More-Specific Route Option for the 6to4 prefix 2002::/16, this method of implementating a 6to4 router has rarely if ever been done. Also, support for the [RFC4191] More-Specific Route option is not universally deployed in common end-user operating systems, and furthermore, one particularly ubiquitous end-user operating system is known to incorrectly interpret a RA lifetime of 0 as «infinite». These realities renders the suggested work-around operationally ineffective on today's Internet. Perhaps too long? Ole, feel free edit and rewrite as you see fit. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From ietfc@btconnect.com Thu Apr 28 07:03:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDBCE0669 for ; Thu, 28 Apr 2011 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqreYjkGYJfK for ; Thu, 28 Apr 2011 07:03:36 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6E105E06F5 for ; Thu, 28 Apr 2011 07:03:35 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr06.btconnect.com with SMTP id CWD67374; Thu, 28 Apr 2011 15:03:32 +0100 (BST) Message-ID: <02e401cc05a4$853acb20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , References: Date: Thu, 28 Apr 2011 15:02:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Poor-1, source=Queried, refid=tid=0001.0A0B0303.4DB973B4.0051, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4DB973B4.0238,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [v6ops] 6to4-historic summary point: 1. "has rarely if ever beendeployed" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 14:03:37 -0000 ----- Original Message ----- From: "Fred Baker" To: Sent: Wednesday, April 27, 2011 10:17 PM > > 1. "has rarely if ever been deployed" > > ------------------------------------- > > - Furthermore, is not true the text in the document that indicates that this > > mechanism is unsuitable for widespread deployment and the same applies to > > "has rarely if ever been deployed". > > - I couldn't find a reference in the draft which would support statement (1). If there has been some > > study showing that 6to4 deployment, by some quantifiable metric, is indeed many times lower than > > deployment of other tunnels (for example, Teredo), then I think having a reference to such data would > > make statement (1) more justified. > > > > Action: clarify the text in the introduction to avoid impression that 6to4 as a whole has never been deployed. > > Does the working group agree with the summarization of the concern? Do we agree with the proposed action? > > Reply if the answer is "no", and give a better suggestion. It is rarely if ever possible to prove a negative without extensive commitment of resources that are rarely if ever justified. Um; I think the formulation clumsy (but not the idea) and have some sympathy for the view that the I-D provides no evidence in support of this statement which, if the statement remains, it should. I would reword it as more of a positive eg "There would appear to be no evidence of any substantial deployment of the variant of 6to4 in which ....." Tom Petch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ietfc@btconnect.com Thu Apr 28 07:05:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61EE06F0 for ; Thu, 28 Apr 2011 07:05:46 -0700 (PDT) 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.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75xUKip4WWse for ; Thu, 28 Apr 2011 07:05:46 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id E5D14E06E0 for ; Thu, 28 Apr 2011 07:05:45 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr06.btconnect.com with SMTP id CWD70090; Thu, 28 Apr 2011 15:05:43 +0100 (BST) Message-ID: <02ea01cc05a4$d32e3ce0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> Date: Thu, 28 Apr 2011 15:04:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Poor-1, source=Queried, refid=tid=0001.0A0B0301.4DB97437.0026, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4DB97437.01B0,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 14:05:46 -0000 ----- Original Message ----- From: "Fred Baker" To: Sent: Wednesday, April 27, 2011 10:17 PM > > 4. "Phase out plan" > > ------------------- > > - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should > > not published in its current form because it sets no standard for network operations without 6to4. > > A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft. > > > > Action: None. > > Does the working group agree with the summarization of the concern? Do we agree with the proposed (in)action? > > Reply if the answer is "no", and give a better suggestion. I agree with the inaction, ie my answer is yes, but think that the new paragraph on 6rd (which I like) is such a standard and might be called out as such. Tom Petch > From tore.anderson@redpill-linpro.com Thu Apr 28 07:22:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C237E06D6 for ; Thu, 28 Apr 2011 07:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSsZtEmq4M29 for ; Thu, 28 Apr 2011 07:22:26 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 49541E06A6 for ; Thu, 28 Apr 2011 07:22:26 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id AE6CCCC7A7; Thu, 28 Apr 2011 16:22:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 o+JswpPU2KEZ; Thu, 28 Apr 2011 16:22:24 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 28 Apr 2011 16:22:23 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 7D1FD170C00C; Thu, 28 Apr 2011 16:22:23 +0200 (CEST) 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 ZpNjmyyGIkiD; Thu, 28 Apr 2011 16:22:23 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id EE9BF170C00B; Thu, 28 Apr 2011 16:22:22 +0200 (CEST) Message-ID: <4DB9781E.8020107@redpill-linpro.com> Date: Thu, 28 Apr 2011 16:22:22 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Fred Baker References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> In-Reply-To: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 14:22:27 -0000 * Fred Baker > I think this should be reworded as " >> 9. "why 6to4 is preventing IPv6 roll out" > >> ----------------------------------------- >> - My opinion: There needs to be a clear motivation for why 6to4 is actively preventing 6to4 roll out. >> I think this clear motivation is somewhat lacking in the current text. The current focus, the way >> I read it, is on why 6to4 isn't a great protocol, rather a clear description of why 6to4 is actively >> preventing native IPv6 roll out. There also needs to be a clear end date for implementation of the >> deprecation, to avoid a transition on a transition. >> >> - But I would suggest that the authors amend the text so that it: >> i) better motivates that use of 6to4 is actively preventing roll out of native IPv6 >> ii) includes a clear date for full deprecation (perhaps immediately), >> iii) clarifies what it means to deprecate a protocol whilst still allowing it as a "last resort" >> (or indeed consider changing it to straight deprecation) >> >> Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore? > > Erik/Tore? I'll try: Content providers have no way of performing a gradual IPv6 deployment, as the presence of an AAAA record in DNS serves as a crude on/off switch. When an AAAA record is published for a web site, a significant number of end users on the Internet will attempt to use the 6to4 connectivity in preference to IPv4. This will, due to the performance and reliability problems 6to4 suffers from [I-D.ietf-v6ops-6to4-advisory], cause an overall decrease in end-user reachability and experienced service quality and/or performance of the web site. In order to avoid this service degradation, a content provider may simply choose to avoid publishing AAAA records altogether [I-D.vandevelde-v6ops-harmful-tunnels]. A content provider may compartmentalise the problem by deploying the technique described in [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications], however this can not solve the problem completely as it is impossible to ascertain that there are no 6to4-users in a whitelisted network. Finally, operating an AAAA whitelist comes with a considerable maintenance burden, which in itself might cause a content provider to opt not to deploy neither a whitelist nor any AAAA records. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From ichiroumakino@gmail.com Thu Apr 28 08:23:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78064E069F for ; Thu, 28 Apr 2011 08:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnDFaa97rrgV for ; Thu, 28 Apr 2011 08:23:24 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7CFBE0670 for ; Thu, 28 Apr 2011 08:23:23 -0700 (PDT) Received: by ewy19 with SMTP id 19so1060503ewy.31 for ; Thu, 28 Apr 2011 08:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :x-priority:in-reply-to:date:cc:content-transfer-encoding:message-id :references:to:x-mailer; bh=4XVaYQohz8DnfsOdjCvEpuI6GmlRwrGhvEYNr6Cu4ew=; b=l8dcn4dBQgBy5RlYAgsckrzWL4nhVeKOJgdPy+jJdK0AdkxKncbR7ctoxoqTEaoIjR TUpuRSFxbmNqwl+Q2BtfSof5vhgSdDJOmyLrepg0otc586UunJXwT5TPwewdM9xCCdna MU8OLIEeJuXI73w8A6U5SIxH2XxU8jy6IGtrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; b=IIkF4EO7HGyBGya3b4vBn1p2qrfGJSTZrOs7qh3NWOO0eoK/xQ+o3S/piwxZoH4OIU IyuFjLTLFA+m1DFeT7oMDdkwMbsyPs91OViKYmjWVHQ+HOF5J33UrcqlNuPIoHSY4Ebt +2fKLt6ayEbXCA9bqPZFz8sLwSNcPAJF7U/wY= Received: by 10.14.27.140 with SMTP id e12mr85173eea.185.1304004202619; Thu, 28 Apr 2011 08:23:22 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id y7sm1357239eeh.14.2011.04.28.08.23.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 08:23:21 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 In-Reply-To: <02e401cc05a4$853acb20$4001a8c0@gateway.2wire.net> Date: Thu, 28 Apr 2011 17:23:19 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <02e401cc05a4$853acb20$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 1. "has rarely if ever beendeployed" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:23:24 -0000 Tom, [...] > I would reword it as more of a positive eg > "There would appear to be no evidence of any substantial deployment of the > variant of 6to4 in which ....." I like this one better too. will change. cheers, Ole From behcetsarikaya@yahoo.com Thu Apr 28 08:35:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01C8E0725 for ; Thu, 28 Apr 2011 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxyjUlROfMHS for ; Thu, 28 Apr 2011 08:35:07 -0700 (PDT) Received: from nm21-vm0.bullet.mail.sp2.yahoo.com (nm21-vm0.bullet.mail.sp2.yahoo.com [98.139.91.220]) by ietfa.amsl.com (Postfix) with SMTP id 1DB1DE071E for ; Thu, 28 Apr 2011 08:35:07 -0700 (PDT) Received: from [98.139.91.70] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 15:35:02 -0000 Received: from [98.139.91.40] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 15:35:02 -0000 Received: from [127.0.0.1] by omp1040.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 15:35:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 217404.54124.bm@omp1040.mail.sp2.yahoo.com Received: (qmail 27875 invoked by uid 60001); 28 Apr 2011 15:35:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304004901; bh=UWhG6JLX9AVlFXAogn/XoG7fLXE7L4Rc2yFPlPC+Hs0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P1hpB99OYW6YGKXEZdm5yybiimQPGLYulpEunUPRRn3XrkS7XvVBZ3Usr/zDQxdLdB6Ca0KeqecMcbnisxU0ng5Ab+tDDXn+h8GZP42/DIt44tNyUIrfy/DTEmqz4j94WYU8CPTKjSCTrdaMOfABNNMciPPsGVAO9UVDtzLhzZA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wv/jOGM+KyeN2q6q0EjzlXjNYxgW8cMx5REP37DXUo4pjS5wWvXlCnnz3lMGWwMGD9jHJpylnTRr6dDyp8QXlIrnxZ95bRgvH2J225bwL2jMdps6xSAZgmGwmV1PbPtCV9BxEkYb4QL+vut7EuayMde7mtAeNhYD0c1XHastI4U=; Message-ID: <54043.2203.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: O2yO8ZQVM1nLd2HTLTSJPD7lxnMz7G0i10xYRXYGnfd1wfh DrdWlxLmEFBZvJgO8E3DGnhZ4Nj6nE0Z88XH6T2c.cqAQjUL21zRbBeNmMp0 yWIYvIClyMgjBkELvJHiSRvHjcM3IPO8tr.BpxzSEYqkeoTUjSVJ5xJ6Duie af_UnkFeK4Vw8KRbZ0Tm_lSa3lEsB0wxo9amRgLn4LfqJ_.Z_SuIDk1Ju0f8 D0XdQtSdKliTlSPjly2FRxGwzMVGePm5tDFY7OuQEMvj5_0d8hn4S8SSYmMU GPr5tAobI.us2.JCzncsX_jA4fqteZXccNXQ1DuhrmiRZaUHqOfDF9cD.sma .56YJW0jqVw0BZQPrUc.9bFNrMQoWWdzID5xL2NmVyNnDSuyIJh4biipbq99 v6NO3RLz5j9bmvg-- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Thu, 28 Apr 2011 08:35:00 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <201104071411.p37EBPTN025009@irp-view13.cisco.com> <3EDFD736-4E40-4E74-B368-481D424A600E@gmail.com> Date: Thu, 28 Apr 2011 08:35:00 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen , IPv6 Operations In-Reply-To: <3EDFD736-4E40-4E74-B368-481D424A600E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-v6ops-3gpp-eps@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-3gpp-eps-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:35:07 -0000 > Hi, > > As mentioned in Prague meeting presentation, the draft could have a reference >to RFC3316 and some text on related topics. Here's the proposed text: > > 5.4. IPv6 Neighbor Discovery Considerations > > 3GPP link between the UE and the next hop router (e.g. GGSN) > resemble a point to point (p2p) link, which has no link layer > addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. I think this has been fixed in EPS. PDN GW sends UE Interface Identifier in Create Default Bearer Response message and IId eventually gets delivered to the UE. The solution applies to 3G MS's connected to the EPC via R8 SGSNs. Regards, Behcet From Dmitry.Anipko@microsoft.com Thu Apr 28 10:29:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A543E06EF for ; Thu, 28 Apr 2011 10:29:54 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLxWYDMj7eaB for ; Thu, 28 Apr 2011 10:29:53 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4A556E06D0 for ; Thu, 28 Apr 2011 10:29:53 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Apr 2011 10:29:52 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 28 Apr 2011 10:29:52 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Thu, 28 Apr 2011 10:29:25 -0700 From: Dmitry Anipko To: Tore Anderson , Fred Baker Date: Thu, 28 Apr 2011 10:29:24 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwFr8AkzGkK5knCQZic4GOvpa4ZUAAGSxjw Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> In-Reply-To: <4DB9781E.8020107@redpill-linpro.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 WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:29:54 -0000 Hello Tore, If such addition is to be made to the draft, I'd suggest to say that impact= of this particular problem is limited to nodes not implementing RFC 3484 f= or the address selection (that is, by market share, a small minority of the= nodes), and the operating systems and applications which do not implement = RFC 3484 shall be updated. Thank you, Dmitry -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= ore Anderson Sent: Thursday, April 28, 2011 7:22 AM To: Fred Baker Cc: v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" * Fred Baker > I think this should be reworded as " >> 9. "why 6to4 is preventing IPv6 roll out" >=20 >> ----------------------------------------- >> - My opinion: There needs to be a clear motivation for why 6to4 is act= ively preventing 6to4 roll out. >> I think this clear motivation is somewhat lacking in the current tex= t. The current focus, the way >> I read it, is on why 6to4 isn't a great protocol, rather a clear des= cription of why 6to4 is actively >> preventing native IPv6 roll out. There also needs to be a clear end = date for implementation of the >> deprecation, to avoid a transition on a transition.=20 >> >> - But I would suggest that the authors amend the text so that it: >> i) better motivates that use of 6to4 is actively preventing roll out= of native IPv6 >> ii) includes a clear date for full deprecation (perhaps immediately)= , >> iii) clarifies what it means to deprecate a protocol whilst still al= lowing it as a "last resort" >> (or indeed consider changing it to straight deprecation) >> >> Action: I'll try to word smith some descriptive text. Appreciate some he= lp Erik/Tore? >=20 > Erik/Tore? I'll try: Content providers have no way of performing a gradual IPv6 deployment, as the presence of an AAAA record in DNS serves as a crude on/off switch. When an AAAA record is published for a web site, a significant number of end users on the Internet will attempt to use the 6to4 connectivity in preference to IPv4. This will, due to the performance and reliability problems 6to4 suffers from [I-D.ietf-v6ops-6to4-advisory], cause an overall decrease in end-user reachability and experienced service quality and/or performance of the web site. In order to avoid this service degradation, a content provider may simply choose to avoid publishing AAAA records altogether [I-D.vandevelde-v6ops-harmful-tunnels]. A content provider may compartmentalise the problem by deploying the technique described in [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications], however this can not solve the problem completely as it is impossible to ascertain that there are no 6to4-users in a whitelisted network. Finally, operating an AAAA whitelist comes with a considerable maintenance burden, which in itself might cause a content provider to opt not to deploy neither a whitelist nor any AAAA records. --=20 Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From tore.anderson@redpill-linpro.com Thu Apr 28 11:10:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62665E06C8 for ; Thu, 28 Apr 2011 11:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbB9GjMEMN8z for ; Thu, 28 Apr 2011 11:10:14 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id B5754E0670 for ; Thu, 28 Apr 2011 11:10:12 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id C7522DC2ED; Thu, 28 Apr 2011 20:10:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 WX0mEy7LGrkL; Thu, 28 Apr 2011 20:10:09 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 28 Apr 2011 20:10:09 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 7D78B170C00C; Thu, 28 Apr 2011 20:10:09 +0200 (CEST) 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 8P-ydySy1Y5b; Thu, 28 Apr 2011 20:10:06 +0200 (CEST) Received: from envy.fud.no (unknown [77.40.198.54]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id D4BC3170C00A; Thu, 28 Apr 2011 20:10:05 +0200 (CEST) Message-ID: <4DB9AD7D.2020102@redpill-linpro.com> Date: Thu, 28 Apr 2011 20:10:05 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 18:10:15 -0000 * Dmitry Anipko > If such addition is to be made to the draft, I'd suggest to say that > impact of this particular problem is limited to nodes not > implementing RFC 3484 for the address selection (that is, by market > share, a small minority of the nodes), and the operating systems and > applications which do not implement RFC 3484 shall be updated. Hi Dmitry, I have no problems with that. I'll leave it up to Ole on how to work that into the text, though. You're right it's a minority of users that prefer 6to4 over IPv4, but it's currently about 3 out of 10 Mac users (if my numbers from Norway is indicative of the global Mac OS X version distribution), which probably means it's millions of users world-wide. That said, no released Mac OS X version implements RFC 3484 to the best of my knownledge; however Apple did fortunately make a change in recent 10.6 Snow Leopard that specifically de-preferred 6to4 to IPv4. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From ichiroumakino@gmail.com Thu Apr 28 11:38:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80AE0681 for ; Thu, 28 Apr 2011 11:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMUPVvqz1CJA for ; Thu, 28 Apr 2011 11:38:04 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1EDBE0670 for ; Thu, 28 Apr 2011 11:38:03 -0700 (PDT) Received: by ewy19 with SMTP id 19so1127841ewy.31 for ; Thu, 28 Apr 2011 11:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=t0uaYk4jS/N6sDVeCaVedv4aQZIw7u214+H+Mx67EkY=; b=snQ9DEXH8w8ZuyUjVdf/pVVttziP2A90Wjmye/GdKK80+n0ClJXbeWd9OGV2iIiFzS fRyxRDODVLPqsxdSjQ1HoIs4xjYVPhcW4E0ymSb6+b+AKX3Kyace4inphtKm8Knh0cFD e0Q7Qy7EAhGNWwNaoonpO9+Crt665kFZlePzY= 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=ux0S31c2w/7YQhxHeyMkd0o9tXjTzuZxWMSOq1h6MvkRa/qjnDvbihWYkmxbM7/BFK 5MhoEbUmz/s1TwFx4/P88ad4cfsLZe7Y2g1xvTA57LLzT7RrtvV0bkRPprbqgCRyPRoy mnTQLsQFR9eGTr2aidOUdOpyntosEEA5o5mvA= Received: by 10.213.103.72 with SMTP id j8mr3269382ebo.137.1304015882780; Thu, 28 Apr 2011 11:38:02 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id s49sm1461923eei.26.2011.04.28.11.38.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 11:38:01 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4DB9AD7D.2020102@redpill-linpro.com> Date: Thu, 28 Apr 2011 20:37:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 18:38:05 -0000 >> If such addition is to be made to the draft, I'd suggest to say that >> impact of this particular problem is limited to nodes not >> implementing RFC 3484 for the address selection (that is, by market >> share, a small minority of the nodes), and the operating systems and >> applications which do not implement RFC 3484 shall be updated. >=20 > Hi Dmitry, >=20 > I have no problems with that. I'll leave it up to Ole on how to work > that into the text, though. >=20 > You're right it's a minority of users that prefer 6to4 over IPv4, but > it's currently about 3 out of 10 Mac users (if my numbers from Norway = is > indicative of the global Mac OS X version distribution), which = probably > means it's millions of users world-wide. That said, > no released Mac OS X version implements RFC 3484 to the best of my > knownledge; however Apple did fortunately make a change in recent 10.6 > Snow Leopard that specifically de-preferred 6to4 to IPv4. that's only measured at a web site.=20 if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of = other traffic too. http://www.potaroo.net/ispcol/2011-04/teredo.html created by applications doing their 'own' thing and not following the = default policy table. cheers, Ole= From martin@millnert.se Thu Apr 28 13:07:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5B9E06EF for ; Thu, 28 Apr 2011 13:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUUI-NVBo15Z for ; Thu, 28 Apr 2011 13:07:45 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 60BDEE0724 for ; Thu, 28 Apr 2011 13:07:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 6590F77EE; Thu, 28 Apr 2011 22:23:34 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxvT+b8I2vgZ; Thu, 28 Apr 2011 22:23:34 +0200 (CEST) Received: from [IPv6:2a02:9a0:100:2800::53] (dns.shakira.millnert.se [IPv6:2a02:9a0:100:2800::53]) by ncis.csbnet.se (Postfix) with ESMTPSA id 4397076C5; Thu, 28 Apr 2011 22:23:32 +0200 (CEST) From: Martin Millnert To: Ole Troan In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 28 Apr 2011 16:07:41 -0400 Message-ID: <1304021261.4286.171.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:07:46 -0000 Ole, part of this is slightly off-topic, to point 9, but highly on-topic in general. On Thu, 2011-04-28 at 20:37 +0200, Ole Troan wrote: > that's only measured at a web site. > if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of other traffic too. > http://www.potaroo.net/ispcol/2011-04/teredo.html > > created by applications doing their 'own' thing and not following the default policy table. Yes and no. Yes, there is a substantial amount of Teredo traffic, yet the protocol is virtually never used for HTTP. No, I find no suggestion in his article that this traffic is created by "applications doing their 'own' thing and not following the default policy table". To take a very real example: the various torrent DHT "clouds" are teeming with IPv6 end-point addresses. Connecting to these with Teredo, if available, is in accordance with 3484, if that is the only v6 connectivity a host has. The alternative is, of course, to not connect to them at all. Same goes for a host using any other form of IPv6 connectivity to make a connection. These are not hostnames resolving to A/AAAA records. And even if they were, as Geoff points out in his article, Windows 7/Vista will not even resolve the AAAA record, if Teredo is the only non-link-local v6 connectivity a host has! Now we may discuss an operating system not following the default policy table, but not applications. Let me drive my point home: People say/argue Teredo (and 6to4) is bad because many connections fail, among other problems, but Teredo isn't the black sheep in the automated v6-tunneling family, and it does address a very real problem (lack of IPv6 connectivity). I haven't heard a single content provider say they will hold back deployment of AAAA records because of it. The responsible thing for IETF to do wrt. any deprecation of Teredo is to provide a realistic alternative solution *before* doing so (to include in a phase-out plan of the protocol, for example), unless it wants to be tilting at windmills. If Teredo can be replaced by another protocol addressing the same problem space, which somehow has a much better connection rate, I would be all for that :) If not, the problem does not really truly lie with the IETF, short of a Teredo-advisory. I do think this may be showing that 3484 is insufficient when it comes to addressing (no pun intended) the *varying* connectivity needs of various applications: Some applications, predominantly such with plenty of redundancy, are quite fine with a v6 where connections fail 1 out of 3 times. To me this mostly shows how insufficient non-end-to-end NATed IPv4 is on the Internet today. Other applications really depend on their connections to succeed if attempted, and would probably prefer to fail with -EINADEQUATECONNECTIVITYPRESENT, rather than launch a connection attempt using last-resort connectivity. More skilled socket API folks than I are highly welcome to school me on the following idea: If OS socket API:s were to provide a way for applications to require better-than-last-resort connectivity (or inverse, accept last-resort connectivity), that could be useful for application developers IMO. I guess it could be a two-dimensional approach, with the ability to make or relax this requirement on both the source and the destination address. Blizzard recently seems to have figured out to suggest native IPv6 to be used ("Use IPv6" box default checked with this connectivity present at the box), but not 6to4/Teredo ("Use IPv6" defaults to unchecked). This seems IMO like a useful approach in addressing this problem, i.e, application-specific, since only the application itself can know its requirements. Best, Martin From fred@cisco.com Thu Apr 28 13:32:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F6EE06D2 for ; Thu, 28 Apr 2011 13:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.966 X-Spam-Level: X-Spam-Status: No, score=-109.966 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCFstgQoC4xr for ; Thu, 28 Apr 2011 13:32:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 172DEE069A for ; Thu, 28 Apr 2011 13:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5530; q=dns/txt; s=iport; t=1304022733; x=1305232333; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=IVlkZPiMPec4iIfNaPmUcWjRDX1ObPmveehWSroAehE=; b=EDJn9zfqexCoXiKmA7grnPFIBeTx+fJWaEt14EleZAR+TEc8kR9L+Nct 1P7PvNsH0uWOslr2JnfuvtKFXG5PmGKS+aOPJ/aCSRspOfOEfLToL6qEH 3i0jb6rpb2u25Wa7wWVKX7FnseiLMWrGl4AlqwAfDXuvRnrMtLrN+SXlG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO7NuU2rRDoI/2dsb2JhbACmBXeIcJ92nQ2FdgSGCYhThBSKFQ X-IronPort-AV: E=Sophos;i="4.64,283,1301875200"; d="scan'208";a="438430193" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 28 Apr 2011 20:32:08 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3SKW2jm003676; Thu, 28 Apr 2011 20:32:07 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 28 Apr 2011 13:32:07 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 28 Apr 2011 13:32:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <1304021261.4286.171.camel@shakira.millnert.se> Date: Thu, 28 Apr 2011 13:31:51 -0700 Message-Id: <53409792-E6F4-4AC6-9DE0-037A8AD5D62C@cisco.com> References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <1304021261.4286.171.camel@shakira.millnert.se> To: Martin Millnert X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:32:14 -0000 On Apr 28, 2011, at 1:07 PM, Martin Millnert wrote: > Ole,=20 >=20 > part of this is slightly off-topic, to point 9, but highly on-topic in > general. Correct me if I'm wrong; the comment is specific to Teredo and not to = 6to4, correct? Speaking strictly for myself, I would seriously wonder why the = alternative to any overlay architecture is not native deployment. The = concern raised with 6to4 is the set of use cases in which it doesn't = work as expected, for any of a variety of reasons, and as a result = inhibits consumer interest in IPv6 or distracts service provider = attention from native deployment. If your statement is that the IETF is = irresponsible in pointing out a deployment solution that isn't working = as well as hoped for without providing an alternative, I think the IETF = has set forth (and service providers are in the process of deploying) a = replacement. What I do not expect the IETF to do is recommend one overlay = architecture instead of another. In RFC 6180 (aka = draft-arkko-ipv6-transition-guidelines), Jari and I tried to point out = things that were known to work in deployment as general advice in "how = to get over a bump in the deployment roadmap", but our point was = explicitly not to say "deploy this overlay and stop". To our minds, and = I understood the working group's mind, the finish-line is "the universal = deployment of native IPv6". > On Thu, 2011-04-28 at 20:37 +0200, Ole Troan wrote: > >> that's only measured at a web site.=20 >> if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of = other traffic too. >> http://www.potaroo.net/ispcol/2011-04/teredo.html >>=20 >> created by applications doing their 'own' thing and not following the = default policy table. >=20 > Yes and no. > Yes, there is a substantial amount of Teredo traffic, yet the protocol > is virtually never used for HTTP. > No, I find no suggestion in his article that this traffic is created = by > "applications doing their 'own' thing and not following the default > policy table". =20 >=20 > To take a very real example: the various torrent DHT "clouds" are > teeming with IPv6 end-point addresses. Connecting to these with = Teredo, > if available, is in accordance with 3484, if that is the only v6 > connectivity a host has. The alternative is, of course, to not = connect > to them at all. Same goes for a host using any other form of IPv6 > connectivity to make a connection. > These are not hostnames resolving to A/AAAA records. And even if they > were, as Geoff points out in his article, Windows 7/Vista will not = even > resolve the AAAA record, if Teredo is the only non-link-local v6 > connectivity a host has! Now we may discuss an operating system not > following the default policy table, but not applications. >=20 >=20 > Let me drive my point home: >=20 > People say/argue Teredo (and 6to4) is bad because many connections = fail, > among other problems, but Teredo isn't the black sheep in the = automated > v6-tunneling family, and it does address a very real problem (lack of > IPv6 connectivity). I haven't heard a single content provider say they > will hold back deployment of AAAA records because of it. > The responsible thing for IETF to do wrt. any deprecation of Teredo = is > to provide a realistic alternative solution *before* doing so (to > include in a phase-out plan of the protocol, for example), unless it > wants to be tilting at windmills. >=20 > If Teredo can be replaced by another protocol addressing the same > problem space, which somehow has a much better connection rate, I = would > be all for that :) If not, the problem does not really truly lie with > the IETF, short of a Teredo-advisory. >=20 >=20 > I do think this may be showing that 3484 is insufficient when it comes > to addressing (no pun intended) the *varying* connectivity needs of > various applications: =20 > Some applications, predominantly such with plenty of redundancy, are > quite fine with a v6 where connections fail 1 out of 3 times. To me = this > mostly shows how insufficient non-end-to-end NATed IPv4 is on the > Internet today. > Other applications really depend on their connections to succeed if > attempted, and would probably prefer to fail with > -EINADEQUATECONNECTIVITYPRESENT, rather than launch a connection = attempt > using last-resort connectivity. >=20 > More skilled socket API folks than I are highly welcome to school me = on > the following idea: > If OS socket API:s were to provide a way for applications to require > better-than-last-resort connectivity (or inverse, accept last-resort > connectivity), that could be useful for application developers IMO. =20= > I guess it could be a two-dimensional approach, with the ability to = make > or relax this requirement on both the source and the destination > address. >=20 > Blizzard recently seems to have figured out to suggest native IPv6 to = be > used ("Use IPv6" box default checked with this connectivity present at > the box), but not 6to4/Teredo ("Use IPv6" defaults to unchecked). > This seems IMO like a useful approach in addressing this problem, i.e, > application-specific, since only the application itself can know its > requirements. >=20 > Best, > Martin >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gih@apnic.net Thu Apr 28 13:36:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD49E06D7 for ; Thu, 28 Apr 2011 13:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.62 X-Spam-Level: X-Spam-Status: No, score=-98.62 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, RELAY_IS_203=0.994, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RIwJ51hIIMG for ; Thu, 28 Apr 2011 13:36:10 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 62151E06C3 for ; Thu, 28 Apr 2011 13:36:09 -0700 (PDT) Received: from [203.119.76.150] (unknown [203.119.76.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8ABE0B6731; Fri, 29 Apr 2011 06:36:07 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 29 Apr 2011 06:36:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:36:10 -0000 On 29/04/2011, at 4:37 AM, Ole Troan wrote: >>> If such addition is to be made to the draft, I'd suggest to say that >>> impact of this particular problem is limited to nodes not >>> implementing RFC 3484 for the address selection (that is, by market >>> share, a small minority of the nodes), and the operating systems and >>> applications which do not implement RFC 3484 shall be updated. >>=20 >> Hi Dmitry, >>=20 >> I have no problems with that. I'll leave it up to Ole on how to work >> that into the text, though. >>=20 >> You're right it's a minority of users that prefer 6to4 over IPv4, but >> it's currently about 3 out of 10 Mac users (if my numbers from Norway = is >> indicative of the global Mac OS X version distribution), which = probably >> means it's millions of users world-wide. That said, >> no released Mac OS X version implements RFC 3484 to the best of my >> knownledge; however Apple did fortunately make a change in recent = 10.6 >> Snow Leopard that specifically de-preferred 6to4 to IPv4. >=20 > that's only measured at a web site.=20 > if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of = other traffic too. > http://www.potaroo.net/ispcol/2011-04/teredo.html >=20 > created by applications doing their 'own' thing and not following the = default policy table. I believe I can confirm this. The recent Ipv6 study by Arbor Networks = found a hefty proportion of peer-to-peer traffic using Ipv6. What I have found is by passive = listening to 2400::/12, where what I see is dominated by high-numbered port TCP connection = events, predominated=20 from Teredo source addresses. Extrapolating a bit, what I understand is that a number of popular = peer-to-peer applications now offer IPv6 as an option, and latch onto the V6 = interfaces that are present on the host. Geoff =20 From Dmitry.Anipko@microsoft.com Thu Apr 28 13:44:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AD4E071E for ; Thu, 28 Apr 2011 13:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxYNRoMXQvTk for ; Thu, 28 Apr 2011 13:44:54 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 08BB5E06C3 for ; Thu, 28 Apr 2011 13:44:53 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Apr 2011 13:44:53 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 28 Apr 2011 13:44:51 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Thu, 28 Apr 2011 13:44:23 -0700 From: Dmitry Anipko To: Geoff Huston , Ole Troan Date: Thu, 28 Apr 2011 13:44:20 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwF4+n8TZeRWAYvQi6NVgWRlDclxAAALS1g Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> In-Reply-To: <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.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: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:44:55 -0000 As far as I see, these data don't invalidate the statement that for the pro= blem Tore described (IPv6 deployments are affected by 6to4), it is still tr= ue that only applications and operating systems not implementing RFC 3484 a= re affected? -----Original Message----- From: Geoff Huston [mailto:gih@apnic.net]=20 Sent: Thursday, April 28, 2011 1:36 PM To: Ole Troan Cc: Tore Anderson; Dmitry Anipko; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" On 29/04/2011, at 4:37 AM, Ole Troan wrote: >>> If such addition is to be made to the draft, I'd suggest to say that >>> impact of this particular problem is limited to nodes not >>> implementing RFC 3484 for the address selection (that is, by market >>> share, a small minority of the nodes), and the operating systems and >>> applications which do not implement RFC 3484 shall be updated. >>=20 >> Hi Dmitry, >>=20 >> I have no problems with that. I'll leave it up to Ole on how to work >> that into the text, though. >>=20 >> You're right it's a minority of users that prefer 6to4 over IPv4, but >> it's currently about 3 out of 10 Mac users (if my numbers from Norway is >> indicative of the global Mac OS X version distribution), which probably >> means it's millions of users world-wide. That said, >> no released Mac OS X version implements RFC 3484 to the best of my >> knownledge; however Apple did fortunately make a change in recent 10.6 >> Snow Leopard that specifically de-preferred 6to4 to IPv4. >=20 > that's only measured at a web site.=20 > if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of oth= er traffic too. > http://www.potaroo.net/ispcol/2011-04/teredo.html >=20 > created by applications doing their 'own' thing and not following the def= ault policy table. I believe I can confirm this. The recent Ipv6 study by Arbor Networks found= a hefty proportion of peer-to-peer traffic using Ipv6. What I have found is by passive listening = to 2400::/12, where what I see is dominated by high-numbered port TCP connection events, = predominated=20 from Teredo source addresses. Extrapolating a bit, what I understand is that a number of popular peer-to-= peer applications now offer IPv6 as an option, and latch onto the V6 interfaces = that are present on the host. Geoff =20 From jouni.nospam@gmail.com Thu Apr 28 13:47:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D71E072B for ; Thu, 28 Apr 2011 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZhjCGxR58TM for ; Thu, 28 Apr 2011 13:47:52 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79607E0728 for ; Thu, 28 Apr 2011 13:47:52 -0700 (PDT) Received: by ewy19 with SMTP id 19so1167628ewy.31 for ; Thu, 28 Apr 2011 13:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+c4fJR3gSdnhh2PG4sZRPsdPe/iNpgmXM8KpizkyjkY=; b=REZsvOAUICl5a4klC92j3aTqnrR67rTDOGSr0RG4+8R7UuHGtnaV81RVxWy2UeigHx QXrgFy7BOcKCb7kbeiPyhM8/AprEDMzngbSVTGdBuUb8oxfqNvbLt5hTHRCBzJgR3u57 7GmMRocHFz5h4gT437cWnYRa9Imr2h4sy77n4= 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=K4ZcJPb6WDzZTUsh0J/vr91BtCoS5z6MFuWim4bhxhi5NtQ2Jp3rtNB9U/CAnJ07qY i5gP4Cguqi5zp/2MOYiDMePF0T7QunLDc2fW2cmR4X0MoNE8fRpPPNt+RMkyUwHNl7rj lDDUx0pF+uM20UkzsrrssjV2LmcmYLaHthLG8= Received: by 10.213.9.72 with SMTP id k8mr1875295ebk.1.1304023671273; Thu, 28 Apr 2011 13:47:51 -0700 (PDT) Received: from a88-114-64-117.elisa-laajakaista.fi (a88-114-64-117.elisa-laajakaista.fi [88.114.64.117]) by mx.google.com with ESMTPS id s50sm1535872eeh.8.2011.04.28.13.47.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 13:47:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <54043.2203.qm@web111408.mail.gq1.yahoo.com> Date: Thu, 28 Apr 2011 23:47:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <78805B3F-9D2B-457F-B8C7-7AB548CD3010@gmail.com> References: <201104071411.p37EBPTN025009@irp-view13.cisco.com> <3EDFD736-4E40-4E74-B368-481D424A600E@gmail.com> <54043.2203.qm@web111408.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , draft-ietf-v6ops-3gpp-eps@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-3gpp-eps-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:47:53 -0000 You are mixing topics now. The text below talks about link-layer = addresses, not interface identifiers. See Section 5.2 for a discussion = about interface identifiers. - Jouni On Apr 28, 2011, at 6:35 PM, Behcet Sarikaya wrote: >=20 >=20 >=20 >=20 >=20 >> Hi, >>=20 >> As mentioned in Prague meeting presentation, the draft could have a = reference=20 >=20 >> to RFC3316 and some text on related topics. Here's the proposed = text: >>=20 >> 5.4. IPv6 Neighbor Discovery Considerations >>=20 >> 3GPP link between the UE and the next hop router (e.g. GGSN) >> resemble a point to point (p2p) link, which has no link layer >> addresses [RFC3316] and this has not changed from 2G/3G GPRS to = EPS. >=20 > I think this has been fixed in EPS. > PDN GW sends UE Interface Identifier in=20 > Create Default Bearer Response message and IId eventually gets = delivered to the=20 > UE. > The solution applies to 3G MS's connected to the EPC via R8 SGSNs. >=20 > Regards, >=20 > Behcet >=20 From tore.anderson@redpill-linpro.com Thu Apr 28 14:02:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA575E06D7 for ; Thu, 28 Apr 2011 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkTbUj5CExhU for ; Thu, 28 Apr 2011 14:02:35 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F5E06C3 for ; Thu, 28 Apr 2011 14:02:34 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 9CAFFDC376; Thu, 28 Apr 2011 23:02:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 JG7-tk8yJJHQ; Thu, 28 Apr 2011 23:02:33 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 28 Apr 2011 23:02:33 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 44E89170C00C; Thu, 28 Apr 2011 23:02:33 +0200 (CEST) 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 XvEhHTykgtVg; Thu, 28 Apr 2011 23:02:32 +0200 (CEST) Received: from envy.fud.no (unknown [77.40.198.54]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 5CD47170C00B; Thu, 28 Apr 2011 23:02:32 +0200 (CEST) Message-ID: <4DB9D5E8.4080703@redpill-linpro.com> Date: Thu, 28 Apr 2011 23:02:32 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 21:02:39 -0000 * Dmitry Anipko > As far as I see, these data don't invalidate the statement that for > the problem Tore described (IPv6 deployments are affected by 6to4), > it is still true that only applications and operating systems not > implementing RFC 3484 are affected? Hi again, Ole pointed out, quite correctly, that my data only revolves around measurements done from a web site's vantage point. Shame on me for forgetting for a second that the internet is more than just the web. Ole is also correct in that applications can do whatever they like. Opera <= 10.10 is a very good example of this happening, it preferred Teredo and 6to4 over IPv4, even when running on Windows (which implements RFC 3484). Fortunately, Opera users have shown themselves to be good at upgrading, so for HTTP traffic, the problem of applications doing their own thing is for the most part solved now. However, I have no idea what the situation is like for any non-HTTP services; I'm not aware of any focused research here. But if there's a great number of applications that do their own resolving in a non-RFC3484 manner, the situation could very well be significantly worse than it is for HTTP is right now. And even if every single application for the service in question is well-behaved and uses the operating system-provided resolver interfaces, there's still too many users using OSes that do not implement RFC3484 to ignore. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From Dmitry.Anipko@microsoft.com Thu Apr 28 14:28:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F56CE0730 for ; Thu, 28 Apr 2011 14:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.346 X-Spam-Level: X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cpXRsP5P-5z for ; Thu, 28 Apr 2011 14:28:09 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 282D6E06C3 for ; Thu, 28 Apr 2011 14:28:09 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Apr 2011 14:28:08 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 28 Apr 2011 14:28:08 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Thu, 28 Apr 2011 14:28:08 -0700 From: Dmitry Anipko To: Tore Anderson Date: Thu, 28 Apr 2011 14:28:06 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwF55n5ZlY15DwTTS2ghHKmXcGxHQAAj13w Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> In-Reply-To: <4DB9D5E8.4080703@redpill-linpro.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 WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 21:28:10 -0000 Hello Tore, >> Ole pointed out, quite correctly, that my data only revolves around measurements done from a web site's vantage point >> However, I have no idea what the situation is like for any non-HTTP services; I'm not aware of any focused research here. I'm trying to understand - how does this change the problem statement you m= ade in the proposed addition to the draft: "as the hosts behind the 6to4 ro= uter will not be aware that its 6to4 connectivity is restricted in scope to= other 6to4 sites, and could therefore attempt to use this connectivity for= destinations on the global IPv6 Internet"?=20 If these data don't affect the problem statement, then you've agreed that t= he impact of that problem is scoped only to operating systems and applicati= ons not following RFC 3484, and I think it would be useful if the proposed = text reflected that. If it does change the problem statement, then does the text you proposed to= include in the draft need to be updated to reflect the change, whatever th= at change is? >> there's still too many users using OSes that do not implement RFC3484 to= ignore Sure, this sounds like a strong reason for such OSes to be updated to imple= ment RFC 3484, rather than a reason to deprecate 6to4. Thank you, Dmitry -----Original Message----- From: Tore Anderson [mailto:tore.anderson@redpill-linpro.com]=20 Sent: Thursday, April 28, 2011 2:03 PM To: Dmitry Anipko Cc: Geoff Huston; Ole Troan; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" * Dmitry Anipko > As far as I see, these data don't invalidate the statement that for > the problem Tore described (IPv6 deployments are affected by 6to4), > it is still true that only applications and operating systems not > implementing RFC 3484 are affected? Hi again, Ole pointed out, quite correctly, that my data only revolves around measurements done from a web site's vantage point. Shame on me for forgetting for a second that the internet is more than just the web. Ole is also correct in that applications can do whatever they like. Opera <=3D 10.10 is a very good example of this happening, it preferred Teredo and 6to4 over IPv4, even when running on Windows (which implements RFC 3484). Fortunately, Opera users have shown themselves to be good at upgrading, so for HTTP traffic, the problem of applications doing their own thing is for the most part solved now. However, I have no idea what the situation is like for any non-HTTP services; I'm not aware of any focused research here. But if there's a great number of applications that do their own resolving in a non-RFC3484 manner, the situation could very well be significantly worse than it is for HTTP is right now. And even if every single application for the service in question is well-behaved and uses the operating system-provided resolver interfaces, there's still too many users using OSes that do not implement RFC3484 to ignore. Best regards, --=20 Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gih@apnic.net Thu Apr 28 15:02:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C961E073F for ; Thu, 28 Apr 2011 15:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J5uECW3mrgM for ; Thu, 28 Apr 2011 15:02:41 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 8A798E0730 for ; Thu, 28 Apr 2011 15:02:40 -0700 (PDT) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 42463B672F; Fri, 29 Apr 2011 08:02:38 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 29 Apr 2011 08:02:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:02:42 -0000 On 29/04/2011, at 7:28 AM, Dmitry Anipko wrote: > Hello Tore, >=20 >>> Ole pointed out, quite correctly, that my data only revolves around > measurements done from a web site's vantage point >>> However, I have no idea what the situation is like for any non-HTTP > services; I'm not aware of any focused research here. >=20 > I'm trying to understand - how does this change the problem statement = you made in the proposed addition to the draft: "as the hosts behind the = 6to4 router will not be aware that its 6to4 connectivity is restricted = in scope to other 6to4 sites, and could therefore attempt to use this = connectivity for destinations on the global IPv6 Internet"?=20 >=20 > If these data don't affect the problem statement, then you've agreed = that the impact of that problem is scoped only to operating systems and = applications not following RFC 3484, and I think it would be useful if = the proposed text reflected that. >=20 > If it does change the problem statement, then does the text you = proposed to include in the draft need to be updated to reflect the = change, whatever that change is? >=20 >>> there's still too many users using OSes that do not implement = RFC3484 to ignore >=20 > Sure, this sounds like a strong reason for such OSes to be updated to = implement RFC 3484, rather than a reason to deprecate 6to4. Speaking personally, the major reason for me to deprecate 6to4 is its = shocking connection failure rate. I have observed in the packet capture = that I've been performing = (http://www.potaroo.net/ispcol/2010-12/6to4fail.html) is that between = 10% to 20% of 6to4 hosts that can successfully emit a SYN fail to emit = the followup SYN/ACK in the TCP initial handshake. The predominate = reason, as far as I can tell, is inbound protocol 41 filters close to = the client, rather than use of non-routed addresses in the embedded IPv4 = address of the 6to4 packet. For me this exposes a basic flaw in the = auto-tunnelling concept - namely that of unintentional consequences, = where a firewall filter set adopts a conservative position with respect = to incoming packets, including, presumably, blocking all IP protocols = except TCP. UDP and ICMP. Then, in the "inside" someone deploys an out = of the box host that will use 6to4 under certain conditions. The result = is messy, given that the unit typically waits for a protracted period of = resend attempts before ultimately giving up. Yes, using a local preference table that prefers IPv4 over = auto-tunnelled 6to4 will avoid this behaviour for external dual stack = services, but where the local application does not use such a preference = table, or the external service point is IP6 only, the problem of the = protracted wait for failure in up to 1 in 5 cases is, from an unwitting = end user perspective, presumably best avoided. Geoff From tore.anderson@redpill-linpro.com Thu Apr 28 15:15:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BE1E06C3 for ; Thu, 28 Apr 2011 15:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIu4+9dt5hh1 for ; Thu, 28 Apr 2011 15:15:48 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEAEE06A6 for ; Thu, 28 Apr 2011 15:15:48 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 7B23CCC1B3; Fri, 29 Apr 2011 00:15:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 QQow6A45wVEs; Fri, 29 Apr 2011 00:15:46 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Fri, 29 Apr 2011 00:15:46 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id E2BC2170C00B; Fri, 29 Apr 2011 00:15:46 +0200 (CEST) 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 oRUBwo8nLeY4; Fri, 29 Apr 2011 00:15:45 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id A936B170C00A; Fri, 29 Apr 2011 00:15:45 +0200 (CEST) Message-ID: <4DB9E711.2060300@redpill-linpro.com> Date: Fri, 29 Apr 2011 00:15:45 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:15:49 -0000 * Dmitry Anipko >>> Ole pointed out, quite correctly, that my data only revolves >>> around > measurements done from a web site's vantage point >>> However, I have no idea what the situation is like for any >>> non-HTTP > services; I'm not aware of any focused research here. > > I'm trying to understand - how does this change the problem statement > you made in the proposed addition to the draft: "as the hosts behind > the 6to4 router will not be aware that its 6to4 connectivity is > restricted in scope to other 6to4 sites, and could therefore attempt > to use this connectivity for destinations on the global IPv6 > Internet"? > > If these data don't affect the problem statement, then you've agreed > that the impact of that problem is scoped only to operating systems > and applications not following RFC 3484, and I think it would be > useful if the proposed text reflected that. > > If it does change the problem statement, then does the text you > proposed to include in the draft need to be updated to reflect the > change, whatever that change is? Hi Dmitry, It does not change the problem statement. I did send you a reply a few hours ago where I did agree with you in that the problem is scoped only to hosts and applications that do not implement RFC 3484 (or something similiar to it). My comments in the previous message was just an observation that even for HTTP, where the applications are for the most part well-behaved, the operational problems with 6to4 today remain significant. For services other than HTTP, the situation is less clear - but even in the best case, it can't get much better than the already crappy situation we have with HTTP today. >>> there's still too many users using OSes that do not implement >>> RFC3484 to ignore > > Sure, this sounds like a strong reason for such OSes to be updated to > implement RFC 3484, rather than a reason to deprecate 6to4. I encourage every OS and application developer to implement RFC 3484. However, the toothpaste is out of the tube already. Even if we by some miracle were able to put it back in by making every OS and application in the world RFC 3484-compliant, my gut feeling is that what we will then have accomplished amounts to nothing more than chopping another head off the Hydra that is 6to4-related operational problems. I'm sick and tired of handling those, there's no end to them. I tried really hard for a while to do so, but I'm now convinced that 6to4 cannot be salvaged in any meaningful way. That is why I feel it's high time for the IETF to abandon the technology altogether by deprecating it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From martin@millnert.se Thu Apr 28 15:20:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE0BE06C3 for ; Thu, 28 Apr 2011 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMdQztgS9yPU for ; Thu, 28 Apr 2011 15:20:22 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 99911E06A6 for ; Thu, 28 Apr 2011 15:20:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 2EEAB77EE; Fri, 29 Apr 2011 00:36:11 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOv46Qmz4M5J; Fri, 29 Apr 2011 00:36:11 +0200 (CEST) Received: from [IPv6:2a02:9a0:100:2800::53] (dns.shakira.millnert.se [IPv6:2a02:9a0:100:2800::53]) by ncis.csbnet.se (Postfix) with ESMTPSA id 3C33276C5; Fri, 29 Apr 2011 00:36:09 +0200 (CEST) From: Martin Millnert To: Fred Baker In-Reply-To: <53409792-E6F4-4AC6-9DE0-037A8AD5D62C@cisco.com> References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <1304021261.4286.171.camel@shakira.millnert.se> <53409792-E6F4-4AC6-9DE0-037A8AD5D62C@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 28 Apr 2011 18:20:17 -0400 Message-ID: <1304029217.4286.207.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: [v6ops] On Teredo [was Re: 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:20:23 -0000 Fred, On Thu, 2011-04-28 at 13:31 -0700, Fred Baker wrote: > Correct me if I'm wrong; the comment is specific to Teredo and not to 6to4, correct? Yes, you are right. Overall the comment was mostly specific to Teredo. > > Speaking strictly for myself, I would seriously wonder why the > alternative to any overlay architecture is not native deployment. I agree completely that native IPv6 is the end-goal. My (before mis-placed) point is simply that recommending the removal of an overlay protocol (Teredo in this case) without proof of actual users/providers actually being adversely affected by it (clearly not the case with 6to4), *will not* in itself result in giving these users native IPv6. And leaving the protocol in place, will, likewise, not give these users access to IPv6 web servers via native IPv6 connectivity. That was clearly not the topic of point 9, and in retrospect I should've restricted my response to the lack of evidence of any causality between the (non-http) traffic levels seen in Teredo with applications not following the provided 3484 on their host and doing their own thing, presented in Geoff's thorough research article. I did continue by offering an explanation on why I believe that largely to be a completely inaccurate explanation for the traffic measured in Geoff's work. (Ie, largely, traffic exists with no rule-breaking going on). > The concern raised with 6to4 is the set of use cases in which it > doesn't work as expected, for any of a variety of reasons, and as a > result inhibits consumer interest in IPv6 or distracts service > provider attention from native deployment. Yes, and I'm also in agreement that phasing out 6to4 is the right action now. > If your statement is that the IETF is irresponsible in pointing out a > deployment solution that isn't working as well as hoped for without > providing an alternative, I think the IETF has set forth (and service > providers are in the process of deploying) a replacement. No, that was not my statement (see above)! > What I do not expect the IETF to do is recommend one overlay > architecture instead of another. I was not suggesting the IETF to recommend operators to let their users rely on overlay architectures as the users means of IPv6 connectivity. I very much welcome clear evidence that Teredo is an obstacle to native deployment. I don't think it is, and I can't remember seeing any such evidence so far. Teredo is there, with a purpose, [and until proven otherwise, ] it does not hurt native v6 deployment - and recommending removing it solves nothing. > In RFC 6180 (aka draft-arkko-ipv6-transition-guidelines), Jari and I > tried to point out things that were known to work in deployment as > general advice in "how to get over a bump in the deployment roadmap", > but our point was explicitly not to say "deploy this overlay and > stop". To our minds, and I understood the working group's mind, the > finish-line is "the universal deployment of native IPv6". No arguments here. Personally, I believe we can approximate having reached the finish line to when deploying a single-stack native IPv6 network is the norm. Best, Martin > > > > On Thu, 2011-04-28 at 20:37 +0200, Ole Troan wrote: > > > >> that's only measured at a web site. > >> if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of other traffic too. > >> http://www.potaroo.net/ispcol/2011-04/teredo.html > >> > >> created by applications doing their 'own' thing and not following the default policy table. > > > > Yes and no. > > Yes, there is a substantial amount of Teredo traffic, yet the protocol > > is virtually never used for HTTP. > > No, I find no suggestion in his article that this traffic is created by > > "applications doing their 'own' thing and not following the default > > policy table". > > > > To take a very real example: the various torrent DHT "clouds" are > > teeming with IPv6 end-point addresses. Connecting to these with Teredo, > > if available, is in accordance with 3484, if that is the only v6 > > connectivity a host has. The alternative is, of course, to not connect > > to them at all. Same goes for a host using any other form of IPv6 > > connectivity to make a connection. > > These are not hostnames resolving to A/AAAA records. And even if they > > were, as Geoff points out in his article, Windows 7/Vista will not even > > resolve the AAAA record, if Teredo is the only non-link-local v6 > > connectivity a host has! Now we may discuss an operating system not > > following the default policy table, but not applications. > > > > > > Let me drive my point home: > > > > People say/argue Teredo (and 6to4) is bad because many connections fail, > > among other problems, but Teredo isn't the black sheep in the automated > > v6-tunneling family, and it does address a very real problem (lack of > > IPv6 connectivity). I haven't heard a single content provider say they > > will hold back deployment of AAAA records because of it. > > The responsible thing for IETF to do wrt. any deprecation of Teredo is > > to provide a realistic alternative solution *before* doing so (to > > include in a phase-out plan of the protocol, for example), unless it > > wants to be tilting at windmills. > > > > If Teredo can be replaced by another protocol addressing the same > > problem space, which somehow has a much better connection rate, I would > > be all for that :) If not, the problem does not really truly lie with > > the IETF, short of a Teredo-advisory. > > > > > > I do think this may be showing that 3484 is insufficient when it comes > > to addressing (no pun intended) the *varying* connectivity needs of > > various applications: > > Some applications, predominantly such with plenty of redundancy, are > > quite fine with a v6 where connections fail 1 out of 3 times. To me this > > mostly shows how insufficient non-end-to-end NATed IPv4 is on the > > Internet today. > > Other applications really depend on their connections to succeed if > > attempted, and would probably prefer to fail with > > -EINADEQUATECONNECTIVITYPRESENT, rather than launch a connection attempt > > using last-resort connectivity. > > > > More skilled socket API folks than I are highly welcome to school me on > > the following idea: > > If OS socket API:s were to provide a way for applications to require > > better-than-last-resort connectivity (or inverse, accept last-resort > > connectivity), that could be useful for application developers IMO. > > I guess it could be a two-dimensional approach, with the ability to make > > or relax this requirement on both the source and the destination > > address. > > > > Blizzard recently seems to have figured out to suggest native IPv6 to be > > used ("Use IPv6" box default checked with this connectivity present at > > the box), but not 6to4/Teredo ("Use IPv6" defaults to unchecked). > > This seems IMO like a useful approach in addressing this problem, i.e, > > application-specific, since only the application itself can know its > > requirements. > > > > Best, > > Martin > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > From behcetsarikaya@yahoo.com Thu Apr 28 15:24:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF29AE070B for ; Thu, 28 Apr 2011 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJMpT2S1k8aZ for ; Thu, 28 Apr 2011 15:24:25 -0700 (PDT) Received: from nm16-vm0.bullet.mail.sp2.yahoo.com (nm16-vm0.bullet.mail.sp2.yahoo.com [98.139.91.210]) by ietfa.amsl.com (Postfix) with SMTP id 320FBE06A6 for ; Thu, 28 Apr 2011 15:24:25 -0700 (PDT) Received: from [98.139.91.65] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 22:24:22 -0000 Received: from [98.139.91.21] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 22:24:22 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 22:24:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 712537.32929.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 61588 invoked by uid 60001); 28 Apr 2011 22:24:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304029462; bh=97eYJ7ipUiQNENzdv12Ivps/HQ48mCHGnIS4l9ufReQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=O9V0qR6Md78k8VRvlGtA6C5BUIgwQNfxU7Eq1v0zTyqRkxm3Gk9KgR14XMamjalDNc4xW0gGCqVmpiWHSMX1qKCsXThxr0mEa/Cxz3ghnhIuk+6tcfFv6n3tM7mU31TOnMHZtuPr0hCvJ8KRcY4Bg8qiC2Dg4bHsyEcBA7VEM3Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fiGpihunxiW6PQBo2UXOdQxKjZuYHGKwL5AvYF81EuJIPQE03/VrjS98LxpzdkIUVMspuSTnNL2dWhshEvCJvpRv0Br5p71pcp0+EelrCGp3sRiO8rInIPaj3Eyd90YiVPd1EwEcewdRHJumElykgHO7KId2Qdk1uXoVzHvN/4E=; Message-ID: <205282.60063.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: AM.ckI8VM1mLW1p7RzHHIkKZVOlch2Q6rIsmeJCGllVd.8v I.KY- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 28 Apr 2011 15:24:21 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <201104071411.p37EBPTN025009@irp-view13.cisco.com> <3EDFD736-4E40-4E74-B368-481D424A600E@gmail.com> <54043.2203.qm@web111408.mail.gq1.yahoo.com> <78805B3F-9D2B-457F-B8C7-7AB548CD3010@gmail.com> Date: Thu, 28 Apr 2011 15:24:21 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <78805B3F-9D2B-457F-B8C7-7AB548CD3010@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IPv6 Operations , draft-ietf-v6ops-3gpp-eps@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-3gpp-eps-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:24:25 -0000 > You are mixing topics now. The text below talks about link-layer addresses, >not interface > > identifiers. Well, you can obtain LLA from an Iid, right? > See Section 5.2 for a discussion about interface identifiers. But the text you proposed in your mail is more talking about the UE not able to get the LLA of GGSN thus failing the neighbor discovery. So in theory, UE can provide an LLA during an ND exchange. I think it (this whole thing) is splitting hairs. Regards, Behcet From Dmitry.Anipko@microsoft.com Thu Apr 28 15:27:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB687E070B for ; Thu, 28 Apr 2011 15:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu9J6K2Ytc4o for ; Thu, 28 Apr 2011 15:27:57 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D7E06A6 for ; Thu, 28 Apr 2011 15:27:57 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Apr 2011 15:27:56 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 28 Apr 2011 15:27:56 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Thu, 28 Apr 2011 15:27:44 -0700 From: Dmitry Anipko To: Tore Anderson Date: Thu, 28 Apr 2011 15:27:42 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwF8dbWZfHMd5BmQ5uC+rgMfT4+JwAAElow Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> <4DB9E711.2060300@redpill-linpro.com> In-Reply-To: <4DB9E711.2060300@redpill-linpro.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 WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:27:57 -0000 Hello Tore, >> It does not change the problem statement. I did send you a reply a few hours ago where I did agree with you in that the problem is scoped only to hosts and applications that do not implement RFC 3484 (or something similiar to it). Thank you. It seems to me that you and I are in agreement that if the propo= sed text regarding "why 6to4 is preventing 6to4 roll out" was to be include= d, it shall include a statement that the problem is only scoped to implemen= tations not following RFC 3484. This fork of the summary thread was created= by the chair specifically on that item of the Ole's summary, and that's wh= y I'm commenting on that. >> I tried really hard for a while to do so, but I'm now convinced that 6to= 4 cannot be salvaged in any meaningful way. That is why I feel it's high ti= me for the IETF to abandon the technology altogether by deprecating it. I understand there can be different arguments that can be discussed as to w= hether or not to deprecate 6to4. I think if we follow the process suggested= by the chair and discuss and evaluate each of the items individually, rath= er than applying to each of them the same self-justified statement that 6to= 4 should be deprecated because there is a bunch of problem with it, it will= help evaluate validity and scope of each argument more objectively.=20 My understanding is that this fork was specifically about "why 6to4 is prev= enting 6to4 roll out" and you proposed a text which described a specific pr= oblem, on which I commented. If you believe there are other problems which = are worth describing, then I think the proposed text can be updated to refl= ect those. Thank you, Dmitry -----Original Message----- From: Tore Anderson [mailto:tore.anderson@redpill-linpro.com]=20 Sent: Thursday, April 28, 2011 3:16 PM To: Dmitry Anipko Cc: Geoff Huston; Ole Troan; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" * Dmitry Anipko >>> Ole pointed out, quite correctly, that my data only revolves >>> around > measurements done from a web site's vantage point >>> However, I have no idea what the situation is like for any >>> non-HTTP > services; I'm not aware of any focused research here. >=20 > I'm trying to understand - how does this change the problem statement > you made in the proposed addition to the draft: "as the hosts behind > the 6to4 router will not be aware that its 6to4 connectivity is > restricted in scope to other 6to4 sites, and could therefore attempt > to use this connectivity for destinations on the global IPv6 > Internet"? >=20 > If these data don't affect the problem statement, then you've agreed > that the impact of that problem is scoped only to operating systems > and applications not following RFC 3484, and I think it would be > useful if the proposed text reflected that. >=20 > If it does change the problem statement, then does the text you > proposed to include in the draft need to be updated to reflect the > change, whatever that change is? Hi Dmitry, It does not change the problem statement. I did send you a reply a few hours ago where I did agree with you in that the problem is scoped only to hosts and applications that do not implement RFC 3484 (or something similiar to it). My comments in the previous message was just an observation that even for HTTP, where the applications are for the most part well-behaved, the operational problems with 6to4 today remain significant. For services other than HTTP, the situation is less clear - but even in the best case, it can't get much better than the already crappy situation we have with HTTP today. >>> there's still too many users using OSes that do not implement >>> RFC3484 to ignore >=20 > Sure, this sounds like a strong reason for such OSes to be updated to > implement RFC 3484, rather than a reason to deprecate 6to4. I encourage every OS and application developer to implement RFC 3484. However, the toothpaste is out of the tube already. Even if we by some miracle were able to put it back in by making every OS and application in the world RFC 3484-compliant, my gut feeling is that what we will then have accomplished amounts to nothing more than chopping another head off the Hydra that is 6to4-related operational problems. I'm sick and tired of handling those, there's no end to them. I tried really hard for a while to do so, but I'm now convinced that 6to4 cannot be salvaged in any meaningful way. That is why I feel it's high time for the IETF to abandon the technology altogether by deprecating it. Best regards, --=20 Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From jhw@apple.com Thu Apr 28 16:08:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF53E06DC for ; Thu, 28 Apr 2011 16:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsTsJ9NTBYN1 for ; Thu, 28 Apr 2011 16:08:51 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 04909E06A6 for ; Thu, 28 Apr 2011 16:08:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LKD004SAXLN4KG0@mail-out.apple.com> for v6ops@ietf.org; Thu, 28 Apr 2011 16:08:50 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-f4-4db9f3814480 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id B0.35.29082.283F9BD4; Thu, 28 Apr 2011 16:08:50 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LKD00BOWXMP6E20@koseret.apple.com> for v6ops@ietf.org; Thu, 28 Apr 2011 16:08:49 -0700 (PDT) From: james woodyatt In-reply-to: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> Date: Thu, 28 Apr 2011 16:08:49 -0700 Message-id: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 23:08:51 -0000 On Apr 27, 2011, at 13:17 , Fred Baker wrote: >> 4. "Phase out plan" >> ------------------- >> - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should >> not published in its current form because it sets no standard for network operations without 6to4. >> A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft. >> >> Action: None. > > Does the working group agree with the summarization of the concern? Do we agree with the proposed (in)action? > > Reply if the answer is "no", and give a better suggestion. For the record, I agree with the characterization of concern quoted above. I remain opposed to the draft unless action is taken to establish a phaseout plan. I will now offer "a better suggestion" for why action should be taken. Among content providers, there is a powerful perception that the continued operation of 6to4 tunnels in the Internet is preventing the transition of their commercial services to general dual-stack IPv6/IPv4 availability. As content providers continue to stall on making content available over IPv6 as well as IPv4, it has the side effect of starving the service providers and end users of any incentive to upgrade legacy networks to support IPv6. In short, 6to4 is perceived by content providers to be a show-stopper for their IPv6 transition. For this reason, I continue to maintain that IETF has a stark choice between only two alternatives: A) explicitly phase out 6to4 with an aggressive reclamation of the 2002::/16 and 192.88.99/24 prefixes in the default-free zone and the establishment of a new requirement for hosts not to auto-configure interface addresses statelessly with the 2002::/16 prefix; B) allow continued operation of 6to4 to squelch the supply of IPv6 native content, and thereby create powerful incentives for service providers, large enterprises and equipment vendors to ignore the IPv6 transition altogether. I prefer option A over option B, and I see no other alternatives. Ceterum censeo Carthaginem esse delendam. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Thu Apr 28 16:39:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02069E06EC for ; Thu, 28 Apr 2011 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUI9XVPSboek for ; Thu, 28 Apr 2011 16:39:39 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1CE0677 for ; Thu, 28 Apr 2011 16:39:38 -0700 (PDT) Received: by fxm15 with SMTP id 15so2527796fxm.31 for ; Thu, 28 Apr 2011 16:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wg6UtrSWKMY+FZsBSP45Cs2RnfbVZrOQYJcAsqCQg80=; b=CaJWkmhW/itGWA2UhGEUE9Wq9yOFXkvHKX+RhoMJC6vZlmXuaVKbb481I54NXq/sLr 9iwDsNYAFYQGfFORbV+/20mB7OB2+Ci6CBikJcjGBqKUdOZMUVvIrTeH7hNkzXnnQPn0 kaphDLvn8YGaRHqQpCeNCw8QPhzhvCNUSXG1s= 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=EKjxZY7NyJHG4DyiRVqJSwTK4gKreur1rBzOO0KyXNtGG2V+b7LNcqw9wbAPeILSYt eu231moFkhHcttOKxfcNbh+JwAK4bODTGIzGhycK/ViPHXohUARr2rG3Q4F5XBAT4Y+w szMQPr4vqi5igq5ANLPJY40Tf6cH17yAzq4Xs= Received: by 10.223.3.12 with SMTP id 12mr727251fal.122.1304033978341; Thu, 28 Apr 2011 16:39:38 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id k5sm723809faa.15.2011.04.28.16.39.34 (version=SSLv3 cipher=OTHER); Thu, 28 Apr 2011 16:39:37 -0700 (PDT) Message-ID: <4DB9FAB1.2090707@gmail.com> Date: Fri, 29 Apr 2011 11:39:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 23:39:40 -0000 James, I really think your description is a caricature of the situation. But I have covered this in, I hope, a constructive and positive way in draft-ietf-v6ops-6to4-advisory, especially in section 5, so I will not repeat myself here. However, the measures described there obviate any need for aggressive destruction of 6to4 infrastructure for those who are happily using it. Brian On 2011-04-29 11:08, james woodyatt wrote: > On Apr 27, 2011, at 13:17 , Fred Baker wrote: > >>> 4. "Phase out plan" >>> ------------------- >>> - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should >>> not published in its current form because it sets no standard for network operations without 6to4. >>> A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft. >>> >>> Action: None. >> Does the working group agree with the summarization of the concern? Do we agree with the proposed (in)action? >> >> Reply if the answer is "no", and give a better suggestion. > > For the record, I agree with the characterization of concern quoted above. I remain opposed to the draft unless action is taken to establish a phaseout plan. I will now offer "a better suggestion" for why action should be taken. > > Among content providers, there is a powerful perception that the continued operation of 6to4 tunnels in the Internet is preventing the transition of their commercial services to general dual-stack IPv6/IPv4 availability. As content providers continue to stall on making content available over IPv6 as well as IPv4, it has the side effect of starving the service providers and end users of any incentive to upgrade legacy networks to support IPv6. In short, 6to4 is perceived by content providers to be a show-stopper for their IPv6 transition. > > For this reason, I continue to maintain that IETF has a stark choice between only two alternatives: > > A) explicitly phase out 6to4 with an aggressive reclamation of the 2002::/16 and 192.88.99/24 prefixes in the default-free zone and the establishment of a new requirement for hosts not to auto-configure interface addresses statelessly with the 2002::/16 prefix; > > B) allow continued operation of 6to4 to squelch the supply of IPv6 native content, and thereby create powerful incentives for service providers, large enterprises and equipment vendors to ignore the IPv6 transition altogether. > > I prefer option A over option B, and I see no other alternatives. Ceterum censeo Carthaginem esse delendam. > > > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tore.anderson@redpill-linpro.com Thu Apr 28 16:48:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ED4E073F for ; Thu, 28 Apr 2011 16:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzKjBHJJzsia for ; Thu, 28 Apr 2011 16:48:00 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id A0411E073E for ; Thu, 28 Apr 2011 16:47:59 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 535A2DC40C; Fri, 29 Apr 2011 01:47:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 nPhrdWAp1IDD; Fri, 29 Apr 2011 01:47:57 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Fri, 29 Apr 2011 01:47:57 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 7F827170C00B; Fri, 29 Apr 2011 01:47:57 +0200 (CEST) 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 UL+qauap57DE; Fri, 29 Apr 2011 01:47:34 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 5A133170C00A; Fri, 29 Apr 2011 01:47:34 +0200 (CEST) Message-ID: <4DB9FC95.6030006@redpill-linpro.com> Date: Fri, 29 Apr 2011 01:47:33 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dmitry Anipko References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> <4DB9E711.2060300@redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 23:48:00 -0000 Hi again, * Dmitry Anipko > Thank you. It seems to me that you and I are in agreement that if the > proposed text regarding "why 6to4 is preventing 6to4 roll out" was to > be included, it shall include a statement that the problem is only > scoped to implementations not following RFC 3484. Yep. Agreed. >>> I tried really hard for a while to do so, but I'm now convinced >>> that 6to4 cannot be salvaged in any meaningful way. That is why I >>> feel it's high time for the IETF to abandon the technology >>> altogether by deprecating it. > > I understand there can be different arguments that can be discussed > as to whether or not to deprecate 6to4. I think if we follow the > process suggested by the chair and discuss and evaluate each of the > items individually, rather than applying to each of them the same > self-justified statement that 6to4 should be deprecated because there > is a bunch of problem with it, it will help evaluate validity and > scope of each argument more objectively. > > My understanding is that this fork was specifically about "why 6to4 > is preventing 6to4 roll out" and you proposed a text which described > a specific problem, on which I commented. If you believe there are > other problems which are worth describing, then I think the proposed > text can be updated to reflect those. The operational problems associated with 6to4 in combination with its preference to IPv4 (where there's a lack of RFC 3484), is *THE* reason «why 6to4 is preventing 6to4[sic] roll out». (In turn, this is the single largest reason why I support deprecating it altogether - my apologies if this statement was out of place.) As you've pointed out, omnipresent RFC 3484 support would in theory solve this concern without any deprecating of 6to4 necessary. It would of course not solve any of the operational problems with 6to4 itself, but if it's never being used in preference to IPv4, then it causes no harm for a HTTP content provider like myself. However, the way I see it, this solution is unfortunately not realistically achievable. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From tore.anderson@redpill-linpro.com Thu Apr 28 17:05:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF74E0730 for ; Thu, 28 Apr 2011 17:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctbkMd93yPgN for ; Thu, 28 Apr 2011 17:05:04 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id D0513E0728 for ; Thu, 28 Apr 2011 17:05:03 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 1FC4AC3EE6; Fri, 29 Apr 2011 02:05:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at 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 BXkH81l5XNBz; Fri, 29 Apr 2011 02:05:03 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Fri, 29 Apr 2011 02:05:03 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id ECEE8170C00B; Fri, 29 Apr 2011 02:05:01 +0200 (CEST) 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 JyUbAsE-4Z-V; Fri, 29 Apr 2011 02:04:42 +0200 (CEST) Received: from envy.fud.no (stat.linpro.no [87.238.42.2]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 33924170C00A; Fri, 29 Apr 2011 02:04:42 +0200 (CEST) Message-ID: <4DBA0099.2040109@redpill-linpro.com> Date: Fri, 29 Apr 2011 02:04:41 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: james woodyatt References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 00:05:05 -0000 * james woodyatt > Among content providers, there is a powerful perception that the > continued operation of 6to4 tunnels in the Internet is preventing the > transition of their commercial services to general dual-stack > IPv6/IPv4 availability. As content providers continue to stall on > making content available over IPv6 as well as IPv4, it has the side > effect of starving the service providers and end users of any > incentive to upgrade legacy networks to support IPv6. In short, 6to4 > is perceived by content providers to be a show-stopper for their IPv6 > transition. > > For this reason, I continue to maintain that IETF has a stark choice > between only two alternatives: > > A) explicitly phase out 6to4 with an aggressive reclamation of the > 2002::/16 and 192.88.99/24 prefixes in the default-free zone and the > establishment of a new requirement for hosts not to auto-configure > interface addresses statelessly with the 2002::/16 prefix; Hi James, I'm strongly opposed to this alternative. If 2002::/16 and 192.88.99/24 was null-routed everywhere right now, everyone successfully using 6to4 today (intentionally or not) will become a «broken user». These broken users are what we content providers really hate. We don't actually hate the 6to4 protocol itself, rather the fact that it is responsible for so many of those broken users. (Case in point: According to Geoff, the Teredo protocol is at least as bad as 6to4 in practise, but since it doesn't really create the broken users 6to4 does you don't see us getting worked up over it.) Your proposal A will surely give 6to4 a quick and merciless death, but at the expense of creating millions of new broken users that won't go away until all the affected users have replaced their problematic software and/or hardware. Which would probably take many years. That is really counter-productive if the goal is to help content providers deploy IPv6; we want fewer, not more, broken users. The more broken users there are out there, the more difficult it is for us to deploy IPv6. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From marka@isc.org Thu Apr 28 20:11:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D8BE071E for ; Thu, 28 Apr 2011 20:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHKvpaLqW+z6 for ; Thu, 28 Apr 2011 20:11:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 43515E0710 for ; Thu, 28 Apr 2011 20:11:21 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id D3C9AC941E; Fri, 29 Apr 2011 03:11:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 9AA8F216C33; Fri, 29 Apr 2011 03:11:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C30B6E53A56; Fri, 29 Apr 2011 13:11:23 +1000 (EST) To: Tore Anderson From: Mark Andrews References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <4DBA0099.2040109@redpill-linpro.com> In-reply-to: Your message of "Fri, 29 Apr 2011 02:04:41 +0200." <4DBA0099.2040109@redpill-linpro.com> Date: Fri, 29 Apr 2011 13:11:23 +1000 Message-Id: <20110429031123.C30B6E53A56@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 03:11:23 -0000 There is third alternative. Actively contact the address holders of sites that have embrionic TCP connections from 6to4 address with the date, time and the embedded IP address. " You appear to have a broken 6to4[1] IPv6 connection as we logged embrionic[2] TCP connections from the following IPv6 address at the following times. Please see ... for how to check to see if 6to4 is actually broken for you and some steps that can be taken to fix it. Failure to fix this will result in slow network performance to any site that supports both IPv4 and IPv6. As of 10.6.5, which is to say "rather a while back", that's also true of = Apple. That has made a big difference for Apple users. That said, it doesn't really address the issue - if anything, it = confirms the observation in the draft. The observation is that the use = of 6to4 results in unreliable connectivity, and that a service that = appears to a user to be unreliable is not acceptable to a content = provider. Your assertion is, in essence, that in the presence of IPv4 = connectivity, hosts will choose that over 6to4. So, great, said hosts = are using 6to4 significantly less. WHEN THEY USE 6TO4, they still have a = problem - 6to4 is not a wonderful service as found in the wild. The = proposal is to tell vendors that, by default, they should not enable = 6to4, and the observation in the draft (confirmed last night in private = email that I was told was confidential as to the parties involved) is = that the unreliability of the service is a reason given for closely = managing IPv6 deployment - non-deployment, whitelisting, and so on. I'm not sure how throwing around Microsoft's market dominance helps this = discussion. It's certainly not pertinent to the topic of the thread.= From Dmitry.Anipko@microsoft.com Fri Apr 29 12:56:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33EE0793 for ; Fri, 29 Apr 2011 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJVZs94-Ebjn for ; Fri, 29 Apr 2011 12:56:35 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id E174AE06E0 for ; Fri, 29 Apr 2011 12:56:34 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Apr 2011 12:56:34 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 29 Apr 2011 12:56:34 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Fri, 29 Apr 2011 12:56:32 -0700 From: Dmitry Anipko To: Fred Baker Date: Fri, 29 Apr 2011 12:56:31 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwGpBCkv5bBkrVLTFeKydZhb8XvLwAALuEQ Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@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: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 19:56:35 -0000 Hello Fred, There was no intent to "throw around" any particular operating system domin= ance - it is unfortunate if an attempt to clarify the scope of the problem = and perform analysis based on facts is interpreted that way.=20 This thread was started by the chair with a request whether Erik & Tore can= help with the text describing " motivation for why 6to4 is actively preven= ting 6to4 roll out".=20 Such text was proposed by Tore. In my opinion, given that > 90% (and I'm ha= ppy that more and more Internet users do not experience problem now that Ap= ple OS starting from 10.6.5) of hosts are not affected by the problem, shou= ld be reflected by that text. Tore agreed with such clarification, so I don= 't have any other comments on that, unless the facts (that > 90% of the hos= ts - including Apple, Microsoft implementations, and possibly others, are n= ot affected by the issue) are questioned. Thank you, Dmitry -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Friday, April 29, 2011 12:31 PM To: Dmitry Anipko Cc: Lorenzo Colitti; Ole Troan; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" On Apr 29, 2011, at 11:47 AM, Dmitry Anipko wrote: > For example, all Windows hosts which have IPv6 enabled by default have th= is change implemented and choose NAT IPv4->IPv4 instead of using 6to4->Nati= ve. So at least 89.5% of hosts (per most recent Netmarketshare data) on the= Internet already are not affected by the "why 6to4 is preventing 6to4 roll= out", as described in the text proposed by Tore, and I think a fair text d= escribing the problem shall reflect the scope of the problem correctly. As of 10.6.5, which is to say "rather a while back", that's also true of Ap= ple. That has made a big difference for Apple users. That said, it doesn't really address the issue - if anything, it confirms t= he observation in the draft. The observation is that the use of 6to4 result= s in unreliable connectivity, and that a service that appears to a user to = be unreliable is not acceptable to a content provider. Your assertion is, i= n essence, that in the presence of IPv4 connectivity, hosts will choose tha= t over 6to4. So, great, said hosts are using 6to4 significantly less. WHEN= THEY USE 6TO4, they still have a problem - 6to4 is not a wonderful service= as found in the wild. The proposal is to tell vendors that, by default, th= ey should not enable 6to4, and the observation in the draft (confirmed last= night in private email that I was told was confidential as to the parties = involved) is that the unreliability of the service is a reason given for cl= osely managing IPv6 deployment - non-deployment, whitelisting, and so on. I'm not sure how throwing around Microsoft's market dominance helps this di= scussion. It's certainly not pertinent to the topic of the thread. From lorenzo@google.com Fri Apr 29 13:44:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46B6E0793 for ; Fri, 29 Apr 2011 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8PKyvJouBR5 for ; Fri, 29 Apr 2011 13:44:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3B271E06E7 for ; Fri, 29 Apr 2011 13:44:27 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p3TKiQPM015697 for ; Fri, 29 Apr 2011 13:44:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304109866; bh=n5X6ac/lmvjNXWngWAXQA4GGW/A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=P0+42cGCnsaS4LSlExKBeSPpR88sSQyhCqN+zAS7TaNl4mRNFGosw08lSpYCaMKFz AeHljGbOiLDQb8p2/soNg== Received: from ywa1 (ywa1.prod.google.com [10.192.1.1]) by kpbe14.cbf.corp.google.com with ESMTP id p3TKiOrn018593 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 29 Apr 2011 13:44:25 -0700 Received: by ywa1 with SMTP id 1so1524409ywa.28 for ; Fri, 29 Apr 2011 13:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yCcGd3cgpGObVhGO5mf7Hi2U7GzATF4ibVBWOHr2p3A=; b=s5dnVBiTcwOe6UWo90itNLE0Aq0chHB9OJ3LA2mPNpu6Ctitd9dNLLUzNFVShxR559 vYnKjm4QSGFk4F64Ax0g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=qXpYLxwyYmTDvsw9q1A/jeJs1FHHpxLVgyGMLlkU0wBaDetGQHi0rkrEmpxvMkoTjN 1dbySy2toFPwsVat5OYQ== Received: by 10.150.116.1 with SMTP id o1mr4542736ybc.321.1304109864119; Fri, 29 Apr 2011 13:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Fri, 29 Apr 2011 13:44:04 -0700 (PDT) In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> From: Lorenzo Colitti Date: Fri, 29 Apr 2011 13:44:04 -0700 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=000e0cd3b04032f00104a214bddc X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 20:44:28 -0000 --000e0cd3b04032f00104a214bddc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 29, 2011 at 12:31 PM, Fred Baker wrote: > the observation in the draft (confirmed last night in private email that I > was told was confidential as to the parties involved) is that the > unreliability of the service is a reason given for closely managing IPv6 > deployment - non-deployment, whitelisting, and so on. > Absolutely. The reason we (Google) cannot publish AAAA records for our services today is because we have data that shows that a non-trivial number of users will experience connection problems if we did so. That is the reason we employ DNS whitelisting: it's the only way to get any IPv6 deployment at all without causing unacceptable breakage. We have evidence that broken 6to4 connections are a large part of the problem. For example, the dual-stack connection failure rate for Mac OS 10.6.4 among Google users is *over one percent*, while the connection failure rate for Mac OS 10.6.5 is over 20x lower. The difference, of course, is that 10.6.5 deprefs 6to4 by default. Geoff Huston and RIPE NCC have also done measurements that indicate that connection failure rates of users that have 6to4 is between 10 and 20%. I think we all agree that that is unreliable; from a content provider perspective, it's unacceptable. --000e0cd3b04032f00104a214bddc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 29, 2011 at 12:31 PM, Fred Baker <fred@cisco.com>= wrote:
the observation in the draft (confirmed last night in pri= vate email that I was told was confidential as to the parties involved) is = that the unreliability of the service is a reason given for closely managin= g IPv6 deployment - non-deployment, whitelisting, and so on.

Absolutely. The reason we (Google) cannot = publish AAAA records for our services today is because we have data that sh= ows that a non-trivial number of users will experience connection problems = if we did so. That is the reason we employ DNS whitelisting: it's the o= nly way to get any IPv6 deployment at all without causing unacceptable brea= kage.

We have evidence that broken 6to4 connections are a lar= ge part of the problem. For example, the dual-stack connection failure rate= for Mac OS 10.6.4 among Google users is *over one percent*, while the conn= ection failure rate for Mac OS 10.6.5 is over 20x lower. The difference, of= course, is that 10.6.5 deprefs 6to4 by default.

Geoff Huston and RIPE NCC have also done measurements t= hat indicate that connection failure rates of users that have 6to4 is betwe= en 10 and 20%. I think we all agree that that is unreliable; from a content= provider perspective, it's unacceptable.
--000e0cd3b04032f00104a214bddc-- From lorenzo@google.com Fri Apr 29 13:57:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E16E0793 for ; Fri, 29 Apr 2011 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN232A03GBo3 for ; Fri, 29 Apr 2011 13:57:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CFD32E0669 for ; Fri, 29 Apr 2011 13:57:38 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p3TKvbTU017237 for ; Fri, 29 Apr 2011 13:57:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304110658; bh=Sq4ch+sBW0rjMLmJ/Hy7tbB2dqI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TL4U/2/PPKhJo8OhfIIr1xdBfJeQglDeVY8OYyC0xjfTQR3qnIRBJdySfDhxpq4Sv Cr36zWzypqPO4EyYjpBjg== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by hpaq5.eem.corp.google.com with ESMTP id p3TKvZQH013037 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 29 Apr 2011 13:57:36 -0700 Received: by gyh4 with SMTP id 4so1714546gyh.12 for ; Fri, 29 Apr 2011 13:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZCdCJdg23iK7xWSyiYIrkLHwkCOP19Ls3+jtU1S3sC4=; b=a3fJ2TEJhviD8UcJpR49HxvzZo5lIqgwfTydHkxoSUWU2InjMhFPo7BXYECBq0LPKu Mqimb664U+b1Z1ILsfAA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=hUXHqU9v9pdAKnfzdqGYsSUE7ZVVoK/Kyw46mBl3Oa8Dri7PLm/iRHKZUtW/trYqKF xeRaHFynwu96BZ2Obw9w== Received: by 10.151.24.10 with SMTP id b10mr4615214ybj.93.1304110655188; Fri, 29 Apr 2011 13:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Fri, 29 Apr 2011 13:57:15 -0700 (PDT) In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> From: Lorenzo Colitti Date: Fri, 29 Apr 2011 13:57:15 -0700 Message-ID: To: Dmitry Anipko Content-Type: multipart/alternative; boundary=000e0cd23ef659ae4304a214ecec X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 20:57:39 -0000 --000e0cd23ef659ae4304a214ecec Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko wrote: > Such text was proposed by Tore. In my opinion, given that > 90% (and I'm > happy that more and more Internet users do not experience problem now that > Apple OS starting from 10.6.5) of hosts are not affected by the problem, > should be reflected by that text. Tore agreed with such clarification, so I > don't have any other comments on that, unless the facts (that > 90% of the > hosts - including Apple, Microsoft implementations, and possibly others, are > not affected by the issue) are questioned. > I think that saying "90% of Internet hosts are not affected by this problem" provides the impression that this is not an important problem. Unfortunately, the contribution of that 10% of hosts to overall IPv6 reliability is very high, simply because 6to4 *is so much less reliable* than native IPv4 and native IPv6 that its contribution to availability is disproportionate. To pull numbers out of the air as an example: say IPv4 works 99.99% of the time, and say 6to4 works only 90% of the time (though it's actually less than that). If 1% of users use 6to4, by publishing an AAAA record reliability will be approximately 99%, which is 100 times worse than the 99.99% you'd have if you stuck with IPv4 only. --000e0cd23ef659ae4304a214ecec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko = <Dmitry= .Anipko@microsoft.com> wrote:
Such text was proposed by Tore. In my opinion, given that > 90% (and I&#= 39;m happy that more and more Internet users do not experience problem now = that Apple OS starting from 10.6.5) of hosts are not affected by the proble= m, should be reflected by that text. Tore agreed with such clarification, s= o I don't have any other comments on that, unless the facts (that > = 90% of the hosts - including Apple, Microsoft implementations, and possibly= others, are not affected by the issue) are questioned.

I think that saying "90% of Internet = hosts are not affected by this problem" provides the impression that t= his is not an important problem. Unfortunately, the contribution of that 10= % of hosts to overall IPv6 reliability is very high, simply because 6to4 *i= s so much less reliable* than native IPv4 and native IPv6 that its contribu= tion to availability is disproportionate.

To pull numbers out of the air as an example: say IPv4 = works 99.99% of the time, and say 6to4 works only 90% of the time (though i= t's actually less than that). If 1% of users use 6to4, by publishing an= AAAA record reliability will be approximately 99%, which is 100 times wors= e than the=A099.99% you'd have if you stuck with IPv4 only.
--000e0cd23ef659ae4304a214ecec-- From Dmitry.Anipko@microsoft.com Fri Apr 29 14:33:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D1E06A8 for ; Fri, 29 Apr 2011 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5CWkT3pi0Db for ; Fri, 29 Apr 2011 14:33:04 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 20EA8E0670 for ; Fri, 29 Apr 2011 14:33:03 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Apr 2011 14:33:04 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 29 Apr 2011 14:33:03 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Fri, 29 Apr 2011 14:32:15 -0700 From: Dmitry Anipko To: Lorenzo Colitti Date: Fri, 29 Apr 2011 14:32:15 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwGsBPxTbGuTnedSEODw7MDgUNA3gAAPK+g Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@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: multipart/alternative; boundary="_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E07DENAEXMSGS702_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 21:33:06 -0000 --_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E07DENAEXMSGS702_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Lorenzo, 90% was a bottom estimate, easy to figure out from the available sources. T= he actual number of not affected hosts is probably much higher (and the num= bers you quoted based on Google data in parallel fork seem to confirm that)= . >> I think that saying "90% of Internet hosts are not affected by this prob= lem" provides the impression that this is not an important problem. I'd rather say that it allows to reflect more accurately the importance of = the problem, whether that is small or large, without making incorrect impre= ssion that the whole Internet is broken because of 6to4. If instead we are = solving the problem for 1% of users (or whatever the number is), why not st= ate as such - if people think that is important, as well as that that probl= em could actually be solved in a least invasive way, by updating implementa= tions not following standard address selection recommendations. Thank you, Dmitry From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Friday, April 29, 2011 1:57 PM To: Dmitry Anipko Cc: Fred Baker; Ole Troan; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko > wrote: Such text was proposed by Tore. In my opinion, given that > 90% (and I'm ha= ppy that more and more Internet users do not experience problem now that Ap= ple OS starting from 10.6.5) of hosts are not affected by the problem, shou= ld be reflected by that text. Tore agreed with such clarification, so I don= 't have any other comments on that, unless the facts (that > 90% of the hos= ts - including Apple, Microsoft implementations, and possibly others, are n= ot affected by the issue) are questioned. I think that saying "90% of Internet hosts are not affected by this problem= " provides the impression that this is not an important problem. Unfortunat= ely, the contribution of that 10% of hosts to overall IPv6 reliability is v= ery high, simply because 6to4 *is so much less reliable* than native IPv4 a= nd native IPv6 that its contribution to availability is disproportionate. To pull numbers out of the air as an example: say IPv4 works 99.99% of the = time, and say 6to4 works only 90% of the time (though it's actually less th= an that). If 1% of users use 6to4, by publishing an AAAA record reliability= will be approximately 99%, which is 100 times worse than the 99.99% you'd = have if you stuck with IPv4 only. --_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E07DENAEXMSGS702_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Lorenzo,

 

90% was a bottom estimate, easy to figure out from the avail= able sources. The actual number of not affected hosts is probably much higher (a= nd the numbers you quoted based on Google data in parallel fork seem to confirm th= at).

 

>> I think that saying "90% of Internet ho= sts are not affected by this problem" provides the impression that this is= not an important problem.

 

I’d rather say that it allows to reflect more accurate= ly the importance of the problem, whether that is small or large, without maki= ng incorrect impression that the whole Internet is broken because of 6to4. If instead we= are solving the problem for 1% of users (or whatever the number is), why not st= ate as such – if people think that is important, as well as that that pro= blem could actually be solved in a least invasive way, by updating implementatio= ns not following standard address selection recommendations.=

 

Thank you,

Dmitry

 

From: Lorenzo Colit= ti [mailto:lorenzo@google.com]
Sent: Friday, April 29, 2011 1:57 PM
To: Dmitry Anipko
Cc: Fred Baker; Ole Troan; v6ops@ietf.org WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 = is preventing 6to4 roll out"

 

On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko <Dmitry.Anipko@microsoft.com= > wrote:

Such text was proposed by Tore. In my opinion, given t= hat > 90% (and I'm happy that more and more Internet users do not experience problem now that Apple OS starting from 10.6.5) of hosts are not affected b= y the problem, should be reflected by that text. Tore agreed with such clarification, so I don't have any other comments on that, unless the facts (that > 90% of the hosts - including Apple, Microsoft implementations, a= nd possibly others, are not affected by the issue) are questioned.<= /p>

 

I think that saying "90% of Internet hosts are no= t affected by this problem" provides the impression that this is not an important problem. Unfortunately, the contribution of that 10% of hosts to overall IPv6 reliability is very high, simply because 6to4 *is so much less reliable* than native IPv4 and native IPv6 that its contribution to availab= ility is disproportionate.

 

To pull numbers out of the air as an example: say IPv4= works 99.99% of the time, and say 6to4 works only 90% of the time (though it's actually less than that). If 1% of users use 6to4, by publishing an AAAA re= cord reliability will be approximately 99%, which is 100 times worse than the 99.99% you'd have if you stuck with IPv4 only.

--_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E07DENAEXMSGS702_-- From martin@millnert.se Fri Apr 29 15:01:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AD9E06AF for ; Fri, 29 Apr 2011 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zezZeAeNgcKK for ; Fri, 29 Apr 2011 15:01:30 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id ED226E0670 for ; Fri, 29 Apr 2011 15:01:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 43F8677F4; Sat, 30 Apr 2011 00:17:30 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3I+FbmqRhbe; Sat, 30 Apr 2011 00:17:30 +0200 (CEST) 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 71A387756; Sat, 30 Apr 2011 00:17:28 +0200 (CEST) From: Martin Millnert To: Lorenzo Colitti In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 29 Apr 2011 18:01:25 -0400 Message-ID: <1304114485.19431.23.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 22:01:31 -0000 Lorenzo, Dmitry, loosely summarizing your two points: On Fri, 2011-04-29 at 13:57 -0700, Lorenzo Colitti wrote: > On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko >> ~ ">90% 6to4 hosts are OK" > > "10% broken 6to4 hosts *is* a show stopper for AAAA publishing due > to the scale of the Internet". I think this is perfectly fine to formulate and include in the document. I have no doubt that we can stay factual and still achieve the goal of coming through with good arguments for vendors to convince themselves to disable 6to4 by default [on new products*]. Regards, -- Martin Millnert * If the goal is to make vendors push changes to old code/products, I'm not sure this document will achieve its goal regardless of formulation of point 9, simply according to what has already been quite clearly stated on this list wrt. the document previously. Perhaps, a more reasonable goal of the document should be good internet engineering? (It's the I*E*TF after all?) From Dmitry.Anipko@microsoft.com Fri Apr 29 15:13:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1E5E0795 for ; Fri, 29 Apr 2011 15:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.504 X-Spam-Level: X-Spam-Status: No, score=-10.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAD9gqEambnS for ; Fri, 29 Apr 2011 15:13:18 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFB9E0769 for ; Fri, 29 Apr 2011 15:13:18 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Apr 2011 15:13:18 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 29 Apr 2011 15:13:17 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Fri, 29 Apr 2011 15:13:17 -0700 From: Dmitry Anipko To: Martin Millnert , Lorenzo Colitti Date: Fri, 29 Apr 2011 15:13:17 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwGuQFT2Q+51h/0RzyTSmXavppMTAAATSAQ Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> <1304114485.19431.23.camel@shakira.millnert.se> In-Reply-To: <1304114485.19431.23.camel@shakira.millnert.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 22:13:19 -0000 SSdkIGFncmVlIHdpdGggc3VjaCBwaHJhc2luZyBpZiB0aGUgbnVtYmVyIHF1b3RlZCBpcyBiYXNl ZCBvbiBkYXRhIChhbmQgaXQgc3VyZWx5IGNhbiBiZSBlLmcuIGJhc2VkIG9uIEdvb2dsZSBtZWFz dXJlbWVudHMpLCBhbmQgdGhlcmUgaXMgYSBkaXNjdXNzaW9uIHdoeSBvdGhlciBtaXRpZ2F0aW9u cyBzdWNoIGFzIGRlcHJpb3JpdGl6YXRpb24gNnRvNCBvbiBob3N0cyBhcmUgbm90IHN1ZmZpY2ll bnQuDQoNCj4+KiBJZiB0aGUgZ29hbCBpcyB0byBtYWtlIHZlbmRvcnMgcHVzaCBjaGFuZ2VzIHRv IG9sZCBjb2RlL3Byb2R1Y3RzLCBJJ20NCm5vdCBzdXJlIHRoaXMgZG9jdW1lbnQgd2lsbCBhY2hp ZXZlIGl0cyBnb2FsIHJlZ2FyZGxlc3Mgb2YgZm9ybXVsYXRpb24NCm9mIHBvaW50IDkNCg0KSSBh Z3JlZSB3aXRoIHRoYXQuIEFuZCBpZiB0aGUgcHJvYmxlbSBpcyB0aGVyZSAoZm9yIHdoYXRldmVy IG51bWJlciBvZiB1c2VycyksIGl0IG1heSBhY3R1YWxseSBiZSBhIGZhc3RlciBhbmQgbW9yZSBl ZmZpY2llbnQgd2F5IHRvIGFkZHJlc3MgdGhhdCBwcm9ibGVtIHRvIHVwZGF0ZSB0aGUgT1MvYXBw cyB0byBkZXByZWYgNnRvNCAobXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IE9TZXMgZG8gaGF2ZSB1 cGRhdGUgY2hhbm5lbHMsIHdoaWxlIGZvciBJR0RzLCBhdCBiZXN0LCB1c2VyIGludm9sdmVtZW50 IGlzIHJlcXVpcmVkKS4NCg0KVGhhbmsgeW91Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTWFydGluIE1pbGxuZXJ0IFttYWlsdG86bWFydGluQG1pbGxuZXJ0LnNlXSANClNl bnQ6IEZyaWRheSwgQXByaWwgMjksIDIwMTEgMzowMSBQTQ0KVG86IExvcmVuem8gQ29saXR0aQ0K Q2M6IERtaXRyeSBBbmlwa287IHY2b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSA2dG80LWhpc3RvcmljIHN1bW1hcnkgcG9pbnQ6IDkuICJ3aHkgNnRvNCBpcyBwcmV2ZW50aW5n IDZ0bzQgcm9sbCBvdXQiDQoNCkxvcmVuem8sIERtaXRyeSwNCg0KbG9vc2VseSBzdW1tYXJpemlu ZyB5b3VyIHR3byBwb2ludHM6DQoNCk9uIEZyaSwgMjAxMS0wNC0yOSBhdCAxMzo1NyAtMDcwMCwg TG9yZW56byBDb2xpdHRpIHdyb3RlOg0KPiBPbiBGcmksIEFwciAyOSwgMjAxMSBhdCAxMjo1NiBQ TSwgRG1pdHJ5IEFuaXBrbyANCj4+IH4gIj45MCUgNnRvNCBob3N0cyBhcmUgT0siIA0KPiANCj4g IjEwJSBicm9rZW4gNnRvNCBob3N0cyAqaXMqIGEgc2hvdyBzdG9wcGVyIGZvciBBQUFBIHB1Ymxp c2hpbmcgZHVlIA0KPiB0byB0aGUgc2NhbGUgb2YgdGhlIEludGVybmV0Ii4NCg0KSSB0aGluayB0 aGlzIGlzIHBlcmZlY3RseSBmaW5lIHRvIGZvcm11bGF0ZSBhbmQgaW5jbHVkZSBpbiB0aGUgZG9j dW1lbnQuDQpJIGhhdmUgbm8gZG91YnQgdGhhdCB3ZSBjYW4gc3RheSBmYWN0dWFsIGFuZCBzdGls bCBhY2hpZXZlIHRoZSBnb2FsIG9mDQpjb21pbmcgdGhyb3VnaCB3aXRoIGdvb2QgYXJndW1lbnRz IGZvciB2ZW5kb3JzIHRvIGNvbnZpbmNlIHRoZW1zZWx2ZXMgdG8NCmRpc2FibGUgNnRvNCBieSBk ZWZhdWx0IFtvbiBuZXcgcHJvZHVjdHMqXS4NCg0KUmVnYXJkcywNCi0tIA0KTWFydGluIE1pbGxu ZXJ0IDxtYXJ0aW5AbWlsbG5lcnQuc2U+DQoNCiogSWYgdGhlIGdvYWwgaXMgdG8gbWFrZSB2ZW5k b3JzIHB1c2ggY2hhbmdlcyB0byBvbGQgY29kZS9wcm9kdWN0cywgSSdtDQpub3Qgc3VyZSB0aGlz IGRvY3VtZW50IHdpbGwgYWNoaWV2ZSBpdHMgZ29hbCByZWdhcmRsZXNzIG9mIGZvcm11bGF0aW9u DQpvZiBwb2ludCA5LCBzaW1wbHkgYWNjb3JkaW5nIHRvIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBx dWl0ZSBjbGVhcmx5DQpzdGF0ZWQgb24gdGhpcyBsaXN0IHdydC4gdGhlIGRvY3VtZW50IHByZXZp b3VzbHkuIFBlcmhhcHMsIGEgbW9yZQ0KcmVhc29uYWJsZSBnb2FsIG9mIHRoZSBkb2N1bWVudCBz aG91bGQgYmUgZ29vZCBpbnRlcm5ldCBlbmdpbmVlcmluZz8NCihJdCdzIHRoZSBJKkUqVEYgYWZ0 ZXIgYWxsPykNCg0KDQo= From dhc@dcrocker.net Fri Apr 29 16:32:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACA7E074B; Fri, 29 Apr 2011 16:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htsCb10xWS+X; Fri, 29 Apr 2011 16:32:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0CE06DC; Fri, 29 Apr 2011 16:32:31 -0700 (PDT) Received: from [192.168.5.61] ([64.134.238.192]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3TNWNHw032000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2011 16:32:29 -0700 Message-ID: <4DBB4A83.7010408@dcrocker.net> Date: Fri, 29 Apr 2011 16:32:19 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF Discussion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 29 Apr 2011 16:32:29 -0700 (PDT) X-Mailman-Approved-At: Fri, 29 Apr 2011 16:59:30 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 23:32:39 -0000 Review: Title: IPv6 AAAA DNS Whitelisting Implications I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 By: D. Crocker Date: 29 April 2011 Summary: This draft is a discussion of a technique for resolving a dual-stack problem between IPv4 and IPv6, through the use of special DNS records. The document appears to continue a recent use of the term 'whitelisting' that strongly conflicts with long-standing use of the term by the anti-abuse community. The document needs to do a more careful job of introducing the problem it is solving and the explaining the way the 'whitelisting' mechanism works. I also very strongly encourage finding a different term. d/ > Abstract > > The objective of this document is to describe what the whitelisting > of DNS AAAA resource records is, hereafter referred to as DNS RRs are whitelisted? Isn't it the addresses and not the records that are whitelisted? Does this mean putting whitelisting records into the DNS or does it mean something else? Comcast's own considerable expertise notwithstanding, has this doc been vetted with a range of organizations that actually DO whitelisting? Has it been circulated through MAAWG and APWG? Any comments from Spamhaus? The Acknowledgements list does not seem to indicate a range of whitelist ops folks whose names I know. (But then, I only know a few...) > 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. I suspect that product marketers won't have much interest in this. I suspect that the target for this is anti-abuse technical and operations staff. > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on August 26, 2011. > > Copyright Notice > > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > > > > Livingood Expires August 26, 2011 [Page 1] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > described in the Simplified BSD License. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Livingood Expires August 26, 2011 [Page 2] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 6 > 2.1. Description of the Operation of DNS Whitelisting . . . . . 7 > 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 > 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 9 > 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 12 > 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 12 > 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 12 > 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 13 > 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13 > 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 14 > 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15 > 7.1. Architectural Implications . . . . . . . . . . . . . . . . 15 > 7.2. Public IPv6 Address Reachability Implications . . . . . . 16 > 7.3. Operational Implications . . . . . . . . . . . . . . . . . 17 > 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 17 > 7.3.2. Authoritative DNS Server Operational Implications . . 17 > 7.3.3. DNS Recursive Resolver Server Operational > Implications . . . . . . . . . . . . . . . . . . . . . 18 > 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 19 > 7.3.5. Implications of Operational Momentum . . . . . . . . . 19 > 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 20 > 7.3.7. Additional Implications If Deployed On An Ad Hoc > Basis . . . . . . . . . . . . . . . . . . . . . . . . 20 > 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 20 > 7.5. Technology Policy Implications . . . . . . . . . . . . . . 21 > 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22 > 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 23 > 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 23 > 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 23 > 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 24 > 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 24 > 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 24 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 > 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 25 > 10.2. Authoritative DNS Response Consistency Considerations . . 26 > 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 > 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 > 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 > 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 > 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 > 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 > Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 31 > Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 > > > > Livingood Expires August 26, 2011 [Page 3] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Livingood Expires August 26, 2011 [Page 4] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > 1. Introduction > > This document describes the emerging practice of whitelisting of DNS > AAAA resource records (RRs), which contain IPv6 addresses, hereafter > referred to as DNS whitelisting. The document explores the > implications of this emerging practice are and what alternatives may > exist. > > The practice of DNS whitelisting appears to have first been used by > major web content sites (sometimes described herein as "highly- Really? Not for email first? > trafficked domains" or "major domains"). These web site operators, > or domain operators, observed that when they added AAAA resource > records to their authoritative DNS servers in order to support IPv6 Oh. You mean /IPv6/ whitelisting. > access to their content that a small fraction of end users had slow > or otherwise impaired access to a given web site with both AAAA and A > resource records. The fraction of users with such impaired access > has been estimated to be roughly 0.078% of total Internet users > [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 > Brokenness]. Thus, in an example Internet Service Provider (ISP) > network of 10 million users, approximately 7,800 of those users may > experience such impaired access. At a minimum, these sorts of statistics need to be normalized across IPv6 users/traffic, given how small a percentage that is in total users and total traffice. If that's what is meant it should be stated. If it isn't, the statistic should be recalculated. > As a result of this impairment affecting end users of a given domain, > a few major domains have either implemented DNS whitelisting or are > considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. How or why does whitelisting affect slow performance for these folk? > When implemented, DNS whitelisting in practice means that a domain's > authoritative DNS will return a AAAA resource record to DNS recursive > resolvers [RFC1035] on the whitelist, while returning no AAAA > resource records to DNS resolvers which are not on the whitelist. It Oh. The whitelisting is for resolving a conflict between AAAA and A record choices? Normally, the term 'whitelisting' is used to refer to bypass anti-abuse mechanisms. This appears to be for something else and it seems odd to call it whitelisting. Note the more typical use of the term: It appears that some v6 folks have chosen to co-opt a distinctive and very well established anti-abuse term for an entirely different purpose. > is important to note that these major domains are motivated by a > desire to maintain a high-quality user experience for all of their > users. By engaging in DNS whitelisting, they are attempting to > shield users with impaired access from the symptoms of those > impairments. > > Critics of the practice of DNS whitelisting have articulated several > concerns. Among these are that: > > o DNS whitelisting is a very different behavior from the current > practice concerning the publishing of IPv4 address resource > records, > > o that it may create a two-tiered Internet, > > o that policies concerning whitelisting and de-whitelisting are > opaque, > > > > > > Livingood Expires August 26, 2011 [Page 5] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > o that DNS whitelisting reduces interest in the deployment of IPv6, Well, it certainly suggests that there is a problem handling v4/v6 in dual stack environments cleanly. And it certainly seems that dealing with the underlying problem would be better. Beyond that, this appears to be a hack that is useful but not scalable. > > o that new operational and management burdens are created, well, yeah... > o and that the costs and negative implications of DNS whitelisting > outweigh the perceived benefits, compared to fixing underlying > impairments. > > This document explores the reasons and motivations for DNS > whitelisting. It also explores the outlined concerns regarding this > practice. Readers will hopefully better understand what DNS > whitelisting is, why some parties are implementing it, and what > criticisms of the practice exist. -- Dave Crocker Brandenburg InternetWorking bbiw.net From mohacsi@niif.hu Sat Apr 30 06:59:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E4EE066F for ; Sat, 30 Apr 2011 06:59:43 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FIHtDSoHK8b for ; Sat, 30 Apr 2011 06:59:42 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 40068E062A for ; Sat, 30 Apr 2011 06:59:41 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 00FB186D95; Sat, 30 Apr 2011 15:59:39 +0200 (CEST) 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 haAyhmD2bje2; Sat, 30 Apr 2011 15:59:19 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id A799287467; Sat, 30 Apr 2011 15:59:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6139E86D95; Sat, 30 Apr 2011 15:59:18 +0200 (CEST) Date: Sat, 30 Apr 2011 15:59:18 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Lorenzo Colitti In-Reply-To: Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-973080353-1304171958=:63146" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 13:59:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-973080353-1304171958=:63146 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 29 Apr 2011, Lorenzo Colitti wrote: > On Fri, Apr 29, 2011 at 12:58 AM, Ole Troan wrote: > > Sure, this sounds like a strong reason for such OSes to be updated to implement RFC 3484, > rather than a reason to deprecate 6to4. > > there are many cases where 3484(bis) fails. > http://tools.ietf.org/html/draft-v6ops-multihoming-without-ipv6nat-00 > > that argument is as much a reason to implement happy eyeballs as well. > > > RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4 to (much more reliable) NATed > IPv4. RFC 3484bis will help, but it may take a while. In the meantime, we have operational problems ("it > doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is unreliable, but don't worry, just > wait for RFC 3484bis to be published and then you can depref 6to4"? Happy eyeballs is also a bit too far > down the road. All the current RFC 3484 implementations I am aware of treats RFC 1918 IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 and Teredo. -> It was one reason to revise RFC 3484. Regards, Janos > > Notice that both these solutions don't make 6to4 more reliable, they just avoid it except as a last > resort. The root of the issue is that 6to4 is unreliable. So think the best way is to acknowledge that and > move on. > > --0-973080353-1304171958=:63146-- From Dmitry.Anipko@microsoft.com Sat Apr 30 11:38:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7BDE069A for ; Sat, 30 Apr 2011 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.515 X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVbApb23F9cy for ; Sat, 30 Apr 2011 11:38:55 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DA485E0697 for ; Sat, 30 Apr 2011 11:38:55 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 30 Apr 2011 11:38:55 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 30 Apr 2011 11:38:55 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Sat, 30 Apr 2011 11:38:55 -0700 From: Dmitry Anipko To: Mohacsi Janos , Lorenzo Colitti Date: Sat, 30 Apr 2011 11:38:54 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwHPu2gZmB1YAW9SseK6fYY1pBP8QAJhXpr Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@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: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 18:38:56 -0000 Thanks Janos. Lorenzo, if Google has such data regarding client brokenness,= is it possible to share the OS/browser type distribution of those broken c= lients coming specifically from 6to4 source addresses?=20 ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Mohacsi = Janos [mohacsi@niif.hu] Sent: Saturday, April 30, 2011 6:59 AM To: Lorenzo Colitti Cc: v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" On Fri, 29 Apr 2011, Lorenzo Colitti wrote: > On Fri, Apr 29, 2011 at 12:58 AM, Ole Troan wrote: > > Sure, this sounds like a strong reason for such OSes to be update= d to implement RFC 3484, > rather than a reason to deprecate 6to4. > > there are many cases where 3484(bis) fails. > http://tools.ietf.org/html/draft-v6ops-multihoming-without-ipv6nat-= 00 > > that argument is as much a reason to implement happy eyeballs as we= ll. > > > RFC 3484 by itself will not help here, because it prefers (unreliable) 6t= o4 to (much more reliable) NATed > IPv4. RFC 3484bis will help, but it may take a while. In the meantime, we= have operational problems ("it > doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is u= nreliable, but don't worry, just > wait for RFC 3484bis to be published and then you can depref 6to4"? Happy= eyeballs is also a bit too far > down the road. All the current RFC 3484 implementations I am aware of treats RFC 1918 IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 and Teredo. -> It was one reason to revise RFC 3484. Regards, Janos > > Notice that both these solutions don't make 6to4 more reliable, they just= avoid it except as a last > resort. The root of the issue is that 6to4 is unreliable. So think the be= st way is to acknowledge that and > move on. > >= From lorenzo@google.com Sat Apr 30 11:50:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19B8E069F for ; Sat, 30 Apr 2011 11:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTc2dal9JgWa for ; Sat, 30 Apr 2011 11:50:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 18D3EE0697 for ; Sat, 30 Apr 2011 11:50:06 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p3UIo5PN002664 for ; Sat, 30 Apr 2011 11:50:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304189406; bh=S3+Q4lpsGOm+V74jEzAm2ucyghk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rKLPQQxPvuGOXKgxyOVQv+JaKkWYIeqnO0E2fg+kj6CaNWuQaCeL/W55r9ijuW24X t0e+0m0KY6VoQKNlcUqXg== Received: from yia25 (yia25.prod.google.com [10.243.65.25]) by hpaq1.eem.corp.google.com with ESMTP id p3UIo33W016624 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Apr 2011 11:50:04 -0700 Received: by yia25 with SMTP id 25so1969318yia.26 for ; Sat, 30 Apr 2011 11:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KO9u2mnUbiL5CS8T4J3NnFkfRujrbsEFrZaYN1qkIR4=; b=KR6sNkTp91xArh1SUu7eLCo7otLx0LhZ/o2/hdZTe+ghIRQz/motcc5lmdCSg6vOIE 2xHyyAgP5guiokDcMDwg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=hXWNr4le42H9hNRMcvtA8ZBsfNdO+/uI00/j65YpF8PRBK8brBIp7TolyAEZimmpQl EVUxTF1iPvW4PndbDSJQ== Received: by 10.151.135.34 with SMTP id m34mr5336050ybn.36.1304189403421; Sat, 30 Apr 2011 11:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Sat, 30 Apr 2011 11:49:43 -0700 (PDT) In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> From: Lorenzo Colitti Date: Sat, 30 Apr 2011 11:49:43 -0700 Message-ID: To: Dmitry Anipko Content-Type: multipart/alternative; boundary=000e0cd595341c5c4f04a22742dc X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 18:50:07 -0000 --000e0cd595341c5c4f04a22742dc Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 11:38 AM, Dmitry Anipko wrote: > Thanks Janos. Lorenzo, if Google has such data regarding client brokenness, > is it possible to share the OS/browser type distribution of those broken > clients coming specifically from 6to4 source addresses? > Not sure we can share data. What's the question? --000e0cd595341c5c4f04a22742dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 30, 2011 at 11:38 AM, Dmitry Anipko = <Dmitry= .Anipko@microsoft.com> wrote:
Thanks Janos. Lorenzo, if Google has such data regarding client brokenness,= is it possible to share the OS/browser type distribution of those broken c= lients coming specifically from 6to4 source addresses?

Not sure we can share data. What's the question?=A0=
--000e0cd595341c5c4f04a22742dc-- From lorenzo@google.com Sat Apr 30 11:52:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520E7E069F for ; Sat, 30 Apr 2011 11:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkkIFwKbimmh for ; Sat, 30 Apr 2011 11:52:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id AFEDFE0697 for ; Sat, 30 Apr 2011 11:52:22 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p3UIqLUn020869 for ; Sat, 30 Apr 2011 11:52:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304189542; bh=X6w31Dsmv4zN7vxxijY2UmKkWj0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Pkv0ZUx8dGNt1eZhzwmQxQfoe1RrgFBDH3xiZBtWCNM/ilN+urhAv1e3Z5QQRUDUq Ioxt1FDBdYeiHRhwJvf3A== Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by hpaq11.eem.corp.google.com with ESMTP id p3UIqJPZ019059 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Apr 2011 11:52:20 -0700 Received: by ywg8 with SMTP id 8so1920292ywg.20 for ; Sat, 30 Apr 2011 11:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lNOIhMC4AmQuH+vW5Jq57QP/kvt9wqO8AHB+7NLZ5fs=; b=TwndBOuKh9ezRLvEsGhqfrHeqlZDwk9yZVIGrqE1kd9w7QMeYQp84K4GSLwK6TqzjQ sg7aNuiTP+dSI5S3gx8w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Y38vEvtoTWkJH9L5nbC4WSv5dI+Oh/b636BNl0ihWjQETvj0yjasI4fd6y5LNjb5B6 XaT38svZI6XihJmELQ1Q== Received: by 10.150.116.1 with SMTP id o1mr5256856ybc.321.1304189539172; Sat, 30 Apr 2011 11:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Sat, 30 Apr 2011 11:51:59 -0700 (PDT) In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> From: Lorenzo Colitti Date: Sat, 30 Apr 2011 11:51:59 -0700 Message-ID: To: Mohacsi Janos Content-Type: multipart/alternative; boundary=000e0cd3b04033c25a04a2274a08 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 18:52:23 -0000 --000e0cd3b04033c25a04a2274a08 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 30, 2011 at 6:59 AM, Mohacsi Janos wrote: > All the current RFC 3484 implementations I am aware of treats RFC 1918 IPv4 > addresses as a global scope address -> NATed IPv4 prefered to 6to4 and > Teredo. -> It was one reason to revise RFC 3484. > What about Windows XP? It's true that it has IPv6 off by default, but various popular P2P clients appear to enable IPv6 when they are installed. --000e0cd3b04033c25a04a2274a08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 30, 2011 at 6:59 AM, Mohacsi Janos <= span dir=3D"ltr"><mohacsi@niif.hu= > wrote:
All the current RFC 3484 implementations I am aware of tr= eats RFC 1918 IPv4 addresses as a global scope address -> NATed IPv4 pre= fered to 6to4 and Teredo. -> It was one reason to revise RFC 3484.

What about Windows XP? It's true that = it has IPv6 off by default, but various popular P2P clients appear to enabl= e IPv6 when they are installed.
--000e0cd3b04033c25a04a2274a08-- From martin@millnert.se Sat Apr 30 12:45:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27179E06C2 for ; Sat, 30 Apr 2011 12:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7UPUfoPr6tP for ; Sat, 30 Apr 2011 12:45:43 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 15C72E06BE for ; Sat, 30 Apr 2011 12:45:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id EAC29780E; Sat, 30 Apr 2011 22:01:49 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi+3O5F6h-TI; Sat, 30 Apr 2011 22:01:49 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id 791B07713; Sat, 30 Apr 2011 22:01:47 +0200 (CEST) From: Martin Millnert To: Dmitry Anipko In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> , Content-Type: text/plain; charset="UTF-8" Date: Sat, 30 Apr 2011 15:45:38 -0400 Message-ID: <1304192738.19431.45.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 19:45:51 -0000 Dmitry, On Sat, 2011-04-30 at 11:38 -0700, Dmitry Anipko wrote: > Thanks Janos. Lorenzo, if Google has such data regarding client brokenness, is it possible to share the OS/browser type distribution of those broken clients coming specifically from 6to4 source addresses? Tore has public data at http://www.fud.no/ipv6/ with some presented OS/browser drill-down. Do see his note about 2010-12-21. Emile and Geoff have done similar studies: https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really http://www.potaroo.net/ispcol/2010-12/6to4fail.html but Tore's the only one I know of that continuously publishes the (now flawed?) data. Regards, Martin > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Mohacsi Janos [mohacsi@niif.hu] > Sent: Saturday, April 30, 2011 6:59 AM > To: Lorenzo Colitti > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" > > On Fri, 29 Apr 2011, Lorenzo Colitti wrote: > > > On Fri, Apr 29, 2011 at 12:58 AM, Ole Troan wrote: > > > Sure, this sounds like a strong reason for such OSes to be updated to implement RFC 3484, > > rather than a reason to deprecate 6to4. > > > > there are many cases where 3484(bis) fails. > > http://tools.ietf.org/html/draft-v6ops-multihoming-without-ipv6nat-00 > > > > that argument is as much a reason to implement happy eyeballs as well. > > > > > > RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4 to (much more reliable) NATed > > IPv4. RFC 3484bis will help, but it may take a while. In the meantime, we have operational problems ("it > > doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is unreliable, but don't worry, just > > wait for RFC 3484bis to be published and then you can depref 6to4"? Happy eyeballs is also a bit too far > > down the road. > > All the current RFC 3484 implementations I am aware of treats RFC 1918 > IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 > and Teredo. -> It was one reason to revise RFC 3484. > > Regards, > Janos > > > > > Notice that both these solutions don't make 6to4 more reliable, they just avoid it except as a last > > resort. The root of the issue is that 6to4 is unreliable. So think the best way is to acknowledge that and > > move on. > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From martin@millnert.se Sat Apr 30 13:35:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AADE06E8 for ; Sat, 30 Apr 2011 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSYtTLMDN1CG for ; Sat, 30 Apr 2011 13:35:14 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id BA9DCE06D5 for ; Sat, 30 Apr 2011 13:35:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 11280780E; Sat, 30 Apr 2011 22:51:23 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRbJe9hWBHCL; Sat, 30 Apr 2011 22:51:22 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id DA2487713; Sat, 30 Apr 2011 22:51:21 +0200 (CEST) From: Martin Millnert To: Dmitry Anipko In-Reply-To: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> , Content-Type: text/plain; charset="UTF-8" Date: Sat, 30 Apr 2011 16:35:12 -0400 Message-ID: <1304195712.19431.107.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 20:35:15 -0000 Oops, forgot one data point: http://www.google.com/intl/en/ipv6/statistics/ With this public data we can make an educated guess to Goog's total client loss due to 6to4: % successful connections to A/AAAA from 6to4/Teredo: 0.05% (today and 2010-12-21). From Tore we can infer that 99% of these 6to4/Teredo connections are 6to4, and 1% Teredo. I round to 100% 6to4. Emile at RIPE reports around 15% failure on 6to4 connections, with failures on the inbound path from the client masked. (how big is the X here?) => 0.15 * (0.0005/0.85) = 0.009% total client loss from 6to4 failure, minimum (see X above). This number is in the ballpark of Tore's total client loss which as of 2010-12-21 was 0.016% (trending down quite sharply, but measurement data became polluted from that day). There are likely differences between regions and global overall data. (% clients using public IPv4 on their host, for example) This gives us an idea of what failure rate is considered too much, which is what point 9 was about, right? Personally I'd find it interesting to see a greater breakdown on what OS/browsers are behind this, but I'm honestly not sure it is necessary to answer point 9? That is unless the document is to state something like "Due to (vendor,browser) {(X1,Y1),(X2,Y2),...,(Xn,Yn)}, 6to4 has to be made historic.". /M On Sat, 2011-04-30 at 11:38 -0700, Dmitry Anipko wrote: > Thanks Janos. Lorenzo, if Google has such data regarding client brokenness, is it possible to share the OS/browser type distribution of those broken clients coming specifically from 6to4 source addresses? > > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Mohacsi Janos [mohacsi@niif.hu] > Sent: Saturday, April 30, 2011 6:59 AM > To: Lorenzo Colitti > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" > > On Fri, 29 Apr 2011, Lorenzo Colitti wrote: > > > On Fri, Apr 29, 2011 at 12:58 AM, Ole Troan wrote: > > > Sure, this sounds like a strong reason for such OSes to be updated to implement RFC 3484, > > rather than a reason to deprecate 6to4. > > > > there are many cases where 3484(bis) fails. > > http://tools.ietf.org/html/draft-v6ops-multihoming-without-ipv6nat-00 > > > > that argument is as much a reason to implement happy eyeballs as well. > > > > > > RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4 to (much more reliable) NATed > > IPv4. RFC 3484bis will help, but it may take a while. In the meantime, we have operational problems ("it > > doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is unreliable, but don't worry, just > > wait for RFC 3484bis to be published and then you can depref 6to4"? Happy eyeballs is also a bit too far > > down the road. > > All the current RFC 3484 implementations I am aware of treats RFC 1918 > IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 > and Teredo. -> It was one reason to revise RFC 3484. > > Regards, > Janos > > > > > Notice that both these solutions don't make 6to4 more reliable, they just avoid it except as a last > > resort. The root of the issue is that 6to4 is unreliable. So think the best way is to acknowledge that and > > move on. > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Dmitry.Anipko@microsoft.com Sat Apr 30 16:36:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4564EE06FE for ; Sat, 30 Apr 2011 16:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcqMvITDhX4T for ; Sat, 30 Apr 2011 16:36:44 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D7E0713 for ; Sat, 30 Apr 2011 16:36:44 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 30 Apr 2011 16:36:44 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 30 Apr 2011 16:36:43 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Sat, 30 Apr 2011 16:36:43 -0700 From: Dmitry Anipko To: Martin Millnert Date: Sat, 30 Apr 2011 16:36:42 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwHdiFWlGHNIlVyT022WDf1OeRt9wAFAMrZ Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> , , <1304195712.19431.107.camel@shakira.millnert.se> In-Reply-To: <1304195712.19431.107.camel@shakira.millnert.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 23:36:45 -0000 Hello Martin,=20 thank you very much for the references. To answer question about point 9, = let me recap what point 9 is: Quote from the chair's mail, starting point 9 thread: [quote] My opinion: T= here needs to be a clear motivation for why 6to4 is actively preventing 6to= 4 roll out...The current focus, the way I read it, is on why 6to4 isn't a g= reat protocol, rather a clear description of why 6to4 is actively preventin= g native IPv6 roll out..But I would suggest that the authors amend the text= so that it: i) better motivates that use of 6to4 is actively preventing = roll out of native IPv6... Action: I'll try to word smith some descriptive = text. Appreciate some help Erik/Tore? [/quote] Tore suggested text, essentially: [quote] >>Content providers have no way o= f performing a gradual IPv6 deployment...When an AAAA record is published f= or a web site, a significant number of end users on the Internet will attem= pt to use the 6to4 connectivity in preference to IPv4. [/quote] So, the point 9 is about affect on IPv6 roll out, and not about how 6to4 is= not great. Do you agree with definition of point 9? If you do, then on poi= nt 9, let me quote the data sources you pointed to. Emile: [quote] >>Content providers will not be affected much by the 6to4 breakage we see, = as long as operating systems and applications prefer native IPv4 over auto-= tunneled IPv6 (6to4,Teredo) by default, and as long as they prefer native I= Pv6 over everything else. Luckily, with the latest fix to Mac OS X (10.6.5)= , all major operating systems behave the way it is described above. >>Moral of the story: Go dual-stack. Now. [/quote] Tore: [quote] >>The secondary purpose of the measurement is to determine why I observe cl= ient loss - what are the underlying causes? The answer to that appears to b= e old versions of the Opera web browser and Mac OS X. This is because they = prefer transitional IPv6 connectivity (6to4, Teredo) above more reliable IP= v4 in certain cases... >>Any remaining problems is really hard to distinguish from statistical noi= se at this point. [/quote] Geoff: [quote] >>However, for as long as we can continue to operate in dual stack mode and= use IPv4 as a backup, then the vast majority of these failed connection at= tempts in IPv6 are resolved in IPv4, and the underlying dual stack failure = rate is far lower... >>The best advice to offer here is that the most useful way to use auto-tun= nelling techniques, including 6to4 and Teredo is to put it as a last resort= and only use it when all other connection attempts, including IPv4, have f= ailed[/quote] So, I fail to see how these data would support the point 9 "why 6to4 is pre= venting IPv6 roll out". Further more, Emile expresses clearly opposite opin= ion. In Tore's opinion, quoted above, the only major OS significant affecte= d is older versions of MAC OS, and the only major browser significantly aff= ected is older versions of Opera (and market share of those older versions = of Opera is rapidly declining, AFAIK). According to Tore, Apple has release= d patches for some OS versions, and not others - I guess one has to assume = that there was some rationale behind that decision, including consideration= s of the broken users of those versions of the OS. Google data indicate that usage of 6to4 has dropped 3 times since late 2009= till now. Interestingly, this is about the same time MAC OS 10.6 was relea= sed (August 2009), for which 6to4 patches are available.=20 So to summarize my opinion, based on these data sources and quotes:=20 if point 9 is indeed about whether or not 6to4 prevents IPv6 roll out, and = if it does, how to address it efficiently, then based on the data sources y= ou pointed to, that problem problem is scoped to older versions of a partic= ular OS and older version of a particular browser. In my opinion, it is inc= orrect to say that in general 6to4 is preventing IPv6 roll out because of i= mpact on content providers. While I think Brian Carpenter's draft shows clearly why 6to4 should not be = on by default in routers and I agree with that recommendation. I also agree= with the RFC 3484bis to depref 6to4 below IPv4 in general. However it is unclear to me why proponents of the "historic" draft think th= at declaring "historic" status would actually help to solve the point 9 pro= blem impacting some versions of that particular OS in any short timeframe: = I think consumers are quite unlikely to go and buy new IGDs over night, or = upgrade software on the IGDs, nor typically IGDs can upgrade themselves.=20 On the other hand, PC OS vendors may have OS update channels which can upda= te functionality basically without / with little user intervention - and if= that has not been done, then probably business justification and user pain= wasn't perceived to be strong enough. Thank you, Dmitry ________________________________________ From: Martin Millnert [martin@millnert.se] Sent: Saturday, April 30, 2011 1:35 PM To: Dmitry Anipko Cc: Mohacsi Janos; Lorenzo Colitti; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" Oops, forgot one data point: http://www.google.com/intl/en/ipv6/statistics/ With this public data we can make an educated guess to Goog's total client loss due to 6to4: % successful connections to A/AAAA from 6to4/Teredo: 0.05% (today and 2010-12-21). From Tore we can infer that 99% of these 6to4/Teredo connections are 6to4, and 1% Teredo. I round to 100% 6to4. Emile at RIPE reports around 15% failure on 6to4 connections, with failures on the inbound path from the client masked. (how big is the X here?) =3D> 0.15 * (0.0005/0.85) =3D 0.009% total client loss from 6to4 failure, minimum (see X above). This number is in the ballpark of Tore's total client loss which as of 2010-12-21 was 0.016% (trending down quite sharply, but measurement data became polluted from that day). There are likely differences between regions and global overall data. (% clients using public IPv4 on their host, for example) This gives us an idea of what failure rate is considered too much, which is what point 9 was about, right? Personally I'd find it interesting to see a greater breakdown on what OS/browsers are behind this, but I'm honestly not sure it is necessary to answer point 9? That is unless the document is to state something like "Due to (vendor,browser) {(X1,Y1),(X2,Y2),...,(Xn,Yn)}, 6to4 has to be made historic.". /M On Sat, 2011-04-30 at 11:38 -0700, Dmitry Anipko wrote: > Thanks Janos. Lorenzo, if Google has such data regarding client brokennes= s, is it possible to share the OS/browser type distribution of those broken= clients coming specifically from 6to4 source addresses? > > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Mohacs= i Janos [mohacsi@niif.hu] > Sent: Saturday, April 30, 2011 6:59 AM > To: Lorenzo Colitti > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is prevent= ing 6to4 roll out" > > On Fri, 29 Apr 2011, Lorenzo Colitti wrote: > > > On Fri, Apr 29, 2011 at 12:58 AM, Ole Troan wrot= e: > > > Sure, this sounds like a strong reason for such OSes to be upda= ted to implement RFC 3484, > > rather than a reason to deprecate 6to4. > > > > there are many cases where 3484(bis) fails. > > http://tools.ietf.org/html/draft-v6ops-multihoming-without-ipv6na= t-00 > > > > that argument is as much a reason to implement happy eyeballs as = well. > > > > > > RFC 3484 by itself will not help here, because it prefers (unreliable) = 6to4 to (much more reliable) NATed > > IPv4. RFC 3484bis will help, but it may take a while. In the meantime, = we have operational problems ("it > > doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is= unreliable, but don't worry, just > > wait for RFC 3484bis to be published and then you can depref 6to4"? Hap= py eyeballs is also a bit too far > > down the road. > > All the current RFC 3484 implementations I am aware of treats RFC 1918 > IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 > and Teredo. -> It was one reason to revise RFC 3484. > > Regards, > Janos > > > > > Notice that both these solutions don't make 6to4 more reliable, they ju= st avoid it except as a last > > resort. The root of the issue is that 6to4 is unreliable. So think the = best way is to acknowledge that and > > move on. > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops= From Dmitry.Anipko@microsoft.com Sat Apr 30 16:45:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388B6E064A for ; Sat, 30 Apr 2011 16:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akc+18Ged17G for ; Sat, 30 Apr 2011 16:45:17 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 3025DE0593 for ; Sat, 30 Apr 2011 16:45:17 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 30 Apr 2011 16:45:16 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 30 Apr 2011 16:45:16 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Sat, 30 Apr 2011 16:45:16 -0700 From: Dmitry Anipko To: Lorenzo Colitti , Mohacsi Janos Date: Sat, 30 Apr 2011 16:41:24 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" Thread-Index: AcwHZ8qVMJAocpUARwaRHDBbQunKDQAKFOVJ Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@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: multipart/alternative; boundary="_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E87A0NAEXMSGS702_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 23:45:18 -0000 --_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E87A0NAEXMSGS702_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It doesn't seem to me that the data sources, quoted in the forked thread by= Martin, indicate that there is a significant number of XP hosts which are = affected by the problem. If Google has data indicating the opposite, I'd hi= ghly appreciate if you could share those data, either on the mailing list o= r offline. Thank you. ________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti [lorenzo@google.com] Sent: Saturday, April 30, 2011 11:51 AM To: Mohacsi Janos Cc: v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventin= g 6to4 roll out" On Sat, Apr 30, 2011 at 6:59 AM, Mohacsi Janos > wrote: All the current RFC 3484 implementations I am aware of treats RFC 1918 IPv4= addresses as a global scope address -> NATed IPv4 prefered to 6to4 and Ter= edo. -> It was one reason to revise RFC 3484. What about Windows XP? It's true that it has IPv6 off by default, but vario= us popular P2P clients appear to enable IPv6 when they are installed. --_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E87A0NAEXMSGS702_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It does= n't seem to me that the data sources, quoted in the forked thread by Martin= , indicate that there is a significant number of XP hosts which are affecte= d by the problem. If Google has data indicating the opposite, I'd highly appreciate if you could share those data, ei= ther on the mailing list or offline.
=  
Thank y= ou.
From: v6ops-bounces@ietf.org [v6ops= -bounces@ietf.org] On Behalf Of Lorenzo Colitti [lorenzo@google.com]
Sent: Saturday, April 30, 2011 11:51 AM
To: Mohacsi Janos
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 = is preventing 6to4 roll out"

On Sat, Apr 30, 2011 at 6:59 AM, Mohacsi Janos <= span dir=3D"ltr"> <mohacsi@niif.hu> wrote= :
All the current RFC 3484 implementations I am aware of tr= eats RFC 1918 IPv4 addresses as a global scope address -> NATed IPv4 pre= fered to 6to4 and Teredo. -> It was one reason to revise RFC 3484.

What about Windows XP? It's true that it has IPv6 off by default, but = various popular P2P clients appear to enable IPv6 when they are installed.<= /div>
--_000_DD1A73D9E9C89144A927C5080F70285A015E3F1E87A0NAEXMSGS702_-- From Dmitry.Anipko@microsoft.com Sat Apr 30 17:09:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A38E06A7 for ; Sat, 30 Apr 2011 17:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZeSVucv-s+1 for ; Sat, 30 Apr 2011 17:09:38 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA29E0593 for ; Sat, 30 Apr 2011 17:09:38 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 30 Apr 2011 17:09:37 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 30 Apr 2011 17:09:37 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Sat, 30 Apr 2011 17:09:37 -0700 From: Dmitry Anipko To: Fred Baker , "v6ops@ietf.org WG" Date: Sat, 30 Apr 2011 17:09:36 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" Thread-Index: AcwFGHumsxCaETB8RsCOA/Ry+a3gnwCepJ8l Message-ID: References: <011CD3B0-3F46-4CA5-959B-E400EA13E0EE@cisco.com> In-Reply-To: <011CD3B0-3F46-4CA5-959B-E400EA13E0EE@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 Subject: Re: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 00:09:39 -0000 >>Does the working group agree with the summarization of the concern?=20 I agree the concern was summarized correctly. >> Do we agree with the proposed action? As I said in the quoted feedback, I don't think the action draft proposes i= s necessary to address the problem quoted, for the reasons listed below in = the feedback summary. So I agree with the proposed action to change the tex= t and I propose: to remove all the references about moving RFC 3056 to hist= oric status from the draft, since in my opinion the draft doesn't state suf= ficient reasons for moving RFC 3056 to historic. Those of the listed proble= ms, which are specific to 6to4, are addressed by the companion advisory and= RFC 3484bis. Those which are not specific to 6to4, in my opinion, shall no= t be in the draft. Thank you. ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Fred Bak= er [fred@cisco.com] Sent: Wednesday, April 27, 2011 1:17 PM To: v6ops@ietf.org WG Subject: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" > 3. "non-RFC1918 addresses" > -------------------------- > - The issue (B), if I understand correctly, it is essentially about usa= ge of non-RFC1918 addresses in networks, > connected to Internet e.g. using a NAT. There are existing mitigation= s to this problem > (e.g. Windows implementation will not configure 6to4 interface if the= re is other IPv6 connectivity > in the network; depending on particular implementation, in managed en= vironments administrators may > have control whether to enable or disable 6to4 on hosts). But even le= aving those mitigations aside, > it seems that the de-prioritization of 6to4 in prefix policy table be= low IPv4 in the proposed RFC 3484 > revision would take care of this issue, and moving RFC 3056 is a much= stronger measure, which doesn't > seem to be necessary, as far as the issue (B) is concerned. With the = revised RFC 3484, 6to4 will be one > of the "last resort" mechanisms, which will essentially be used only = if nothing else can, so it won't > be harmful. > > Reply: with the introduction of CGNs non-RFC1918 addresses may have limit= ed topological span making them > unsuitable for 6to4. > > So to summarize, in my opinion, in the current draft there seem to be= sufficient arguments to move RFC 3068 > to historic, but not RFC 3056. There may be such arguments for RFC 30= 56, but if there are, I think they > are not sufficiently reflected in the draft. > > Reply: Current text states: > - Not deployed > - Same problems as 3068 for the reverse path > - Same problem with filtering > - Not working with non-1918 addresses with topologically limited s= pan > > Actions: Suggestions for text to make it even clearer why also 3056 needs= to be deprecated? Does the working group agree with the summarization of the concern? Do we a= gree with the proposed action? Reply if the answer is "no", and give a better suggestion. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= From Dmitry.Anipko@microsoft.com Sat Apr 30 17:36:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF5E06AF for ; Sat, 30 Apr 2011 17:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhjJWgbbPM16 for ; Sat, 30 Apr 2011 17:36:36 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 969FFE0593 for ; Sat, 30 Apr 2011 17:36:36 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 30 Apr 2011 17:36:36 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 30 Apr 2011 17:36:36 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Sat, 30 Apr 2011 17:36:35 -0700 From: Dmitry Anipko To: Fred Baker , "v6ops@ietf.org WG" Date: Sat, 30 Apr 2011 17:36:34 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 2. "protocol 41" Thread-Index: AcwFGMeQjvcrs/EYS1GzUsA5Hzd3kwCfedzv 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 00:36:37 -0000 >>Does the working group agree with the summarization of the concern?=20 I agree with the summarization of the concern. >>Do we agree with the proposed (in)action? I disagree with the proposed action. I suggest to either remove the problem= from the list of 6to4 problems, since as currently worded this is not a 6t= o4 problem, but protocol 41 problem, and this draft, in its current form, d= oesn't seem to have any intentions to deal with general protocol 41, or to = add text illustrating why this problem is 6to4 specific and other uses of p= rotocol 41 on the Internet do not have this problem or how that problem is/= can be mitigated for them. Also, if it is shown how this problem is 6to4 specific, RFC 3484bis recomme= ndation would mitigate the problem and hence, in my opinion, this problem c= annot be used as a justification for declaring RFC 3056 historic - in that = case I suggest to remove the "historic" recommendation and instead add a re= ference to RFC 3484bis. ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Fred Bak= er [fred@cisco.com] Sent: Wednesday, April 27, 2011 1:17 PM To: v6ops@ietf.org WG Subject: [v6ops] 6to4-historic summary point: 2. "protocol 41" > 2. "protocol 41" > ---------------- > - Specifically, the issue (A) states that "6to4 has no specified mechan= ism to handle the case where > protocol 41 is blocked...". Do other tunneling mechanisms using proto= col 41 have such mechanism? > If they don't, then should usage of protocol 41 be moved to historic,= because the stated filtering/PMTUD > problems are then not specific to RFC 3056? If they do, then having a= brief overview of those and how/why > they don't apply to 6to4 would help to strengthen the statement. > > Action: None Does the working group agree with the summarization of the concern? Do we a= gree with the proposed (in)action? Reply if the answer is "no", and give a better suggestion. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= From Dmitry.Anipko@microsoft.com Sat Apr 30 18:01:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A59E06FB for ; Sat, 30 Apr 2011 18:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRz1IXvnt0Qx for ; Sat, 30 Apr 2011 18:01:48 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id BAB29E06AF for ; Sat, 30 Apr 2011 18:01:48 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 30 Apr 2011 18:01:48 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 30 Apr 2011 18:01:48 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Sat, 30 Apr 2011 18:01:47 -0700 From: Dmitry Anipko To: Fred Baker , Tore Anderson Date: Sat, 30 Apr 2011 18:01:46 -0700 Thread-Topic: 6to4-historic summary point: 5. "Clarifications" Thread-Index: AcwFGCybD0rqbVurTmCFE0hVGoBXngCgFazZ Message-ID: References: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> In-Reply-To: <6464744E-8507-497A-8AF5-693C74BB6795@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 WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 01:01:49 -0000 I agree with the recommendations 1-2-3 in the section 4 in the draft versio= n dated April 27 and I think those are sufficient, hence I suggest to remov= e wording regarding deprecation of RFC 3056 and prefix 2002::/16. Thank you, Dmitry ________________________________________ From: Fred Baker [fred@cisco.com] Sent: Wednesday, April 27, 2011 1:17 PM To: Tore Anderson; Dmitry Anipko Cc: v6ops@ietf.org WG Subject: 6to4-historic summary point: 5. "Clarifications" > 5. "Clarifications" > ------------------- > >> The approach that's most likely to get widespread support is: >> >> 1. make it not be on by default >> 2. make noise about it being A Bad Thing >> 3. deprioritise 2002::/16 addresses in resolver libs >> 4. then make the option hard to find on operating systems / CPEs >> 5. then remove the option on operating systems >> 6. then slowly decommission 6to4 relays over many years >> >> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. > > I do think it would be useful to elaborate on the arguments Tore just > provided to Dmitry for deprecation of 3056 in the draft, as a form of > history writing for the archives. > > Actions: Proposed text? Tore and Dmitry, this appears to be directed to you. Could you please work = with Ole on proposed text?=