From owner-v6ops@ops.ietf.org Wed Oct 1 06:28:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989AD3A680A for ; Wed, 1 Oct 2008 06:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 QPh5NXwz7G7s for ; Wed, 1 Oct 2008 06:28:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59E793A6C40 for ; Wed, 1 Oct 2008 06:28:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kl1fo-0009Hm-8q for v6ops-data@psg.com; Wed, 01 Oct 2008 13:23:24 +0000 Received: from [216.82.245.115] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kl1fj-0009H0-Oy for v6ops@ops.ietf.org; Wed, 01 Oct 2008 13:23:22 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1222867397!21279017!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 32061 invoked from network); 1 Oct 2008 13:23:17 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-6.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 1 Oct 2008 13:23:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m91DNGHG013573; Wed, 1 Oct 2008 09:23:17 -0400 Received: from 01GAF5142010624.AD.BLS.COM ([139.76.131.91]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m91DNDQh013541; Wed, 1 Oct 2008 09:23:13 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 1 Oct 2008 09:23:12 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 1 Oct 2008 09:23:12 -0400 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 Subject: RE: v4v6interim@ietf.org Mailing list Date: Wed, 1 Oct 2008 09:23:08 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0AF5DD30@crexc41p> In-Reply-To: <013201c922f2$82025230$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v4v6interim@ietf.org Mailing list Thread-Index: AckY6uKeN8eY2PYZS82b7Wp6/WSgKwJ35irgAAn2vLAANZYJYA== References: <48CEE763.8030502@cisco.com><2A9F30EB-9A1E-46B8-AF83-03B729F8DFF5@lilacglade.org> <48D13E0D.8060002@cisco.com> <013201c922f2$82025230$c2f0200a@cisco.com> From: "Stark, Barbara" To: "Dan Wing" , "Narayanan, Vidya" , "Mark Townsley" , "Margaret Wasserman" Cc: "Brian Haberman" , "Internet Area" , , "IPv6 Operations" , , "Behave WG" , X-OriginalArrivalTime: 01 Oct 2008 13:23:12.0350 (UTC) FILETIME=[DA8747E0:01C923C8] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Could someone confirm the name of the jabber room? My client tells me = that "v4v6existence" doesn't exist. Barbara -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Dan Wing Sent: Tuesday, September 30, 2008 7:49 AM To: 'Narayanan, Vidya'; 'Mark Townsley'; 'Margaret Wasserman' Cc: 'Brian Haberman'; 'Internet Area'; softwires@ietf.org; 'IPv6 = Operations'; ipv6@ietf.org; 'Behave WG'; v4v6interim@ietf.org Subject: RE: v4v6interim@ietf.org Mailing list See the "Remote Participation" section at: http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim Please register for remote participation, so we have a feeling of how = many people are supposed to be in the jabber room and on the conference = bridge. -d =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, September 30, 2008 12:04 AM > To: Mark Townsley; Margaret Wasserman > Cc: Brian Haberman; Internet Area; softwires@ietf.org; Dan=20 > Wing; 'IPv6 Operations'; ipv6@ietf.org; Behave WG > Subject: RE: v4v6interim@ietf.org Mailing list >=20 > Mark, > Please share the remote particpation info (jabber room, audio=20 > link, etc.) when you have it. >=20 > Thanks, > vidya >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of Mark Townsley > > Sent: Wednesday, September 17, 2008 10:28 AM > > To: Margaret Wasserman > > Cc: Brian Haberman; Internet Area; softwires@ietf.org; Dan > > Wing; 'IPv6 Operations'; ipv6@ietf.org; Behave WG > > Subject: Re: v4v6interim@ietf.org Mailing list > > > > > > We are discussing the situation with the host, and any > > volunteers we can muster up. > > > > Our goal is to have streaming audio and video for the > > presentations, with the ability to ask questions or make > > statements to the speaker remotely over jabber (via a local > > moderator, speaking on the remote participants behalf). I'm > > afraid we probably will not have the right infrastructure for > > effective real-time, multipoint, participation among remote > > and local participants. > > > > It looks like there will be a good bit of alpha code running > > no matter what we do, so don't bet that there will be no > > problems. We'll make the experience as good as we can for > > remote folks based on what we have though. > > > > - Mark > > > > Margaret Wasserman wrote: > > > > > > Has there been any resolution on how/if it will be possible > > to attend > > > this meeting remotely (conference bridge, web conference, > > jabber room, > > > etc.)? > > > > > > I will not be able to travel to Montreal, but would like to > > attend all > > > or part of the meeting remotely, if possible. > > > > > > Thanks, > > > Margaret > > > > > > On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote: > > > > > >> > > >> We have setup an email list for discussion leading up to > > the interim > > >> v4v6 coexistence meeting on October 1-2, 2008 in Montr=E9al, > > Canada. If > > >> you are registered to attend the meeting, you should=20 > already be on > > >> the list. > > >> > > >> The list is open, please subscribe and begin using it for > > all interim > > >> meeting related discussion (technical as well as > > >> administrative/logistical). For now, please consider this a > > >> short-lived list focused on agenda items for discussion at this > > >> interim meeting alone. We should know better after the > > meeting how to > > >> best divide discussion back among the individual WG lists, > > or whether > > >> a long-lived list of this nature is warranted. > > >> > > >> If you are attending and haven't registered, please do: > > >> > > >> > >=20 > http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6inte > > >> rim > > >> > > >> Tentative agenda, etc. can be found here: > > >> > > >> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim > > >> > > >> Thanks, > > >> > > >> - Mark, Jari, Dan and Brian > > >> > > >> > > >> > > >> > > >> > > -------------------------------------------------------------------- > > >> IETF IPv6 working group mailing list > > >> ipv6@ietf.org > > >> Administrative Requests:=20 > https://www.ietf.org/mailman/listinfo/ipv6 > > >> > > -------------------------------------------------------------------- > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > From owner-v6ops@ops.ietf.org Wed Oct 1 06:32:34 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9606828C1A8 for ; Wed, 1 Oct 2008 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 H6SBYLRNizCa for ; Wed, 1 Oct 2008 06:32:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 268AA3A6BF1 for ; Wed, 1 Oct 2008 06:32:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kl1o1-000A6m-Lj for v6ops-data@psg.com; Wed, 01 Oct 2008 13:31:53 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kl1nu-000A5n-Ae for v6ops@ops.ietf.org; Wed, 01 Oct 2008 13:31:48 +0000 X-IronPort-AV: E=Sophos;i="4.33,343,1220227200"; d="scan'208";a="85316877" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2008 13:31:45 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m91DVi3g032472; Wed, 1 Oct 2008 06:31:44 -0700 Received: from [192.168.3.108] (sjc-vpn5-1095.cisco.com [10.21.92.71]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m91DVgZW008260; Wed, 1 Oct 2008 13:31:43 GMT Cc: "Dan Wing" , "Narayanan, Vidya" , "Mark Townsley" , "Margaret Wasserman" , "Brian Haberman" , "Internet Area" , , "IPv6 Operations" , , "Behave WG" , Message-Id: From: Cullen Jennings To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0AF5DD30@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: v4v6interim@ietf.org Mailing list Date: Wed, 1 Oct 2008 09:31:47 -0400 References: <48CEE763.8030502@cisco.com><2A9F30EB-9A1E-46B8-AF83-03B729F8DFF5@lilacglade.org> <48D13E0D.8060002@cisco.com> <013201c922f2$82025230$c2f0200a@cisco.com> <7582BC68E4994F4ABF0BD4723975C3FA0AF5DD30@crexc41p> X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4881; t=1222867904; x=1223731904; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20v4v6interim@ietf.org=20Mailing=20list |Sender:=20; bh=Hn2fx1hoB3sBfD7xnqv0de46EBKRUhwar7hXwLVly7A=; b=t/TGsYJ4TBmDn/mJGPNDmnhqJ05JZOcZIoit4kvjOGu0Z+L49gJoJRKkNw yIg+Lh9UjeyuHWSZa8Rb+iMSOIhSPLf+5j0LQphVGYDAqwA3oiagKFG1pLp/ 7CWSMKentP; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Sorry - the correct name should be v4v6coexistence I just updated the wiki On Oct 1, 2008, at 9:23 , Stark, Barbara wrote: > Could someone confirm the name of the jabber room? My client tells =20 > me that "v4v6existence" doesn't exist. > Barbara > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On =20= > Behalf Of Dan Wing > Sent: Tuesday, September 30, 2008 7:49 AM > To: 'Narayanan, Vidya'; 'Mark Townsley'; 'Margaret Wasserman' > Cc: 'Brian Haberman'; 'Internet Area'; softwires@ietf.org; 'IPv6 =20 > Operations'; ipv6@ietf.org; 'Behave WG'; v4v6interim@ietf.org > Subject: RE: v4v6interim@ietf.org Mailing list > > See the "Remote Participation" section at: > http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim > > Please register for remote participation, so we have a feeling of =20 > how many > people are supposed to be in the jabber room and on the conference =20 > bridge. > > -d > > >> -----Original Message----- >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> Sent: Tuesday, September 30, 2008 12:04 AM >> To: Mark Townsley; Margaret Wasserman >> Cc: Brian Haberman; Internet Area; softwires@ietf.org; Dan >> Wing; 'IPv6 Operations'; ipv6@ietf.org; Behave WG >> Subject: RE: v4v6interim@ietf.org Mailing list >> >> Mark, >> Please share the remote particpation info (jabber room, audio >> link, etc.) when you have it. >> >> Thanks, >> vidya >> >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >>> Behalf Of Mark Townsley >>> Sent: Wednesday, September 17, 2008 10:28 AM >>> To: Margaret Wasserman >>> Cc: Brian Haberman; Internet Area; softwires@ietf.org; Dan >>> Wing; 'IPv6 Operations'; ipv6@ietf.org; Behave WG >>> Subject: Re: v4v6interim@ietf.org Mailing list >>> >>> >>> We are discussing the situation with the host, and any >>> volunteers we can muster up. >>> >>> Our goal is to have streaming audio and video for the >>> presentations, with the ability to ask questions or make >>> statements to the speaker remotely over jabber (via a local >>> moderator, speaking on the remote participants behalf). I'm >>> afraid we probably will not have the right infrastructure for >>> effective real-time, multipoint, participation among remote >>> and local participants. >>> >>> It looks like there will be a good bit of alpha code running >>> no matter what we do, so don't bet that there will be no >>> problems. We'll make the experience as good as we can for >>> remote folks based on what we have though. >>> >>> - Mark >>> >>> Margaret Wasserman wrote: >>>> >>>> Has there been any resolution on how/if it will be possible >>> to attend >>>> this meeting remotely (conference bridge, web conference, >>> jabber room, >>>> etc.)? >>>> >>>> I will not be able to travel to Montreal, but would like to >>> attend all >>>> or part of the meeting remotely, if possible. >>>> >>>> Thanks, >>>> Margaret >>>> >>>> On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote: >>>> >>>>> >>>>> We have setup an email list for discussion leading up to >>> the interim >>>>> v4v6 coexistence meeting on October 1-2, 2008 in Montr=E9al, >>> Canada. If >>>>> you are registered to attend the meeting, you should >> already be on >>>>> the list. >>>>> >>>>> The list is open, please subscribe and begin using it for >>> all interim >>>>> meeting related discussion (technical as well as >>>>> administrative/logistical). For now, please consider this a >>>>> short-lived list focused on agenda items for discussion at this >>>>> interim meeting alone. We should know better after the >>> meeting how to >>>>> best divide discussion back among the individual WG lists, >>> or whether >>>>> a long-lived list of this nature is warranted. >>>>> >>>>> If you are attending and haven't registered, please do: >>>>> >>>>> >>> >> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6inte >>>>> rim >>>>> >>>>> Tentative agenda, etc. can be found here: >>>>> >>>>> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim >>>>> >>>>> Thanks, >>>>> >>>>> - Mark, Jari, Dan and Brian >>>>> >>>>> >>>>> >>>>> >>>>> >>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> >>> -------------------------------------------------------------------- >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > > > From abadissa@federalgovernment.dell.com Wed Oct 1 09:13:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C5B3A6C36 for ; Wed, 1 Oct 2008 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.261 X-Spam-Level: X-Spam-Status: No, score=-20.261 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, RATWARE_MS_HASH=1.398, RATWARE_OUTLOOK_NONAME=2.171, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6-UalSS+MjT for ; Wed, 1 Oct 2008 09:13:17 -0700 (PDT) Received: from 80-42-216-159.dynamic.dsl.as9105.com (80-42-216-159.dynamic.dsl.as9105.com [80.42.216.159]) by core3.amsl.com (Postfix) with ESMTP id 5CFD23A6C0D for ; Wed, 1 Oct 2008 09:13:16 -0700 (PDT) From: MAL To: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C923E9.0EBB2E30" Subject: Order details Date: Wed, 1 Oct 2008 17:13:43 +0100 Message-ID: <000901c923e0$acf6c630$9fd82a50@youre0xdvq65tr> X-MS-TNEF-Correlator: Thread-Topic: Order details Thread-Index: Ackj6Q67twV3cuheQe2u94wBEgIHIQ== ------=_NextPart_000_000A_01C923E9.0EBB2E30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This message was sent to v6ops-archive@megatron.ietf.org Unsubscribe | Manage Subscriptions | Privacy Policy To stop ALL email from ABCNews Newsletters, click here to remove = yourself from our lists. This email was sent by: ABCNews, 7 WEST 66th Street, New York, NY 10023. ------=_NextPart_000_000A_01C923E9.0EBB2E30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

3D""

This = message was sent=20 to v6ops-archive@megatron.ietf.org

Unsubscribe=20 | Manage=20 Subscriptions | Privacy=20 Policy

To stop ALL email from ABCNews Newsletters, = click here=20 to remove yourself from our lists.

This=20 email was sent by: ABCNews, 7 WEST 66th Street, New York, NY = 10023.
------=_NextPart_000_000A_01C923E9.0EBB2E30-- From owner-v6ops@ops.ietf.org Wed Oct 1 22:47:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7B23A681D for ; Wed, 1 Oct 2008 22:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFgTSz4uAO7S for ; Wed, 1 Oct 2008 22:47:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D53D43A690D for ; Wed, 1 Oct 2008 22:47:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlGwj-000P1H-7y for v6ops-data@psg.com; Thu, 02 Oct 2008 05:41:53 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlGwf-000P0o-Ei for v6ops@ops.ietf.org; Thu, 02 Oct 2008 05:41:51 +0000 Received: from [192.168.0.51] (ip-118-90-75-60.xdsl.xnet.co.nz [118.90.75.60]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 8FD3827874; Thu, 2 Oct 2008 18:41:46 +1300 (NZDT) Cc: "Dan Wing" , "Narayanan, Vidya" , "Mark Townsley" , "Margaret Wasserman" , Internet Area , v4v6interim@ietf.org, ipv6@ietf.org, IPv6 Operations , softwires@ietf.org, Behave WG Message-Id: <594873B7-9476-4836-97F4-16EBA2A0815D@daork.net> From: Nathan Ward To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0AF5DD30@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [v4v6interim] v4v6interim@ietf.org Mailing list Date: Thu, 2 Oct 2008 18:41:44 +1300 References: <48CEE763.8030502@cisco.com><2A9F30EB-9A1E-46B8-AF83-03B729F8DFF5@lilacglade.org> <48D13E0D.8060002@cisco.com> <013201c922f2$82025230$c2f0200a@cisco.com> <7582BC68E4994F4ABF0BD4723975C3FA0AF5DD30@crexc41p> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: v4v6coexistence On 2/10/2008, at 2:23 AM, Stark, Barbara wrote: > Could someone confirm the name of the jabber room? My client tells =20 > me that "v4v6existence" doesn't exist. > Barbara > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On =20= > Behalf Of Dan Wing > Sent: Tuesday, September 30, 2008 7:49 AM > To: 'Narayanan, Vidya'; 'Mark Townsley'; 'Margaret Wasserman' > Cc: 'Brian Haberman'; 'Internet Area'; softwires@ietf.org; 'IPv6 =20 > Operations'; ipv6@ietf.org; 'Behave WG'; v4v6interim@ietf.org > Subject: RE: v4v6interim@ietf.org Mailing list > > See the "Remote Participation" section at: > http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim > > Please register for remote participation, so we have a feeling of =20 > how many > people are supposed to be in the jabber room and on the conference =20 > bridge. > > -d > > >> -----Original Message----- >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> Sent: Tuesday, September 30, 2008 12:04 AM >> To: Mark Townsley; Margaret Wasserman >> Cc: Brian Haberman; Internet Area; softwires@ietf.org; Dan >> Wing; 'IPv6 Operations'; ipv6@ietf.org; Behave WG >> Subject: RE: v4v6interim@ietf.org Mailing list >> >> Mark, >> Please share the remote particpation info (jabber room, audio >> link, etc.) when you have it. >> >> Thanks, >> vidya >> >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >>> Behalf Of Mark Townsley >>> Sent: Wednesday, September 17, 2008 10:28 AM >>> To: Margaret Wasserman >>> Cc: Brian Haberman; Internet Area; softwires@ietf.org; Dan >>> Wing; 'IPv6 Operations'; ipv6@ietf.org; Behave WG >>> Subject: Re: v4v6interim@ietf.org Mailing list >>> >>> >>> We are discussing the situation with the host, and any >>> volunteers we can muster up. >>> >>> Our goal is to have streaming audio and video for the >>> presentations, with the ability to ask questions or make >>> statements to the speaker remotely over jabber (via a local >>> moderator, speaking on the remote participants behalf). I'm >>> afraid we probably will not have the right infrastructure for >>> effective real-time, multipoint, participation among remote >>> and local participants. >>> >>> It looks like there will be a good bit of alpha code running >>> no matter what we do, so don't bet that there will be no >>> problems. We'll make the experience as good as we can for >>> remote folks based on what we have though. >>> >>> - Mark >>> >>> Margaret Wasserman wrote: >>>> >>>> Has there been any resolution on how/if it will be possible >>> to attend >>>> this meeting remotely (conference bridge, web conference, >>> jabber room, >>>> etc.)? >>>> >>>> I will not be able to travel to Montreal, but would like to >>> attend all >>>> or part of the meeting remotely, if possible. >>>> >>>> Thanks, >>>> Margaret >>>> >>>> On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote: >>>> >>>>> >>>>> We have setup an email list for discussion leading up to >>> the interim >>>>> v4v6 coexistence meeting on October 1-2, 2008 in Montr=E9al, >>> Canada. If >>>>> you are registered to attend the meeting, you should >> already be on >>>>> the list. >>>>> >>>>> The list is open, please subscribe and begin using it for >>> all interim >>>>> meeting related discussion (technical as well as >>>>> administrative/logistical). For now, please consider this a >>>>> short-lived list focused on agenda items for discussion at this >>>>> interim meeting alone. We should know better after the >>> meeting how to >>>>> best divide discussion back among the individual WG lists, >>> or whether >>>>> a long-lived list of this nature is warranted. >>>>> >>>>> If you are attending and haven't registered, please do: >>>>> >>>>> >>> >> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6inte >>>>> rim >>>>> >>>>> Tentative agenda, etc. can be found here: >>>>> >>>>> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim >>>>> >>>>> Thanks, >>>>> >>>>> - Mark, Jari, Dan and Brian >>>>> >>>>> >>>>> >>>>> >>>>> >>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> >>> -------------------------------------------------------------------- >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > > > _______________________________________________ > v4v6interim mailing list > v4v6interim@ietf.org > https://www.ietf.org/mailman/listinfo/v4v6interim > > !DSPAM:22,48e45edb202913425321090! > > -- Nathan Ward From owner-v6ops@ops.ietf.org Thu Oct 2 16:48:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2D23A67A4 for ; Thu, 2 Oct 2008 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.33 X-Spam-Level: X-Spam-Status: No, score=-5.33 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiQ3OUVY-x5E for ; Thu, 2 Oct 2008 16:48:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 268153A67F2 for ; Thu, 2 Oct 2008 16:48:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlXpu-000Fr1-Sh for v6ops-data@psg.com; Thu, 02 Oct 2008 23:43:58 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlXpr-000FqR-A8 for v6ops@ops.ietf.org; Thu, 02 Oct 2008 23:43:57 +0000 Received: from [192.168.0.51] (ip-118-90-75-60.xdsl.xnet.co.nz [118.90.75.60]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id C006E27928; Fri, 3 Oct 2008 12:43:48 +1300 (NZDT) Cc: Brian E Carpenter , IPv6 Operations Message-Id: <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> From: Nathan Ward To: "Erik Kline" In-Reply-To: <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: implications of 6to4 for v6coex Date: Fri, 3 Oct 2008 12:43:47 +1300 References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <48CDDB4B.3000506@gmail.com> <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/10/2008, at 2:26 AM, Erik Kline wrote: > On Sun, Sep 21, 2008 at 7:12 PM, Brian E Carpenter > wrote: >> On 2008-09-20 12:54, Nathan Ward wrote: >>> On 20/09/2008, at 12:15 PM, james woodyatt wrote: >>>> There is clearly something broken about 6to4, and I'm not sure >>>> how to >>>> fix it. Can it be saved as a standard? >> >> Just to be clear, the issue is not with basic 6to4, which was >> intended >> to be implemented only in routers. It's with the "obvious" extension >> to allow host-based 6to4, which led fairly quickly to the notion >> of anycast relays and the resulting lack of both configuration and of >> a discovery protocol. > > Well it seems to be working well enough (or popular enough, anyway). > What if I said that 69.8% of IPv6-enabled users who visit google.com > have 6to4? So, Brian disagrees with the host based 6to4 thing, ie. the way Windows Vista and XPSP2 do it. I don't think that the anycast relays has anything to do with the host based stuff. It might have been related thought trains in peoples' minds in 2001, but the anycast relays are just as relevant to router- based 6to4 as they are to host-based 6to4. For example, Airport Extreme, Linksys RVS4000, Cisco 8XX+config, etc. So, it's not just Windows. I'm not so hot on 6to4 stacks in hosts either, but my problem is wider - it is more with automatically configured 6to4, which is not specific to hosts. My feeling is still that this whole relay stealing thing is a non- issue in current implementations, I'll write up in a draft with some recommendations to remove that paragraph and bring it in line with most existing deployments. Also, these stats are interesting, and are roughly the same as what I'd expect. So, my understanding is that this test is to a hostname with A and AAAA records, right? That would make sense, as Teredo will only be used by XP SP2 and Linux boxes who have Teredo enabled (Vista prefers A over AAAA if it only has Teredo IPv6 connectivity). I don't think that you can accurately say that that you tested all IPv6 enabled users, because you aren't testing whether they are Vista and have Teredo enabled. Point em at a hostname with only AAAA and my expectation is that you'll significantly see different results - close to what I see, which are like: - ~90% Teredo - ~7-8% 6to4 - rest Native -- Nathan Ward From owner-v6ops@ops.ietf.org Thu Oct 2 18:37:01 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EB23A6827 for ; Thu, 2 Oct 2008 18:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, 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 xdFQRG4nuJjJ for ; Thu, 2 Oct 2008 18:37:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A0113A67A4 for ; Thu, 2 Oct 2008 18:37:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlZX8-000NjA-JF for v6ops-data@psg.com; Fri, 03 Oct 2008 01:32:42 +0000 Received: from [209.85.198.225] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlZX4-000Nig-P0 for v6ops@ops.ietf.org; Fri, 03 Oct 2008 01:32:40 +0000 Received: by rv-out-0506.google.com with SMTP id b25so1205670rvf.41 for ; Thu, 02 Oct 2008 18:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VQo6m7FpD5muk6oXdNrF/pqLiQkwCJZMb/6wRz8Gag0=; b=fJZOzUR6GSmtI2yEDOFrywfrakfimtZtPXDpZK1eyCsLriDdPNgp5/erzZ8C+wQfsb 9UAXnZyLCw5Zvcx4LbPsTwJXP6288fgZ44jykPmLN2QvgpIRDDD3nBS9EMxIYjFUvlpo uyVMcnVeBcGrjtQOrLU4U355zRHe8fspSTiVM= 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=STP9HVdc8UOyucTalXL4WfSIo9rdFjkEKVB4GYN+6VxFgPzqd3smRa1Igto7vRwZSU LtNbS2dSwlq+y6BPMJNO9nGLzaaBTjo9xh1upcbc0VWF8SNfZuIvxjrQ7A4En384gHDg +Oq/5dWJJmKUdaZedVMikXwkN3cHhvNFnppUs= Received: by 10.141.142.15 with SMTP id u15mr221201rvn.51.1222997557507; Thu, 02 Oct 2008 18:32:37 -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 k2sm11841714rvb.1.2008.10.02.18.32.35 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Oct 2008 18:32:36 -0700 (PDT) Message-ID: <48E57631.8010009@gmail.com> Date: Fri, 03 Oct 2008 14:32:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Ward CC: IPv6 Operations , ekline@ekline.com Subject: Re: implications of 6to4 for v6coex References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <48CDDB4B.3000506@gmail.com> <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> In-Reply-To: <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2008-10-03 12:43, Nathan Ward wrote: > On 3/10/2008, at 2:26 AM, Erik Kline wrote: >> On Sun, Sep 21, 2008 at 7:12 PM, Brian E Carpenter >> wrote: >>> On 2008-09-20 12:54, Nathan Ward wrote: >>>> On 20/09/2008, at 12:15 PM, james woodyatt wrote: >>>>> There is clearly something broken about 6to4, and I'm not sure how to >>>>> fix it. Can it be saved as a standard? >>> >>> Just to be clear, the issue is not with basic 6to4, which was intended >>> to be implemented only in routers. It's with the "obvious" extension >>> to allow host-based 6to4, which led fairly quickly to the notion >>> of anycast relays and the resulting lack of both configuration and of >>> a discovery protocol. >> >> Well it seems to be working well enough (or popular enough, anyway). >> What if I said that 69.8% of IPv6-enabled users who visit google.com >> have 6to4? That's the least I'd expect, as an author of 6to4 ;-) Any stats for Teredo? > > > So, Brian disagrees with the host based 6to4 thing, ie. the way Windows > Vista and XPSP2 do it. No, I don't disagree with it, I just want to remind people that most of the thinking about how 6to4 routes should be announced was based on the router model, without considering either automatic discovery or anycast. > > I don't think that the anycast relays has anything to do with the host > based stuff. It might have been related thought trains in peoples' minds > in 2001, but the anycast relays are just as relevant to router-based > 6to4 as they are to host-based 6to4. Except that the idea was that router relationships for 6to4 would be configured by mutually consenting operators; whereas the anycast model implies zero-conf. There's a gap in the middle where a discovery protocol could live. > > For example, Airport Extreme, Linksys RVS4000, Cisco 8XX+config, etc. > So, it's not just Windows. > > I'm not so hot on 6to4 stacks in hosts either, but my problem is wider - > it is more with automatically configured 6to4, which is not specific to > hosts. OK, but it's dominated by hosts, especially because of Vista. Brian > > My feeling is still that this whole relay stealing thing is a non-issue > in current implementations, I'll write up in a draft with some > recommendations to remove that paragraph and bring it in line with most > existing deployments. > > > > Also, these stats are interesting, and are roughly the same as what I'd > expect. > So, my understanding is that this test is to a hostname with A and AAAA > records, right? That would make sense, as Teredo will only be used by XP > SP2 and Linux boxes who have Teredo enabled (Vista prefers A over AAAA > if it only has Teredo IPv6 connectivity). > > I don't think that you can accurately say that that you tested all IPv6 > enabled users, because you aren't testing whether they are Vista and > have Teredo enabled. Point em at a hostname with only AAAA and my > expectation is that you'll significantly see different results - close > to what I see, which are like: > - ~90% Teredo > - ~7-8% 6to4 > - rest Native > > -- > Nathan Ward > > > > > From owner-v6ops@ops.ietf.org Thu Oct 2 20:12:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2CC3A686A for ; Thu, 2 Oct 2008 20:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_14=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVj2SfDHkmXB for ; Thu, 2 Oct 2008 20:12:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A0A43A6827 for ; Thu, 2 Oct 2008 20:12:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Klb0w-0004fP-DZ for v6ops-data@psg.com; Fri, 03 Oct 2008 03:07:34 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Klb0r-0004ep-Kx for v6ops@ops.ietf.org; Fri, 03 Oct 2008 03:07:32 +0000 Received: from [121.90.51.41] (unknown [121.90.51.41]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 9AA9D2792E; Fri, 3 Oct 2008 16:07:14 +1300 (NZDT) Cc: IPv6 Operations , ekline@ekline.com Message-Id: <4B36D7CB-D2DA-4F0E-B0DE-FBDB67E919E6@daork.net> From: Nathan Ward To: Brian E Carpenter In-Reply-To: <48E57631.8010009@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: implications of 6to4 for v6coex Date: Fri, 3 Oct 2008 16:06:23 +1300 References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <48CDDB4B.3000506@gmail.com> <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> <48E57631.8010009@gmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 3/10/2008, at 2:32 PM, Brian E Carpenter wrote: >> So, Brian disagrees with the host based 6to4 thing, ie. the way >> Windows >> Vista and XPSP2 do it. > > No, I don't disagree with it, I just want to remind people that most > of the thinking about how 6to4 routes should be announced was based > on the router model, without considering either automatic discovery > or anycast. That's interesting eh, as so many people think of 6to4 the other way around. >> I don't think that the anycast relays has anything to do with the >> host >> based stuff. It might have been related thought trains in peoples' >> minds >> in 2001, but the anycast relays are just as relevant to router-based >> 6to4 as they are to host-based 6to4. > > Except that the idea was that router relationships for 6to4 would be > configured by mutually consenting operators; whereas the anycast model > implies zero-conf. There's a gap in the middle where a discovery > protocol could live. Yes. I have some thoughts around this I wouldn't mind whiteboarding with you - I'll get in touch next week. >> For example, Airport Extreme, Linksys RVS4000, Cisco 8XX+config, etc. >> So, it's not just Windows. >> >> I'm not so hot on 6to4 stacks in hosts either, but my problem is >> wider - >> it is more with automatically configured 6to4, which is not >> specific to >> hosts. > > OK, but it's dominated by hosts, especially because of Vista. Yes. This is easy to see that, at least for Vista and XP, because the address is of the form: 2002:AABB:CCDD::AABB:CCDD (Where AA.BB.CC.DD is the IPv4 address) Note that AABB:CCDD is repeated in the last 32 bits as well as in bits 33-48. -- Nathan Ward From owner-v6ops@ops.ietf.org Thu Oct 2 21:02:13 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B17A3A6A76 for ; Thu, 2 Oct 2008 21:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.727 X-Spam-Level: X-Spam-Status: No, score=0.727 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, 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 7QbLlAkBIDhk for ; Thu, 2 Oct 2008 21:02:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB6603A6977 for ; Thu, 2 Oct 2008 21:02:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Klbqw-0008YI-H7 for v6ops-data@psg.com; Fri, 03 Oct 2008 04:01:18 +0000 Received: from [64.233.170.185] (helo=rn-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Klbqj-0008XN-F3 for v6ops@ops.ietf.org; Fri, 03 Oct 2008 04:01:15 +0000 Received: by rn-out-0910.google.com with SMTP id i50so455442rne.11 for ; Thu, 02 Oct 2008 21:01:04 -0700 (PDT) Received: by 10.151.39.2 with SMTP id r2mr1067032ybj.76.1223006464592; Thu, 02 Oct 2008 21:01:04 -0700 (PDT) Received: by 10.150.157.19 with HTTP; Thu, 2 Oct 2008 21:01:04 -0700 (PDT) Message-ID: <67099930810022101q573e2162v42a0b722cc2f8bcc@mail.gmail.com> Date: Fri, 3 Oct 2008 00:01:04 -0400 From: "Erik Kline" To: "Brian E Carpenter" Subject: Re: implications of 6to4 for v6coex Cc: "Nathan Ward" , "IPv6 Operations" In-Reply-To: <48E57631.8010009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> <48E57631.8010009@gmail.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >>> Well it seems to be working well enough (or popular enough, anyway). >>> What if I said that 69.8% of IPv6-enabled users who visit google.com >>> have 6to4? > > That's the least I'd expect, as an author of 6to4 ;-) > > Any stats for Teredo? This test was against a dual-stacked hostname. Teredo comes in around 1.2%. The same or less than ISATAP. A full presentation by the engineer who did the work will be at RIPE57. (I tried to find a reference to Steinar Gunderson's talk on http://www.ripe.net/ripe/meetings/ripe-57/meeting-plan.html and related but I seem to be having connectivity problems.) Hopefully I haven't stolen any thunder. >> So, my understanding is that this test is to a hostname with A and AAAA >> records, right? That would make sense, as Teredo will only be used by XP >> SP2 and Linux boxes who have Teredo enabled (Vista prefers A over AAAA >> if it only has Teredo IPv6 connectivity). >> >> I don't think that you can accurately say that that you tested all IPv6 >> enabled users, because you aren't testing whether they are Vista and >> have Teredo enabled. Point em at a hostname with only AAAA and my >> expectation is that you'll significantly see different results - close >> to what I see, which are like: >> - ~90% Teredo >> - ~7-8% 6to4 >> - rest Native Yeah, but this doesn't represent reality for me as a content provider. We spoke about this at APNIC26, IIRC, but to put it on-record on the list: I (with my Google hat on) am not interested in "how much Teredo is _deployed_", e.g. in the sense of "how much Teredo _might_ I see". I'm interested purely in "how much Teredo am I _actually_ seeing", to help answer the question "should I bother to deploy my own Teredo relay and/or actually have Teredo VIPs for services?". Right now that answer appears to be "don't bother yet". And, to state the obvious, google.com is never going turn off IPv4 and still leave IPv6 up for any service until there's so few IPv4 users that it's operationally not a financial win (i.e. we save more money operationally by turning it off than revenue sacrificed by doing so). Not that Teredo isn't amazing and can leap tall buildings and make my espresso for me; I understand. :-) -Erik From owner-v6ops@ops.ietf.org Fri Oct 3 00:36:27 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4954A3A685F for ; Fri, 3 Oct 2008 00:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSxO9h+jPucS for ; Fri, 3 Oct 2008 00:36:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 738503A6452 for ; Fri, 3 Oct 2008 00:36:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlfA5-0000ay-AG for v6ops-data@psg.com; Fri, 03 Oct 2008 07:33:17 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlfA1-0000aV-7K for v6ops@ops.ietf.org; Fri, 03 Oct 2008 07:33:15 +0000 Received: by yop.chewa.net (Postfix, from userid 33) id A323BA85; Fri, 3 Oct 2008 09:33:09 +0200 (CEST) To: Erik Kline Subject: Re: implications of 6to4 for v6coex MIME-Version: 1.0 Date: Fri, 03 Oct 2008 09:33:09 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Cc: Brian E Carpenter , Nathan Ward , IPv6 Operations Organization: Remlab.net In-Reply-To: <67099930810022101q573e2162v42a0b722cc2f8bcc@mail.gmail.com> References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> <48E57631.8010009@gmail.com> <67099930810022101q573e2162v42a0b722cc2f8bcc@mail.gmail.com> Message-ID: <72497d58720f5ed82d26e39827324f68@chewa.net> X-Sender: rdenis@simphalempin.com User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, 3 Oct 2008 00:01:04 -0400, "Erik Kline" wrote: >>>> Well it seems to be working well enough (or popular enough, anyway). >>>> What if I said that 69.8% of IPv6-enabled users who visit google.com >>>> have 6to4? >> >> That's the least I'd expect, as an author of 6to4 ;-) >> >> Any stats for Teredo? > > This test was against a dual-stacked hostname. Teredo comes in around > 1.2%. The same or less than ISATAP. I expect that Teredo should be _forever_ close to 0% against *dual-stacked* hostnames, thanks to source address selection. I have been proposing to fix the address scoping rules of RFC3484 to get that number even lower: RFC1918 IPv4 addresses should global scope (which they are because of NATs), w.r.t. to source address selection. It appears that Windows already does this; if it did not it would prefer Teredo over native NAT'ed IPv4 in face of a dual-stacked hostnames. Teredo should be statically meaningful only with IPv6-only hostnames. (...) >>> I don't think that you can accurately say that that you tested all IPv6 >>> enabled users, because you aren't testing whether they are Vista and >>> have Teredo enabled. Point em at a hostname with only AAAA and my >>> expectation is that you'll significantly see different results - close >>> to what I see, which are like: >>> - ~90% Teredo >>> - ~7-8% 6to4 >>> - rest Native > > Yeah, but this doesn't represent reality for me as a content provider. I tend to agree that content provider should not have to care much about Teredo. To me, it seems more useful for peer-to-peer use cases. I would say, that's a concern for "consumer ISPs", not for Google. -- Rémi Denis-Courmont From owner-v6ops@ops.ietf.org Sat Oct 4 02:12:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591AA3A68E7 for ; Sat, 4 Oct 2008 02:12:21 -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_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 BfZFPi-1caHL for ; Sat, 4 Oct 2008 02:12:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 162193A699F for ; Sat, 4 Oct 2008 02:12:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Km368-000OzM-K2 for v6ops-data@psg.com; Sat, 04 Oct 2008 09:06:48 +0000 Received: from [2001:770:10:300::86e2:510b] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Km35v-000OyP-NW for v6ops@ops.ietf.org; Sat, 04 Oct 2008 09:06:44 +0000 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 4 Oct 2008 10:06:32 +0100 (BST) Date: Sat, 4 Oct 2008 10:06:28 +0100 From: David Malone To: Erik Kline Cc: Brian E Carpenter , Nathan Ward , IPv6 Operations Subject: Re: implications of 6to4 for v6coex Message-ID: <20081004090628.GA71165@walton.maths.tcd.ie> References: <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> <48E57631.8010009@gmail.com> <67099930810022101q573e2162v42a0b722cc2f8bcc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67099930810022101q573e2162v42a0b722cc2f8bcc@mail.gmail.com> User-Agent: Mutt/1.5.6i Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Fri, Oct 03, 2008 at 12:01:04AM -0400, Erik Kline wrote: > This test was against a dual-stacked hostname. Teredo comes in around > 1.2%. The same or less than ISATAP. In the stats I did on ftp.heanet.ie's log files, I saw a big rise in teredo mid 2006, to the level of being a few percent of the IPv6 addresses connecting (see Figure 4 in this): http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf Strangely, the increase didn't seem to be due to Vista, based on the user agent srings. ISATAP use seemed to grow between 2004 and 2005, but Teredo seemed to overtake it in 2006. I haven't rechecked the stats for 2008, but I could do if someone was interested. David. From owner-v6ops@ops.ietf.org Sat Oct 4 22:19:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2DA28C0DE for ; Sat, 4 Oct 2008 22:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.305 X-Spam-Level: X-Spam-Status: No, score=-98.305 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_DOB=0.732, J_CHICKENPOX_14=0.6, RCVD_IN_DOB=1.103, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezps7znbpsBZ for ; Sat, 4 Oct 2008 22:19:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E005B28C0D9 for ; Sat, 4 Oct 2008 22:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmLx3-000LUJ-UN for v6ops-data@psg.com; Sun, 05 Oct 2008 05:14:41 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmLwz-000LTo-Rx for v6ops@ops.ietf.org; Sun, 05 Oct 2008 05:14:40 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5EE769B; Sun, 5 Oct 2008 07:14:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5E7329A for ; Sun, 5 Oct 2008 07:14:31 +0200 (CEST) Date: Sun, 5 Oct 2008 07:14:31 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: some real life data Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi. I conducted an experiment to collect some ipv4/v6 data with the help of a certain large p2p bittorrent tracker website. I had them include javascript code that would load three 42 byte gifs upon webpage load completion (to not impact user experience). The site itself wasn't v6 enabled. The site itself is biased towards the scandinavian geographical region, but has a worldwide user base. The first gif was loaded from an address with a single A record (v4only). Second had both A and AAAA (v4v6). Third had just AAAA (v6only). I haven't put all the data into a neat presentation or anything yet (though I have given it to others who will), but I thought I'd share some key numbers ("user" here is an IP number in the log, where each IP number is only counted once, I only used unix tools like cut/awk/sort/uniq etc, nothing fancy). This data is only from around 24 hours or collecting, but still hundreds of thousands of unique IPs. 0.5% of the users pulled the v4v6 gif using IPv6. 6% of the users were able to get the v6only gif. Of the v6only accesses, 91% were from 6to4 addresses, 7% were teredo and 2% were from other ipv6 space. The "other ipv6 space" was from 58 different /32s. Of the users getting v6 only gif from non-tunnel-space, 58% were from Proxad (free.fr I believe), and then on the list came UNINET, SUNET, FUNET (university networks in .no, .se and .fi) and Hurricane electric. 98% of Teredo users run Windows XP. 88% of 6to4 users run Windows Vista. The difference in page loads between v4only and v4v6 was 0.4%, indicating that some users might have problems loading something that has both A and AAAA DNS. This might be that it's slower, doesn't work, or simply that some users clicked on a link before that gif was loaded. The gifs were loaded in the order indicated above, with the javascript function "window.onload". Feedback appreciated. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Sun Oct 5 01:31:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634283A6822 for ; Sun, 5 Oct 2008 01:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[AWL=-2.950, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_14=0.6, 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 AfajP++7Z4m9 for ; Sun, 5 Oct 2008 01:31:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A1253A67B6 for ; Sun, 5 Oct 2008 01:31:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmOxt-0007gs-3Y for v6ops-data@psg.com; Sun, 05 Oct 2008 08:27:45 +0000 Received: from [212.124.200.129] (helo=waikiki.gih.co.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmOxn-0007g9-Fq for v6ops@ops.ietf.org; Sun, 05 Oct 2008 08:27:41 +0000 Received: from waikiki.gih.co.uk (localhost.localdomain [127.0.0.1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 8A75518F3CA; Sun, 5 Oct 2008 09:27:36 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:from :to:references:subject:date:mime-version:content-type: content-transfer-encoding; s=mahalo1; bh=IZviz8zAyZSBGKDQsiHJCGs 8yFI=; b=LGsTiOmC/1aPjhm87gcDOYO4l+Aa6F7S6/Bi9n4vjZHZlx+SvmXVIlh NIla/7npg1zmCy0btkEEyAqgQQhEeBZwX2hiuUJP5ePWU6W2YWrEtGDfNwGumPoi SeQHEeKh0wdUFEHUy1o/tUeBrkYCSWPD15PokGB+xxHu8XDDfQJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:from:to :references:subject:date:mime-version:content-type: content-transfer-encoding; q=dns; s=mahalo1; b=ebj7tWwiDtJRB03O/ S0CsxXFBNKkhONj2c3RWleNyi0t9vwPno1sMkJggF5iaVLDnzskDtWOoRKrtOGE3 IHLOWbFVlwM9BAFikf4XWpgy5fon0D/A83S2JoCXTPbGgFxKGGfWjR3N/7kwSLWu TGhqV+0tTGPYMXuPmls1k/oLSw= Received: from ALOHA2 (ANice-151-1-44-3.w83-197.abo.wanadoo.fr [83.197.6.3]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id A97B518F3B0; Sun, 5 Oct 2008 09:27:35 +0100 (BST) Message-ID: <2EC08612926E44CBA7EFB2378BB28F8B@ALOHA2> From: "Olivier MJ Crepin-Leblond" To: "Mikael Abrahamsson" , References: Subject: Re: some real life data Date: Sun, 5 Oct 2008 10:26:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello Mikael, very interesting. You might wish to extend your sample size to beyond 24h to gain better usage patterns. Short samples of 24h might favour specific heavy users on this occasion. Kind regards, Olivier -- Olivier MJ Crepin-Leblond, Ph.D. E-mail: | http://www.gih.com/ocl.html ----- Original Message ----- From: "Mikael Abrahamsson" To: Sent: Sunday, October 05, 2008 6:14 AM Subject: some real life data > > Hi. > > I conducted an experiment to collect some ipv4/v6 data with the help of a > certain large p2p bittorrent tracker website. I had them include > javascript code that would load three 42 byte gifs upon webpage load > completion (to not impact user experience). The site itself wasn't v6 > enabled. The site itself is biased towards the scandinavian geographical > region, but has a worldwide user base. > > The first gif was loaded from an address with a single A record (v4only). > Second had both A and AAAA (v4v6). > Third had just AAAA (v6only). > > I haven't put all the data into a neat presentation or anything yet > (though I have given it to others who will), but I thought I'd share some > key numbers ("user" here is an IP number in the log, where each IP number > is only counted once, I only used unix tools like cut/awk/sort/uniq etc, > nothing fancy). This data is only from around 24 hours or collecting, but > still hundreds of thousands of unique IPs. > > 0.5% of the users pulled the v4v6 gif using IPv6. > > 6% of the users were able to get the v6only gif. > > Of the v6only accesses, 91% were from 6to4 addresses, 7% were teredo and > 2% were from other ipv6 space. The "other ipv6 space" was from 58 > different /32s. > > Of the users getting v6 only gif from non-tunnel-space, 58% were from > Proxad (free.fr I believe), and then on the list came UNINET, SUNET, FUNET > (university networks in .no, .se and .fi) and Hurricane electric. > > 98% of Teredo users run Windows XP. > 88% of 6to4 users run Windows Vista. > > The difference in page loads between v4only and v4v6 was 0.4%, indicating > that some users might have problems loading something that has both A and > AAAA DNS. This might be that it's slower, doesn't work, or simply that > some users clicked on a link before that gif was loaded. The gifs were > loaded in the order indicated above, with the javascript function > "window.onload". > > Feedback appreciated. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > From owner-v6ops@ops.ietf.org Sun Oct 5 05:51:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61AE3A6890 for ; Sun, 5 Oct 2008 05:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-2.750, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4fk4hdzCGxL for ; Sun, 5 Oct 2008 05:51:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0CFB3A6819 for ; Sun, 5 Oct 2008 05:51:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmT0w-0001fW-A1 for v6ops-data@psg.com; Sun, 05 Oct 2008 12:47:10 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmT0o-0001el-Hm for v6ops@ops.ietf.org; Sun, 05 Oct 2008 12:47:08 +0000 X-IronPort-AV: E=Sophos;i="4.33,363,1220227200"; d="scan'208";a="21646347" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2008 12:46:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m95CkutX024818; Sun, 5 Oct 2008 14:46:56 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m95CkudB022491; Sun, 5 Oct 2008 12:46:56 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Oct 2008 14:46: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 Subject: RE: some real life data Date: Sun, 5 Oct 2008 14:43:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some real life data Thread-Index: AckmqlgY/3L+uKOdSYaRWyEk6SIM3gAPNGyw References: From: "Eric Vyncke (evyncke)" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 05 Oct 2008 12:46:56.0618 (UTC) FILETIME=[7357ECA0:01C926E8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3473; t=1223210816; x=1224074816; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:=20=22Eric=20Vyncke=20(evyncke)=22=20 |Subject:=20RE=3A=20some=20real=20life=20data |Sender:=20; bh=Ajv7+itnoiMEZK4yrGV8qEXkl2VJQly8uf+uU5Vgl6A=; b=j7B6O/cuPEYtgrvABYegHzpmZKI3d7Dtm4RbUkVHfDIBqBmLPxrxDkqgTS m/ApfXsxsqTFuc9S+nXwDUvirvNyQjPKZwlWUDZS65cZNvSBk9Rivmch7ZmM DQQio/B/dP; Authentication-Results: ams-dkim-2; header.From=evyncke@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Very very interesting because it tends to confirm my own experiment = based on = http://www.ietf.org/internet-drafts/draft-vyncke-http-server-64aware-00.t= xt Also playing tricks with loading an IPv6 only 1x1 pixel images on some = web pages. As the web pages are on French speaking web sites until now, = there is a clear bias towards France/Canada/Belgium/Switzerland where = Free.net has an clear advantage of course. Stats compiled for more than 1 month: http://sigma.hec.be/~evyncke/family/countv6/stats.php (see the several = graphs at the end) It is about 10% of IPv6 able clients... (mainly Vista). Teredo is the = most used connectivity followed by Free NB: feel free to look at the http://www.vyncke.org/countv6/ to see how = is is done and add the 'tracker' to any page of yours of course. Empirical experiment with uTorrent also shows between 5% and 10% of IPv6 = peers. Hope this helps to show that IPv6 could be more than the 'advertised' = 0.01% of the Internet traffic. -=E9ric =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mikael Abrahamsson > Sent: dimanche 5 octobre 2008 7:15 > To: v6ops@ops.ietf.org > Subject: some real life data >=20 >=20 > Hi. >=20 > I conducted an experiment to collect some ipv4/v6 data with=20 > the help of a certain large p2p bittorrent tracker website. I=20 > had them include javascript code that would load three 42=20 > byte gifs upon webpage load completion (to not impact user=20 > experience). The site itself wasn't v6 enabled. The site=20 > itself is biased towards the scandinavian geographical=20 > region, but has a worldwide user base. >=20 > The first gif was loaded from an address with a single A=20 > record (v4only). > Second had both A and AAAA (v4v6). > Third had just AAAA (v6only). >=20 > I haven't put all the data into a neat presentation or=20 > anything yet (though I have given it to others who will), but=20 > I thought I'd share some key numbers ("user" here is an IP=20 > number in the log, where each IP number is only counted once,=20 > I only used unix tools like cut/awk/sort/uniq etc, nothing=20 > fancy). This data is only from around 24 hours or collecting,=20 > but still hundreds of thousands of unique IPs. >=20 > 0.5% of the users pulled the v4v6 gif using IPv6. >=20 > 6% of the users were able to get the v6only gif. >=20 > Of the v6only accesses, 91% were from 6to4 addresses, 7% were=20 > teredo and 2% were from other ipv6 space. The "other ipv6=20 > space" was from 58 different /32s. >=20 > Of the users getting v6 only gif from non-tunnel-space, 58%=20 > were from Proxad (free.fr I believe), and then on the list=20 > came UNINET, SUNET, FUNET (university networks in .no, .se=20 > and .fi) and Hurricane electric. >=20 > 98% of Teredo users run Windows XP. > 88% of 6to4 users run Windows Vista. >=20 > The difference in page loads between v4only and v4v6 was=20 > 0.4%, indicating that some users might have problems loading=20 > something that has both A and AAAA DNS. This might be that=20 > it's slower, doesn't work, or simply that some users clicked=20 > on a link before that gif was loaded. The gifs were loaded in=20 > the order indicated above, with the javascript function=20 > "window.onload". >=20 > Feedback appreciated. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 From owner-v6ops@ops.ietf.org Sun Oct 5 07:25:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE12C3A6847 for ; Sun, 5 Oct 2008 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.153 X-Spam-Level: X-Spam-Status: No, score=-5.153 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0Cz-s04rgBP for ; Sun, 5 Oct 2008 07:25:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6D3C3A6837 for ; Sun, 5 Oct 2008 07:25:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmUUx-000AU9-5D for v6ops-data@psg.com; Sun, 05 Oct 2008 14:22:15 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmUUs-000ATK-9Y for v6ops@ops.ietf.org; Sun, 05 Oct 2008 14:22:13 +0000 Received: from [192.168.0.51] (ip-118-90-75-60.xdsl.xnet.co.nz [118.90.75.60]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 938332751E; Mon, 6 Oct 2008 03:22:05 +1300 (NZDT) Cc: v6ops@ops.ietf.org Message-Id: From: Nathan Ward To: Mikael Abrahamsson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: some real life data Date: Mon, 6 Oct 2008 03:22:04 +1300 References: X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 5/10/2008, at 6:14 PM, Mikael Abrahamsson wrote: > Hi. > > I conducted an experiment to collect some ipv4/v6 data with the help > of a certain large p2p bittorrent tracker website. I had them > include javascript code that would load three 42 byte gifs upon > webpage load completion (to not impact user experience). The site > itself wasn't v6 enabled. The site itself is biased towards the > scandinavian geographical region, but has a worldwide user base. > > The first gif was loaded from an address with a single A record > (v4only). > Second had both A and AAAA (v4v6). > Third had just AAAA (v6only). > > I haven't put all the data into a neat presentation or anything yet > (though I have given it to others who will), but I thought I'd share > some key numbers ("user" here is an IP number in the log, where each > IP number is only counted once, I only used unix tools like cut/awk/ > sort/uniq etc, nothing fancy). This data is only from around 24 > hours or collecting, but still hundreds of thousands of unique IPs. > > 0.5% of the users pulled the v4v6 gif using IPv6. > > 6% of the users were able to get the v6only gif. > > Of the v6only accesses, 91% were from 6to4 addresses, 7% were teredo > and 2% were from other ipv6 space. The "other ipv6 space" was from > 58 different /32s. > > Of the users getting v6 only gif from non-tunnel-space, 58% were > from Proxad (free.fr I believe), and then on the list came UNINET, > SUNET, FUNET (university networks in .no, .se and .fi) and Hurricane > electric. > > 98% of Teredo users run Windows XP. > 88% of 6to4 users run Windows Vista. > > The difference in page loads between v4only and v4v6 was 0.4%, > indicating that some users might have problems loading something > that has both A and AAAA DNS. This might be that it's slower, > doesn't work, or simply that some users clicked on a link before > that gif was loaded. The gifs were loaded in the order indicated > above, with the javascript function "window.onload". I have some javascript code that can be dropped on to a web page with little effort to do exactly this. In addition, it times how long images take to load, and provides feedback on status periodically by updating another IMG tag's address to a url with several parameters in it. http://www.braintrust.co.nz/ipv6wwwtest/ It's not amazing code as I'm not a javascript coder, but it seems to work OK. The Teredo count on the IPv6 only address seems very low, considering that Teredo is used by hosts behind NAT, while 6to4 is used by hosts not behind NAT. Given that most hosts are behind NAT, it would be my suspicion that most hosts are on Teredo - and that is indeed what my research shows. That 98% of Teredo users run XP suggests to me that perhaps the v6only gif had an A record on it accidentally.. Vista will prefer A over AAAA if it only has Teredo connectivity. XP will prefer AAAA over A all the time. Considering that Teredo is disabled by default in XP, the numbers you've got here seem more like what I'd expect from an A+AAAA DNS name (though many XP Bittorrent users now have Teredo turned on thanks to uTorrent). I'd also recommend trying various combinations with 6to4 and Teredo IPv6 addresses in AAAA records as well. My code there only does Teredo and 6to4 addresses, no native addresses as at the time I was using it I did not have native connectivity. Also, looking at packet captures, keeping an eye out for ICMPv6 ping for the Teredo relay discovery could be interesting. You might find that the Teredo relay closest to you was unreliable, in which case you'd see ICMPv6 echo requests coming to you and responses going out, but no initial SYN packet. Were you running your own relay? Also of interest would be bits 33-64 of the Teredo address, see what hosts are using what Teredo servers (ie. who is using the Microsoft ones? Who is using ones provided by $linux_vendor?). 6to4 addresses are also interesting, you can detect Windows style host- based 6to4 by checking to see if the address is of the format: 2002:AABB:CCDD::AABB:CCDD, ie the IPv4 address appears in the last 32 bits, as well as bits 17-48. It would be interesting to see what Windows vs. non-Windows hosts are on which type of addresses, etc. Also looking for EUI-64 vs static addressing (ie 2002:AABB:CCDD::1 or something). I've been crunching numbers with this sort of data for a while so if anyone doing this sort of research, I'd be more than happy to help out any way I can, drop me a line offlist - nward@braintrust.co.nz. I've got a bunch of custom tools and things for processing packets (ie. decoding Teredo/6to4/etc.) and such and putting info in to databases so that it can be queried etc. etc. -- Nathan Ward From owner-v6ops@ops.ietf.org Sun Oct 5 08:00:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9743A6832 for ; Sun, 5 Oct 2008 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.235 X-Spam-Level: X-Spam-Status: No, score=-99.235 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DNS_FROM_DOB=0.732, J_CHICKENPOX_14=0.6, RCVD_IN_DOB=1.103, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mgB+CsLTJag for ; Sun, 5 Oct 2008 08:00:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 351433A659B for ; Sun, 5 Oct 2008 08:00:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmV58-000Ea5-5n for v6ops-data@psg.com; Sun, 05 Oct 2008 14:59:38 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmV53-000EZX-Iw for v6ops@ops.ietf.org; Sun, 05 Oct 2008 14:59:35 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 453F19B; Sun, 5 Oct 2008 16:59:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 44CD39A for ; Sun, 5 Oct 2008 16:59:32 +0200 (CEST) Date: Sun, 5 Oct 2008 16:59:32 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 6 Oct 2008, Nathan Ward wrote: > The Teredo count on the IPv6 only address seems very low, considering that > Teredo is used by hosts behind NAT, while 6to4 is used by hosts not behind > NAT. Given that most hosts are behind NAT, it would be my suspicion that most > hosts are on Teredo - and that is indeed what my research shows. Well, I thought so too. I have been trying to get teredo working on my XP box behind a NAT, but I couldn't get it working, I don't know why yet. It works well without NAT though. > That 98% of Teredo users run XP suggests to me that perhaps the v6only gif > had an A record on it accidentally.. Vista will prefer A over AAAA if it only > has Teredo connectivity. XP will prefer AAAA over A all the time. Considering > that Teredo is disabled by default in XP, the numbers you've got here seem > more like what I'd expect from an A+AAAA DNS name (though many XP Bittorrent > users now have Teredo turned on thanks to uTorrent). For some strange reason I have approx 1% of v4 addresses in my v6only log. v6only has no A record, it never has had, and currently I have no idea how the v4 addresses come to fetch it. > Were you running your own relay? Yes, we have a local relay. It might have some kind of problem, I'll look into that as well. > Also of interest would be bits 33-64 of the Teredo address, see what hosts > are using what Teredo servers (ie. who is using the Microsoft ones? Who is > using ones provided by $linux_vendor?). I'll look into that. > I've been crunching numbers with this sort of data for a while so if anyone > doing this sort of research, I'd be more than happy to help out any way I > can, drop me a line offlist - nward@braintrust.co.nz. I'll definitely do that. I'm going to do some more work on the data during the coming week when more has been collected. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Sun Oct 5 08:50:29 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4A73A6927 for ; Sun, 5 Oct 2008 08:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.382 X-Spam-Level: X-Spam-Status: No, score=-101.382 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, DNS_FROM_DOB=0.732, J_CHICKENPOX_14=0.6, RCVD_IN_DOB=1.103, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6s-wrLSFJCc for ; Sun, 5 Oct 2008 08:50:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A1953A691B for ; Sun, 5 Oct 2008 08:50:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmVpb-000J8S-Bm for v6ops-data@psg.com; Sun, 05 Oct 2008 15:47:39 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmVpX-000J7q-E4 for v6ops@ops.ietf.org; Sun, 05 Oct 2008 15:47:37 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m95FlTsb005446; Sun, 5 Oct 2008 18:47:29 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m95FlSC7005442; Sun, 5 Oct 2008 18:47:29 +0300 Date: Sun, 5 Oct 2008 18:47:28 +0300 (EEST) From: Pekka Savola To: Mikael Abrahamsson cc: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: ClamAV 0.93.3/8374/Sat Oct 4 20:41:34 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 5 Oct 2008, Mikael Abrahamsson wrote: > Of the users getting v6 only gif from non-tunnel-space, 58% were from Proxad > (free.fr I believe), and then on the list came UNINET, SUNET, FUNET > (university networks in .no, .se and .fi) and Hurricane electric. > > 98% of Teredo users run Windows XP. > 88% of 6to4 users run Windows Vista. Total OS breakdown (including also v4only) would be interesting to show the popularity of the OSes in your user base. What would be interestesting to know the percentage of Vista, XP, Linux, .. (and other identifiable OSs) that were IPv6-capable? In particular I'd be interested in Vista and Apple (various versions) percentages, as those enable some v6 transition mechanisms out of the box AFAIR. I'm puzzled at why Vista users are not more prominent in Teredo count, but Nathan already wondered about the same thign as well, and also that the teredo counts for v6only were so low compared to 6to4. It smells as if something is not quite right somewhere. -- 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 owner-v6ops@ops.ietf.org Sun Oct 5 09:04:30 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35053A68A1 for ; Sun, 5 Oct 2008 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, DNS_FROM_DOB=0.732, J_CHICKENPOX_14=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DOB=1.103, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dnplZk6Ep4G for ; Sun, 5 Oct 2008 09:04:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 380353A68DE for ; Sun, 5 Oct 2008 09:04:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmW3w-000Kdr-A7 for v6ops-data@psg.com; Sun, 05 Oct 2008 16:02:28 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmW3r-000Kci-3f for v6ops@ops.ietf.org; Sun, 05 Oct 2008 16:02:25 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id E008D9B; Sun, 5 Oct 2008 18:02:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DDBD99A for ; Sun, 5 Oct 2008 18:02:21 +0200 (CEST) Date: Sun, 5 Oct 2008 18:02:21 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 5 Oct 2008, Pekka Savola wrote: > I'm puzzled at why Vista users are not more prominent in Teredo count, > but Nathan already wondered about the same thign as well, and also that > the teredo counts for v6only were so low compared to 6to4. It smells as > if something is not quite right somewhere. I just verified that my test server is reachable within Sweden via Teredo from my XP laptop anyway (I am behind another ISP and a NAT right now). is located on the same machine as I use for hosting the gif:s, if you're out in the world and have IPv6 access via Teredo, please check and see if you can reach that page. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Mon Oct 6 07:21:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969353A6A6D for ; Mon, 6 Oct 2008 07:21: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=[AWL=-0.900, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 26Ae7AYUB00o for ; Mon, 6 Oct 2008 07:20:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC1CA3A67B4 for ; Mon, 6 Oct 2008 07:20:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmqmF-000AEZ-In for v6ops-data@psg.com; Mon, 06 Oct 2008 14:09:35 +0000 Received: from [212.27.42.64] (helo=smtp7-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmqm9-000ADe-5f for v6ops@ops.ietf.org; Mon, 06 Oct 2008 14:09:31 +0000 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 08422B019F; Mon, 6 Oct 2008 16:09:27 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp7-g19.free.fr (Postfix) with ESMTP id C0463B01D7; Mon, 6 Oct 2008 16:09:20 +0200 (CEST) Message-ID: <48EA1BC1.9000509@free.fr> Date: Mon, 06 Oct 2008 16:08:01 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Erik Kline CC: Nathan Ward , Brian E Carpenter , IPv6 Operations Subject: Re: implications of 6to4 for v6coex - 6to4 and 6rd properties References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <48CDDB4B.3000506@gmail.com> <47074AEB-0A3B-4E53-B19E-A5DDDC61AA6B@daork.net> <87F68CA7-37E4-40A1-85C8-C7D409D5120B@suspicious.org> <8EFB68EAE061884A8517F2A755E8B60A1349FBBD01@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4437E9C9-553D-43BE-A573-379BF6702DE8@daork.net> <48D6D4C1.5070307@gmail.com> <67099930810020626h56e8f1fcna3efa6c17a09e87e@mail.gmail.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> In-Reply-To: <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > On 3/10/2008, at 2:26 AM, Erik Kline wrote: >> Well it seems to be working well enough (or popular enough, anyway). >> What if I said that 69.8% of IPv6-enabled users who visit google.com >> have 6to4? As we discussed in Montreal, this proves that there is, for v6 packets that have the prefix of 6to4 (2002::/16), a path from ipv6.google.com servers to the IPv4 Internet. But it doesn't prove that clients of IPv6.Google, if they try to reach another IPv6 server, will always have a 6to4 return path for their packets. similarly, they may not be reachable, as servers, from any client having native IPv6 connectivity. This is the reason why I introduced 6rd (draft-despres-6rd-00). A 6rd ISP simply replaces, in IPv6 prefixes its provides to its customers, the standard 6to4 prefix by an IPv6 prefix that has been assigned to it. Thus any customer site of this ISP as guaranteed IPv6 connectivity, provided 6rd is supported in its home-gateway. A return path is available from any server or client remote host that has IPv6 connectivity (a 2002::/16 route form this host toward to 6to4 relay is no longer needed). So far, Free, the second ISP in France with several million customers, is AFAIK the only one that has deployed IPv6 using 6rd. I am about to revise draft-despres-6rd-00, essentially to no longer include a proposal for a 6rd DHCP option. ((1) It isn't necessary for ISPs that, like Free, deploy IPv6 in sites where they provide home-gateways. (2) Without the DHCP option, the proposed RFC stays purely informational. Having no IANA or protocol implication, it can follow a much much shorter path to be published.) Regards, RD PS: If not too complex, it would be really nice to have additional statistics giving, in the 30% users that are not 6to4, which proportion is Teredo (2001:0000::/32), and which proportion is neither. Even more ideally, at least for me, on would have the percentage of Free customers (2a01:0e30::/28) Thanks if you can do anything on this. From owner-v6ops@ops.ietf.org Mon Oct 6 08:57:49 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551793A6932 for ; Mon, 6 Oct 2008 08:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv0+mbLAiiMj for ; Mon, 6 Oct 2008 08:57:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AE053A6969 for ; Mon, 6 Oct 2008 08:57:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmsR8-000LdZ-K5 for v6ops-data@psg.com; Mon, 06 Oct 2008 15:55:54 +0000 Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmsQs-000Lba-EL for v6ops@ops.ietf.org; Mon, 06 Oct 2008 15:55:49 +0000 Received: from basile.remlab.net (unknown [IPv6:2002:591b:3aef:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id 5051D974; Mon, 6 Oct 2008 17:55:37 +0200 (CEST) From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net To: =?utf-8?q?R=C3=A9mi_Despr=C3=A9s?= Subject: Re: implications of 6to4 for v6coex - 6to4 and 6rd properties Date: Mon, 6 Oct 2008 18:55:34 +0300 User-Agent: KMail/1.9.9 Cc: Erik Kline , Nathan Ward , Brian E Carpenter , IPv6 Operations References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> <48EA1BC1.9000509@free.fr> In-Reply-To: <48EA1BC1.9000509@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810061855.35468.rdenis@simphalempin.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello, Le lundi 6 octobre 2008 17:08:01 R=C3=A9mi Despr=C3=A9s, vous avez =C3=A9cr= it=C2=A0: > > On 3/10/2008, at 2:26 AM, Erik Kline wrote: > >> Well it seems to be working well enough (or popular enough, anyway). > >> What if I said that 69.8% of IPv6-enabled users who visit google.com > >> have 6to4? > > As we discussed in Montreal, this proves that there is, for v6 packets > that have the prefix of 6to4 (2002::/16), a path from ipv6.google.com > servers to the IPv4 Internet. > > But it doesn't prove that clients of IPv6.Google, if they try to reach > another IPv6 server, will always have a 6to4 return path for their > packets. similarly, they may not be reachable, as servers, from any > client having native IPv6 connectivity. Last time I checked, Google used HTTP, HTTP ran on TCP, and TCP checked=20 return-routability in the three-way handshake. I don't disagree that the lack of built-in return-routability in 6to4 _is_ = a=20 problem in certain circumstances. Namely, when there is an IPv4 firewall on= =20 the proto-41 path. But lets not pretend it is worse than it really is. =2D-=20 R=C3=A9mi Denis-Courmont http://www.remlab.net/ From owner-v6ops@ops.ietf.org Mon Oct 6 10:05:55 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984F23A6A48 for ; Mon, 6 Oct 2008 10:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 KWrJ-Xpzu84k for ; Mon, 6 Oct 2008 10:05:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D5373A69AB for ; Mon, 6 Oct 2008 10:05:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmtUf-0003QJ-Nq for v6ops-data@psg.com; Mon, 06 Oct 2008 17:03:37 +0000 Received: from [212.27.42.36] (helo=smtp6-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmtUQ-0003Oj-Dz for v6ops@ops.ietf.org; Mon, 06 Oct 2008 17:03:32 +0000 Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id 75EA318C76; Mon, 6 Oct 2008 19:03:21 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g19.free.fr (Postfix) with ESMTP id 252B518CA8; Mon, 6 Oct 2008 19:02:46 +0200 (CEST) Message-ID: <48EA445C.9090704@free.fr> Date: Mon, 06 Oct 2008 19:01:16 +0200 From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= CC: Erik Kline , Nathan Ward , Brian E Carpenter , IPv6 Operations Subject: Re: implications of 6to4 for v6coex - 6to4 and 6rd properties References: <6C2047ED-8BFF-43B1-A6D4-68FDA93D8013@apple.com> <68E6072E-50B1-40B6-972E-4ACEA976B372@daork.net> <48EA1BC1.9000509@free.fr> <200810061855.35468.rdenis@simphalempin.com> In-Reply-To: <200810061855.35468.rdenis@simphalempin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Rémi Denis-Courmont (m/j/a) 10/6/08 5:55 PM: > Hello, > > Le lundi 6 octobre 2008 17:08:01 Rémi Després, vous avez écrit : >>> On 3/10/2008, at 2:26 AM, Erik Kline wrote: >>>> Well it seems to be working well enough (or popular enough, anyway). >>>> What if I said that 69.8% of IPv6-enabled users who visit google.com >>>> have 6to4? >> As we discussed in Montreal, this proves that there is, for v6 packets >> that have the prefix of 6to4 (2002::/16), a path from ipv6.google.com >> servers to the IPv4 Internet. >> >> But it doesn't prove that clients of IPv6.Google, if they try to reach >> another IPv6 server, will always have a 6to4 return path for their >> packets. similarly, they may not be reachable, as servers, from any >> client having native IPv6 connectivity. > > Last time I checked, Google used HTTP, HTTP ran on TCP, and TCP checked > return-routability in the three-way handshake. Did I suggest the contrary in any way? > I don't disagree that the lack of built-in return-routability in 6to4 _is_ a > problem in certain circumstances. Namely, when there is an IPv4 firewall on > the proto-41 path. But lets not pretend it is worse than it really is. > 1. In my understanding, the problem is not only with firewalls. If you have seen a proof that all ISPs that offer IPv6 have a guaranteed route for the 2002::/16 prefix toward the IPv4 Internet, with a quality they can control, that's good news :-), but it's not the state of the art I know. 2. I don't "pretend" anything. I just tell what I believe is true, when IMHO it helps IETF to make progress. Please remember that thanks to this kind of analysis, I now have native IPv6 at home. My ISP, Free, which didn't consider offering IPv6 across 6to4 relays, deployed IPv6 at no charge for customers after I had explained 6rd's potential. Regards, RD From owner-v6ops@ops.ietf.org Wed Oct 8 11:14:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACC13A6847 for ; Wed, 8 Oct 2008 11:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.5 X-Spam-Level: X-Spam-Status: No, score=-105.5 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 tSa+N+zcqqoy for ; Wed, 8 Oct 2008 11:14:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8485D3A67DF for ; Wed, 8 Oct 2008 11:14:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndUa-000I3V-V9 for v6ops-data@psg.com; Wed, 08 Oct 2008 18:10:36 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndUV-000I2s-ET for v6ops@ops.ietf.org; Wed, 08 Oct 2008 18:10:34 +0000 X-IronPort-AV: E=Sophos;i="4.33,379,1220227200"; d="scan'208";a="88484873" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-1.cisco.com with ESMTP; 08 Oct 2008 18:10:28 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id m98IASNV001106; Wed, 8 Oct 2008 11:10:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m98IARkK009330; Wed, 8 Oct 2008 18:10:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 11:10:28 -0700 Received: from stealth-10-32-244-219.cisco.com ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 11:10:28 -0700 Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Calling for agenda items Date: Wed, 8 Oct 2008 11:10:27 -0700 Cc: Ron Bonica , Kurt Erik Lindqvist X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 08 Oct 2008 18:10:28.0053 (UTC) FILETIME=[24B31850:01C92971] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=194; t=1223489428; x=1224353428; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Calling=20for=20agenda=20items |Sender:=20; bh=l6awPvwQnmLhYFAy8LOKqrlzh79Q3LBK3MJq+f5r9Fo=; b=Y/K0D24gmnoPbH3IlpNE9W/gQOXoE1UFIZh2rW2f72iim6cUNJatbVaAwf 6ZqTPDvBMBMXbo3MgXUMAS6m9f1Qp+ZZcyhiSLX1mAd6RV/F9nCG5q6f25H3 mqdN/ZofpQ; Authentication-Results: sj-dkim-7; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I need to put together an agenda from the coming meeting. The one item I think we are tasked with from outside is finalizing the requirements document. What other items want agenda time? From owner-v6ops@ops.ietf.org Thu Oct 9 08:25:11 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F93228C0D7 for ; Thu, 9 Oct 2008 08:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.672 X-Spam-Level: X-Spam-Status: No, score=-100.672 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, 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 e3ti8eqgS3YV for ; Thu, 9 Oct 2008 08:25:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A05873A69E7 for ; Thu, 9 Oct 2008 08:25:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnxKJ-000MXp-Sj for v6ops-data@psg.com; Thu, 09 Oct 2008 15:21:19 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnxK3-000MVG-Su for v6ops@ops.ietf.org; Thu, 09 Oct 2008 15:21:11 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 22FDF9D; Thu, 9 Oct 2008 17:21:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 213B79A for ; Thu, 9 Oct 2008 17:21:00 +0200 (CEST) Date: Thu, 9 Oct 2008 17:21:00 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 5 Oct 2008, Mikael Abrahamsson wrote: I now have ~1 week of data, and I'll post updated figures. > 0.5% of the users pulled the v4v6 gif using IPv6. This still stands. > 6% of the users were able to get the v6only gif. Still the same. > Of the v6only accesses, 91% were from 6to4 addresses, 7% were teredo and 2% > were from other ipv6 space. The "other ipv6 space" was from 58 different > /32s. This changed to 89% 6to4, 9% teredo and still 2% native. 134 different /32s. > 98% of Teredo users run Windows XP. > 88% of 6to4 users run Windows Vista. Changed to 86% of 6to4 being Vista, 10% XP, 4% OSX. > The difference in page loads between v4only and v4v6 was 0.4%, indicating > that some users might have problems loading something that has both A and > AAAA DNS. This might be that it's slower, doesn't work, or simply that some > users clicked on a link before that gif was loaded. The gifs were loaded in > the order indicated above, with the javascript function "window.onload". The page load difference shrunk to 0.06%, so I believe something was wrong before. So, I see quite a few page accesses to http://ipv6.swm.pp.se via Teredo, did anyone encounter a problem to reach it? I still don't have an explanation to lack of Vista users using Teredo. Could it be that XP by default runs Teredo when one does "ipv6 install", and Vista has 6to4 enabled by default, but not Teredo? -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Oct 9 08:35:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980C228C0EF for ; Thu, 9 Oct 2008 08:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC+lJ599H7dn for ; Thu, 9 Oct 2008 08:35:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF3CD3A68FF for ; Thu, 9 Oct 2008 08:35:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnxY9-000OP9-0T for v6ops-data@psg.com; Thu, 09 Oct 2008 15:35:37 +0000 Received: from [2001:41e0:ff00:0:216:3eff:fe00:4] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnxXz-000ONv-JW for v6ops@ops.ietf.org; Thu, 09 Oct 2008 15:35:31 +0000 Received: from [IPv6:2001:620:20:1001:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1001:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 507EB35A55F; Thu, 9 Oct 2008 17:35:26 +0200 (CEST) Message-ID: <48EE24C0.1010908@spaghetti.zurich.ibm.com> Date: Thu, 09 Oct 2008 17:35:28 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Lightning/0.9 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mikael Abrahamsson CC: v6ops@ops.ietf.org Subject: DON'T use ipv6 install, use netsh int ipv6 install (Was: some real life data) References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB71618A52A45F0B9D9459F9" X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB71618A52A45F0B9D9459F9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mikael Abrahamsson wrote: [..] > Could it be that XP by default runs Teredo when one does "ipv6 install"= , > and Vista has 6to4 enabled by default, but not Teredo? One very very very big note here: NEVER USE ipv6 install. Note that ipv6.exe is deprecated and will be totally removed in the futur= e. "ipv6 install" was indeed the method to use for the BETA versions of the IPv6 stack, but it is different from what the final "netsh interface ipv6 install" does, which is the one that one has to use. Thus, if people want to install IPv6 on XP/Vista, either: - use the Control Panel -> Network Connections -> Interface and add the protocol like anything else, or: - netsh interface ipv6 install =46rom what I understood (I am sure the Microsoft folks can enlighten us here a lot ;) there are some nasty differences between the two, and I have heard about people having broken setups with ipv6.exe while it would work after doing a reinstall and then using netsh. Greets, Jeroen --------------enigFB71618A52A45F0B9D9459F9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFI7iTAKaooUjM+fCMRAlF9AJ44wZafZAFs8oF0RySwd9i4pqoTdgCgqGUm a4ybbPlcwRCAKh9p5NgSIxk= =wo1T -----END PGP SIGNATURE----- --------------enigFB71618A52A45F0B9D9459F9-- From owner-v6ops@ops.ietf.org Thu Oct 9 10:41:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FD23A6AF6 for ; Thu, 9 Oct 2008 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 nQ+bQ4LTPdWg for ; Thu, 9 Oct 2008 10:41:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A88113A69BF for ; Thu, 9 Oct 2008 10:41:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnzTn-000F22-Va for v6ops-data@psg.com; Thu, 09 Oct 2008 17:39:15 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnzTh-000F13-F3 for v6ops@ops.ietf.org; Thu, 09 Oct 2008 17:39:13 +0000 Received: by yw-out-2324.google.com with SMTP id 9so36843ywe.71 for ; Thu, 09 Oct 2008 10:39:09 -0700 (PDT) Received: by 10.151.111.1 with SMTP id o1mr262836ybm.43.1223573948014; Thu, 09 Oct 2008 10:39:08 -0700 (PDT) Received: by 10.150.157.19 with HTTP; Thu, 9 Oct 2008 10:39:07 -0700 (PDT) Message-ID: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> Date: Thu, 9 Oct 2008 10:39:07 -0700 From: "Erik Kline" To: "Mikael Abrahamsson" Subject: Re: some real life data Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > So, I see quite a few page accesses to http://ipv6.swm.pp.se via Teredo, did > anyone encounter a problem to reach it? I still don't have an explanation to > lack of Vista users using Teredo. One thing I've been wondering about is whether or not the client actually tried and was, in fact, in the process of setting up a Teredo connection but it just took *so* long that the state of the page changed (the user navigated away, and thus the javascript was stopped). I remember hearing that some Teredo setup times can be in the multiple 1000s of milliseconds depending on how close the nearest server is. Maybe this is not a factor in your region or for your experiment. From owner-v6ops@ops.ietf.org Thu Oct 9 13:30:00 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B483A68CD for ; Thu, 9 Oct 2008 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.303 X-Spam-Level: X-Spam-Status: No, score=-101.303 tagged_above=-999 required=5 tests=[AWL=1.296, 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 s6AFmjUYvm9J for ; Thu, 9 Oct 2008 13:29:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90F493A688C for ; Thu, 9 Oct 2008 13:29:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko25A-0009Ni-18 for v6ops-data@psg.com; Thu, 09 Oct 2008 20:26:00 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko252-0009MU-F2 for v6ops@ops.ietf.org; Thu, 09 Oct 2008 20:25:56 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id A5C329C; Thu, 9 Oct 2008 22:25:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A56039A for ; Thu, 9 Oct 2008 22:25:49 +0200 (CEST) Date: Thu, 9 Oct 2008 22:25:49 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> Message-ID: References: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 9 Oct 2008, Erik Kline wrote: > One thing I've been wondering about is whether or not the client > actually tried and was, in fact, in the process of setting up a Teredo > connection but it just took *so* long that the state of the page > changed (the user navigated away, and thus the javascript was > stopped). I remember hearing that some Teredo setup times can be in > the multiple 1000s of milliseconds depending on how close the nearest > server is. Maybe this is not a factor in your region or for your > experiment. I've been thinking about this as well, but it doesn't really explain why 98% of my teredo hits are from Windows XP, unless there is a fundamental different in the implementation between these platforms. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Thu Oct 9 14:26:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272F93A6AB5 for ; Thu, 9 Oct 2008 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.264 X-Spam-Level: X-Spam-Status: No, score=-100.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeOsj6nqRpYj for ; Thu, 9 Oct 2008 14:26:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E85D3A6A7E for ; Thu, 9 Oct 2008 14:26:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko316-000G8i-CS for v6ops-data@psg.com; Thu, 09 Oct 2008 21:25:52 +0000 Received: from [2001:470:1f06:248::2] (helo=dns.suspicious.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko2zm-000G0H-Sc for v6ops@ops.ietf.org; Thu, 09 Oct 2008 21:25:01 +0000 Received: from [25.243.214.56] (m665e36d0.tmodns.net [208.54.94.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dns.suspicious.org (Postfix) with ESMTP id 2D2FA1F4D6; Thu, 9 Oct 2008 17:24:18 -0400 (EDT) Cc: v6ops@ops.ietf.org Message-Id: <4C252C0B-CDBA-418E-A94D-5AE995A765BE@suspicious.org> From: Truman Boyes To: Mikael Abrahamsson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: some real life data Date: Thu, 9 Oct 2008 17:23:58 -0400 References: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 9/10/2008, at 4:25 PM, Mikael Abrahamsson wrote: > > I've been thinking about this as well, but it doesn't really explain > why 98% of my teredo hits are from Windows XP, unless there is a > fundamental different in the implementation between these platforms. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > What are the other 2 percent of the teredo hits? Truman From owner-v6ops@ops.ietf.org Thu Oct 9 21:17:42 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908A33A6843 for ; Thu, 9 Oct 2008 21:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.563 X-Spam-Level: X-Spam-Status: No, score=-101.563 tagged_above=-999 required=5 tests=[AWL=1.036, 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 B8+nJyOJc9FM for ; Thu, 9 Oct 2008 21:17:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6B0E3A6811 for ; Thu, 9 Oct 2008 21:17:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko9No-0001pm-SI for v6ops-data@psg.com; Fri, 10 Oct 2008 04:13:44 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko9Nf-0001nl-Uu for v6ops@ops.ietf.org; Fri, 10 Oct 2008 04:13:38 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 07B7F9C; Fri, 10 Oct 2008 06:13:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 070B99A for ; Fri, 10 Oct 2008 06:13:32 +0200 (CEST) Date: Fri, 10 Oct 2008 06:13:32 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: <4C252C0B-CDBA-418E-A94D-5AE995A765BE@suspicious.org> Message-ID: References: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> <4C252C0B-CDBA-418E-A94D-5AE995A765BE@suspicious.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Thu, 9 Oct 2008, Truman Boyes wrote: > What are the other 2 percent of the teredo hits? 0.7% is Vista, 0.05% is OSX, 0.9% is "everything else". -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Oct 10 04:08:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6DB28C17D for ; Fri, 10 Oct 2008 04:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, 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 SrdwoTg1u1gh for ; Fri, 10 Oct 2008 04:08:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 603CB3A67E6 for ; Fri, 10 Oct 2008 04:08:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoFns-000FFG-HF for v6ops-data@psg.com; Fri, 10 Oct 2008 11:05:04 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoFnn-000FEF-2M for v6ops@ops.ietf.org; Fri, 10 Oct 2008 11:05:01 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3FDF69C; Fri, 10 Oct 2008 13:04:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3DFB99A for ; Fri, 10 Oct 2008 13:04:53 +0200 (CEST) Date: Fri, 10 Oct 2008 13:04:53 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, 5 Oct 2008, Mikael Abrahamsson wrote: > 6% of the users were able to get the v6only gif. Here, the OS distribution was as follows: 79% Vista 18% XP 5% OS X 0.3% Ubuntu 0.2% unspecified Linux 0.1% Windows 2003 0.02% Windows CE The discrepancy in these numbers (> 100% total) are due to version strings such as this: "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)" This line will be counted both as NT 5.1 (XP) and NT 6.0 (Vista) in my figures above. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Fri Oct 10 04:53:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFD73A6AF6 for ; Fri, 10 Oct 2008 04:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.34 X-Spam-Level: X-Spam-Status: No, score=-100.34 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 Ff75h5Wss5dv for ; Fri, 10 Oct 2008 04:53:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DB403A68D1 for ; Fri, 10 Oct 2008 04:53:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoGY0-000JXz-U2 for v6ops-data@psg.com; Fri, 10 Oct 2008 11:52:44 +0000 Received: from [207.97.245.217] (helo=smtp217.iad.emailsrvr.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoGXs-000JVu-Hm for v6ops@ops.ietf.org; Fri, 10 Oct 2008 11:52:41 +0000 Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8BA331B429F; Fri, 10 Oct 2008 07:52:34 -0400 (EDT) Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTP id 26F481B41BB; Fri, 10 Oct 2008 07:52:34 -0400 (EDT) Message-ID: <48EF4200.5010304@isoc.org> Date: Fri, 10 Oct 2008 12:52:32 +0100 From: Matthew Ford User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Mikael Abrahamsson CC: v6ops@ops.ietf.org Subject: Re: some real life data References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 9/10/08 16:21, Mikael Abrahamsson wrote: > So, I see quite a few page accesses to http://ipv6.swm.pp.se via Teredo, > did anyone encounter a problem to reach it? I still don't have an > explanation to lack of Vista users using Teredo. I can see that page via Teredo from both XP and OSX systems. What are the chances of a correlation between non-NATed connectivity and Vista use? Mat From owner-v6ops@ops.ietf.org Fri Oct 10 05:44:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAB93A6ACB for ; Fri, 10 Oct 2008 05:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNQxQXX3aiTD for ; Fri, 10 Oct 2008 05:44:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2E6C3A6864 for ; Fri, 10 Oct 2008 05:44:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoHJp-000Oon-L7 for v6ops-data@psg.com; Fri, 10 Oct 2008 12:42:09 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoHJf-000OnH-Sd for v6ops@ops.ietf.org; Fri, 10 Oct 2008 12:42:02 +0000 X-IronPort-AV: E=Sophos;i="4.33,389,1220227200"; d="scan'208";a="22259269" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2008 12:41:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9ACfwGk025786; Fri, 10 Oct 2008 14:41:58 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9ACfwOt002359; Fri, 10 Oct 2008 12:41:58 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 14:41: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 Subject: RE: some real life data Date: Fri, 10 Oct 2008 14:38:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some real life data Thread-Index: AckqyOt8EkeNeePXQ+yco1b4hA+01QACz1OA References: From: "Eric Vyncke (evyncke)" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 10 Oct 2008 12:41:58.0024 (UTC) FILETIME=[956ED880:01C92AD5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1851; t=1223642518; x=1224506518; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:=20=22Eric=20Vyncke=20(evyncke)=22=20 |Subject:=20RE=3A=20some=20real=20life=20data |Sender:=20; bh=QU3XSXrI32g+YlJinG9tnnwUVVS0gOE7T4xqJFzJM5Q=; b=jPhPKT7CRAYsp6Lo6NKoWcZi/gVRV+Wk4e7KJqxvVysEa6QSh4fYUp8aUI pZCDWF0+07cex/xUrdR4C/POWD67pD29qlg+ga4VjhUMmw/1GkECLGslXL4K ZhJ/azsz5O; Authentication-Results: ams-dkim-2; header.From=evyncke@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Quite similar to my own web measurements = (http://www.vyncke.org/countv6/stats.php)=20 IPv6-able (so both when IPv6 is preferred and when it is not) OS % of IPv6-able Windows Vista 57.2 Windows XP 36.4 Linux (unknown) 2.6 Linux (Ubuntu) 1.4 Mac OS X 1.2 Unknown 0.5 Windows CE 0.4 Linux (Debian) 0.2 Windows Server 2 0.2 For Windows Vista: 15% pour Teredo, 9% 6to4 (% relative to the whole = Vista population) For Windows XP: 2% native, 2% Freebox, 0.5% Teredo This means that more than 1/4 of Windows Vista has IPv6 connectivity = which is both a good news and a bad news (meaning that Teredo does not = work immediately -- perhaps because they are part of a AD domain or = because the firewall has been disabled). -=E9ric > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mikael Abrahamsson > Sent: vendredi 10 octobre 2008 13:05 > To: v6ops@ops.ietf.org > Subject: Re: some real life data >=20 > On Sun, 5 Oct 2008, Mikael Abrahamsson wrote: >=20 > > 6% of the users were able to get the v6only gif. >=20 > Here, the OS distribution was as follows: >=20 > 79% Vista > 18% XP > 5% OS X > 0.3% Ubuntu > 0.2% unspecified Linux > 0.1% Windows 2003 > 0.02% Windows CE >=20 > The discrepancy in these numbers (> 100% total) are due to=20 > version strings such as this: >=20 > "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;=20 > Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ;=20 > SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR=20 > 3.0.04506; .NET CLR 1.1.4322)" >=20 > This line will be counted both as NT 5.1 (XP) and NT 6.0=20 > (Vista) in my figures above. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 >=20 From owner-v6ops@ops.ietf.org Fri Oct 10 14:45:21 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9025A3A69DA for ; Fri, 10 Oct 2008 14:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.163 X-Spam-Level: X-Spam-Status: No, score=-105.163 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 tCpVK7t3QCwm for ; Fri, 10 Oct 2008 14:45:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D6653A67A7 for ; Fri, 10 Oct 2008 14:45:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoPih-000DIx-OQ for v6ops-data@psg.com; Fri, 10 Oct 2008 21:40:23 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoPib-000DI5-9Z for v6ops@ops.ietf.org; Fri, 10 Oct 2008 21:40:20 +0000 X-IronPort-AV: E=Sophos;i="4.33,391,1220227200"; d="scan'208";a="89556026" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2008 21:40:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9ALeFF7001864; Fri, 10 Oct 2008 14:40:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9ALeE2w018666; Fri, 10 Oct 2008 21:40:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 14:40:04 -0700 Received: from stealth-10-32-244-219.cisco.com ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 14:40:04 -0700 Cc: Ron Bonica , Kurt Erik Lindqvist Message-Id: <4987C2BD-04E8-43D1-810A-E2F6A60C5246@cisco.com> From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Fwd: V6OPS - Requested sessions have been scheduled for IETF 73 Date: Fri, 10 Oct 2008 14:40:03 -0700 References: <20081010204147.76D503A68A0@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 10 Oct 2008 21:40:04.0240 (UTC) FILETIME=[C1847100:01C92B20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2238; t=1223674815; x=1224538815; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20V6OPS=20-=20Requested=20sessions=20hav e=20been=20scheduled=20for=20IETF=2073=20 |Sender:=20; bh=vv+HYbAIAS6/zLpbXEGCqyW1zT9nHSB2x59AAnbRZu0=; b=O0GGgK7e+J7wOXYgDJqfLnNENbZu7yfNEZSWsV9+tf/2gcQzkDsKnDUytn 61alyvyVJoUs0moxJW1/DwGypfYobxeBHODf9fjJ8yTz34WrFKnzVr418pAg nl5cgaYlRI; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: FYI, we have been allotted these slots. At the moment, I have one request for air time (CPE Routers), and I am expecting Marcello to complete the requirements draft (which I haven't heard from him about). Which leaves me in a bit of a quandary. The Teredo authors tell me they are updating their drafts preparatory to a WGLC, but they're not done yet. The RA Guard authors tell me they are updating their drafts preparatory to a WGLC, but they're not done yet. I'm not sure what to do with - draft-manral-v6ops-tiny-fragments-issues - draft-kaippallimalil-v6ops-ipv6-bbnet - draft-ietf-v6ops-cpe-simple-security Is there an echo out there? What do folks want to talk about? BTW, beyond the requirements, most of the transition work will now be in some combination of int-area, behave, and softwires. Begin forwarded message: > From: IETF Secretariat > Date: October 10, 2008 1:41:47 PM PDT > To: fred.baker@cisco.com > Cc: kurtis@kurtis.pp.se, dromasca@avaya.com, rbonica@juniper.net, session-request@ietf.org > Subject: V6OPS - Requested sessions have been scheduled for IETF 73 > > Dear Fred Baker, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > V6OPS Session 1 (2.5 hours) > Monday, Morning Session I 0900-1130 > Room Name: Meeting Room > ---------------------------------------------- > V6OPS Session 2 (2 hours) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Meeting Room > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: v6ops > Area Name: Operations and Management Area > Session Requester: Fred Baker > > Number of Sessions: 2 > Length of Session(s): 2.5 hours > 2 hours > > Number of Attendees: 100 > Conflicts to Avoid: > First Priority: > shim6,6man > ,intarea > ,opsarea > ,opsawg,pcn,rtgarea,rtgwg,savi,tcpm,tsvarea,tsvwg,rrg,behave,ipr > > Special Requests: > > --------------------------------------------------------- > > From owner-v6ops@ops.ietf.org Sun Oct 12 20:42:17 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F28A3A6B70 for ; Sun, 12 Oct 2008 20:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9grgJojyAJuf for ; Sun, 12 Oct 2008 20:42:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 057493A6B66 for ; Sun, 12 Oct 2008 20:42:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpEF3-0001Ev-UF for v6ops-data@psg.com; Mon, 13 Oct 2008 03:37:09 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpEEz-0001Dm-10 for v6ops@ops.ietf.org; Mon, 13 Oct 2008 03:37:07 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9D3bNtA022006; Sun, 12 Oct 2008 22:37:24 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Oct 2008 22:36:29 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Oct 2008 22:36:28 -0500 Message-ID: <48F2C29B.8090900@ericsson.com> Date: Sun, 12 Oct 2008 23:38:03 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Kurt Zeilenga CC: Pasi Eronen , Tim Polk , secdir@mit.edu, Jim_Hoagland@symantec.com, dthaler@microsoft.com, v6ops@ops.ietf.org Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns-00 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> In-Reply-To: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2008 03:36:28.0869 (UTC) FILETIME=[E0935F50:01C92CE4] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Kurt, Thank you very much for your detailed review and sorry for the long delay in our response. We have modified the draft to address some of your concerns. We also had a few questions for you. Please find our responses inline. Kurt Zeilenga wrote: > I have reviewed this document as part of the security directorate's > ongoing review efforts. These comments were written primarily for the > benefit of the security area directors. Document editors and WG chairs > should treat these comments just like they would treat comments from any > other IETF contributor. > > This document discusses "Security Concerns with [IP] Tunnels". > > I suggest the Security AD pay particular attention to this I-D. Given > it purports to discuss security concerns applicable to a wide range of > [IP] tunneling solutions, it may be appropriate for this I-D to be > assigned to additional secdir reviewers. > > Comments: > > The title and abstract apply this document discusses a wide range of > tunnel technologies, but the text seems focused on IP Tunnels (though I > guess some of the concerns might apply to various non-IP network > tunnels). It might be appropriate to change the title to "Security > Concerns with IP Tunneling", and to clarify the abstract. We have changed the title to "Security Concerns With IP Tunneling" as you suggested. > > My comments assume "IP tunneling" was meant. > > It's not clear what track this I-D is targeted for. I will assume > Informational. Yes. This is meant to be informational > The abstract seems a bit short. > The abstract starts off with: >> A number of security concerns with tunnels are documented. > > where? In this document or elsewhere? If elsewhere, I would hope the > body will detail and provide references to where these concerns are > documented. In this document. We have fixed the abstract to say this. The new abstract is attached below > > The abstract ends with: >> The >> primary intent of this document is to raise the awareness regarding >> the security issues with tunnels as deployed today. > > It's not clear who the intended audience is of this document. > Implementors? Network Operators? Deployers? Etc. But it does say "as > deployed today", which I take as meaning that this document focuses on > security issues in existing IP tunneling solutions. The intended audience is network admins and future protocol developers. We have changed the abstract to read: " A number of security concerns with IP tunnels are documented in this document. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness regarding the security issues with IP tunnels as deployed today. " > > The Introduction says: >> The primary intent of this document is to provide information that can >> be used in any new or updated tunnel protocol specification. > > I don't read either of these 'primary intent' statements as being > equivalent to the other. > 2.1.2 says, >> Evasion by tunneling is often a problem for network-based security >> devices such as network firewalls, intrusion detection and prevention >> systems, and router controls. > > which leads to 2.1.3 recommendation: >> Security administrators who do not consider tunneling an acceptable >> risk should disable tunnel functionality unless their network-based >> security controls adequately recognize the tunneled traffic. > > If the network-based security controls don't have adequate ability to > recognize tunneled traffic, how does the security administrator go about > disabling tunneled traffic? Is the administrator to turn off everything > that might carry a tunnel? If so, wouldn't that be just about everything? One way to go about doing this is to disable the specific tunneling method on the end-hosts. We have added the following text " Security administrators who do not consider tunneling an acceptable risk should disable tunnel functionality either on the end-nodes (hosts) or on the network nodes." to mention this possibility. > In 2.1.3 says: >> To minimize security exposure due to tunnels, we recommend that a >> tunnel be an interface of last resort, independent of IP version. >> Specifically, we suggest that when both native and tunneled access to >> a remote host is available, that the native-based access be used in >> preference to tunneled access. This should also promote greater >> efficiency and reliability. > > This recommendation appears to ignore cases where the tunnel offers data > protective services not available natively. We have changed " Specifically, we suggest that when both native and tunneled access to a remote host is available, that the native access be used in preference to tunneled access." to " Specifically, we suggest that when both native and tunneled access to a remote host is available, that the native access be used in preference to tunneled access except when the tunnel endpoint is known to not bypass security (e.g., an IPsec tunnel to a gateway provided by the security administrator of the network)." in order to allow tunnels offering protective service to still be preferred. > >> Given concerns about tunnel security or a network's lack of >> preparedness for tunnels, a network administrator may wish to simply >> block all use of tunnels. He or she may wish to do so using network >> controls; this could be either due to not having confidence in the >> ability to disable it on all hosts attached to the network or due to >> wanting an extra layer of prevention. > > It may be appropriate to note here that by "simply blocking all use of > tunnels", the network administrator hinders the ability of users from > taking steps to gain security benefit provided by use of tunnels. We have added the phrase "that subvert security" to the end of this sentence so that it reads " Given concerns about tunnel security or a network's lack of preparedness for tunnels, a network administrator may wish to simply block all use of tunnels that subvert security." > >> One simple method to do that is easy to employ for many tunnel >> protocols is to block outbound packets to the UDP or TCP port used >> (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). > > The description of this method is not precise. Is the method to block > dest ports, with these source ports, or either, or both? The method is to block destination ports. We have changed this sentence to read (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, etc.) > >> It is not known if blocking all traffic to a given outbound port >> will interfere with >> non-tunneled traffic. > > Actually, I think it is generally known that blocking all traffic to a > given outbound port may very well interfere with non-tunnel traffic. > The document statement seems to discount operational experience of > simply blocking all traffic to a given outbound port may be harmful. We have changed this text to read " In some cases, however, blocking all traffic to a given outbound port (e.g., port 80) may interfere with non-tunneled traffic so this should be used with caution." > > In 3.1.3, >> Tunneling over UDP or TCP (including HTTP) to reach the Internet is >> not recommended as a solution for managed networks. > First, I'm going to read the sentence as if the word 'managed' was not > used as I think all networks on the Internet are 'managed' to some > degree. If the authors had a particular definition of the term 'managed > network' in mind, they should define it. > > So reading the sentence without the term 'managed', this is basically a > general applicability statement that use of tunneling over UDP or TCP is > not recommend for use to 'reach the Internet'. I don't see this > recommendation as being appropriate given the issue. We have changed this text to read " Tunneling over UDP or TCP (including HTTP) to reach the Internet is not recommended as a solution for networks that wish to enforce security polcies on the user traffic. (Windows, for example, disables Teredo by default if it detects that it is within an enterprise network that contains a Windows domain controller.)" > > In 3.2.3, >> As illustrated above, it should be clear that inspecting the contents >> of tunneled data packets is highly complex and often impractical. > > I would argue that inspecting the contents of non-tunneled data packets > is also highly complex and often impractical. We agree with you and we are not claiming otherwise. >> For this reason, if a network wishes to monitor IP traffic, tunneling >> is not recommended. > > I think it depends on what kind of IP traffic monitoring one wants to > do. Also, if the user doesn't want there data monitored, recommending > use of tunneling with data confidential protections seems quite > appropriate. > The term "NAT" appears to be used to refer to a device (e.g., "a NAT") > not a process (of address translation). This seems improper given that > NAT expands to Network Address Translation. We have changed the document to say "NAT device" when we talk about the device and NAT when we talk about the process, as you stated. > Many acronyms are not spelled out. > > Given this document provides only only a high-level discussion, why are > there so many normative references? Why does a reader need to read, for > instance, RFC 1918, to understand this document? Seems RFC 1918 only > provides information in support of an example. Seems there is > significant over use of normative references here. I think most of the > references listed as normative are more appropriately listed as > informative. Agreed. All the references have been moved to informative. > > In the paragraphs: >> Protocols that embed an IPv4 address in a tunneled IPv6 address >> directly between peers often do filtering based on checking the >> correpondence. >> >> Protocols that accept tunneled packets directly from a server or >> relay do filtering the same way as it would be done on a native >> link with traffic from a router. > > > the text implies the protocols do filtering. Is this correct? It seems > more likely that the devices implementing the protocol do the filtering. You are right. We have fixed the text to read " Implementations of protocols that embed an IPv4 address in a tunneled IPv6 address directly between peers often do filtering based on checking the correspondence. Implementations of protocols that accept tunneled packets directly from a server or relay do filtering the same way as it would be done on a native link with traffic from a router." > >> To do host-based filtering with protocols that allow both other >> hosts and a router over a common tunnel (e.g., 6to4 [RFC3056], >> Teredo, ISATAP [RFC4214], and 6over4 [RFC2529]), hosts would need >> to be able to know the outer IP address of all routers from which >> it could receive traffic. > I am having a hard time parsing this sentence. We have split this sentence into two parts and reworded it. The new text reads " Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC4214], and 6over4 [RFC2529] allow both other hosts and a router over a common tunnel To perform host-based filtering with such protocols a host would need to know the outer IP address of each router from which it could receive traffic, so that packets from hosts beyond the router will be accepted even though the source address would not embed the router's IP address. Router addresses might be learned via Secure Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC4214] section 8.3.2)." Thanks Suresh From owner-v6ops@ops.ietf.org Mon Oct 13 00:45:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C603A68F7 for ; Mon, 13 Oct 2008 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.405 X-Spam-Level: X-Spam-Status: No, score=-5.405 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br6uI5bf9S2O for ; Mon, 13 Oct 2008 00:45:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6138D3A681B for ; Mon, 13 Oct 2008 00:45:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpI4k-000LP7-5c for v6ops-data@psg.com; Mon, 13 Oct 2008 07:42:46 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpI4e-000LOi-Rq for v6ops@ops.ietf.org; Mon, 13 Oct 2008 07:42:42 +0000 Received: from [192.168.0.51] (ip-118-90-104-146.xdsl.xnet.co.nz [118.90.104.146]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id F2A342793F; Mon, 13 Oct 2008 20:42:39 +1300 (NZDT) Cc: "Mikael Abrahamsson" , Message-Id: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> From: Nathan Ward To: Eric Vyncke (evyncke) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: some real life data Date: Mon, 13 Oct 2008 20:42:39 +1300 References: X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mikael, Eric, Are you running Teredo relays close to your content you are using to test? Mikael, are you able to share (privately if need be) the actual test? I'd like to look at how it works to try and see if I can see what's causing Vista/Teredo to not pick it up as much as I expect. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Oct 13 00:45:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5623A68F7 for ; Mon, 13 Oct 2008 00:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4MiCHAtsAzU for ; Mon, 13 Oct 2008 00:45:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7CA13A681B for ; Mon, 13 Oct 2008 00:45:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpI3n-000LJO-0r for v6ops-data@psg.com; Mon, 13 Oct 2008 07:41:47 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpI3g-000LIk-HY for v6ops@ops.ietf.org; Mon, 13 Oct 2008 07:41:43 +0000 Received: from [192.168.0.51] (ip-118-90-104-146.xdsl.xnet.co.nz [118.90.104.146]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id D04052793F; Mon, 13 Oct 2008 20:41:38 +1300 (NZDT) Cc: Kurt Zeilenga , Pasi Eronen , Tim Polk , secdir@mit.edu, Jim_Hoagland@symantec.com, dthaler@microsoft.com, v6ops@ops.ietf.org Message-Id: From: Nathan Ward To: Suresh Krishnan In-Reply-To: <48F2C29B.8090900@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns-00 Date: Mon, 13 Oct 2008 20:41:37 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 13/10/2008, at 4:38 PM, Suresh Krishnan wrote: >>> One simple method to do that is easy to employ for many tunnel >>> protocols is to block outbound packets to the UDP or TCP port used >>> (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). >> The description of this method is not precise. Is the method to >> block dest ports, with these source ports, or either, or both? > > The method is to block destination ports. We have changed this > sentence > to read > (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for > L2TP, etc.) This makes me squirm a bit. It seems silly to promote blocking discrete ports, when a user could simply run their own Teredo server on a different port and tunnel out with that, or run any other proxy or tunnel server of some kind on any port they wanted. We've all run PPP over SSH before, it's not hard to do this stuff, there are tools to do it automatically. If an organisation is concerned about people tunnelling through their firewalls, they must use default-deny if they want to have any effect. >>> In 3.1.3, >>> Tunneling over UDP or TCP (including HTTP) to reach the Internet >>> is >>> not recommended as a solution for managed networks. >> First, I'm going to read the sentence as if the word 'managed' was >> not used as I think all networks on the Internet are 'managed' to >> some degree. If the authors had a particular definition of the >> term 'managed network' in mind, they should define it. >> So reading the sentence without the term 'managed', this is >> basically a general applicability statement that use of tunneling >> over UDP or TCP is not recommend for use to 'reach the Internet'. >> I don't see this recommendation as being appropriate given the issue. > > We have changed this text to read > > " Tunneling over UDP or TCP (including HTTP) to reach the Internet is > not recommended as a solution for networks that wish to enforce > security polcies on the user traffic. (Windows, for example, > disables Teredo by default if it detects that it is within an > enterprise network that contains a Windows domain controller.)" Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? I don't imagine that UDP makes it any more difficult to inspect than an IP protocol. I think this statement should be changed to "Tunnelling through a security device (ie. firewall) is not recommended for.. " etc. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Oct 13 00:50:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD323A68E3 for ; Mon, 13 Oct 2008 00:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeWvSAlotgyI for ; Mon, 13 Oct 2008 00:50:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1BA13A681B for ; Mon, 13 Oct 2008 00:50:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpIBY-000M8y-B7 for v6ops-data@psg.com; Mon, 13 Oct 2008 07:49:48 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpIBS-000M81-F6 for v6ops@ops.ietf.org; Mon, 13 Oct 2008 07:49:45 +0000 Received: from [192.168.0.51] (ip-118-90-104-146.xdsl.xnet.co.nz [118.90.104.146]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 8ACFA2793F; Mon, 13 Oct 2008 20:49:41 +1300 (NZDT) Cc: "Mikael Abrahamsson" , v6ops@ops.ietf.org Message-Id: From: Nathan Ward To: Erik Kline In-Reply-To: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: some real life data Date: Mon, 13 Oct 2008 20:49:40 +1300 References: <67099930810091039h4778bd3fi4abfccb181339ef4@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 10/10/2008, at 6:39 AM, Erik Kline wrote: >> So, I see quite a few page accesses to http://ipv6.swm.pp.se via >> Teredo, did >> anyone encounter a problem to reach it? I still don't have an >> explanation to >> lack of Vista users using Teredo. > > One thing I've been wondering about is whether or not the client > actually tried and was, in fact, in the process of setting up a Teredo > connection but it just took *so* long that the state of the page > changed (the user navigated away, and thus the javascript was > stopped). I remember hearing that some Teredo setup times can be in > the multiple 1000s of milliseconds depending on how close the nearest > server is. Maybe this is not a factor in your region or for your > experiment. I test for this by periodically (maybe every 5 seconds I think?) providing feedback with a javascript timer, until all the images on the different hostnames are loaded. -- Nathan Ward From owner-v6ops@ops.ietf.org Mon Oct 13 05:39:46 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130AA3A6841 for ; Mon, 13 Oct 2008 05:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.816 X-Spam-Level: X-Spam-Status: No, score=-101.816 tagged_above=-999 required=5 tests=[AWL=0.783, 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 VqBpwJIku0v5 for ; Mon, 13 Oct 2008 05:39:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C737D3A6359 for ; Mon, 13 Oct 2008 05:39:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpMf8-000O90-J2 for v6ops-data@psg.com; Mon, 13 Oct 2008 12:36:38 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpMes-000O75-6S for v6ops@ops.ietf.org; Mon, 13 Oct 2008 12:36:34 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C2719B; Mon, 13 Oct 2008 14:36:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8BBF79A for ; Mon, 13 Oct 2008 14:36:20 +0200 (CEST) Date: Mon, 13 Oct 2008 14:36:20 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ops.ietf.org Subject: Re: some real life data In-Reply-To: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> Message-ID: References: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 13 Oct 2008, Nathan Ward wrote: > Mikael, Eric, > > Are you running Teredo relays close to your content you are using to test? Our teredo relay is sitting within 1ms from the "content" (ie, the machine serving up the gif:s). > Mikael, are you able to share (privately if need be) the actual test? > I'd like to look at how it works to try and see if I can see what's > causing Vista/Teredo to not pick it up as much as I expect. The code inserted looks like this: blank 1
blank 1
blank 1
-- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Mon Oct 13 10:55:06 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF27D3A6AFB for ; Mon, 13 Oct 2008 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 VecyFpCb1oTH for ; Mon, 13 Oct 2008 10:55:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C44A3A6820 for ; Mon, 13 Oct 2008 10:55:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpRaJ-0008Nl-PE for v6ops-data@psg.com; Mon, 13 Oct 2008 17:51:59 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpRa6-0008M8-PU for v6ops@ops.ietf.org; Mon, 13 Oct 2008 17:51:54 +0000 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:51:46 -0700 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.1.291.1; Mon, 13 Oct 2008 10:51:45 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Mon, 13 Oct 2008 10:51:45 -0700 From: "Deepak Bansal (NETWORKING)" To: Mikael Abrahamsson , "v6ops@ops.ietf.org" Date: Mon, 13 Oct 2008 10:51:45 -0700 Subject: RE: some real life data Thread-Topic: some real life data Thread-Index: AcktMXbJ3ndZohS+RP6gIWfx30o05wAI6qag Message-ID: <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Can you pls replace one of the URLs below with actual IPv6 address and that= should drive Teredo usage on Vista up. Windows Vista does not issue AAAA q= ueries if the only IPv6 address it has is a Teredo address. Windows Vista w= ill issue AAAA query if it has a 6to4 or native IPv6 address though. This w= ill explain the relative usage of 6to4 and Teredo that you are seeing. Than= ks. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf = Of Mikael Abrahamsson Sent: Monday, October 13, 2008 5:36 AM To: v6ops@ops.ietf.org Subject: Re: some real life data On Mon, 13 Oct 2008, Nathan Ward wrote: > Mikael, Eric, > > Are you running Teredo relays close to your content you are using to test= ? Our teredo relay is sitting within 1ms from the "content" (ie, the machine serving up the gif:s). > Mikael, are you able to share (privately if need be) the actual test? > I'd like to look at how it works to try and see if I can see what's > causing Vista/Teredo to not pick it up as much as I expect. The code inserted looks like this: 3D"blank
3D"blank
3D"blank
-- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Mon Oct 13 23:52:53 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202413A6B98 for ; Mon, 13 Oct 2008 23:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+lItOFxejeD for ; Mon, 13 Oct 2008 23:52:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 001453A676A for ; Mon, 13 Oct 2008 23:52:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpdi0-000K6t-DC for v6ops-data@psg.com; Tue, 14 Oct 2008 06:48:44 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpdhr-000K4z-Vt for v6ops@ops.ietf.org; Tue, 14 Oct 2008 06:48:40 +0000 Received: from [192.168.0.51] (ip-118-90-104-146.xdsl.xnet.co.nz [118.90.104.146]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 3B03527341; Tue, 14 Oct 2008 19:48:32 +1300 (NZDT) Cc: Mikael Abrahamsson , "v6ops@ops.ietf.org" Message-Id: <7BEE708F-87DF-4CF5-9DA6-F3CE671B998C@daork.net> From: Nathan Ward To: Deepak Bansal (NETWORKING) In-Reply-To: <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: some real life data Date: Tue, 14 Oct 2008 19:07:14 +1300 References: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 14/10/2008, at 6:51 AM, Deepak Bansal (NETWORKING) wrote: > Can you pls replace one of the URLs below with actual IPv6 address > and that should drive Teredo usage on Vista up. Windows Vista does > not issue AAAA queries if the only IPv6 address it has is a Teredo > address. Windows Vista will issue AAAA query if it has a 6to4 or > native IPv6 address though. This will explain the relative usage of > 6to4 and Teredo that you are seeing. Thanks. That would most definitely explain it. Is this documented anywhere? I haven't seen any info RE this previously.. I guess the problem now is people with browsers that can't do IPv6 literal addresses, do they throw an error if there are images in a page with those in the URL? I guess it's possible to test what browser it is in javascript though. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Mikael Abrahamsson > Sent: Monday, October 13, 2008 5:36 AM > To: v6ops@ops.ietf.org > Subject: Re: some real life data > > On Mon, 13 Oct 2008, Nathan Ward wrote: > >> Mikael, Eric, >> >> Are you running Teredo relays close to your content you are using >> to test? > > Our teredo relay is sitting within 1ms from the "content" (ie, the > machine > serving up the gif:s). > >> Mikael, are you able to share (privately if need be) the actual test? >> I'd like to look at how it works to try and see if I can see what's >> causing Vista/Teredo to not pick it up as much as I expect. > > The code inserted looks like this: > > > blank 1
> blank 1
> blank 1
> > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > !DSPAM:22,48f39513202918524414327! > > -- Nathan Ward -- Nathan Ward From owner-v6ops@ops.ietf.org Tue Oct 14 00:18:12 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8C03A6BF3 for ; Tue, 14 Oct 2008 00:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=0.685, 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 mfGGEGMJi2Ag for ; Tue, 14 Oct 2008 00:18:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFCB93A6BF0 for ; Tue, 14 Oct 2008 00:18:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpeA1-000NUb-30 for v6ops-data@psg.com; Tue, 14 Oct 2008 07:17:41 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpe9n-000NQg-2F for v6ops@ops.ietf.org; Tue, 14 Oct 2008 07:17:35 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8AA6F9B; Tue, 14 Oct 2008 09:17:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8A0189A for ; Tue, 14 Oct 2008 09:17:25 +0200 (CEST) Date: Tue, 14 Oct 2008 09:17:25 +0200 (CEST) From: Mikael Abrahamsson To: "v6ops@ops.ietf.org" Subject: RE: some real life data In-Reply-To: <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: References: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 13 Oct 2008, Deepak Bansal (NETWORKING) wrote: > Can you pls replace one of the URLs below with actual IPv6 address and > that should drive Teredo usage on Vista up. Windows Vista does not issue What do you mean by "actual IPv6 address"? I should put in the URL as http://[2a00:801::f]... etc? That breaks my vhost config on the webserver I'm using for this experiment. > AAAA queries if the only IPv6 address it has is a Teredo address. > Windows Vista will issue AAAA query if it has a 6to4 or native IPv6 > address though. This will explain the relative usage of 6to4 and Teredo > that you are seeing. Thanks. What is the rationale behind this, and why was it changed from the XP behaviour which I find quite reasonable? -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Wed Oct 15 09:37:05 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC933A691D for ; Wed, 15 Oct 2008 09:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIcamOJzxDgQ for ; Wed, 15 Oct 2008 09:37:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F225D3A69A0 for ; Wed, 15 Oct 2008 09:37:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kq9Ij-000Fcx-NL for v6ops-data@psg.com; Wed, 15 Oct 2008 16:32:45 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kq9IZ-000FaI-3H for v6ops@ops.ietf.org; Wed, 15 Oct 2008 16:32:38 +0000 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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9FGWFes028030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 09:32:20 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9FGWEhm003274; Wed, 15 Oct 2008 09:32:14 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9FGW8kR003069; Wed, 15 Oct 2008 09:32:14 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 09:32:10 -0700 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 Subject: RANGER Date: Wed, 15 Oct 2008 09:32:09 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10517EDDF@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RANGER Thread-Index: AckuLWrQweJ2zqZ5Tj6e+/Xuj9HQuAAqyL2A From: "Templin, Fred L" To: "Internet Area" , Cc: "IPv6 Operations" , , "manet" , , "DHC WG" X-OriginalArrivalTime: 15 Oct 2008 16:32:10.0591 (UTC) FILETIME=[926E0EF0:01C92EE3] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16218.001 X-TM-AS-Result: No--3.739300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This message is to introduce a new Internet-Draft titled: "Routing and Addressing in Next-Generation EnteRprises (RANGER)" RANGER is an architectural framework that uses well known (and in some cases widely-deployed) functional elements. RANGER is not a technical specification in itself, however it provides applicability analysis for the combination of existing and emerging technical specifications. In particular, it outlines an "enterprise-within-enterprise" framework that addresses issues such as routing scaling, IPv6/IPv4 coexistence, link MTU diversity, mobile ad-hoc networking, autoconfiguration, etc. The RANGER enterprise network model supports cooperative operations between diverse organizations that may have competing interests. The model can therefore be applied to the global Internet itself. In order to reduce fragmentation, please post any follow-up comments or questions to the int-area and rrg lists only. Fred Templin fred.l.templin@boeing.com =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, October 14, 2008 11:45 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-templin-ranger-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Routing and Addressing in Next-Generation EnteRprises (RANGER) Author(s) : F. Templin Filename : draft-templin-ranger-00.txt Pages : 17 Date : 2008-10-14 Enterprise networks will require support for both Internet protocol versions (IPv4 and IPv6) for an indeterminant period; perhaps even indefinitely. This is particularly true for existing enterprise networks that must introduce IPv6 without disruption of IPv4 services, but the same principles apply also to clean-slate deployments in new enterprises. Next-generation enterprises therefore require an architected solution for coordination of their internal routing and addressing plans for both IPv6 and IPv4. The RANGER architecture addresses these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-ranger-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. From owner-v6ops@ops.ietf.org Wed Oct 15 11:03:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A143A69DF for ; Wed, 15 Oct 2008 11:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmx1TUFc4CJT for ; Wed, 15 Oct 2008 11:03:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A5E23A69A7 for ; Wed, 15 Oct 2008 11:03:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqAgJ-0002gS-42 for v6ops-data@psg.com; Wed, 15 Oct 2008 18:01:11 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqAgB-0002fm-8G for v6ops@ops.ietf.org; Wed, 15 Oct 2008 18:01:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 44F7428C27F; Wed, 15 Oct 2008 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-tunnel-security-concerns-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081015180002.44F7428C27F@core3.amsl.com> Date: Wed, 15 Oct 2008 11:00:02 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --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 : Security Concerns With IP Tunneling Author(s) : J. Hoagland, et al. Filename : draft-ietf-v6ops-tunnel-security-concerns-01.txt Pages : 20 Date : 2008-10-14 A number of security concerns with IP tunnels are documented in this document. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness regarding the security issues with IP tunnels as deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-security-concerns-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-tunnel-security-concerns-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-15104830.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 17 13:05:08 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1ED93A67F8 for ; Fri, 17 Oct 2008 13:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.425 X-Spam-Level: X-Spam-Status: No, score=-5.425 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMkl0lX15aqG for ; Fri, 17 Oct 2008 13:05:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 940AC3A67E9 for ; Fri, 17 Oct 2008 13:05:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqvVI-000ITb-Gg for v6ops-data@psg.com; Fri, 17 Oct 2008 20:00:56 +0000 Received: from [198.24.6.9] (helo=imr1.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqvVB-000ISr-Q5 for v6ops@ops.ietf.org; Fri, 17 Oct 2008 20:00:53 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9HK1mUp025058; Fri, 17 Oct 2008 15:01:48 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 14:59:37 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 14:59:37 -0500 Message-ID: <48F8EE0D.4060307@ericsson.com> Date: Fri, 17 Oct 2008 15:57:01 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Nathan Ward CC: Kurt Zeilenga , Pasi Eronen , Tim Polk , secdir@mit.edu, Jim_Hoagland@symantec.com, dthaler@microsoft.com, v6ops@ops.ietf.org Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns-00 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2008 19:59:37.0608 (UTC) FILETIME=[E241A080:01C93092] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Nathan, Thanks for your comments. Please see responses inline. Nathan Ward wrote: > On 13/10/2008, at 4:38 PM, Suresh Krishnan wrote: > >>>> One simple method to do that is easy to employ for many tunnel >>>> protocols is to block outbound packets to the UDP or TCP port used >>>> (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). >>> The description of this method is not precise. Is the method to >>> block dest ports, with these source ports, or either, or both? >> >> The method is to block destination ports. We have changed this sentence >> to read >> (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for >> L2TP, etc.) > > This makes me squirm a bit. > > It seems silly to promote blocking discrete ports, when a user could > simply run their own Teredo server on a different port and tunnel out > with that, or run any other proxy or tunnel server of some kind on any > port they wanted. We've all run PPP over SSH before, it's not hard to do > this stuff, there are tools to do it automatically. You are right. This will not stop people from tunneling over other ports. But what would you propose to be done instead? > > If an organisation is concerned about people tunnelling through their > firewalls, they must use default-deny if they want to have any effect. Given the savvy user you mentioned above, I don't understand how this will have any effect either. The users can still tunnel over anything that has been permitted ahead of the default deny. > >>>> In 3.1.3, >>>> Tunneling over UDP or TCP (including HTTP) to reach the Internet is >>>> not recommended as a solution for managed networks. >>> First, I'm going to read the sentence as if the word 'managed' was >>> not used as I think all networks on the Internet are 'managed' to >>> some degree. If the authors had a particular definition of the term >>> 'managed network' in mind, they should define it. >>> So reading the sentence without the term 'managed', this is basically >>> a general applicability statement that use of tunneling over UDP or >>> TCP is not recommend for use to 'reach the Internet'. I don't see >>> this recommendation as being appropriate given the issue. >> >> We have changed this text to read >> >> " Tunneling over UDP or TCP (including HTTP) to reach the Internet is >> not recommended as a solution for networks that wish to enforce >> security polcies on the user traffic. (Windows, for example, >> disables Teredo by default if it detects that it is within an >> enterprise network that contains a Windows domain controller.)" > > Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? > I don't imagine that UDP makes it any more difficult to inspect than an > IP protocol. > > I think this statement should be changed to "Tunnelling through a > security device (ie. firewall) is not recommended for.. " etc. Sounds good. We will make this change. Cheers Suresh From owner-v6ops@ops.ietf.org Fri Oct 17 15:04:26 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539E23A6A22 for ; Fri, 17 Oct 2008 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 6eDWlW11LGmq for ; Fri, 17 Oct 2008 15:04:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5160B3A6AEF for ; Fri, 17 Oct 2008 15:04:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqxOu-000135-6B for v6ops-data@psg.com; Fri, 17 Oct 2008 22:02:28 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqxOo-00011y-RB for v6ops@ops.ietf.org; Fri, 17 Oct 2008 22:02:25 +0000 Received: (qmail 12209 invoked by uid 417); 17 Oct 2008 22:02:08 -0000 Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 17 Oct 2008 22:02:08 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Fri, 17 Oct 2008 16:02:08 -0600 References: <39C363776A4E8C4A94691D2BD9D1C9A10517EDDF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10517EDDF@XCH-NW-7V2.nw.nos.boeing.com> From: EricLKlein@softhome.net To: "Templin, Fred L" Cc: "Internet Area" , rrg@irtf.org, "IPv6 Operations" , autoconf@ietf.org, "manet" , ipv6@ietf.org, "DHC WG" Subject: Re: RANGER Date: Fri, 17 Oct 2008 16:02:08 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: EricLKlein@softhome.net X-Originating-IP: [202.154.82.62] Message-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Fred, How do you see RANGER fitting into the requirements for carriers to supply IP support (v4/v6) to mobile devices? Especially requirements that are similar to the enterprise ones that you describe? Eric Templin, Fred L writes: > This message is to introduce a new Internet-Draft titled: > > "Routing and Addressing in Next-Generation EnteRprises (RANGER)" > > RANGER is an architectural framework that uses well known > (and in some cases widely-deployed) functional elements. > RANGER is not a technical specification in itself, however > it provides applicability analysis for the combination of > existing and emerging technical specifications. In particular, > it outlines an "enterprise-within-enterprise" framework that > addresses issues such as routing scaling, IPv6/IPv4 coexistence, > link MTU diversity, mobile ad-hoc networking, autoconfiguration, > etc. > > The RANGER enterprise network model supports cooperative > operations between diverse organizations that may have > competing interests. The model can therefore be applied > to the global Internet itself. > > In order to reduce fragmentation, please post any follow-up > comments or questions to the int-area and rrg lists only. > > Fred Templin > fred.l.templin@boeing.com > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, October 14, 2008 11:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-templin-ranger-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Routing and Addressing in Next-Generation > EnteRprises (RANGER) > Author(s) : F. Templin > Filename : draft-templin-ranger-00.txt > Pages : 17 > Date : 2008-10-14 > > Enterprise networks will require support for both Internet protocol > versions (IPv4 and IPv6) for an indeterminant period; perhaps even > indefinitely. This is particularly true for existing enterprise > networks that must introduce IPv6 without disruption of IPv4 > services, but the same principles apply also to clean-slate > deployments in new enterprises. Next-generation enterprises > therefore require an architected solution for coordination of their > internal routing and addressing plans for both IPv6 and IPv4. The > RANGER architecture addresses these requirements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-templin-ranger-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. > From owner-v6ops@ops.ietf.org Fri Oct 17 15:10:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB6F28C125 for ; Fri, 17 Oct 2008 15:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[AWL=-1.568, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEkjEfMR9PY8 for ; Fri, 17 Oct 2008 15:10:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F34A28C160 for ; Fri, 17 Oct 2008 15:10:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqxWw-0001h6-77 for v6ops-data@psg.com; Fri, 17 Oct 2008 22:10:46 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqxWo-0001gF-CI for v6ops@ops.ietf.org; Fri, 17 Oct 2008 22:10:41 +0000 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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9HM9tOO014034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2008 17:10:00 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9HM9sWP006695; Fri, 17 Oct 2008 15:09:54 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9HM9s3L006686; Fri, 17 Oct 2008 15:09:54 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Oct 2008 15:09:55 -0700 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 Subject: RE: RANGER Date: Fri, 17 Oct 2008 15:09:52 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1051B3DD9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RANGER Thread-Index: AckwpAkPmJrFi1/8QVyudNl0+fdHGAAAHjGg References: <39C363776A4E8C4A94691D2BD9D1C9A10517EDDF@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: Cc: "Internet Area" , , "IPv6 Operations" , , "manet" , , "DHC WG" X-OriginalArrivalTime: 17 Oct 2008 22:09:55.0099 (UTC) FILETIME=[15D816B0:01C930A5] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16222.001 X-TM-AS-Result: No--17.174100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Eric, Interesting question, and I'm not entirely sure how to answer it. But, if it helps, I was just in the process of adding the following text to Section 3.1 when your message came in: "It is important to note that dual-stack systems such as 'V', 'W' and 'Z' may be simple IPv6/IPv4 hosts, or they may be BRs that attach arbitrarily-complex IPv6-only edge networks. Such IPv6-only edge networks could be as simple as a home network behind a residential gateway, or as complex as a major corporate/academic campus, a large service provider network, etc." Comments are welcome, Fred fred.l.templin@boeing.com=20 >-----Original Message----- >From: EricLKlein@softhome.net [mailto:EricLKlein@softhome.net]=20 >Sent: Friday, October 17, 2008 3:02 PM >To: Templin, Fred L >Cc: Internet Area; rrg@irtf.org; IPv6 Operations;=20 >autoconf@ietf.org; manet; ipv6@ietf.org; DHC WG >Subject: Re: RANGER > >Hi Fred,=20 > >How do you see RANGER fitting into the requirements for=20 >carriers to supply=20 >IP support (v4/v6) to mobile devices? Especially requirements that are=20 >similar to the enterprise ones that you describe?=20 > >Eric=20 > >Templin, Fred L writes:=20 > >> This message is to introduce a new Internet-Draft titled:=20 >>=20 >> "Routing and Addressing in Next-Generation EnteRprises (RANGER)"=20 >>=20 >> RANGER is an architectural framework that uses well known >> (and in some cases widely-deployed) functional elements. >> RANGER is not a technical specification in itself, however >> it provides applicability analysis for the combination of >> existing and emerging technical specifications. In particular, >> it outlines an "enterprise-within-enterprise" framework that >> addresses issues such as routing scaling, IPv6/IPv4 coexistence, >> link MTU diversity, mobile ad-hoc networking, autoconfiguration, >> etc.=20 >>=20 >> The RANGER enterprise network model supports cooperative >> operations between diverse organizations that may have >> competing interests. The model can therefore be applied >> to the global Internet itself.=20 >>=20 >> In order to reduce fragmentation, please post any follow-up >> comments or questions to the int-area and rrg lists only.=20 >>=20 >> Fred Templin >> fred.l.templin@boeing.com =20 >>=20 >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 >> Sent: Tuesday, October 14, 2008 11:45 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-templin-ranger-00.txt =20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories.=20 >>=20 >> Title : Routing and Addressing in Next-Generation >> EnteRprises (RANGER) >> Author(s) : F. Templin >> Filename : draft-templin-ranger-00.txt >> Pages : 17 >> Date : 2008-10-14=20 >>=20 >> Enterprise networks will require support for both Internet protocol >> versions (IPv4 and IPv6) for an indeterminant period; perhaps even >> indefinitely. This is particularly true for existing enterprise >> networks that must introduce IPv6 without disruption of IPv4 >> services, but the same principles apply also to clean-slate >> deployments in new enterprises. Next-generation enterprises >> therefore require an architected solution for coordination of their >> internal routing and addressing plans for both IPv6 and IPv4. The >> RANGER architecture addresses these requirements.=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-templin-ranger-00.txt=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/=20 >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft.=20 >>=20 >=20 > From owner-v6ops@ops.ietf.org Fri Oct 17 16:50:15 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8A83A6969 for ; Fri, 17 Oct 2008 16:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.363 X-Spam-Level: X-Spam-Status: No, score=-99.363 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJZLZ7XDc-JO for ; Fri, 17 Oct 2008 16:50:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B7FF3A6A12 for ; Fri, 17 Oct 2008 16:50:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kqz2f-0007hD-GC for v6ops-data@psg.com; Fri, 17 Oct 2008 23:47:37 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kqz2Y-0007gl-QP for v6ops@ops.ietf.org; Fri, 17 Oct 2008 23:47:32 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 5704A33C59; Fri, 17 Oct 2008 16:47:30 -0700 (PDT) Date: Fri, 17 Oct 2008 16:47:30 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lars Eggert Cc: ext Jari Arkko , 'IPv6 Operations' , IETF IPv6 Mailing List , draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org Subject: Re: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC In-Reply-To: <409ACC0E-8BE6-4348-9DA5-E02A32D42226@nokia.com> References: <20080812141311.F22353A68F8@core3.amsl.com> <48A2949B.9040504@piuha.net> <409ACC0E-8BE6-4348-9DA5-E02A32D42226@nokia.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: At Thu, 18 Sep 2008 14:40:14 +0200, Lars Eggert wrote: > the second last call has ended, but I didn't see a review from the v6 > community. (But maybe I missed it in the pile of unread email that > built up during my vacation.) > > Are the v6 folks OK with this document? If yes, I'd like to move this > forward after the gen-art review has been addressed. In case it's not too late, I'm fine with this document. I have some minor comments (on the 08 version): - it refers to draft-ietf-v6ops-v6onbydefault-03, but this document has been published as RFC4943. - RFC4861 deprecates the "on-link by default" rule, so the situation is not as bad as described in Section 3.2, at least with newer implementations that follow the latest RFC. The main point of this draft still holds, so I think this is a minor issue. As a meta-level comment, I hope the workaround described in Section 4.1 will be more widely adopted and deployed. It's a pity that this document will be published as informational in this sense because it won't affect implementors who would rather be compliant to standards. This is probably a compromise after a political war, however, so I won't object to that conclusion. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-v6ops@ops.ietf.org Sun Oct 19 13:42:39 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98893A6AB4 for ; Sun, 19 Oct 2008 13:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 wccl32Iw+Mwl for ; Sun, 19 Oct 2008 13:42:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EDC913A688B for ; Sun, 19 Oct 2008 13:42:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Krf1i-000G5u-9R for v6ops-data@psg.com; Sun, 19 Oct 2008 20:37:26 +0000 Received: from [209.85.198.239] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Krf1b-000G5X-Mx for v6ops@ops.ietf.org; Sun, 19 Oct 2008 20:37:23 +0000 Received: by rv-out-0506.google.com with SMTP id b25so1414262rvf.41 for ; Sun, 19 Oct 2008 13:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VgyhMwqMn5SLMRhbM4AXfVtBB79xV92gnWjrI9kR+S0=; b=dFsQGo/niegPXxffpz29RIVnWlt1lft8P1m4JrqZiLnpluaZpvyNHqn6esP1XACs/O M4PgWk5Iq7ppIwfipPaRqddHCqL1IZJ3swnwr8vcMO89BvKyDSptRZniYFIuAN5TzhpQ 9QZKEAijjCDrqjhOobXiqqDycSSEC+4OsHtao= 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=PaslFtxa8VJ34SqohiNx7UaV4jitUb/wGmKmpT+W5//VVN7BvnuUjiCbRdE9N6tf+a mMaSi2k32f1Zfk94Cj1yWXfLDwL4843GXk+pMSQOsT9uPPalq8YAEpgs1WFFsI0uOXTu uTbc73rfUtIs0Tsx4H0Kz+Ps/7tawtmBJWlOQ= Received: by 10.140.202.12 with SMTP id z12mr4274076rvf.186.1224448638401; Sun, 19 Oct 2008 13:37:18 -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 k2sm17004390rvb.1.2008.10.19.13.37.15 (version=SSLv3 cipher=RC4-MD5); Sun, 19 Oct 2008 13:37:17 -0700 (PDT) Message-ID: <48FB9A79.8040407@gmail.com> Date: Mon, 20 Oct 2008 09:37:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan CC: Nathan Ward , Kurt Zeilenga , Pasi Eronen , Tim Polk , secdir@mit.edu, Jim_Hoagland@symantec.com, dthaler@microsoft.com, v6ops@ops.ietf.org Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> In-Reply-To: <48F8EE0D.4060307@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ... >> Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? >> I don't imagine that UDP makes it any more difficult to inspect than >> an IP protocol. >> >> I think this statement should be changed to "Tunnelling through a >> security device (ie. firewall) is not recommended for.. " etc. > > Sounds good. We will make this change. Now you have me worried enough to say something I've been feeling ever since I really read this draft carefully. To exaggerate, why not just rename it "tunneling considered harmful" and chop it down to one paragraph? I think there's a real risk of this document being misunderstood by typical site IT managers, and being used simply as an excuse to block all kinds of tunnel-based v4/v6 coexistence. But tunnels are a legitimate coexistence strategy. I'd much rather see this document talking more about how to make the use of tunnels safe as part of v4/v6 coexistence. There is some of that material in the document, but the impression the draft leaves is now of a succession of warnings to block tunnels. Brian From owner-v6ops@ops.ietf.org Sun Oct 19 21:44:33 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171963A6A55 for ; Sun, 19 Oct 2008 21:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.547 X-Spam-Level: X-Spam-Status: No, score=-108.547 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 7ksXNEoFBZCK for ; Sun, 19 Oct 2008 21:44:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 591453A6A4E for ; Sun, 19 Oct 2008 21:44:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrmZC-000Ewm-BJ for v6ops-data@psg.com; Mon, 20 Oct 2008 04:40:30 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrmZ7-000EwV-VN for v6ops@ops.ietf.org; Mon, 20 Oct 2008 04:40:27 +0000 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 19 Oct 2008 21:40:25 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.291.1; Sun, 19 Oct 2008 21:40:24 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Sun, 19 Oct 2008 21:40:50 -0700 From: Christian Huitema To: Brian E Carpenter , Suresh Krishnan CC: Nathan Ward , Kurt Zeilenga , Pasi Eronen , Tim Polk , "secdir@mit.edu" , "Jim_Hoagland@symantec.com" , Dave Thaler , "v6ops@ops.ietf.org" Date: Sun, 19 Oct 2008 21:40:20 -0700 Subject: RE: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Topic: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Index: AckyK7876dxng3L8RzC/j07RVge7RAAQVcXg Message-ID: <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> In-Reply-To: <48FB9A79.8040407@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: PiBJIHRoaW5rIHRoZXJlJ3MgYSByZWFsIHJpc2sgb2YgdGhpcyBkb2N1bWVudCBiZWluZyBtaXN1 bmRlcnN0b29kDQo+IGJ5IHR5cGljYWwgc2l0ZSBJVCBtYW5hZ2VycywgYW5kIGJlaW5nIHVzZWQg c2ltcGx5IGFzIGFuIGV4Y3VzZQ0KPiB0byBibG9jayBhbGwga2luZHMgb2YgdHVubmVsLWJhc2Vk IHY0L3Y2IGNvZXhpc3RlbmNlLiBCdXQgdHVubmVscw0KPiBhcmUgYSBsZWdpdGltYXRlIGNvZXhp c3RlbmNlIHN0cmF0ZWd5LiBJJ2QgbXVjaCByYXRoZXIgc2VlDQo+IHRoaXMgZG9jdW1lbnQgdGFs a2luZyBtb3JlIGFib3V0IGhvdyB0byBtYWtlIHRoZSB1c2Ugb2YgdHVubmVscw0KPiBzYWZlIGFz IHBhcnQgb2YgdjQvdjYgY29leGlzdGVuY2UuIFRoZXJlIGlzIHNvbWUgb2YgdGhhdCBtYXRlcmlh bA0KPiBpbiB0aGUgZG9jdW1lbnQsIGJ1dCB0aGUgaW1wcmVzc2lvbiB0aGUgZHJhZnQgbGVhdmVz IGlzIG5vdyBvZg0KPiBhIHN1Y2Nlc3Npb24gb2Ygd2FybmluZ3MgdG8gYmxvY2sgdHVubmVscy4N Cg0KQWN0dWFsbHksIGl0IGlzIGEgc3VjY2Vzc2lvbiBvZiB3YXJuaW5nIHRvIGJsb2NrIHN0YW5k YXJkaXplZCB0dW5uZWxzLCB0aG9zZSB0aGF0IGFyZSB3ZWxsIGRvY3VtZW50ZWQgYW5kIGhhdmUg YSBjbGVhciBzaWduYXR1cmUuIEJ5IGRvaW5nIHNvLCB3ZSBhcmUgcHVzaGluZyBhcHBsaWNhdGlv biBkZXZlbG9wZXJzIHRvIGp1c3QgInJvbGwgdGhlaXIgb3duIHRlY2hub2xvZ2llcyIsIGFuZCBp bmRlZWQgdG8gdXNlIGV2YXNpdmUgdGVjaG5pcXVlcyBzdWNoIGFzIGVuY3J5cHRlZCBwYWNrZXRz LCByYW5kb20gcG9ydCBudW1iZXJzIG9yIHR1bm5lbGluZyBvZiBIVFRQLiBJIGFtIG5vdCBzdXJl IHRoYXQgbmV0d29yayBtYW5hZ2VycyBhcmUgZ29pbmcgdG8gbGlrZSB0aGUgcmVzdWx0Li4uDQoN Ci0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQoNCg== From owner-v6ops@ops.ietf.org Sun Oct 19 22:12:20 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E2D3A6967 for ; Sun, 19 Oct 2008 22:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.99 X-Spam-Level: X-Spam-Status: No, score=-101.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 44GjefY2kqbN for ; Sun, 19 Oct 2008 22:12:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B74DB3A6885 for ; Sun, 19 Oct 2008 22:12:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Krn3Q-000H1A-L2 for v6ops-data@psg.com; Mon, 20 Oct 2008 05:11:44 +0000 Received: from [2a00:801::f] (helo=uplift.swm.pp.se) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Krn3D-000H0H-IU for v6ops@ops.ietf.org; Mon, 20 Oct 2008 05:11:38 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id E6CE59B; Mon, 20 Oct 2008 07:11:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E4AF99A for ; Mon, 20 Oct 2008 07:11:27 +0200 (CEST) Date: Mon, 20 Oct 2008 07:11:27 +0200 (CEST) From: Mikael Abrahamsson To: "v6ops@ops.ietf.org" Subject: Re: some real life data In-Reply-To: Message-ID: References: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 20 Oct 2008, Nathan Ward wrote: > I think a better approach would be to prefer A over AAAA if the client > only has teredo, instead of not querying AAAA at all. This way teredo is > still used for names with AAAA only. This is the way XP works afaik. If your IP indicates that you're over a tunneled IPv6 connection, IPv4 will be preferred over IPv6, but if there is no IPv4 (A), IPv6 (AAAA) will be used. I find this quite reasonable and thus my question why this was changed in Vista. -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Mon Oct 20 03:41:56 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866A23A69C6 for ; Mon, 20 Oct 2008 03:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r7KY8geDsrf for ; Mon, 20 Oct 2008 03:41:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7E4D3A6984 for ; Mon, 20 Oct 2008 03:41:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrsAD-000AtG-RK for v6ops-data@psg.com; Mon, 20 Oct 2008 10:39:05 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrsA7-000AsX-R7 for v6ops@ops.ietf.org; Mon, 20 Oct 2008 10:39:02 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m9KAcpBD009260; Mon, 20 Oct 2008 13:38:51 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m9KAcphn009256; Mon, 20 Oct 2008 13:38:51 +0300 Date: Mon, 20 Oct 2008 13:38:50 +0300 (EEST) From: Pekka Savola To: Mikael Abrahamsson cc: "v6ops@ops.ietf.org" Subject: Re: some real life data In-Reply-To: Message-ID: References: <134344D6-3CFD-4CA5-8C1B-89097CA7295A@daork.net> <523F9371B6E04B4B89382D8B3739F96B0E9A994860@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.93.3/8446/Mon Oct 20 03:00:10 2008 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Mon, 20 Oct 2008, Mikael Abrahamsson wrote: > On Mon, 20 Oct 2008, Nathan Ward wrote: >> I think a better approach would be to prefer A over AAAA if the client >> only has teredo, instead of not querying AAAA at all. This way teredo is >> still used for names with AAAA only. > > This is the way XP works afaik. If your IP indicates that you're over a > tunneled IPv6 connection, IPv4 will be preferred over IPv6, but if there is > no IPv4 (A), IPv6 (AAAA) will be used. > > I find this quite reasonable and thus my question why this was changed in > Vista. My guess would be 1) broken DNS servers, load balancers, etc. causing timeouts (as documented in RFC4074), and 2) MS more clearly targeting Teredo as an overlay network rather than a transition tool, and overlay networks such as p2p systems have their own node discovery mechanisms. -- 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 owner-v6ops@ops.ietf.org Tue Oct 21 08:24:54 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026C93A6AD9 for ; Tue, 21 Oct 2008 08:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh1dCwckGkmU for ; Tue, 21 Oct 2008 08:24:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CD6A3A6834 for ; Tue, 21 Oct 2008 08:24:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsJ1i-000O2F-Fc for v6ops-data@psg.com; Tue, 21 Oct 2008 15:20:06 +0000 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsJ1b-000O0o-6z for v6ops@ops.ietf.org; Tue, 21 Oct 2008 15:20:03 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9LFJEIN006257; Tue, 21 Oct 2008 10:19:16 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:19:15 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:19:15 -0500 Message-ID: <48FDF264.1030006@ericsson.com> Date: Tue, 21 Oct 2008 11:16:52 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Brian E Carpenter CC: Nathan Ward , Kurt Zeilenga , Pasi Eronen , Tim Polk , secdir@mit.edu, Jim_Hoagland@symantec.com, dthaler@microsoft.com, v6ops@ops.ietf.org Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> In-Reply-To: <48FB9A79.8040407@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2008 15:19:15.0549 (UTC) FILETIME=[612E20D0:01C93390] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Brian, Thanks for your comments. Please see responses inline. Brian E Carpenter wrote: > ... >>> Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? >>> I don't imagine that UDP makes it any more difficult to inspect than >>> an IP protocol. >>> >>> I think this statement should be changed to "Tunnelling through a >>> security device (ie. firewall) is not recommended for.. " etc. >> Sounds good. We will make this change. > > Now you have me worried enough to say something I've been feeling > ever since I really read this draft carefully. > > To exaggerate, why not just rename it "tunneling considered > harmful" and chop it down to one paragraph? The draft is about security concerns with tunnels. It discusses concerns and associated recommendations if the concern is considered valid by an admin. It was not our goal to say "tunneling considered harmful" but rather to say "If you want to do foo, tunneling might prevent you from doing foo. So disable tunnels" or "If you don't want your users to do foo, tunneling might allow them to do foo. So disable tunnels". > > I think there's a real risk of this document being misunderstood > by typical site IT managers, and being used simply as an excuse > to block all kinds of tunnel-based v4/v6 coexistence. But tunnels > are a legitimate coexistence strategy. I'd much rather see > this document talking more about how to make the use of tunnels > safe as part of v4/v6 coexistence. There is some of that material > in the document, but the impression the draft leaves is now of > a succession of warnings to block tunnels. Although the draft started out as security concerns related to Teredo tunnels, it has been generalized to all kinds of tunnels and not limited to v4/v6 transition tunnels. The draft lists problems and possible solutions to those problems. If you think there is a problem with the tone of the document, I am sure we can work on fixing it, but I sincerely believe that all the stated concerns are real and not FUD. Thanks Suresh From owner-v6ops@ops.ietf.org Tue Oct 21 09:00:52 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457E53A69D9 for ; Tue, 21 Oct 2008 09:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmw-JWVZhsE0 for ; Tue, 21 Oct 2008 09:00:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55EC73A6993 for ; Tue, 21 Oct 2008 09:00:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsJeR-0001kO-6W for v6ops-data@psg.com; Tue, 21 Oct 2008 16:00:07 +0000 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsJeG-0001j9-GJ for v6ops@ops.ietf.org; Tue, 21 Oct 2008 15:59:59 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9LFxMAt025627; Tue, 21 Oct 2008 10:59:22 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:59:22 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:59:22 -0500 Message-ID: <48FDFBCB.1090508@ericsson.com> Date: Tue, 21 Oct 2008 11:56:59 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Christian Huitema CC: Brian E Carpenter , Nathan Ward , Kurt Zeilenga , Pasi Eronen , Tim Polk , "secdir@mit.edu" , "Jim_Hoagland@symantec.com" , Dave Thaler , "v6ops@ops.ietf.org" Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2008 15:59:22.0081 (UTC) FILETIME=[FB95C510:01C93395] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Christian, Thanks for your comments. Please see my response inline Christian Huitema wrote: >> I think there's a real risk of this document being misunderstood >> by typical site IT managers, and being used simply as an excuse >> to block all kinds of tunnel-based v4/v6 coexistence. But tunnels >> are a legitimate coexistence strategy. I'd much rather see >> this document talking more about how to make the use of tunnels >> safe as part of v4/v6 coexistence. There is some of that material >> in the document, but the impression the draft leaves is now of >> a succession of warnings to block tunnels. > > Actually, it is a succession of warning to block standardized tunnels, > those that are well documented and have a clear signature. > By doing so, we are pushing application developers to just "roll > their own technologies", and indeed to use evasive techniques such as > encrypted packets, random port numbers or tunneling of HTTP. I am not > sure that network managers are going to like the result... While I agree with you about the possibility of an "arms race" I really do not see anything we can do about this. What would you recommend instead? I am really open to suggestions. Thanks Suresh From owner-v6ops@ops.ietf.org Tue Oct 21 14:19:37 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9403A6BA5 for ; Tue, 21 Oct 2008 14:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 75cjpuUFt8EI for ; Tue, 21 Oct 2008 14:19:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D24E13A685D for ; Tue, 21 Oct 2008 14:19:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsOaA-0002Mt-B3 for v6ops-data@psg.com; Tue, 21 Oct 2008 21:16:02 +0000 Received: from [209.85.132.247] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsOa2-0002MP-W6 for v6ops@ops.ietf.org; Tue, 21 Oct 2008 21:15:58 +0000 Received: by an-out-0708.google.com with SMTP id c24so161804ana.18 for ; Tue, 21 Oct 2008 14:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UkyAC1fAePv/hkr8NcvHqxFSVyqYn8fjglelRQmIk8o=; b=NUthboK+jyWdISF7TTjgfVZNw5AE90oWbIYR4srdPlastzfzxeKy+8azgyQJK2pnZ0 JClY5M2GaPyFBLoVosrE/KF+nRxaBF/3RWx02JHvdtxr+d6O8ms5D3aIN71L8MQK4yUn XtowYSaQePGgyYRw74kcd+MuOR58tR8XOjYZE= 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=WuhDTAxzu1a0xFPrFZz28xdd4ucHzighsjuz/lvTi4q0p/LL+zh9rKk5oyalVAEjV9 G9KnarOC7IiYmasZA2tjJSsz2CM+JM47qVTtBCtqAf4BzKqWjccYh+ESFxqscd/aGACp 2B7/79nxjqKMszrk25Ddg0c5V/jYz+BBTbeiA= Received: by 10.142.188.4 with SMTP id l4mr3978910wff.151.1224623753307; Tue, 21 Oct 2008 14:15:53 -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 9sm19251550wfc.19.2008.10.21.14.15.49 (version=SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 14:15:52 -0700 (PDT) Message-ID: <48FE4681.4070006@gmail.com> Date: Wed, 22 Oct 2008 10:15:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan CC: Christian Huitema , Nathan Ward , Kurt Zeilenga , Pasi Eronen , Tim Polk , "secdir@mit.edu" , "Jim_Hoagland@symantec.com" , Dave Thaler , "v6ops@ops.ietf.org" Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> In-Reply-To: <48FDFBCB.1090508@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Suresh, You wrote to Christian: > While I agree with you about the possibility of an "arms race" I really > do not see anything we can do about this. What would you recommend > instead? I am really open to suggestions. My feeling is that we need to tell IT managers something like "If your users have a need for IPv6 tunnels, here is how to make them as safe as possible: and after that, explain the threats, and state that tunnels should be disabled if you are not protected against the threats. There are also other positive suggestions, like operating an on-site 6to4 relay and/or Teredo server, so that those mechanisms don't cross the border router. I agree with you that there are real threats (or will be, once there is enough deployment to make IPv6 tunnels an interesting target). It's quite appropriate to document them. Brian From owner-v6ops@ops.ietf.org Tue Oct 21 14:21:58 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343C53A6BA4 for ; Tue, 21 Oct 2008 14:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.284 X-Spam-Level: X-Spam-Status: No, score=-108.284 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 zrHMUBs9mLGZ for ; Tue, 21 Oct 2008 14:21:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 096723A67EF for ; Tue, 21 Oct 2008 14:21:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsOft-0002h0-W9 for v6ops-data@psg.com; Tue, 21 Oct 2008 21:21:58 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsOfk-0002gJ-5a for v6ops@ops.ietf.org; Tue, 21 Oct 2008 21:21:50 +0000 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 21 Oct 2008 14:21:47 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) with Microsoft SMTP Server id 8.1.291.1; Tue, 21 Oct 2008 14:21:47 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Tue, 21 Oct 2008 14:22:15 -0700 From: Christian Huitema To: Brian E Carpenter , Suresh Krishnan CC: Nathan Ward , Kurt Zeilenga , Pasi Eronen , Tim Polk , "secdir@mit.edu" , "Jim_Hoagland@symantec.com" , Dave Thaler , "v6ops@ops.ietf.org" Date: Tue, 21 Oct 2008 14:20:53 -0700 Subject: RE: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Topic: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Index: AckzwjjrdHuNFu8ORRuRlXgsrzgyngAAGMeQ Message-ID: <8EFB68EAE061884A8517F2A755E8B60A134A7F7EE5@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> In-Reply-To: <48FE4681.4070006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: PiBNeSBmZWVsaW5nIGlzIHRoYXQgd2UgbmVlZCB0byB0ZWxsIElUIG1hbmFnZXJzIHNvbWV0aGlu ZyBsaWtlDQo+ICJJZiB5b3VyIHVzZXJzIGhhdmUgYSBuZWVkIGZvciBJUHY2IHR1bm5lbHMsIGhl cmUgaXMgaG93IHRvDQo+IG1ha2UgdGhlbSBhcyBzYWZlIGFzIHBvc3NpYmxlOg0KPg0KPiAgPGRl c2NyaXB0aW9uIG9mIG1lY2hhbmlzbXMsIGUuZy4gZm9yIGRldGVjdGluZyBEb1MsLi4uPg0KDQpJ IGFncmVlLiBDaGFuZ2UgdGhlIG1lc3NhZ2UgdG8gYSBwb3NpdGl2ZSB0b25lLiBTdGFydCB3aXRo IHRoZSBhc3N1bXB0aW9uIHRoYXQgdHVubmVscyBhcmUgZ29pbmcgdG8gaGFwcGVuIG9uZSB3YXkg b3IgYW5vdGhlciwgdGhlbiB3b3JrIGZyb20gdGhlcmUgdG8gc3BlY2lmeSB0aGUgc2FmZSBkZXBs b3ltZW50IGd1aWRlbGluZXMsIGFzIGFwcHJvcHJpYXRlIGZvciB0aGUgdmFyaW91cyBkZXBsb3lt ZW50IGNhc2VzLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0K From owner-v6ops@ops.ietf.org Tue Oct 21 23:05:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3123A6886 for ; Tue, 21 Oct 2008 23:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.321 X-Spam-Level: X-Spam-Status: No, score=-5.321 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HJz0kW3IXEd for ; Tue, 21 Oct 2008 23:05:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF9183A67DD for ; Tue, 21 Oct 2008 23:05:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsWl2-00092O-Kl for v6ops-data@psg.com; Wed, 22 Oct 2008 05:59:48 +0000 Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsWkw-00091q-Aq for v6ops@ops.ietf.org; Wed, 22 Oct 2008 05:59:45 +0000 Received: from [192.168.0.51] (ip-118-90-107-173.xdsl.xnet.co.nz [118.90.107.173]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id A3E5527940; Wed, 22 Oct 2008 18:59:37 +1300 (NZDT) Cc: Suresh Krishnan , Christian Huitema , Kurt Zeilenga , Pasi Eronen , Tim Polk , "secdir@mit.edu" , "Jim_Hoagland@symantec.com" , Dave Thaler , "v6ops@ops.ietf.org" Message-Id: <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> From: Nathan Ward To: Brian E Carpenter In-Reply-To: <48FE4681.4070006@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns Date: Wed, 22 Oct 2008 18:59:36 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 22/10/2008, at 10:15 AM, Brian E Carpenter wrote: > Suresh, > > You wrote to Christian: > >> While I agree with you about the possibility of an "arms race" I >> really >> do not see anything we can do about this. What would you recommend >> instead? I am really open to suggestions. > > My feeling is that we need to tell IT managers something like > "If your users have a need for IPv6 tunnels, here is how to > make them as safe as possible: > > > > and after that, explain the threats, and state that tunnels > should be disabled if you are not protected against the threats. > > There are also other positive suggestions, like operating > an on-site 6to4 relay and/or Teredo server, so that those > mechanisms don't cross the border router. Operating a Teredo server on site does not help unfortunately. It helps an administrator filter outbound packets when sent to an IPv6 address outside 2001::/32. It does not help an administrator filter inbound packets, or packets to/from other Teredo hosts. > I agree with you that there are real threats (or will be, once > there is enough deployment to make IPv6 tunnels an interesting > target). It's quite appropriate to document them. I need to preface these remarks by say that I haven't read the document apart from a quick skim read, so sorry if I'm saying something that's already in there, or is not relevant. I think it's important to distinguish between tunnels that end users' systems create automatically (ala 6to4, Teredo in Vista), and tunnels that end users create to work around firewalls. The former is easy to document solutions for, in fact, it seems to me that any tunnelling protocol RFC should include details as to how a network administrator can prevent these protocols passing through their network. For Teredo this means blocking port 3544/3545. For 6to4 this means blocking protocol 41 (preferably returning ICMPv6 messages encapsulated in 6to4 so the the application is told about it..). This is more about blocking things that do not work or perform poorly in a certain environment, rather than trying to secure a network. The latter is not so easy, and I think this document should simply point out that the only way to really do this is to completely control the end users' machines, and not allow any third party software or configuration changes. Anything else is instilling a false sense of security in the minds of network administrators who perhaps are not as fluent in these things as we are. -- Nathan Ward From owner-v6ops@ops.ietf.org Wed Oct 22 13:25:43 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A7828C0FC for ; Wed, 22 Oct 2008 13:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 t4Lq9XbNPmj8 for ; Wed, 22 Oct 2008 13:25:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7674A3A6A97 for ; Wed, 22 Oct 2008 13:25:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KskBj-000Nwe-Ko for v6ops-data@psg.com; Wed, 22 Oct 2008 20:20:15 +0000 Received: from [209.85.217.20] (helo=mail-gx0-f20.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KskBc-000Nw9-FI for v6ops@ops.ietf.org; Wed, 22 Oct 2008 20:20:12 +0000 Received: by gxk13 with SMTP id 13so8199210gxk.17 for ; Wed, 22 Oct 2008 13:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/uoRPRq8x4yh9euQOshuI6QEd3Qa7Y75PwiiOFRtV64=; b=e5NbrS194sOV2viBQEdkvLJO1UZns9YUmJPVukrvd7QGLXKBQ//debitZ38c27GaeG uLrIBiVZVdQsDPexkw/1gauwheAoTr+PUco8S8nci0rlsLE1MJcrv6h6lHDi9IsVFFfu 7an5VTPh2UF9Vf486C3ouqgDDtLhfFqocGGEQ= 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=BMuXRtHuy81rVFrfaFFylXWrRVWa/qp7mNZKrUCAnxazUFSygH/wOn0qWzk1AIqCOF 4/lwSYCUdIOFM2oMyYoJmqBsym9OCenJgXEehzdmsbSnRkv1VlXweM7CsBQJLgaDizCO 6sDc/LHP82CWjRIvHgZZ9AJpqa+GGIrVAxbHY= Received: by 10.143.35.4 with SMTP id n4mr4561992wfj.64.1224706807011; Wed, 22 Oct 2008 13:20:07 -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 28sm22227652wfg.15.2008.10.22.13.20.03 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 13:20:06 -0700 (PDT) Message-ID: <48FF8AEC.9060708@gmail.com> Date: Thu, 23 Oct 2008 09:19:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Ward CC: Suresh Krishnan , Christian Huitema , Kurt Zeilenga , Pasi Eronen , Tim Polk , "secdir@mit.edu" , "Jim_Hoagland@symantec.com" , Dave Thaler , "v6ops@ops.ietf.org" Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> In-Reply-To: <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Nathan, On 2008-10-22 18:59, Nathan Ward wrote: > On 22/10/2008, at 10:15 AM, Brian E Carpenter wrote: > >> Suresh, >> >> You wrote to Christian: >> >>> While I agree with you about the possibility of an "arms race" I really >>> do not see anything we can do about this. What would you recommend >>> instead? I am really open to suggestions. >> >> My feeling is that we need to tell IT managers something like >> "If your users have a need for IPv6 tunnels, here is how to >> make them as safe as possible: >> >> >> >> and after that, explain the threats, and state that tunnels >> should be disabled if you are not protected against the threats. >> >> There are also other positive suggestions, like operating >> an on-site 6to4 relay and/or Teredo server, so that those >> mechanisms don't cross the border router. > > Operating a Teredo server on site does not help unfortunately. > > It helps an administrator filter outbound packets when sent to an IPv6 > address outside 2001::/32. It does not help an administrator filter > inbound packets, or packets to/from other Teredo hosts. As far as I can see, there's a general problem in attempting to detect and block Teredo packets (I mean UDP/IPv4 packets in Teredo format). But it seems to me that by running an internal Teredo server, a site is much better placed to track and trace Teredo users. This is important as Teredo users really need to be running an IPv6-savvy host firewall. > >> I agree with you that there are real threats (or will be, once >> there is enough deployment to make IPv6 tunnels an interesting >> target). It's quite appropriate to document them. > > > I need to preface these remarks by say that I haven't read the document > apart from a quick skim read, so sorry if I'm saying something that's > already in there, or is not relevant. > > I think it's important to distinguish between tunnels that end users' > systems create automatically (ala 6to4, Teredo in Vista), and tunnels > that end users create to work around firewalls. > > The former is easy to document solutions for, in fact, it seems to me > that any tunnelling protocol RFC should include details as to how a > network administrator can prevent these protocols passing through their > network. For Teredo this means blocking port 3544/3545. For 6to4 this > means blocking protocol 41 (preferably returning ICMPv6 messages > encapsulated in 6to4 so the the application is told about it..). This is > more about blocking things that do not work or perform poorly in a > certain environment, rather than trying to secure a network. > > The latter is not so easy, and I think this document should simply point > out that the only way to really do this is to completely control the end > users' machines, and not allow any third party software or configuration > changes. Anything else is instilling a false sense of security in the > minds of network administrators who perhaps are not as fluent in these > things as we are. Yes, but there are plenty of environments where that's impossible, and default deny is unacceptable because it blocks legitimate usage. I think the document needs to steer between the extremes, and suggest scenarios that are reasonably safe. Brian From owner-v6ops@ops.ietf.org Wed Oct 22 18:36:32 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9EB3A6846 for ; Wed, 22 Oct 2008 18:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmdJCgbJ4WNa for ; Wed, 22 Oct 2008 18:36:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CEB73A6841 for ; Wed, 22 Oct 2008 18:36:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksp47-000Jvv-EZ for v6ops-data@psg.com; Thu, 23 Oct 2008 01:32:43 +0000 Received: from [2001:470:1f06:248::2] (helo=dns.suspicious.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksp41-000JvO-74 for v6ops@ops.ietf.org; Thu, 23 Oct 2008 01:32:39 +0000 Received: from mbp.suspicious.org (mbp.suspicious.org [IPv6:2001:470:8859:beef:21f:5bff:fece:280a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dns.suspicious.org (Postfix) with ESMTP id 7B9483364D; Wed, 22 Oct 2008 21:32:33 -0400 (EDT) Cc: Nathan Ward , IPv6 Operations Message-Id: <1CF0355B-2AE9-441F-B05E-685D0367EAE1@suspicious.org> From: Truman Boyes To: Brian E Carpenter In-Reply-To: <48FF8AEC.9060708@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns Date: Wed, 22 Oct 2008 21:32:31 -0400 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> <48FF8AEC.9060708@gmail.com> X-Mailer: Apple Mail (2.926) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Brian, et. al, On 22/10/2008, at 4:19 PM, Brian E Carpenter wrote: >> > Yes, but there are plenty of environments where that's impossible, > and default deny is unacceptable because it blocks legitimate usage. > I think the document needs to steer between the extremes, and suggest > scenarios that are reasonably safe. > > Brian I agree the document needs to suggest reasonably safe scenarios for tunneling; although "legitimate usage" is up the control and perception of the network owner. Tunnels from end stations may be acceptable in network A and totally unacceptable in network B. I think a default deny of tunnels is bad for all of us; the points that Christian outlined and some of the previous discussion items in this thread clearly articulate the point that a default deny would cause us more re-work of documents as the "target starts to move". If the document simply states what the concerns are, how the tunnels work, then network owners can decide what they want to do. If there are ways to make things a little bit better with some policy or network design, then the document should go that far ... Truman From owner-v6ops@ops.ietf.org Mon Oct 27 06:02:04 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0493A6944 for ; Mon, 27 Oct 2008 06:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, J_BACKHAIR_44=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrTC9ZH9WTbf for ; Mon, 27 Oct 2008 06:02:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3FCE3A6822 for ; Mon, 27 Oct 2008 06:02:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuRcV-000Jn4-Om for v6ops-data@psg.com; Mon, 27 Oct 2008 12:54:55 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuRcH-000JlD-4g for v6ops@ops.ietf.org; Mon, 27 Oct 2008 12:54:48 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 23171206D0; Mon, 27 Oct 2008 13:54:39 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-77-4905ba0e6c39 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F04E720242; Mon, 27 Oct 2008 13:54:38 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 13:54:38 +0100 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 13:54:37 +0100 Message-ID: <4905BA0E.7000502@ericsson.com> Date: Mon, 27 Oct 2008 13:54:38 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Behave WG , 46Translation <46translation@employees.org>, v4v6interim@ietf.org, IETF V6OPS WG , softwires@ietf.org, Internet Area , TSV Area Subject: Status of IPv4-IPv6 Coexistence Work X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2008 12:54:37.0889 (UTC) FILETIME=[2B5ECB10:01C93833] X-Brightmail-Tracker: AAAAAA== Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: IETF Community, There has been a lot of activity on the topic of improving IPv4 and IPv6 coexistence, deployment of IPv6, and coping with the increasing shortage of unassigned IPv4 addresses. This work crosses a number of layer and area boundaries, which has led to new lists, cross-posting, etc. In order to limit confusion, we'd like to give some guidance on where to discuss what on which lists. The intent is not to declare any work as in or out of charter with this message, only to try and direct list discussion. These are only general guidelines, so please don't be alarmed if we missed something in particular. Our hope is that this will help everyone to continue the rich dialog on this important topic. 1. softwires@ietf.org Softwires is chartered to work on combinations of IPv4/IPv6 and IPv6/IPv4, including "dual-stack lite" functionality. This includes discussion related to: - All types of IPv4/IPv6 tunnels, including encapsulation, control plane, etc. - Affects of tunnel endpoints terminating into a concentrator performing IPv4 to IPv4 NAT - Discovery of tunnel endpoints - Tunnels initiated by hosts or gateways - Tunnels automatically setup by routing and special prefixes Thus, if it involves a tunnel or encapsulation of IPvX over IPvY, softwires is the place to go. 2. behave@ietf.org The Behave WG is currently being rechartered. If the new charter is approved, behave will work on various types of IPv4<->IPv6 translation. Please direct all discussion related to: - IPv4 to IPv6 and IPv6 to IPv4 translation - IPv6 to IPv6 NAT - Division of port space to share one IPv4 addresses among multiple endpoints at the same time - Affects on applications and transport protocols - ALGs - IPv4 to IPv4 NAT functionality, including for ISP deployments Thus, if discussion involves an IP translator or the internal function of a NAT, behave is the place to go. 3. v6ops@ietf.org - Operational discussions on the topic of coexistence in general - IPv6-only deployment Thus, if it involves operational issues of IPv6 or IPv4 exhaustion, go to v6ops. 4. The v4v6interim@ietf.org list will be removed after the Minneapolis IETF meeting. Jari Arkko Ron Bonica Lars Eggert Mark Townsley Magnus Westerlund Resources: WGs Behave: http://www.ietf.org/html.charters/behave-charter.html Softwire: http://www.ietf.org/html.charters/softwire-charter.html v6ops: http://www.ietf.org/html.charters/v6ops-charter.html From owner-v6ops@ops.ietf.org Thu Oct 30 08:37:40 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC043A6878 for ; Thu, 30 Oct 2008 08:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=-2.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z56VYSxI1EMO for ; Thu, 30 Oct 2008 08:37:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D56933A6816 for ; Thu, 30 Oct 2008 08:37:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvZUY-000Ab2-Rr for v6ops-data@psg.com; Thu, 30 Oct 2008 15:31:22 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvZUN-000AaB-30 for v6ops@ops.ietf.org; Thu, 30 Oct 2008 15:31:15 +0000 X-IronPort-AV: E=Sophos;i="4.33,516,1220227200"; d="scan'208";a="26223158" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2008 15:31:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9UFV7sh022641; Thu, 30 Oct 2008 11:31:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9UFUqrM015560; Thu, 30 Oct 2008 15:31:07 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 11:30:59 -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 Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? Date: Thu, 30 Oct 2008 11:30:58 -0400 Message-ID: In-Reply-To: <48FF49BE.60005@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Unnecessary restriction in DHCP-PD? Thread-Index: Ack0cI3lIyIj2ArGS0my8xPd8lblRwGMzgmw References: <48F90EA3.6060409@ericsson.com> <48F9135C.70203@ericsson.com><20081017233401.GE5157@isc.org> <48FF49BE.60005@ericsson.com> From: "Hemant Singh (shemant)" To: "Suresh Krishnan" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 15:30:59.0258 (UTC) FILETIME=[825759A0:01C93AA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2572; t=1225380667; x=1226244667; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Unnecessary=20restriction=20i n=20DHCP-PD? |Sender:=20 |To:=20=22Suresh=20Krishnan=22=20,=0A=20=20=20=20=20=20=20=20=22IPv6=20Operations=22=20; bh=IQs/5MK1D6evZsfkva6EXWH0eI4PfmmUjjcBufeTCOo=; b=qhN2Rgm6u5KFt1olzB/XMk6YMsM+Ft6wWC+E5vg+ZA53b5xNIdm2pDtqP6 Z6zgszmMDv3z2tzPI5uq8YA/7bREO6LgkhRGO8yPhUqMwBvcbgufS48nQmIF o4gxzhpI8X; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, We never liked the Unnumbered model that was asked to be put in our CPE Rtr draft. Well, after this discussion a nail in the coffin for the Unnumbered model has been found. Due to this totally valid restriction in the DHCP-PD RFC3633, we need to remove the Unnumbered model from the CPE rtr draft. The reason is because in the Unnumbered model, an IPv6 address from the IA-PD was used for the source of upstream traffic to the Service Provider. Any comments? Thanks. Hemant & Wes -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Wednesday, October 22, 2008 11:42 AM To: David W. Hankins Cc: DHC WG Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD? Hi David, Thanks for your comments. Please find responses inline. David W. Hankins wrote: > On Fri, Oct 17, 2008 at 06:36:12PM -0400, Suresh Krishnan wrote: >> I read Ole's mail on v6ops as well, but I still do not see the=20 >> technical problem. I am running this setup currently and I am not seeing any issues. >> To narrow down my question, "what exactly breaks when we do this?" >=20 > It is an administrative question, not so much a technical one. Ack. I think this might be a good explanation for this restriction. >=20 > The PD client is a client, not representing the network administrator, > on the upstream-facing interface. It is inappropriate to make changes > to the network's management. If the network wished to give the client > additional addresses on that segment, the RA PIOs and/or IA_NA would=20 > already reflect that. >=20 > Having a delegated prefix does not grant the right to manage the=20 > upstream's network. >=20 >=20 > Note however that if the PD client was operating as a DHCPv6 server on > its upstream facing interface as well as advertising the delegated=20 > prefixes there, a recursion error would be present; a client on the=20 > upstream side may acheive a prefix delegation from a PD client on the=20 > same link, which in turn is a client of the upstream network, and so=20 > on. This was not my intent (to re-advertize the prefix upstream) but to just use a configured address. I realize now that pursuing this might be more trouble than it is worth. I am probably better off getting a DHCPv6 address or a SLAAC configured address on the upstream interface. Thanks Suresh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From owner-v6ops@ops.ietf.org Thu Oct 30 09:20:35 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136D03A6982 for ; Thu, 30 Oct 2008 09:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFBsUouoySSf for ; Thu, 30 Oct 2008 09:20:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F205B3A687E for ; Thu, 30 Oct 2008 09:20:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvaDh-000Er2-Ew for v6ops-data@psg.com; Thu, 30 Oct 2008 16:18:01 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvaDW-000Epw-Bb for v6ops@ops.ietf.org; Thu, 30 Oct 2008 16:17:56 +0000 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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9UGHUqE025723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 09:17:30 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9UGHUIO019675; Thu, 30 Oct 2008 09:17:30 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9UGHTl6019625; Thu, 30 Oct 2008 09:17:30 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 09:17:26 -0700 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 Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? Date: Thu, 30 Oct 2008 09:17:25 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10525C7EE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Unnecessary restriction in DHCP-PD? Thread-Index: Ack0cI3lIyIj2ArGS0my8xPd8lblRwGMzgmwAAGQMSA= References: <48F90EA3.6060409@ericsson.com> <48F9135C.70203@ericsson.com><20081017233401.GE5157@isc.org> <48FF49BE.60005@ericsson.com> From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "Suresh Krishnan" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 16:17:26.0788 (UTC) FILETIME=[FFD6AC40:01C93AAA] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16248.003 X-TM-AS-Result: No--31.516200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hemant,=20 >-----Original Message----- >From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 >Sent: Thursday, October 30, 2008 8:31 AM >To: Suresh Krishnan; IPv6 Operations >Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? > >Folks, > >We never liked the Unnumbered model that was asked to be put in our CPE >Rtr draft. Well, after this discussion a nail in the coffin for the >Unnumbered model has been found. Due to this totally valid restriction >in the DHCP-PD RFC3633, we need to remove the Unnumbered model from the >CPE rtr draft. The reason is because in the Unnumbered model, an IPv6 >address from the IA-PD was used for the source of upstream traffic to >the Service Provider. Any comments? If the CPE router assigns an address from the IA-PD prefix on an interface *other than* the one that connects the CPE to the provider, it can use that address for the source of upstream traffic. Fred fred.l.templin@boeing.com > >Thanks. > >Hemant & Wes > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >Of Suresh Krishnan >Sent: Wednesday, October 22, 2008 11:42 AM >To: David W. Hankins >Cc: DHC WG >Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD? > >Hi David, > Thanks for your comments. Please find responses inline. > >David W. Hankins wrote: >> On Fri, Oct 17, 2008 at 06:36:12PM -0400, Suresh Krishnan wrote: >>> I read Ole's mail on v6ops as well, but I still do not see the=20 >>> technical problem. I am running this setup currently and I am not >seeing any issues. >>> To narrow down my question, "what exactly breaks when we do this?" >>=20 >> It is an administrative question, not so much a technical one. > >Ack. I think this might be a good explanation for this restriction. > >>=20 >> The PD client is a client, not representing the network=20 >administrator, > >> on the upstream-facing interface. It is inappropriate to=20 >make changes > >> to the network's management. If the network wished to give=20 >the client > >> additional addresses on that segment, the RA PIOs and/or IA_NA would=20 >> already reflect that. >>=20 >> Having a delegated prefix does not grant the right to manage the=20 >> upstream's network. >>=20 >>=20 >> Note however that if the PD client was operating as a DHCPv6=20 >server on > >> its upstream facing interface as well as advertising the delegated=20 >> prefixes there, a recursion error would be present; a client on the=20 >> upstream side may acheive a prefix delegation from a PD=20 >client on the=20 >> same link, which in turn is a client of the upstream network, and so=20 >> on. > >This was not my intent (to re-advertize the prefix upstream)=20 >but to just >use a configured address. I realize now that pursuing this=20 >might be more >trouble than it is worth. I am probably better off getting a DHCPv6 >address or a SLAAC configured address on the upstream interface. > >Thanks >Suresh >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg > > From owner-v6ops@ops.ietf.org Thu Oct 30 10:03:24 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4D03A696A for ; Thu, 30 Oct 2008 10:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.895 X-Spam-Level: X-Spam-Status: No, score=-103.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 ovXrucMwP0Rp for ; Thu, 30 Oct 2008 10:03:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 951D33A6819 for ; Thu, 30 Oct 2008 10:03:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvasc-000J0x-4U for v6ops-data@psg.com; Thu, 30 Oct 2008 17:00:18 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvasJ-000Iym-ND for v6ops@ops.ietf.org; Thu, 30 Oct 2008 17:00:06 +0000 X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1225385997!4516978!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 21275 invoked from network); 30 Oct 2008 16:59:57 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 30 Oct 2008 16:59:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m9UGxuBA003658; Thu, 30 Oct 2008 12:59:57 -0400 Received: from 01GAF5142010624.AD.BLS.COM ([139.76.131.91]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m9UGxpq2003100; Thu, 30 Oct 2008 12:59:51 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 30 Oct 2008 12:59:50 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 30 Oct 2008 12:59:50 -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 Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? Date: Thu, 30 Oct 2008 12:59:42 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0B738567@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Unnecessary restriction in DHCP-PD? Thread-Index: Ack0cI3lIyIj2ArGS0my8xPd8lblRwGMzgmwAALeIUA= References: <48F90EA3.6060409@ericsson.com> <48F9135C.70203@ericsson.com><20081017233401.GE5157@isc.org> <48FF49BE.60005@ericsson.com> From: "Stark, Barbara" To: "Hemant Singh (shemant)" , "Suresh Krishnan" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 16:59:50.0767 (UTC) FILETIME=[EC2B0FF0:01C93AB0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The unnumbered model provides considerable scalability advantages in the access network of some service providers. I suspect that whether or not you choose to include it in the CPE router draft, the functionality to support this will be required and present in routers supplied by such service providers. Retail routers vendors will choose whether they want to provide routers that also have this function. As demonstrated by PPPoE (which is an informational RFC, and not a standard), service providers have no problem using solutions that make sense, whether or not the IETF blesses them as standards. And CPE vendors have no problem implementing these solutions, if it makes business sense. We also have a very strict requirement that routers not do router advertisement to the WAN. I continue not to see a problem with the unnumbered model. Barbara -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Thursday, October 30, 2008 11:31 AM To: Suresh Krishnan; IPv6 Operations Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? Folks, We never liked the Unnumbered model that was asked to be put in our CPE Rtr draft. Well, after this discussion a nail in the coffin for the Unnumbered model has been found. Due to this totally valid restriction in the DHCP-PD RFC3633, we need to remove the Unnumbered model from the CPE rtr draft. The reason is because in the Unnumbered model, an IPv6 address from the IA-PD was used for the source of upstream traffic to the Service Provider. Any comments? Thanks. Hemant & Wes -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Wednesday, October 22, 2008 11:42 AM To: David W. Hankins Cc: DHC WG Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD? Hi David, Thanks for your comments. Please find responses inline. David W. Hankins wrote: > On Fri, Oct 17, 2008 at 06:36:12PM -0400, Suresh Krishnan wrote: >> I read Ole's mail on v6ops as well, but I still do not see the=20 >> technical problem. I am running this setup currently and I am not seeing any issues. >> To narrow down my question, "what exactly breaks when we do this?" >=20 > It is an administrative question, not so much a technical one. Ack. I think this might be a good explanation for this restriction. >=20 > The PD client is a client, not representing the network administrator, > on the upstream-facing interface. It is inappropriate to make changes > to the network's management. If the network wished to give the client > additional addresses on that segment, the RA PIOs and/or IA_NA would=20 > already reflect that. >=20 > Having a delegated prefix does not grant the right to manage the=20 > upstream's network. >=20 >=20 > Note however that if the PD client was operating as a DHCPv6 server on > its upstream facing interface as well as advertising the delegated=20 > prefixes there, a recursion error would be present; a client on the=20 > upstream side may acheive a prefix delegation from a PD client on the=20 > same link, which in turn is a client of the upstream network, and so=20 > on. This was not my intent (to re-advertize the prefix upstream) but to just use a configured address. I realize now that pursuing this might be more trouble than it is worth. I am probably better off getting a DHCPv6 address or a SLAAC configured address on the upstream interface. Thanks Suresh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From owner-v6ops@ops.ietf.org Thu Oct 30 10:31:47 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA49A3A6A94 for ; Thu, 30 Oct 2008 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up6IUyy1qUG3 for ; Thu, 30 Oct 2008 10:31:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A48473A6A9E for ; Thu, 30 Oct 2008 10:30:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvbK9-000Lhc-0z for v6ops-data@psg.com; Thu, 30 Oct 2008 17:28:45 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvbJx-000LgV-V5 for v6ops@ops.ietf.org; Thu, 30 Oct 2008 17:28:39 +0000 X-IronPort-AV: E=Sophos;i="4.33,516,1220227200"; d="scan'208";a="26240535" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2008 17:28:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9UHSWO4020206; Thu, 30 Oct 2008 13:28:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9UHSWY5012740; Thu, 30 Oct 2008 17:28:32 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 13:28:32 -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 Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? Date: Thu, 30 Oct 2008 13:28:31 -0400 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0B738567@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Unnecessary restriction in DHCP-PD? Thread-Index: Ack0cI3lIyIj2ArGS0my8xPd8lblRwGMzgmwAALeIUAAATKF8A== References: <48F90EA3.6060409@ericsson.com> <48F9135C.70203@ericsson.com><20081017233401.GE5157@isc.org> <48FF49BE.60005@ericsson.com> <7582BC68E4994F4ABF0BD4723975C3FA0B738567@crexc41p> From: "Wes Beebee (wbeebee)" To: "Stark, Barbara" , "Hemant Singh (shemant)" , "Suresh Krishnan" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 17:28:32.0816 (UTC) FILETIME=[EE96E300:01C93AB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4508; t=1225387712; x=1226251712; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Unnecessary=20restriction=20i n=20DHCP-PD? |Sender:=20 |To:=20=22Stark,=20Barbara=22=20,=0A=20=20= 20=20=20=20=20=20=22Hemant=20Singh=20(shemant)=22=20,=0A=20=20=20=20=20=20=20=20=22Suresh=20Krishnan= 22=20,=0A=20=20=20=20=20=20=20 =20=22IPv6=20Operations=22=20; bh=Begvs9y3y4rFhq3EAELmoDKYhXzfSK34Z9cl1cPYO7I=; b=Jj1FL6oYky2aNKbg1t0I7479Ne1nyDGEi4gdoT3ZjXduu9IowrR9kzTbFT peu0PEYzklms7ZUj8o5cVtLmSlTNmIVBK7fdf4U1Quikh2A/8nIavho5u8Wm DqH7OIdZqv; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Barbara -=20 The key piece missing was that all traffic sourced from the LAN/Loopback interfaces must be considered to be off-link in both the Service Provider and CPE Router stacks or basic data forwarding breaks down. With this new information included, we have published an -03 CPE Router draft with the Unnumbered Model included. We will continue to include the Unnumbered Model until we find a show-stopper issue that would prevent any Service Provider from using it. - Wes & Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Stark, Barbara Sent: Thursday, October 30, 2008 1:00 PM To: Hemant Singh (shemant); Suresh Krishnan; IPv6 Operations Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? The unnumbered model provides considerable scalability advantages in the access network of some service providers. I suspect that whether or not you choose to include it in the CPE router draft, the functionality to support this will be required and present in routers supplied by such service providers. Retail routers vendors will choose whether they want to provide routers that also have this function. As demonstrated by PPPoE (which is an informational RFC, and not a standard), service providers have no problem using solutions that make sense, whether or not the IETF blesses them as standards. And CPE vendors have no problem implementing these solutions, if it makes business sense. We also have a very strict requirement that routers not do router advertisement to the WAN. I continue not to see a problem with the unnumbered model. Barbara -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Thursday, October 30, 2008 11:31 AM To: Suresh Krishnan; IPv6 Operations Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD? Folks, We never liked the Unnumbered model that was asked to be put in our CPE Rtr draft. Well, after this discussion a nail in the coffin for the Unnumbered model has been found. Due to this totally valid restriction in the DHCP-PD RFC3633, we need to remove the Unnumbered model from the CPE rtr draft. The reason is because in the Unnumbered model, an IPv6 address from the IA-PD was used for the source of upstream traffic to the Service Provider. Any comments? Thanks. Hemant & Wes -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Wednesday, October 22, 2008 11:42 AM To: David W. Hankins Cc: DHC WG Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD? Hi David, Thanks for your comments. Please find responses inline. David W. Hankins wrote: > On Fri, Oct 17, 2008 at 06:36:12PM -0400, Suresh Krishnan wrote: >> I read Ole's mail on v6ops as well, but I still do not see the=20 >> technical problem. I am running this setup currently and I am not seeing any issues. >> To narrow down my question, "what exactly breaks when we do this?" >=20 > It is an administrative question, not so much a technical one. Ack. I think this might be a good explanation for this restriction. >=20 > The PD client is a client, not representing the network administrator, > on the upstream-facing interface. It is inappropriate to make changes > to the network's management. If the network wished to give the client > additional addresses on that segment, the RA PIOs and/or IA_NA would=20 > already reflect that. >=20 > Having a delegated prefix does not grant the right to manage the=20 > upstream's network. >=20 >=20 > Note however that if the PD client was operating as a DHCPv6 server on > its upstream facing interface as well as advertising the delegated=20 > prefixes there, a recursion error would be present; a client on the=20 > upstream side may acheive a prefix delegation from a PD client on the=20 > same link, which in turn is a client of the upstream network, and so=20 > on. This was not my intent (to re-advertize the prefix upstream) but to just use a configured address. I realize now that pursuing this might be more trouble than it is worth. I am probably better off getting a DHCPv6 address or a SLAAC configured address on the upstream interface. Thanks Suresh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From owner-v6ops@ops.ietf.org Thu Oct 30 10:31:50 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C40E3A6951 for ; Thu, 30 Oct 2008 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THaCClE2Iqra for ; Thu, 30 Oct 2008 10:31:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E82453A6A8D for ; Thu, 30 Oct 2008 10:30:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvbKM-000Liz-EU for v6ops-data@psg.com; Thu, 30 Oct 2008 17:28:58 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvbKA-000Lho-Nu for v6ops@ops.ietf.org; Thu, 30 Oct 2008 17:28:52 +0000 X-IronPort-AV: E=Sophos;i="4.33,516,1220227200"; d="scan'208,217";a="26207126" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2008 17:28:45 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9UHSjTj002078 for ; Thu, 30 Oct 2008 13:28:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9UHSehf010042 for ; Thu, 30 Oct 2008 17:28:45 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 13:28:43 -0400 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_01C93AB4.F4EB1199" Subject: new version of the CPE Rtr draft is ready for review Date: Thu, 30 Oct 2008 13:28:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of the CPE Rtr draft is ready for review Thread-Index: Ack6tPTn74z3LBV0QLGtfA8Lbv8nYQ== From: "Hemant Singh (shemant)" To: "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 17:28:43.0900 (UTC) FILETIME=[F5322BC0:01C93AB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1238; t=1225387725; x=1226251725; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20new=20version=20of=20the=20CPE=20Rtr=20draft=20 is=20ready=20for=20review |Sender:=20 |To:=20=22IPv6=20Operations=22=20; bh=PKkoX8WG84c4tzcVmhZ32/WtRP7HY+Z1zODsEGWZYmI=; b=Mn01zS8UD7LI9iJxh9CQQLEDbiaHCcE+3Wwcuj6MJYFc1QcKzw7pT/0q2O jL2gY8CdGPdGeV9tHVbbTHToLc9xTSmo9NaPEaUBTr7i8cS24MDAUD7es9NC UqAY5zP7yR; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93AB4.F4EB1199 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt =20 Thanks. =20 Hemant & Wes ------_=_NextPart_001_01C93AB4.F4EB1199 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-route= r-03.txt
 
Thanks.
 
Hemant = &=20 Wes
------_=_NextPart_001_01C93AB4.F4EB1199-- From owner-v6ops@ops.ietf.org Thu Oct 30 10:47:59 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01483A6987 for ; Thu, 30 Oct 2008 10:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvg+aZnHJD1N for ; Thu, 30 Oct 2008 10:47:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A3C43A69D3 for ; Thu, 30 Oct 2008 10:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvbai-000NYP-Sx for v6ops-data@psg.com; Thu, 30 Oct 2008 17:45:52 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvbaH-000NTn-KE for v6ops@ops.ietf.org; Thu, 30 Oct 2008 17:45:30 +0000 X-IronPort-AV: E=Sophos;i="4.33,516,1220227200"; d="scan'208,217";a="98186248" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2008 17:45:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9UHjPxT023050 for ; Thu, 30 Oct 2008 10:45:25 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9UHjN1V019522 for ; Thu, 30 Oct 2008 17:45:24 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 13:45:24 -0400 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_01C93AB7.4971F5AD" Subject: RE: new version of the CPE Rtr draft is ready for review Date: Thu, 30 Oct 2008 13:45:24 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of the CPE Rtr draft is ready for review Thread-Index: Ack6tPTn74z3LBV0QLGtfA8Lbv8nYQAAGryA References: From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 17:45:24.0426 (UTC) FILETIME=[498E52A0:01C93AB7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8664; t=1225388725; x=1226252725; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20version=20of=20the=20CPE=20Rtr=20 draft=20is=20ready=20for=20review |Sender:=20; bh=dekxkNUM5rMajfOFBwvwqg6zPXLps+2h6vkU/uoL4T8=; b=gVdhLpVjiPPGnhfCg3r1eArBX9XVmLs/DH1K7CP58OZz1J+QsMqLTqnxbe tFw1optq01y5DdM5BmiagKVtrmP6s//0Udvlcnak+u5jcN5KK/UD6lkK2+2c 13HizYoBJf; Authentication-Results: sj-dkim-4; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93AB7.4971F5AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brief summary of what we closed with reviewers in this -03 version.=20 =20 1. Closed the new text in the mcast section with Remi - see new section in the -03 draft. =20 2. Closed with Francois-Xavier for null route with following text added to the IPv6 Data Forwarding section: =20 A route SHOULD be added to the routing table (to prevent routing loops) that is lower priority than any route except the default route. The choice to drop the packet or send an ICMPv6 Destination Unreachable to the source address of the packet is implementation- dependent. The installation of the null route MAY be automatic. Also closed on bridged mcast with following text: =20 If the CPE Router hardware includes a network bridge between the WAN interface and the LAN interface(s), then the CPE Router MUST support MLDv2 snooping as per [RFC4541]. =20 3. Closed with Shin Miyakawa with the following text: =20 Added following text to the end of the "Unnumbered Model" section: "The unnumbered model is incompatible with the strong host model on the CPE router. The unnumbered model may be inappropriate for use with certain broadband deployments where a device that uses the strong host model can operate as a CPE Router." =20 4. Fred Baker requested us to add an IPv4 section - we complied by adding a short IPv4 section that describes current practice but does not mandate anything. =20 5. Brian Carpenter was right. We added a 6to4 section to the draft - he had asked for such support at the beginning, =20 For other closures, please see the Change-log for this version. =20 Hemant & Wes ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Thursday, October 30, 2008 1:29 PM To: IPv6 Operations Subject: new version of the CPE Rtr draft is ready for review http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt =20 Thanks. =20 Hemant & Wes ------_=_NextPart_001_01C93AB7.4971F5AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brief summary of what we closed with reviewers = in this -03=20 version.
 
1. Closed the new text in the mcast section = with Remi - see=20 new section in the -03 draft.
 
2. Closed with Francois-Xavier for null = route with=20 following text added to the IPv6 Data Forwarding = section:
 
   A route SHOULD be added to the routing table (to = prevent=20 routing
   loops) that is lower priority than any route = except the=20 default
   route.  The choice to drop the packet or = send an=20 ICMPv6 Destination
   Unreachable to the source address of = the=20 packet is implementation-
   dependent.  The = installation of=20 the null route MAY be automatic.
   Also closed on bridged mcast with = following=20 text:
 
   If the CPE Router hardware includes a network = bridge between=20 the WAN
   interface and the LAN interface(s), then the CPE = Router=20 MUST support
   MLDv2 snooping as per=20 [RFC4541].
 
3. Closed with Shin Miyakawa with the = following=20 text:
 
      Added following text to the end = of the=20 "Unnumbered Model" section:
      "The = unnumbered=20 model is incompatible with the strong host=20 model
      on the CPE router.  The = unnumbered=20 model may be inappropriate for
      use = with=20 certain broadband deployments where a device that=20 uses
      the strong host model can operate = as a=20 CPE Router."
 
4. Fred Baker requested us to add an IPv4 = section - we=20 complied by adding a short IPv4 section that describes current = practice but does not mandate anything.
 
5.=20 Brian Carpenter was right.  We added a 6to4 section to the draft - = he had=20 asked for such support at the beginning,
 
For = other closures,=20 please see the Change-log for this = version.
 
Hemant & = Wes

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh=20 (shemant)
Sent: Thursday, October 30, 2008 1:29 = PM
To: IPv6=20 Operations
Subject: new version of the CPE Rtr draft is ready = for=20 review

http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-route= r-03.txt
 
Thanks.
 
Hemant = &=20 Wes
------_=_NextPart_001_01C93AB7.4971F5AD-- From owner-v6ops@ops.ietf.org Thu Oct 30 11:29:25 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E064728C160 for ; Thu, 30 Oct 2008 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.871 X-Spam-Level: X-Spam-Status: No, score=-4.871 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZExUYxN85CK for ; Thu, 30 Oct 2008 11:29:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D7253A694F for ; Thu, 30 Oct 2008 11:29:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvcDv-0001D0-Uz for v6ops-data@psg.com; Thu, 30 Oct 2008 18:26:23 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvcDn-0001CK-9V for v6ops@ops.ietf.org; Thu, 30 Oct 2008 18:26:18 +0000 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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9UIPxHT028269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 13:25:59 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9UIPxI5018165; Thu, 30 Oct 2008 13:25:59 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9UIPq8w017955; Thu, 30 Oct 2008 13:25:59 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 11:25:58 -0700 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_01C93ABC.F428F86D" Subject: RE: new version of the CPE Rtr draft is ready for review Date: Thu, 30 Oct 2008 11:25:57 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10525C966@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of the CPE Rtr draft is ready for review Thread-Index: Ack6tPTn74z3LBV0QLGtfA8Lbv8nYQAAGryAAAGpuqA= References: From: "Templin, Fred L" To: "Hemant Singh (shemant)" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 18:25:58.0385 (UTC) FILETIME=[F44EFE10:01C93ABC] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16248.003 X-TM-AS-Result: No--48.873700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93ABC.F428F86D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 8.6 is missing discussion on IPv6 transition mechanisms that may be needed to support IPv6 devices in IPv4-dominant SOHO networks - in particular, RFC5214 and probably also 'draft-templin-autoconf-dhcp'. =20 Fred fred.l.templin@boeing.com ________________________________ From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Thursday, October 30, 2008 10:45 AM To: Hemant Singh (shemant); IPv6 Operations Subject: RE: new version of the CPE Rtr draft is ready for review =09 =09 Brief summary of what we closed with reviewers in this -03 version.=20 =20 1. Closed the new text in the mcast section with Remi - see new section in the -03 draft. =20 2. Closed with Francois-Xavier for null route with following text added to the IPv6 Data Forwarding section: =20 A route SHOULD be added to the routing table (to prevent routing loops) that is lower priority than any route except the default route. The choice to drop the packet or send an ICMPv6 Destination Unreachable to the source address of the packet is implementation- dependent. The installation of the null route MAY be automatic. =09 Also closed on bridged mcast with following text: =20 If the CPE Router hardware includes a network bridge between the WAN interface and the LAN interface(s), then the CPE Router MUST support MLDv2 snooping as per [RFC4541]. =20 3. Closed with Shin Miyakawa with the following text: =20 Added following text to the end of the "Unnumbered Model" section: "The unnumbered model is incompatible with the strong host model on the CPE router. The unnumbered model may be inappropriate for use with certain broadband deployments where a device that uses the strong host model can operate as a CPE Router." =09 =20 4. Fred Baker requested us to add an IPv4 section - we complied by adding a short IPv4 section that describes current practice but does not mandate anything. =20 5. Brian Carpenter was right. We added a 6to4 section to the draft - he had asked for such support at the beginning, =20 For other closures, please see the Change-log for this version. =20 Hemant & Wes ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Thursday, October 30, 2008 1:29 PM To: IPv6 Operations Subject: new version of the CPE Rtr draft is ready for review =09 =09 =09 http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt =20 Thanks. =20 Hemant & Wes ------_=_NextPart_001_01C93ABC.F428F86D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Section 8.6 is missing discussion on IPv6 = transition=20 mechanisms that may be
needed to support IPv6 devices in IPv4-dominant = SOHO=20 networks - in particular,
RFC5214 and probably also=20 'draft-templin-autoconf-dhcp'.
 
Fred
fred.l.templin@boeing.com

From: Hemant Singh (shemant)=20 [mailto:shemant@cisco.com]
Sent: Thursday, October 30, 2008 = 10:45=20 AM
To: Hemant Singh (shemant); IPv6 = Operations
Subject:=20 RE: new version of the CPE Rtr draft is ready for = review

Brief summary of what we closed with = reviewers in this=20 -03 version.
 
1. Closed the new text in the mcast section = with Remi -=20 see new section in the -03 draft.
 
2. Closed with Francois-Xavier for null = route with=20 following text added to the IPv6 Data Forwarding = section:
 
   A route SHOULD be added to the routing table (to = prevent=20 routing
   loops) that is lower priority than any route = except=20 the default
   route.  The choice to drop the packet = or send=20 an ICMPv6 Destination
   Unreachable to the source = address of the=20 packet is implementation-
   dependent.  The = installation of=20 the null route MAY be automatic.
   Also closed on bridged mcast = with following=20 text:
 
   If the CPE Router hardware includes a network = bridge=20 between the WAN
   interface and the LAN interface(s), = then the=20 CPE Router MUST support
   MLDv2 snooping as per=20 [RFC4541].
 
3. Closed with Shin Miyakawa with = the following=20 text:
 
      Added following text to the = end of the=20 "Unnumbered Model" section:
      "The = unnumbered=20 model is incompatible with the strong host=20 model
      on the CPE router.  The=20 unnumbered model may be inappropriate = for
     =20 use with certain broadband deployments where a device that=20 uses
      the strong host model can = operate as a=20 CPE Router."
 
4. Fred Baker requested us to add an IPv4 = section - we=20 complied by adding a short IPv4 section that = describes current=20 practice but does not mandate anything.
 
5.=20 Brian Carpenter was right.  We added a 6to4 section to the draft = - he had=20 asked for such support at the beginning,
 
For = other closures,=20 please see the Change-log for this = version.
 
Hemant & = Wes

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh=20 (shemant)
Sent: Thursday, October 30, 2008 1:29 = PM
To:=20 IPv6 Operations
Subject: new version of the CPE Rtr draft is = ready=20 for review

http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-route= r-03.txt
 
Thanks.
 
Hemant &=20 Wes
------_=_NextPart_001_01C93ABC.F428F86D-- From owner-v6ops@ops.ietf.org Thu Oct 30 11:57:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206F33A6A68 for ; Thu, 30 Oct 2008 11:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.445 X-Spam-Level: X-Spam-Status: No, score=-5.445 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbDao1qgP0lw for ; Thu, 30 Oct 2008 11:57:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92BC53A6987 for ; Thu, 30 Oct 2008 11:57:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvcfQ-0003yG-G3 for v6ops-data@psg.com; Thu, 30 Oct 2008 18:54:48 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvcfI-0003wn-35 for v6ops@ops.ietf.org; Thu, 30 Oct 2008 18:54:44 +0000 X-IronPort-AV: E=Sophos;i="4.33,517,1220227200"; d="scan'208,217";a="26252626" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2008 18:54:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9UIsasX022769; Thu, 30 Oct 2008 14:54:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9UIsatj014927; Thu, 30 Oct 2008 18:54:36 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 14:54:36 -0400 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_01C93AC0.D68ADC0B" Subject: RE: new version of the CPE Rtr draft is ready for review Date: Thu, 30 Oct 2008 14:53:46 -0400 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10525C966@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of the CPE Rtr draft is ready for review Thread-Index: Ack6tPTn74z3LBV0QLGtfA8Lbv8nYQAAGryAAAGpuqAAAS1icA== References: <39C363776A4E8C4A94691D2BD9D1C9A10525C966@XCH-NW-7V2.nw.nos.boeing.com> From: "Hemant Singh (shemant)" To: "Templin, Fred L" , "IPv6 Operations" X-OriginalArrivalTime: 30 Oct 2008 18:54:36.0305 (UTC) FILETIME=[F444C810:01C93AC0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12968; t=1225392876; x=1226256876; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20version=20of=20the=20CPE=20Rtr=20 draft=20is=20ready=20for=20review |Sender:=20 |To:=20=22Templin,=20Fred=20L=22=20,=0A=20=20=20=20=20=20=20=20=22IPv6=20Operations=22=20; bh=9tDSqKSfiQ78J+R2jhnVpyKWsW6mpPNPzZ8e4qrp37U=; b=PVmCvZ+cc4QFhCU063VHcHbe3P+i5B9xuuWtANy2pKx3hx0rhToyB13e3T 5saotls3KeokzxxUBQY797ot4Ooc3ssJrrVdaAbevGLaaWMTw2YeeIPX1YyF +xLNSa5AL4; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93AC0.D68ADC0B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fred, =20 Thanks for the input. We'll add such data to the next version of our draft. =20 Hemant ________________________________ From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Thursday, October 30, 2008 2:26 PM To: Hemant Singh (shemant); IPv6 Operations Subject: RE: new version of the CPE Rtr draft is ready for review Section 8.6 is missing discussion on IPv6 transition mechanisms that may be needed to support IPv6 devices in IPv4-dominant SOHO networks - in particular, RFC5214 and probably also 'draft-templin-autoconf-dhcp'. =20 Fred fred.l.templin@boeing.com ________________________________ From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: Thursday, October 30, 2008 10:45 AM To: Hemant Singh (shemant); IPv6 Operations Subject: RE: new version of the CPE Rtr draft is ready for review =09 =09 Brief summary of what we closed with reviewers in this -03 version.=20 =20 1. Closed the new text in the mcast section with Remi - see new section in the -03 draft. =20 2. Closed with Francois-Xavier for null route with following text added to the IPv6 Data Forwarding section: =20 A route SHOULD be added to the routing table (to prevent routing loops) that is lower priority than any route except the default route. The choice to drop the packet or send an ICMPv6 Destination Unreachable to the source address of the packet is implementation- dependent. The installation of the null route MAY be automatic. =09 Also closed on bridged mcast with following text: =20 If the CPE Router hardware includes a network bridge between the WAN interface and the LAN interface(s), then the CPE Router MUST support MLDv2 snooping as per [RFC4541]. =20 3. Closed with Shin Miyakawa with the following text: =20 Added following text to the end of the "Unnumbered Model" section: "The unnumbered model is incompatible with the strong host model on the CPE router. The unnumbered model may be inappropriate for use with certain broadband deployments where a device that uses the strong host model can operate as a CPE Router." =09 =20 4. Fred Baker requested us to add an IPv4 section - we complied by adding a short IPv4 section that describes current practice but does not mandate anything. =20 5. Brian Carpenter was right. We added a 6to4 section to the draft - he had asked for such support at the beginning, =20 For other closures, please see the Change-log for this version. =20 Hemant & Wes ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Thursday, October 30, 2008 1:29 PM To: IPv6 Operations Subject: new version of the CPE Rtr draft is ready for review =09 =09 =09 http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt =20 Thanks. =20 Hemant & Wes ------_=_NextPart_001_01C93AC0.D68ADC0B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Fred,
 
Thanks for the input.  We'll add such=20 data to the next version of our = draft.
 
Hemant

From: Templin, Fred L=20 [mailto:Fred.L.Templin@boeing.com]
Sent: Thursday, October = 30, 2008=20 2:26 PM
To: Hemant Singh (shemant); IPv6 = Operations
Subject:=20 RE: new version of the CPE Rtr draft is ready for = review

Section 8.6 is missing discussion on IPv6 = transition=20 mechanisms that may be
needed to support IPv6 devices in IPv4-dominant = SOHO=20 networks - in particular,
RFC5214 and probably also=20 'draft-templin-autoconf-dhcp'.
 
Fred
fred.l.templin@boeing.com

From: Hemant Singh (shemant)=20 [mailto:shemant@cisco.com]
Sent: Thursday, October 30, 2008 = 10:45=20 AM
To: Hemant Singh (shemant); IPv6 = Operations
Subject:=20 RE: new version of the CPE Rtr draft is ready for = review

Brief summary of what we closed with = reviewers in this=20 -03 version.
 
1. Closed the new text in the mcast section = with Remi -=20 see new section in the -03 draft.
 
2. Closed with Francois-Xavier for null = route with=20 following text added to the IPv6 Data Forwarding = section:
 
   A route SHOULD be added to the routing table (to = prevent=20 routing
   loops) that is lower priority than any route = except=20 the default
   route.  The choice to drop the packet = or send=20 an ICMPv6 Destination
   Unreachable to the source = address of the=20 packet is implementation-
   dependent.  The = installation of=20 the null route MAY be automatic.
   Also closed on bridged mcast = with following=20 text:
 
   If the CPE Router hardware includes a network = bridge=20 between the WAN
   interface and the LAN interface(s), = then the=20 CPE Router MUST support
   MLDv2 snooping as per=20 [RFC4541].
 
3. Closed with Shin Miyakawa with = the following=20 text:
 
      Added following text to the = end of the=20 "Unnumbered Model" section:
      "The = unnumbered=20 model is incompatible with the strong host=20 model
      on the CPE router.  The=20 unnumbered model may be inappropriate = for
     =20 use with certain broadband deployments where a device that=20 uses
      the strong host model can = operate as a=20 CPE Router."
 
4. Fred Baker requested us to add an IPv4 = section - we=20 complied by adding a short IPv4 section that = describes current=20 practice but does not mandate anything.
 
5.=20 Brian Carpenter was right.  We added a 6to4 section to the draft = - he had=20 asked for such support at the beginning,
 
For = other closures,=20 please see the Change-log for this = version.
 
Hemant & = Wes

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Hemant Singh=20 (shemant)
Sent: Thursday, October 30, 2008 1:29 = PM
To:=20 IPv6 Operations
Subject: new version of the CPE Rtr draft is = ready=20 for review

http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-route= r-03.txt
 
Thanks.
 
Hemant &=20 Wes
------_=_NextPart_001_01C93AC0.D68ADC0B-- From owner-v6ops@ops.ietf.org Thu Oct 30 12:39:23 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68153A6951 for ; Thu, 30 Oct 2008 12:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 7MmyHui-CNGj for ; Thu, 30 Oct 2008 12:39:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC7083A6909 for ; Thu, 30 Oct 2008 12:39:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvdJV-0007w3-8w for v6ops-data@psg.com; Thu, 30 Oct 2008 19:36:13 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvdJL-0007vB-9V for v6ops@ops.ietf.org; Thu, 30 Oct 2008 19:36:06 +0000 Received: (qmail 10520 invoked by uid 1007); 30 Oct 2008 19:36:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=ZOClpVI7SvgzdZ/oIy/i6G+Q0LKuFDS4btSF6vKfbgeTLaNvDOYmnopiSC9tJoMz ; Date: Thu, 30 Oct 2008 20:36:01 +0100 From: Gert Doering To: "Stark, Barbara" Cc: "Hemant Singh \(shemant\)" , Suresh Krishnan , IPv6 Operations Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD? Message-ID: <20081030193601.GS21072@Space.Net> References: <48F90EA3.6060409@ericsson.com> <48FF49BE.60005@ericsson.com> <7582BC68E4994F4ABF0BD4723975C3FA0B738567@crexc41p> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0B738567@crexc41p> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Thu, Oct 30, 2008 at 12:59:42PM -0400, Stark, Barbara wrote: > I continue not to see a problem with the unnumbered model. Seconded. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 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 owner-v6ops@ops.ietf.org Thu Oct 30 19:30:03 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA08228C21A for ; Thu, 30 Oct 2008 19:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 Sdy6ZFRFOtQX for ; Thu, 30 Oct 2008 19:30:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C4363A69EC for ; Thu, 30 Oct 2008 19:30:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvjf8-000Hv5-4c for v6ops-data@psg.com; Fri, 31 Oct 2008 02:22:58 +0000 Received: from [209.85.198.233] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvjf1-000Hum-P3 for v6ops@ops.ietf.org; Fri, 31 Oct 2008 02:22:54 +0000 Received: by rv-out-0506.google.com with SMTP id b25so930237rvf.41 for ; Thu, 30 Oct 2008 19:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bACJTD8z6PfWLsEqjJNGTAu5kYhFibbEJsOEyUaLcqY=; b=Hj569hMiOV7RK33pgcyy9WkNje1BjeFwGoSMVPambeHU98njPWli89VdDumCnpgRmM OW08FFjkM8DePKbr37nGrX8lQWxHl4gbrVy8JUQxLMKzOFqBS0mTxWIMPrJIKKryOmYQ V+bj9K+FPhTWgqztA68HS9QB3gvKJO3sYjLow= 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=P9RWVY6NEmt12maAVy4CTnx2gGmWc30Y9Rc9Cac4JpsnDHdHh+iq3siT35pzHy6by7 kxRq4PiCSIR7PH0H38vUsgcqZsQ7DYZ+SNzAb+LBf1X0l/9Vunm/XWE81E7Zo6E43hUP 2AWPRQY5nrh4L2K3uxzWo+X4FaTpEXSG/e/8I= Received: by 10.140.163.12 with SMTP id l12mr6283321rve.137.1225419770587; Thu, 30 Oct 2008 19:22:50 -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 g31sm6169176rvb.7.2008.10.30.19.22.49 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Oct 2008 19:22:50 -0700 (PDT) Message-ID: <490A6BF6.10407@gmail.com> Date: Fri, 31 Oct 2008 15:22:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" CC: IPv6 Operations Subject: Re: new version of the CPE Rtr draft is ready for review References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Hemant, On 2008-10-31 06:45, Hemant Singh (shemant) wrote: ... > 5. Brian Carpenter was right. In general, or just this time ? ;-) > We added a 6to4 section to the draft - he > had asked for such support at the beginning, Thanks. Maybe you should refer to RFC3068 as well as RFC3056? Brian From owner-v6ops@ops.ietf.org Fri Oct 31 08:23:09 2008 Return-Path: X-Original-To: ietfarch-v6ops-archive@core3.amsl.com Delivered-To: ietfarch-v6ops-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857B33A6994 for ; Fri, 31 Oct 2008 08:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PteAEr32v5Pv for ; Fri, 31 Oct 2008 08:23:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D7143A67F3 for ; Fri, 31 Oct 2008 08:23:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvvl5-0009Ph-WB for v6ops-data@psg.com; Fri, 31 Oct 2008 15:17:56 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvvks-0009NK-9g for v6ops@ops.ietf.org; Fri, 31 Oct 2008 15:17:49 +0000 X-IronPort-AV: E=Sophos;i="4.33,523,1220227200"; d="scan'208";a="26357164" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2008 15:17:41 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9VFHedc005574; Fri, 31 Oct 2008 11:17:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9VFHe5B012053; Fri, 31 Oct 2008 15:17:40 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 11:17:40 -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 Subject: RE: new version of the CPE Rtr draft is ready for review Date: Fri, 31 Oct 2008 11:17:34 -0400 Message-ID: In-Reply-To: <490A6BF6.10407@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of the CPE Rtr draft is ready for review Thread-Index: Ack6/5R8JZzJGDYUS2yWTQQMdfKLKgAa69Aw References: <490A6BF6.10407@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" Cc: "IPv6 Operations" X-OriginalArrivalTime: 31 Oct 2008 15:17:40.0534 (UTC) FILETIME=[D0AD7D60:01C93B6B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=577; t=1225466261; x=1226330261; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20new=20version=20of=20the=20CPE=20Rtr=20 draft=20is=20ready=20for=20review |Sender:=20 |To:=20=22Brian=20E=20Carpenter=22=20; bh=GGl+AMD4XzPhyL4H+MawA6+fb7bp4dyM6dClmeR2G/k=; b=HxXf2AAKXpqJ3xDjwKr+aCU4qjGmNb9VhOsVu/QzmksL/i4Xzn5tfvolij k06z6EB2D0DPHXibqbt/yHmSZUhXJTHFrOfPQ8k3vyPwHSLSycRi5QCvtNBf 26sk3Gxz+A; Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: >> 5. Brian Carpenter was right. >In general, or just this time ? ;-) I meant this time, but in general also makes sense to me :-). >> We added a 6to4 section to the draft - he had asked for such support=20 >> at the beginning, >Thanks. Maybe you should refer to RFC3068 as well as RFC3056? Yes, that makes sense to include a reference to also RFC3068. We intend to publish the IP addresses (and section # etc.) of the anycast IPv4 (192.88.99.1) and IPv6 address (2002:c058:6301::) in our draft and then reference RFC3068. > Brian Thanks. Hemant