From v6ops-archive@ietf.org Thu Jul 1 06:59:56 2010 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 06F4B3A67B2 for ; Thu, 1 Jul 2010 06:59:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...rchive@ietf.org Pharmacy \256 Official Site -99%\n X-Spam-Flag: NO X-Spam-Score: -34.013 X-Spam-Level: X-Spam-Status: No, score=-34.013 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_H_PHARMACY=1, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_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 m-414mijQsYQ for ; Thu, 1 Jul 2010 06:59:54 -0700 (PDT) Received: from 118-167-198-225.dynamic.hinet.net (118-167-198-225.dynamic.hinet.net [118.167.198.225]) by core3.amsl.com (Postfix) with SMTP id 56A9D3A68DE for ; Thu, 1 Jul 2010 06:59:54 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org Pharmacy ® Official Site -99% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100701135954.56A9D3A68DE@core3.amsl.com> Date: Thu, 1 Jul 2010 06:59:54 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Fri Jul 2 05:34:53 2010 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 0D8483A635F for ; Fri, 2 Jul 2010 05:34:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -02%\n X-Spam-Flag: NO X-Spam-Score: -38.458 X-Spam-Level: X-Spam-Status: No, score=-38.458 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 xlvD0HOYLLAq for ; Fri, 2 Jul 2010 05:34:52 -0700 (PDT) Received: from ndoucoumane.wilane.net (ndoucoumane.wilane.net [91.121.170.26]) by core3.amsl.com (Postfix) with SMTP id A32353A67DA for ; Fri, 2 Jul 2010 05:34:50 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -02% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100702123450.A32353A67DA@core3.amsl.com> Date: Fri, 2 Jul 2010 05:34:50 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Sat Jul 3 05:41:43 2010 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 34C7128C0FC for ; Sat, 3 Jul 2010 05:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_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 EX3GFrxpFA-M for ; Sat, 3 Jul 2010 05:41:41 -0700 (PDT) Received: from agenda-asia.com (unknown [122.164.167.102]) by core3.amsl.com (Postfix) with SMTP id CFC2C3A69BD for ; Sat, 3 Jul 2010 05:41:11 -0700 (PDT) From: Google Pharmacy Subject: How MTV pulls off shock and draw To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100703124111.CFC2C3A69BD@core3.amsl.com> Date: Sat, 3 Jul 2010 05:41:11 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From rsvp-archiven@lists.ietf.org Sat Jul 3 06:18:56 2010 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 07A9B3A6800 for ; Sat, 3 Jul 2010 06:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.409 X-Spam-Level: ** X-Spam-Status: No, score=2.409 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_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 HaUGJyUfN8sG for ; Sat, 3 Jul 2010 06:18:54 -0700 (PDT) Received: from c-75-69-144-125.hsd1.ma.comcast.net (c-75-69-144-125.hsd1.ma.comcast.net [75.69.144.125]) by core3.amsl.com (Postfix) with SMTP id A1A663A67EE for ; Sat, 3 Jul 2010 06:18:52 -0700 (PDT) From: Google Pharmacy Subject: Aniston, Cox's strange diet To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100703131853.A1A663A67EE@core3.amsl.com> Date: Sat, 3 Jul 2010 06:18:52 -0700 (PDT)
Click here.

Dear v6ops-archive@lists.ietf.org
From owner-v6ops@ops.ietf.org Sat Jul 3 12:30:41 2010 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 CC4A93A68CC for ; Sat, 3 Jul 2010 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed4c4Pgvfa0w for ; Sat, 3 Jul 2010 12:30:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F9693A68B5 for ; Sat, 3 Jul 2010 12:30:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OV8Iu-0005qp-QJ for v6ops-data0@psg.com; Sat, 03 Jul 2010 19:23:08 +0000 Received: from n73.bullet.mail.sp1.yahoo.com ([98.136.44.191]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OV8In-0005ph-Vi for v6ops@ops.ietf.org; Sat, 03 Jul 2010 19:23:02 +0000 Received: from [216.252.122.216] by n73.bullet.mail.sp1.yahoo.com with NNFMP; 03 Jul 2010 19:23:01 -0000 Received: from [98.136.44.171] by t1.bullet.sp1.yahoo.com with NNFMP; 03 Jul 2010 19:23:01 -0000 Received: from [127.0.0.1] by omp612.mail.sp1.yahoo.com with NNFMP; 03 Jul 2010 19:23:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 475337.18765.bm@omp612.mail.sp1.yahoo.com Received: (qmail 41565 invoked by uid 60001); 3 Jul 2010 19:23:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278184981; bh=g7qqO1hF4rdy0/Ts8xArka4JxZgATHiOYfByDNhsFf8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SMV+Gy0wlSLkXGsjXrgeNE2rhstf8SWMZxZZiLSlh4ieE15AzSCzricKQ6eDdgxeg2ZewEUGjk0qVWWvhUCNs8oJQ07HsV4pcRiwVxXKopnSxjolKDDBTBJ7ouMPjh4YVItcyt1P62OMFFB6hQXNHKchbex1XTEa1g9X6RM+2JY= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OmLulKu2veeysscjzgl07lKJWNz9dmH/fkdBvIa0aVvtiBJnHwughIODi9olhqbVk8orBtmZKzz2I8DYpN9s2J4SlPr7VFbaB6vUKbkm0/tWdF2deNTkTwepXEHdPk4os1wCSR874O8rRZ6pKcONlVCdjyixJYgxQwqhMoBmny8=; Message-ID: <214571.41530.qm@web45501.mail.sp1.yahoo.com> X-YMail-OSG: _ujfXc0VM1l2gjcpzKhUHO08IKIlbCWA2MlY080DMYHRjxR RKIBXVdGp2ndQbBTGE_6XRO4wRGCUtEX6jW33zD1EjdCZI2oMKjO.njmeHIA JA2E8QFwjYccW2NrlBTxdKJIIA2kxwCawdsmgSd6Vszu9lZl0KI8qWWMY5Du 3o3f2aWa_jcOrrM63fF2bEjsFikWwW7qBXXd5s1p2ivosFHuIC1Q9g_ryJPX LyneYsxrqlHw0EeLKdWM2zgMojrWAWGQagNCWlyL84S_jsENIoYmv6sq8Fxo KcuNnpDNi5QZ8eG7CME._7MWm8jlJtRRM07Q- Received: from [85.64.216.120] by web45501.mail.sp1.yahoo.com via HTTP; Sat, 03 Jul 2010 12:23:01 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.274457 References: <1769D24B-6110-4C3D-A44E-D3AB3A83E98A@cisco.com> Date: Sat, 3 Jul 2010 12:23:01 -0700 (PDT) From: Gabi Nakibly Subject: draft-nakibly-v6ops-tunnel-loops as a WG item? (was Re: Agenda for 78th IETF) To: Fred Baker Cc: IPv6 Operations In-Reply-To: <1769D24B-6110-4C3D-A44E-D3AB3A83E98A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, =0AI=A0would like to propose the adoption of the =0Adraft=A0draft-nak= ibly-v6ops-tunnel-loops as a WG item. The draft documents=A0the =0Arouting = loop=A0attack=A0and mitigation measures and practices as=A0discussed on the= =0Alist.=A0I believe=A0that the document=A0contains=A0some useful informat= ion for network =0Aoperators who wishes to securely deploy IPv6 within an I= Pv4 network. The =0Adocument falls under goal #2 of the WG charter:=0A=0A= =A0=A0=A0 2. Publish Informational or BCP RFCs that identify potential secu= rity=0A=A0=A0=A0 risks in the operation of shared IPv4/IPv6 networks, and d= ocument=0A=A0=A0=A0 operational practices to eliminate or mitigate those ri= sks.=0A=0AI will=A0appreciate yours and the=A0list's=A0feedback.=0A=0ABest = regards,=0AGabi=0A=0A----- Original Message ----=0A> From: Fred Baker =0A> To: IPv6 Operations =0A> Sent: Mon, Jun= e 28, 2010 9:55:41 AM=0A> Subject: Agenda for 78th IETF=0A> =0A> I rather e= xpected to get requests for=0A> =0A> =A0 =A0 =A0 =A0 draft-sarikaya-v6ops-p= refix-delegation-01.txt=0A> =A0 =A0 =A0 =A0 draft-nakibly-v6ops-tunnel-loop= s-02.txt=0A> =A0 =A0 =A0 =A0 draft-korhonen-v6ops-3gpp-eps-03.txt=0A> =A0 = =A0 =A0 =A0 draft-ietf-v6ops-incremental-cgn-01.txt=0A> =0A> What I have is= the following.=0A> =0A> Those who want agenda time should please post draf= ts to support it and should =0A>let me know. We were in fact given two slot= s in the initial agenda. If things =0A>remain as they stand, I'll cut that = back to one.=0A> =0A> Begin forwarded message:=0A> =0A> > From: Fred Baker = =0A> > Date: June 24, 2010 5:33:31 AM PDT=0A> > To: IPv6 Op= erations =0A> > Subject: Agenda call=0A> > =0A> > Anyon= e who wants time, please drop me a note.=0A> > =0A> > Note that the Secreta= riat and IESG are currently struggling with the agenda, =0A>and we may very= well wind up with one slot instead of two. I want to give all =0A>the time= needed for discussions we need to have, and not waste time arguing for =0A= >the second slot if we won't actually use it. So I really need to know this= week.=0A> =0A> Begin forwarded message:=0A> =0A> > From: "Gunter Van de Ve= lde (gvandeve)" =0A> > Date: June 24, 2010 7:19:46 AM P= DT=0A> > To: "Fred Baker (fred)" , "IPv6 Operations" =0A>=0A> > Cc: "Ole Troan" , =0A> > Subject: RE: Agenda call=0A> > =0A> > Ole, Tim and myself would l= ike few minutes on the harmful tunnels work.=0A> > It is to be re-submitted= very soon.=0A> > =0A> > G/=0A> > =0A> =0A> =0A> Begin forwarded message:= =0A> =0A> > From: Rajeev Koodli =0A> > Date: June 24, 20= 10 5:51:55 AM PDT=0A> > To: Fred Baker =0A> > Subject: Re: = Agenda call=0A> > =0A> > =0A> > ------ Forwarded Message=0A> > From: Rajeev= Koodli =0A> > Date: Sat, 19 Jun 2010 18:09:06 -0700=0A>= > To: Fred Baker =0A> > Conversation: Looking for v6ops ag= enda items=0A> > Subject: Re: Looking for v6ops agenda items=0A> > =0A> > = =0A> > Hi Fred,=0A> > =0A> > I would like 10 minutes please. Depending on t= he "agenda density", I could=0A> > use 5 more minutes for Q&A.=0A> > =0A> >= draft-ietf-v6ops-v6-in-mobile-networks=0A> > =0A> > Thanks,=0A> > =0A> > -= Rajeev=0A> > =0A> Begin forwarded message:=0A> =0A> > From: "Gunter Van de = Velde (gvandeve)" =0A> > Date: June 24, 2010 7:22:15 AM= PDT=0A> > To: "Fred Baker (fred)" =0A> > Cc: "Tony Hain (a= hain)" , "Chip Popoviciu (cpopovic)" =0A>=0A> > Subject: RE: Agenda call=0A> > =0A> > Hi Fred,=0A> > =0A> > I wou= ld like to ask 10 minutes time to discuss "IP protocol=0A> > selection"... = its not a draft yet, but the idea is out there and I just=0A> > have to wri= te it down... should be done rather soon once I get to it.=0A> > =0A> > G/= =0A> Begin forwarded message:=0A> =0A> > From: =0A> > D= ate: June 27, 2010 11:39:30 AM PDT=0A> > To: =0A> > Cc: , =0A> > Subject: RE: Agenda ca= ll=0A> > =0A> > Fred,=0A> > =0A> > Tony Li, Marla Azinger and I would like = a few minutes to discuss a CIDR for =0A>IPv6 draft which is basically an up= date to RFC4632. It will be submitted to the =0A>list shortly. Either Marla= or I will be in attendance to present.=0A> > =0A> > Thanks,=0A> > =0A> > J= ason=0A> =0A> =0A> =0A=0A=0A From owner-v6ops@ops.ietf.org Sat Jul 3 15:49:15 2010 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 A80673A68A3 for ; Sat, 3 Jul 2010 15:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.295 X-Spam-Level: X-Spam-Status: No, score=-105.295 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, 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 pCVshNaHAiqf for ; Sat, 3 Jul 2010 15:49:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1386F3A6898 for ; Sat, 3 Jul 2010 15:49:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OVBRE-0001jN-7t for v6ops-data0@psg.com; Sat, 03 Jul 2010 22:43:56 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OVBRA-0001is-UO for v6ops@ops.ietf.org; Sat, 03 Jul 2010 22:43:53 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANRZL0yrRN+K/2dsb2JhbACfZXGkIJksglyCSQSDeIRC X-IronPort-AV: E=Sophos;i="4.53,532,1272844800"; d="scan'208";a="153503201" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 03 Jul 2010 22:43:51 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o63MgHKn024825; Sat, 3 Jul 2010 22:43:46 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Sat, 03 Jul 2010 15:43:51 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Sat, 03 Jul 2010 15:43:51 -0700 Subject: Re: draft-nakibly-v6ops-tunnel-loops as a WG item? (was Re: Agenda for 78th IETF) Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <214571.41530.qm@web45501.mail.sp1.yahoo.com> Date: Sat, 3 Jul 2010 15:43:46 -0700 Cc: Gabi Nakibly Message-Id: <3EBCAF7A-ACFC-4075-975B-CC502A3AD3EC@cisco.com> References: <1769D24B-6110-4C3D-A44E-D3AB3A83E98A@cisco.com> <214571.41530.qm@web45501.mail.sp1.yahoo.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Over to the list. Opinions? On Jul 3, 2010, at 12:23 PM, Gabi Nakibly wrote: > Fred,=20 > I would like to propose the adoption of the=20 > draft draft-nakibly-v6ops-tunnel-loops as a WG item. The draft = documents the=20 > routing loop attack and mitigation measures and practices as discussed = on the=20 > list. I believe that the document contains some useful information for = network=20 > operators who wishes to securely deploy IPv6 within an IPv4 network. = The=20 > document falls under goal #2 of the WG charter: >=20 > 2. Publish Informational or BCP RFCs that identify potential = security > risks in the operation of shared IPv4/IPv6 networks, and document > operational practices to eliminate or mitigate those risks. >=20 > I will appreciate yours and the list's feedback. >=20 > Best regards, > Gabi >=20 > ----- Original Message ---- >> From: Fred Baker >> To: IPv6 Operations >> Sent: Mon, June 28, 2010 9:55:41 AM >> Subject: Agenda for 78th IETF >>=20 >> I rather expected to get requests for >>=20 >> draft-sarikaya-v6ops-prefix-delegation-01.txt >> draft-nakibly-v6ops-tunnel-loops-02.txt >> draft-korhonen-v6ops-3gpp-eps-03.txt >> draft-ietf-v6ops-incremental-cgn-01.txt >>=20 >> What I have is the following. >>=20 >> Those who want agenda time should please post drafts to support it = and should=20 >> let me know. We were in fact given two slots in the initial agenda. = If things=20 >> remain as they stand, I'll cut that back to one. >>=20 >> Begin forwarded message: >>=20 >>> From: Fred Baker >>> Date: June 24, 2010 5:33:31 AM PDT >>> To: IPv6 Operations >>> Subject: Agenda call >>>=20 >>> Anyone who wants time, please drop me a note. >>>=20 >>> Note that the Secretariat and IESG are currently struggling with the = agenda,=20 >> and we may very well wind up with one slot instead of two. I want to = give all=20 >> the time needed for discussions we need to have, and not waste time = arguing for=20 >> the second slot if we won't actually use it. So I really need to know = this week. >>=20 >> Begin forwarded message: >>=20 >>> From: "Gunter Van de Velde (gvandeve)" >>> Date: June 24, 2010 7:19:46 AM PDT >>> To: "Fred Baker (fred)" , "IPv6 Operations"=20 >> >>> Cc: "Ole Troan" , >>> Subject: RE: Agenda call >>>=20 >>> Ole, Tim and myself would like few minutes on the harmful tunnels = work. >>> It is to be re-submitted very soon. >>>=20 >>> G/ >>>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Rajeev Koodli >>> Date: June 24, 2010 5:51:55 AM PDT >>> To: Fred Baker >>> Subject: Re: Agenda call >>>=20 >>>=20 >>> ------ Forwarded Message >>> From: Rajeev Koodli >>> Date: Sat, 19 Jun 2010 18:09:06 -0700 >>> To: Fred Baker >>> Conversation: Looking for v6ops agenda items >>> Subject: Re: Looking for v6ops agenda items >>>=20 >>>=20 >>> Hi Fred, >>>=20 >>> I would like 10 minutes please. Depending on the "agenda density", I = could >>> use 5 more minutes for Q&A. >>>=20 >>> draft-ietf-v6ops-v6-in-mobile-networks >>>=20 >>> Thanks, >>>=20 >>> -Rajeev >>>=20 >> Begin forwarded message: >>=20 >>> From: "Gunter Van de Velde (gvandeve)" >>> Date: June 24, 2010 7:22:15 AM PDT >>> To: "Fred Baker (fred)" >>> Cc: "Tony Hain (ahain)" , "Chip Popoviciu = (cpopovic)"=20 >> >>> Subject: RE: Agenda call >>>=20 >>> Hi Fred, >>>=20 >>> I would like to ask 10 minutes time to discuss "IP protocol >>> selection"... its not a draft yet, but the idea is out there and I = just >>> have to write it down... should be done rather soon once I get to = it. >>>=20 >>> G/ >> Begin forwarded message: >>=20 >>> From: >>> Date: June 27, 2010 11:39:30 AM PDT >>> To: >>> Cc: , >>> Subject: RE: Agenda call >>>=20 >>> Fred, >>>=20 >>> Tony Li, Marla Azinger and I would like a few minutes to discuss a = CIDR for=20 >> IPv6 draft which is basically an update to RFC4632. It will be = submitted to the=20 >> list shortly. Either Marla or I will be in attendance to present. >>>=20 >>> Thanks, >>>=20 >>> Jason >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From v6ops-archive@ietf.org Sun Jul 4 09:12:03 2010 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 E3C183A67B7 for ; Sun, 4 Jul 2010 09:12:03 -0700 (PDT) X-Quarantine-ID: <1X7Zk1B2Jk6D> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -93%\n X-Spam-Flag: NO X-Spam-Score: -33.385 X-Spam-Level: X-Spam-Status: No, score=-33.385 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 1X7Zk1B2Jk6D for ; Sun, 4 Jul 2010 09:12:02 -0700 (PDT) Received: from triband-mum-59.184.135.82.mtnl.net.in (triband-mum-59.184.135.82.mtnl.net.in [59.184.135.82]) by core3.amsl.com (Postfix) with SMTP id 935253A6452 for ; Sun, 4 Jul 2010 09:12:01 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -93% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100704161201.935253A6452@core3.amsl.com> Date: Sun, 4 Jul 2010 09:12:01 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Sun Jul 4 15:55:50 2010 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 47AB13A6781 for ; Sun, 4 Jul 2010 15:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.947 X-Spam-Level: X-Spam-Status: No, score=-7.947 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 ZHKGIZ8YTvpf for ; Sun, 4 Jul 2010 15:55:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 957D13A67CF for ; Sun, 4 Jul 2010 15:55:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OVXz3-0007i1-Lh for v6ops-data0@psg.com; Sun, 04 Jul 2010 22:48:21 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OVXyy-0007hL-Il for v6ops@ops.ietf.org; Sun, 04 Jul 2010 22:48:17 +0000 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,537,1272844800"; d="scan'208";a="340981389" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Jul 2010 22:48:15 +0000 Received: from iwan-view2.cisco.com (iwan-view2.cisco.com [171.70.65.8]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o64MmFb4007431; Sun, 4 Jul 2010 22:48:15 GMT Received: from ams-townsley-8711.cisco.com (ams-townsley-8711.cisco.com [10.55.233.226]) by iwan-view2.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o64MmDH00827; Sun, 4 Jul 2010 15:48:14 -0700 (PDT) Message-ID: <4C310FA6.8080004@cisco.com> Date: Mon, 05 Jul 2010 00:48:06 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations , Gabi Nakibly Subject: Re: draft-nakibly-v6ops-tunnel-loops as a WG item? (was Re: Agenda for 78th IETF) References: <1769D24B-6110-4C3D-A44E-D3AB3A83E98A@cisco.com> <214571.41530.qm@web45501.mail.sp1.yahoo.com> <3EBCAF7A-ACFC-4075-975B-CC502A3AD3EC@cisco.com> In-Reply-To: <3EBCAF7A-ACFC-4075-975B-CC502A3AD3EC@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: It is important to document all issues, good and bad, with automatic tunneling, and we found Gabi's analysis useful with 6rd. As such, I support it becoming a WG document. However, one thing that is missing here is a sufficient discussion of the operational environment for which the automatic mechanisms mentioned are targeted or are deployed today. For example, 6rd is targeted at a certain domain of operation within an SP network, ISATAP is more commonly found within enterprise deployments, etc. As such, if we publish this as an IETF work, I think it at least needs a clear mention that such operational domain considerations are not a part of the analysis, or an expansion of scope to include them. Also, the real threat of tunnel loops is dependent upon where the loops can be launched and sustained (some loops are bad, some don't really matter), and other mitigations may exist outside of those described in the document when deploying an automatic tunneling mechanism that is not reachable on the open Internet. As for the mitigation recommendations described in the document, some are borderline protocol modifications (as they recommend filtering techniques beyond what is typically configurable by standard ACLs), and as such could be stepping out of charter a bit for v6ops. I would be far more comfortable with an Informational target with no normative text (and no text suggesting what kind of "simple" checks a router "can" do, but rather text suggesting what a router "could" in the event that some other router fails to do something else...). - Mark On 7/4/10 12:43 AM, Fred Baker wrote: > Over to the list. Opinions? > > On Jul 3, 2010, at 12:23 PM, Gabi Nakibly wrote: > >> Fred, >> I would like to propose the adoption of the >> draft draft-nakibly-v6ops-tunnel-loops as a WG item. The draft documents the >> routing loop attack and mitigation measures and practices as discussed on the >> list. I believe that the document contains some useful information for network >> operators who wishes to securely deploy IPv6 within an IPv4 network. The >> document falls under goal #2 of the WG charter: >> >> 2. Publish Informational or BCP RFCs that identify potential security >> risks in the operation of shared IPv4/IPv6 networks, and document >> operational practices to eliminate or mitigate those risks. >> >> I will appreciate yours and the list's feedback. >> >> Best regards, >> Gabi >> >> ----- Original Message ---- >>> From: Fred Baker >>> To: IPv6 Operations >>> Sent: Mon, June 28, 2010 9:55:41 AM >>> Subject: Agenda for 78th IETF >>> >>> I rather expected to get requests for >>> >>> draft-sarikaya-v6ops-prefix-delegation-01.txt >>> draft-nakibly-v6ops-tunnel-loops-02.txt >>> draft-korhonen-v6ops-3gpp-eps-03.txt >>> draft-ietf-v6ops-incremental-cgn-01.txt >>> >>> What I have is the following. >>> >>> Those who want agenda time should please post drafts to support it and should >>> let me know. We were in fact given two slots in the initial agenda. If things >>> remain as they stand, I'll cut that back to one. >>> >>> Begin forwarded message: >>> >>>> From: Fred Baker >>>> Date: June 24, 2010 5:33:31 AM PDT >>>> To: IPv6 Operations >>>> Subject: Agenda call >>>> >>>> Anyone who wants time, please drop me a note. >>>> >>>> Note that the Secretariat and IESG are currently struggling with the agenda, >>> and we may very well wind up with one slot instead of two. I want to give all >>> the time needed for discussions we need to have, and not waste time arguing for >>> the second slot if we won't actually use it. So I really need to know this week. >>> >>> Begin forwarded message: >>> >>>> From: "Gunter Van de Velde (gvandeve)" >>>> Date: June 24, 2010 7:19:46 AM PDT >>>> To: "Fred Baker (fred)" , "IPv6 Operations" >>> >>>> Cc: "Ole Troan" , >>>> Subject: RE: Agenda call >>>> >>>> Ole, Tim and myself would like few minutes on the harmful tunnels work. >>>> It is to be re-submitted very soon. >>>> >>>> G/ >>>> >>> >>> >>> Begin forwarded message: >>> >>>> From: Rajeev Koodli >>>> Date: June 24, 2010 5:51:55 AM PDT >>>> To: Fred Baker >>>> Subject: Re: Agenda call >>>> >>>> >>>> ------ Forwarded Message >>>> From: Rajeev Koodli >>>> Date: Sat, 19 Jun 2010 18:09:06 -0700 >>>> To: Fred Baker >>>> Conversation: Looking for v6ops agenda items >>>> Subject: Re: Looking for v6ops agenda items >>>> >>>> >>>> Hi Fred, >>>> >>>> I would like 10 minutes please. Depending on the "agenda density", I could >>>> use 5 more minutes for Q&A. >>>> >>>> draft-ietf-v6ops-v6-in-mobile-networks >>>> >>>> Thanks, >>>> >>>> -Rajeev >>>> >>> Begin forwarded message: >>> >>>> From: "Gunter Van de Velde (gvandeve)" >>>> Date: June 24, 2010 7:22:15 AM PDT >>>> To: "Fred Baker (fred)" >>>> Cc: "Tony Hain (ahain)" , "Chip Popoviciu (cpopovic)" >>> >>>> Subject: RE: Agenda call >>>> >>>> Hi Fred, >>>> >>>> I would like to ask 10 minutes time to discuss "IP protocol >>>> selection"... its not a draft yet, but the idea is out there and I just >>>> have to write it down... should be done rather soon once I get to it. >>>> >>>> G/ >>> Begin forwarded message: >>> >>>> From: >>>> Date: June 27, 2010 11:39:30 AM PDT >>>> To: >>>> Cc: , >>>> Subject: RE: Agenda call >>>> >>>> Fred, >>>> >>>> Tony Li, Marla Azinger and I would like a few minutes to discuss a CIDR for >>> IPv6 draft which is basically an update to RFC4632. It will be submitted to the >>> list shortly. Either Marla or I will be in attendance to present. >>>> >>>> Thanks, >>>> >>>> Jason >>> >>> >>> >> >> >> >> > > http://www.ipinc.net/IPv4.GIF > > > From v6ops-archive@ietf.org Sun Jul 4 20:07:42 2010 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 B03093A67CC for ; Sun, 4 Jul 2010 20:07:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -49%\n X-Spam-Flag: NO X-Spam-Score: -17.198 X-Spam-Level: X-Spam-Status: No, score=-17.198 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 XvAQ7TiNpIca for ; Sun, 4 Jul 2010 20:07:41 -0700 (PDT) Received: from 59-115-103-195.dynamic.hinet.net (59-115-103-195.dynamic.hinet.net [59.115.103.195]) by core3.amsl.com (Postfix) with SMTP id 356E83A6407 for ; Sun, 4 Jul 2010 20:07:41 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -49% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100705030741.356E83A6407@core3.amsl.com> Date: Sun, 4 Jul 2010 20:07:41 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Mon Jul 5 15:52:34 2010 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 B40673A6782 for ; Mon, 5 Jul 2010 15:52:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -80%\n X-Spam-Flag: NO X-Spam-Score: -9.423 X-Spam-Level: X-Spam-Status: No, score=-9.423 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 cSSKgQeD7nFC for ; Mon, 5 Jul 2010 15:52:33 -0700 (PDT) Received: from 201-1-116-173.dsl.telesp.net.br (201-1-116-173.dsl.telesp.net.br [201.1.116.173]) by core3.amsl.com (Postfix) with SMTP id 136813A684E for ; Mon, 5 Jul 2010 15:52:32 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -80% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100705225233.136813A684E@core3.amsl.com> Date: Mon, 5 Jul 2010 15:52:32 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Mon Jul 5 19:57:29 2010 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 532323A6A0E for ; Mon, 5 Jul 2010 19:57:29 -0700 (PDT) X-Quarantine-ID: <8pnLIJHxMNrX> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...rchive@ietf.org Pharmacy \256 Official Site -42%\n X-Spam-Flag: NO X-Spam-Score: -20.625 X-Spam-Level: X-Spam-Status: No, score=-20.625 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 8pnLIJHxMNrX for ; Mon, 5 Jul 2010 19:57:28 -0700 (PDT) Received: from ABCDEFGHIJKLMNOPQRSTUVWXYZ01.cngogo.org (unknown [114.32.121.2]) by core3.amsl.com (Postfix) with SMTP id CE15C3A6A0D for ; Mon, 5 Jul 2010 19:57:27 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org Pharmacy ® Official Site -42% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100706025727.CE15C3A6A0D@core3.amsl.com> Date: Mon, 5 Jul 2010 19:57:27 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner@megatron.ietf.org Mon Jul 5 22:43:23 2010 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 1B24C3A6A1E for ; Mon, 5 Jul 2010 22:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.668 X-Spam-Level: X-Spam-Status: No, score=-11.668 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_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 TnJBeMAd4amY for ; Mon, 5 Jul 2010 22:43:21 -0700 (PDT) Received: from abs-cbn.com (unknown [125.162.125.149]) by core3.amsl.com (Postfix) with SMTP id 3FC503A6949 for ; Mon, 5 Jul 2010 22:43:09 -0700 (PDT) From: Google Pharmacy Subject: How MTV pulls off shock and draw To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100706054318.3FC503A6949@core3.amsl.com> Date: Mon, 5 Jul 2010 22:43:09 -0700 (PDT)
Click here.

Dear v6ops-archive@megatron.ietf.org
From owner-v6ops@ops.ietf.org Mon Jul 5 23:26:18 2010 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 734D03A687C for ; Mon, 5 Jul 2010 23:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.913 X-Spam-Level: X-Spam-Status: No, score=-100.913 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO1qjWxk6TKw for ; Mon, 5 Jul 2010 23:26:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B7E23A6A24 for ; Mon, 5 Jul 2010 23:26:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OW1Vf-000OOQ-7o for v6ops-data0@psg.com; Tue, 06 Jul 2010 06:19:59 +0000 Received: from [2001:14b8:400::130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OW1Vc-000ONy-N1 for v6ops@ops.ietf.org; Tue, 06 Jul 2010 06:19:57 +0000 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A52D12CED4 for ; Tue, 6 Jul 2010 09:19:55 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihU-8Zya7an3 for ; Tue, 6 Jul 2010 09:19:55 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id ED13E2CC62 for ; Tue, 6 Jul 2010 09:19:54 +0300 (EEST) Message-ID: <4C32CB0A.4090107@piuha.net> Date: Tue, 06 Jul 2010 09:19:54 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: 'IPv6 Operations' Subject: FW: I-D Action:draft-arkko-ipv6-only-experience-00.txt References: <20100705220002.05D7C3A659A@core3.amsl.com> In-Reply-To: <20100705220002.05D7C3A659A@core3.amsl.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: FYI

Internet-Drafts@ietf.org kirjoitti: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Experiences from an IPv6-Only Network
	Author(s)       : J. Arkko, A. Keranen
	Filename        : draft-arkko-ipv6-only-experience-00.txt
	Pages           : 17
	Date            : 2010-07-05

This document discusses our experiences from moving a small number of
users to an IPv6-only network, with access to the IPv4-only parts of
the Internet via a NAT64 device.  The document covers practical
experiences as well as road blocks and opportunities for this type of
a network setup.  The document also makes some recommendations about
where such networks are applicable and what should be taken into
account in the network design.  The document also discusses further
work that is needed to make IPv6-only networking applicable in all
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arkko-ipv6-only-experience-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.
  

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From owner-v6ops@ops.ietf.org Tue Jul 6 07:51:47 2010 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 A29C73A67C2 for ; Tue, 6 Jul 2010 07:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2jggmk5BzFh for ; Tue, 6 Jul 2010 07:51:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCA983A68B8 for ; Tue, 6 Jul 2010 07:51:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OW9PC-000K7l-6D for v6ops-data0@psg.com; Tue, 06 Jul 2010 14:45:50 +0000 Received: from n71.bullet.mail.sp1.yahoo.com ([98.136.44.36]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OW9P7-000K7F-Di for v6ops@ops.ietf.org; Tue, 06 Jul 2010 14:45:46 +0000 Received: from [69.147.84.145] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 06 Jul 2010 14:45:44 -0000 Received: from [98.136.44.162] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 06 Jul 2010 14:45:44 -0000 Received: from [127.0.0.1] by omp603.mail.sp1.yahoo.com with NNFMP; 06 Jul 2010 14:45:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 843481.72913.bm@omp603.mail.sp1.yahoo.com Received: (qmail 66073 invoked by uid 60001); 6 Jul 2010 14:45:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278427544; bh=9SAT4CfnLZIgF3JSjbmKdnHRdQD14rlFWOf/aNDgFzI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3o0F58NkC93NfTGyvqk9g7J7vvbew0+MjX0ohkyOy46yBXUHsjxJ4AcGvmgv7KGPxRMuIw2CcLZO3k7vuQiI31JO8jdqL2ewoG2Puqgd3GpSe2CPsq9CjADA3LT3u0RwuFiUK364pfTsZBXg9NvJ0KJFD90RLOHNk89dOw0vZbc= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vJzG6+vcTLSHn8upIWeUxBMSx8vNBKwNs1niCbwnRMJP+a6uQ5/NmagjNEKHj4CYE4nbf9zczz9kQ8Fvbri7xPj8KHHsjaB1yeWU453e/qvleGQLobRDhX/VmrDFgaxYyCAkQe+f9mdJt0MNeeuoOn6nwztHVcb/9drBhZZwB6M=; Message-ID: <694152.61987.qm@web45516.mail.sp1.yahoo.com> X-YMail-OSG: zp01qrAVM1kvypDjcHiRhRR4VenP74Bw_kF6zZueDxDLYcQ 2aQLGdNLJ3ZcNSYlahb5r0fDMkBgyAYhD1oBqi8eNVfqbzikRK..O5Si3xwn 50jz_m5N0RnOjk7kP2japxY6.O1_dq6O.MbxCPeoYIcHwuG6oaKPbW14Lyxm KXhpjS97UKDLs01uGv74R.ip_NmxDzvjnlcqnJfJoPk98IbJhmpj3K3XW6XB ZmiFFEOu.FSaeE.Te6pKJ0DGYDtVauItEMywDJ2yx7PJuEqDdWzBkd5IA4Y3 uK_D9F.JA3VwuFQfEDzl6IHIhMEup9X2SFnQ- Received: from [85.64.216.89] by web45516.mail.sp1.yahoo.com via HTTP; Tue, 06 Jul 2010 07:45:44 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.274457 References: <1769D24B-6110-4C3D-A44E-D3AB3A83E98A@cisco.com> <214571.41530.qm@web45501.mail.sp1.yahoo.com> <3EBCAF7A-ACFC-4075-975B-CC502A3AD3EC@cisco.com> <4C310FA6.8080004@cisco.com> Date: Tue, 6 Jul 2010 07:45:44 -0700 (PDT) From: Gabi Nakibly Subject: Re: draft-nakibly-v6ops-tunnel-loops as a WG item? (was Re: Agenda for 78th IETF) To: Mark Townsley , Fred Baker Cc: IPv6 Operations In-Reply-To: <4C310FA6.8080004@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark,=0AThanks for the input. I'll be sure to address it in the next versio= n.=0A=0AGabi=A0=0A=0A=0A=0A----- Original Message ----=0A> From: Mark Towns= ley =0A> To: Fred Baker =0A> Cc: IPv6 O= perations ; Gabi Nakibly =0A> Sent:= Mon, July 5, 2010 1:48:06 AM=0A> Subject: Re: draft-nakibly-v6ops-tunnel-l= oops as a WG item? (was Re: Agenda for =0A>78th IETF)=0A> =0A> =0A> It is i= mportant to document all issues, good and bad, with automatic=0A> tunneling= , and we found Gabi's analysis useful with 6rd. As such, I=0A> support it b= ecoming a WG document.=0A> =0A> However, one thing that is missing here is = a sufficient discussion of=0A> the operational environment for which the au= tomatic mechanisms mentioned=0A> are targeted or are deployed today. For ex= ample, 6rd is targeted at a=0A> certain domain of operation within an SP ne= twork, ISATAP is more=0A> commonly found within enterprise deployments, etc= . As such, if we=0A> publish this as an IETF work, I think it at least need= s a clear mention=0A> that such operational domain considerations are not a= part of the=0A> analysis, or an expansion of scope to include them. Also, = the real=0A> threat of tunnel loops is dependent upon where the loops can b= e launched=0A> and sustained (some loops are bad, some don't really matter)= , and other=0A> mitigations may exist outside of those described in the doc= ument when=0A> deploying an automatic tunneling mechanism that is not reach= able on the=0A> open Internet.=0A> =0A> As for the mitigation recommendatio= ns described in the document, some=0A> are borderline protocol modification= s (as they recommend filtering=0A> techniques beyond what is typically conf= igurable by standard ACLs), and=0A> as such could be stepping out of charte= r a bit for v6ops. I would be far=0A> more comfortable with an Informationa= l target with no normative text=0A> (and no text suggesting what kind of "s= imple" checks a router "can" do,=0A> but rather text suggesting what a rout= er "could" in the event that some=0A> other router fails to do something el= se...).=0A> =0A> - Mark=0A> =0A> =0A> On 7/4/10 12:43 AM, Fred Baker wrote:= =0A> > Over to the list. Opinions?=0A> > =0A> > On Jul 3, 2010, at 12:23 PM= , Gabi Nakibly wrote:=0A> > =0A> >> Fred, =0A> >> I would like to propose t= he adoption of the =0A> >> draft draft-nakibly-v6ops-tunnel-loops as a WG i= tem. The draft documents the =0A>=0A> >> routing loop attack and mitigation= measures and practices as discussed on =0A>the =0A>=0A> >> list. I believe= that the document contains some useful information for =0A>network =0A>=0A= > >> operators who wishes to securely deploy IPv6 within an IPv4 network. T= he =0A> >> document falls under goal #2 of the WG charter:=0A> >>=0A> >>=A0= =A0 2. Publish Informational or BCP RFCs that identify potential security= =0A> >>=A0 =A0 risks in the operation of shared IPv4/IPv6 networks, and doc= ument=0A> >>=A0 =A0 operational practices to eliminate or mitigate those ri= sks.=0A> >>=0A> >> I will appreciate yours and the list's feedback.=0A> >>= =0A> >> Best regards,=0A> >> Gabi=0A> >>=0A> >> ----- Original Message ----= =0A> >>> From: Fred Baker =0A> >>> To: IPv6 Operations =0A> >>> Sent: Mon, June 28, 2010 9:55:41 AM=0A> >>> Subjec= t: Agenda for 78th IETF=0A> >>>=0A> >>> I rather expected to get requests f= or=0A> >>>=0A> >>>=A0 =A0 =A0 =A0 draft-sarikaya-v6ops-prefix-delegation-01= .txt=0A> >>>=A0 =A0 =A0 =A0 draft-nakibly-v6ops-tunnel-loops-02.txt=0A> >>>= =A0 =A0 =A0 =A0 draft-korhonen-v6ops-3gpp-eps-03.txt=0A> >>>=A0 =A0 =A0 =A0= draft-ietf-v6ops-incremental-cgn-01.txt=0A> >>>=0A> >>> What I have is the= following.=0A> >>>=0A> >>> Those who want agenda time should please post d= rafts to support it and =0A>should =0A>=0A> >>> let me know. We were in fac= t given two slots in the initial agenda. If =0A>things =0A>=0A> >>> remain = as they stand, I'll cut that back to one.=0A> >>>=0A> >>> Begin forwarded m= essage:=0A> >>>=0A> >>>> From: Fred Baker =0A> >>>> Date: J= une 24, 2010 5:33:31 AM PDT=0A> >>>> To: IPv6 Operations =0A> >>>> Subject: Agenda call=0A> >>>>=0A> >>>> Anyone who wants time, p= lease drop me a note.=0A> >>>>=0A> >>>> Note that the Secretariat and IESG = are currently struggling with the =0A>agenda, =0A>=0A> >>> and we may very = well wind up with one slot instead of two. I want to give =0A>all =0A>=0A> = >>> the time needed for discussions we need to have, and not waste time arg= uing =0A>for =0A>=0A> >>> the second slot if we won't actually use it. So I= really need to know this =0A>week.=0A> >>>=0A> >>> Begin forwarded message= :=0A> >>>=0A> >>>> From: "Gunter Van de Velde (gvandeve)" =0A> >>>> Date: June 24, 2010 7:19:46 AM PDT=0A> >>>> To: "Fred Baker (f= red)" , "IPv6 Operations" =0A> >>> =0A>= >>>> Cc: "Ole Troan" , =0A> >>>> Subjec= t: RE: Agenda call=0A> >>>>=0A> >>>> Ole, Tim and myself would like few min= utes on the harmful tunnels work.=0A> >>>> It is to be re-submitted very so= on.=0A> >>>>=0A> >>>> G/=0A> >>>>=0A> >>>=0A> >>>=0A> >>> Begin forwarded m= essage:=0A> >>>=0A> >>>> From: Rajeev Koodli =0A> >>>> D= ate: June 24, 2010 5:51:55 AM PDT=0A> >>>> To: Fred Baker = =0A> >>>> Subject: Re: Agenda call=0A> >>>>=0A> >>>>=0A> >>>> ------ Forwar= ded Message=0A> >>>> From: Rajeev Koodli =0A> >>>> Date:= Sat, 19 Jun 2010 18:09:06 -0700=0A> >>>> To: Fred Baker = =0A> >>>> Conversation: Looking for v6ops agenda items=0A> >>>> Subject: Re= : Looking for v6ops agenda items=0A> >>>>=0A> >>>>=0A> >>>> Hi Fred,=0A> >>= >>=0A> >>>> I would like 10 minutes please. Depending on the "agenda densit= y", I =0Acould=0A> >>>> use 5 more minutes for Q&A.=0A> >>>>=0A> >>>> draft= -ietf-v6ops-v6-in-mobile-networks=0A> >>>>=0A> >>>> Thanks,=0A> >>>>=0A> >>= >> -Rajeev=0A> >>>>=0A> >>> Begin forwarded message:=0A> >>>=0A> >>>> From:= "Gunter Van de Velde (gvandeve)" =0A> >>>> Date: June = 24, 2010 7:22:15 AM PDT=0A> >>>> To: "Fred Baker (fred)" = =0A> >>>> Cc: "Tony Hain (ahain)" , "Chip Popoviciu (cpopo= vic)" =0A> >>> =0A> >>>> Subject: RE: Agenda call=0A> >= >>>=0A> >>>> Hi Fred,=0A> >>>>=0A> >>>> I would like to ask 10 minutes time= to discuss "IP protocol=0A> >>>> selection"... its not a draft yet, but th= e idea is out there and I just=0A> >>>> have to write it down... should be = done rather soon once I get to it.=0A> >>>>=0A> >>>> G/=0A> >>> Begin forwa= rded message:=0A> >>>=0A> >>>> From: =0A> >>>> Date: Ju= ne 27, 2010 11:39:30 AM PDT=0A> >>>> To: =0A> >>>> Cc: , =0A> >>>> Subject: RE: Agenda = call=0A> >>>>=0A> >>>> Fred,=0A> >>>>=0A> >>>> Tony Li, Marla Azinger and I= would like a few minutes to discuss a CIDR =0A>for =0A>=0A> >>> IPv6 draft= which is basically an update to RFC4632. It will be submitted to =0A>the = =0A>=0A> >>> list shortly. Either Marla or I will be in attendance to prese= nt.=0A> >>>>=0A> >>>> Thanks,=0A> >>>>=0A> >>>> Jason=0A> >>>=0A> >>>=0A> >= >>=0A> >>=0A> >>=0A> >>=0A> >>=0A> > =0A> > http://www.ipinc.net/IPv4.GIF= =0A> > =0A> > =0A> > =0A> =0A> =0A> =0A=0A=0A From owner-v6ops@ops.ietf.org Tue Jul 6 08:43:35 2010 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 2312A3A65A6 for ; Tue, 6 Jul 2010 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.895 X-Spam-Level: X-Spam-Status: No, score=-106.895 tagged_above=-999 required=5 tests=[AWL=1.600, 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 DIp9KZJmQhPX for ; Tue, 6 Jul 2010 08:43:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E8CD3A63C9 for ; Tue, 6 Jul 2010 08:43:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OWAHR-0002pz-21 for v6ops-data0@psg.com; Tue, 06 Jul 2010 15:41:53 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OWAHM-0002pN-UV for v6ops@ops.ietf.org; Tue, 06 Jul 2010 15:41:49 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB/sMkyrRN+K/2dsb2JhbACgB3GmTppLhSUEg3iEQg X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="scan'208";a="555076728" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2010 15:41:47 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o66FfeHr009785 for ; Tue, 6 Jul 2010 15:41:42 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Tue, 06 Jul 2010 08:41:47 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Tue, 06 Jul 2010 08:41:47 -0700 From: Fred Baker Subject: BBF Liaison to IETF Date: Tue, 6 Jul 2010 08:41:34 -0700 Message-Id: <2750C967-FB70-48CF-9B03-7249A541835C@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Broadband Forum has sent a liaison to us, asking for on their documents. = The statement will no doubt be on the IETF site in the next day or two, = but for the present you can find it at: ftp://ftpeng.cisco.com/fred/BBF_BBHome_Liaison_to_IETF We will discuss how best to respond to this in Maastricht. http://www.ipinc.net/IPv4.GIF From v6ops-archive@ietf.org Wed Jul 7 08:03:45 2010 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 B96BA3A67AE for ; Wed, 7 Jul 2010 08:03:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -77%\n X-Spam-Flag: NO X-Spam-Score: -21.968 X-Spam-Level: X-Spam-Status: No, score=-21.968 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 xHB6Jlt2VKKU for ; Wed, 7 Jul 2010 08:03:45 -0700 (PDT) Received: from 230-233-112-92.pool.ukrtel.net (230-233-112-92.pool.ukrtel.net [92.112.233.230]) by core3.amsl.com (Postfix) with SMTP id B22F13A67FC for ; Wed, 7 Jul 2010 08:03:42 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -77% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100707150342.B22F13A67FC@core3.amsl.com> Date: Wed, 7 Jul 2010 08:03:42 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Wed Jul 7 12:43:58 2010 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 881163A68F0 for ; Wed, 7 Jul 2010 12:43:58 -0700 (PDT) X-Quarantine-ID: <1gPSJV4Kw1F6> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -30%\n X-Spam-Flag: NO X-Spam-Score: -16.306 X-Spam-Level: X-Spam-Status: No, score=-16.306 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 1gPSJV4Kw1F6 for ; Wed, 7 Jul 2010 12:43:57 -0700 (PDT) Received: from 94.179.217.91.pool.3g.utel.ua (94.179.217.91.pool.3g.utel.ua [94.179.217.91]) by core3.amsl.com (Postfix) with SMTP id BCA703A6830 for ; Wed, 7 Jul 2010 12:43:56 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -30% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100707194356.BCA703A6830@core3.amsl.com> Date: Wed, 7 Jul 2010 12:43:56 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner@megatron.ietf.org Thu Jul 8 00:08:35 2010 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 A8FA43A67D3 for ; Thu, 8 Jul 2010 00:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.314 X-Spam-Level: ** X-Spam-Status: No, score=2.314 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_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 rx225GpBfrit for ; Thu, 8 Jul 2010 00:08:34 -0700 (PDT) Received: from aacps.org (unknown [94.181.143.145]) by core3.amsl.com (Postfix) with SMTP id 0E7403A6359 for ; Thu, 8 Jul 2010 00:08:29 -0700 (PDT) From: Google Pharmacy Subject: Recap: 'The Bachelorette' To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100708070833.0E7403A6359@core3.amsl.com> Date: Thu, 8 Jul 2010 00:08:29 -0700 (PDT)
Click here.

Dear v6ops-archive@megatron.ietf.org
From v6ops-archive@ietf.org Fri Jul 9 08:27:10 2010 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 BA8B53A6832 for ; Fri, 9 Jul 2010 08:27:10 -0700 (PDT) X-Quarantine-ID: <1iES5Xd7qGPx> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -96%\n X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 1iES5Xd7qGPx for ; Fri, 9 Jul 2010 08:27:09 -0700 (PDT) Received: from 109-121-34-15.adsl-a-7.sezampro.rs (109-121-34-15.adsl-a-7.sezampro.rs [109.121.34.15]) by core3.amsl.com (Postfix) with SMTP id 4B8773A680F for ; Fri, 9 Jul 2010 08:27:07 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -96% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100709152708.4B8773A680F@core3.amsl.com> Date: Fri, 9 Jul 2010 08:27:07 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Sun Jul 11 04:15:53 2010 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 AFB673A67D3 for ; Sun, 11 Jul 2010 04:15:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -28%\n X-Spam-Flag: NO X-Spam-Score: -25.001 X-Spam-Level: X-Spam-Status: No, score=-25.001 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 OS76UKOtRXoN for ; Sun, 11 Jul 2010 04:15:47 -0700 (PDT) Received: from 230-239-124-91.pool.ukrtel.net (230-239-124-91.pool.ukrtel.net [91.124.239.230]) by core3.amsl.com (Postfix) with SMTP id EF26C3A67A3 for ; Sun, 11 Jul 2010 04:15:45 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -28% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100711111545.EF26C3A67A3@core3.amsl.com> Date: Sun, 11 Jul 2010 04:15:45 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Sun Jul 11 08:10:13 2010 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 8C1683A69AE for ; Sun, 11 Jul 2010 08:10:13 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive VIAGRA \256 Official Site -71%\n X-Spam-Flag: NO X-Spam-Score: -25.001 X-Spam-Level: X-Spam-Status: No, score=-25.001 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 B8KPTrEPF3y8 for ; Sun, 11 Jul 2010 08:10:06 -0700 (PDT) Received: from 191-242-113-92.pool.ukrtel.net (191-242-113-92.pool.ukrtel.net [92.113.242.191]) by core3.amsl.com (Postfix) with SMTP id EF21B3A69A5 for ; Sun, 11 Jul 2010 08:10:05 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive VIAGRA ® Official Site -71% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100711151005.EF21B3A69A5@core3.amsl.com> Date: Sun, 11 Jul 2010 08:10:05 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Sun Jul 11 12:55:06 2010 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 37AAB3A6814 for ; Sun, 11 Jul 2010 12:55:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -67%\n X-Spam-Flag: NO X-Spam-Score: -13.465 X-Spam-Level: X-Spam-Status: No, score=-13.465 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 zlenBllyDt7Y for ; Sun, 11 Jul 2010 12:54:59 -0700 (PDT) Received: from adslgva0791.worldcom.ch (adslgva0791.worldcom.ch [83.172.201.82]) by core3.amsl.com (Postfix) with SMTP id 89A113A69A3 for ; Sun, 11 Jul 2010 12:54:58 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -67% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100711195458.89A113A69A3@core3.amsl.com> Date: Sun, 11 Jul 2010 12:54:58 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Mon Jul 12 09:22:48 2010 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 EADA63A6953 for ; Mon, 12 Jul 2010 09:22:48 -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=[AWL=0.000, 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 J8g35IMWTBBy for ; Mon, 12 Jul 2010 09:22:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABC8B3A6957 for ; Mon, 12 Jul 2010 09:22:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYLf5-0003hN-0a for v6ops-data0@psg.com; Mon, 12 Jul 2010 16:15:19 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYLf1-0003gz-6I for v6ops@ops.ietf.org; Mon, 12 Jul 2010 16:15:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 842333A6407; Mon, 12 Jul 2010 09:15:03 -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-v6-in-mobile-networks-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712161505.842333A6407@core3.amsl.com> Date: Mon, 12 Jul 2010 09:15:03 -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 : Mobile Networks Considerations for IPv6 Deployment Author(s) : R. Koodli Filename : draft-ietf-v6ops-v6-in-mobile-networks-01.txt Pages : 16 Date : 2010-07-12 Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-in-mobile-networks-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-v6-in-mobile-networks-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12090338.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Tue Jul 13 17:37:39 2010 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 531763A6874 for ; Tue, 13 Jul 2010 17:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_05=-1.11, 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 mGBqsry0fCam for ; Tue, 13 Jul 2010 17:37:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A20AF3A63D3 for ; Tue, 13 Jul 2010 17:37:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYprn-000G5w-Ty for v6ops-data0@psg.com; Wed, 14 Jul 2010 00:30:27 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYpri-000G5R-Lp for v6ops@ops.ietf.org; Wed, 14 Jul 2010 00:30:22 +0000 Received: by pwi7 with SMTP id 7so4483432pwi.11 for ; Tue, 13 Jul 2010 17:30:22 -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:subject:content-type :content-transfer-encoding; bh=kXllr4+N0XD3pLGexrCvsZcB5UFPbqaV32+gk9s0750=; b=p8XZGCDYQDRekEdvjsq9s1wG7Ibfd4FtEZ4KppeIz7YCtpv+zYACYHqD801CbhSS+Z BoYYVnIwjUhmUmzjl25x2Ny38PyRHf/EnZrxP1/ay8kTvMUTR8vtUyKYfvyok9zdf1gs 5V7Bmst6+DnQkIoUAegKSZC3kUAyA2I6Zyrzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=BeveXdU/4eJ6NF0uINquRM+BAhmvOVjRhjl46UlTWRPXluVSmD80Bh4zl7sWNKQiTY vA7+VhmFjnyDAAd2n5nfn7PzNDuFVIi6duD9tzmmQRrlxEcKb6TF1lay0fayLisQ8yIB SER1RCsm1zUyf67a6kdiAFGI0TBnggJ633DiI= Received: by 10.142.148.2 with SMTP id v2mr10738360wfd.230.1279067422145; Tue, 13 Jul 2010 17:30:22 -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 b11sm3164187rvf.10.2010.07.13.17.30.20 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 17:30:21 -0700 (PDT) Message-ID: <4C3D0515.6060103@gmail.com> Date: Wed, 14 Jul 2010 12:30:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Subject: Bastille day IPv4 status Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: It seems somehow appropriate that as Bastille Day dawns in Europe, Geoff's model shows exactly 365 days until IANA runs out of IPv4 space. http://www.potaroo.net/tools/ipv4/index.html Regards Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 13 19:13:45 2010 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 051083A6953 for ; Tue, 13 Jul 2010 19:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.873 X-Spam-Level: X-Spam-Status: No, score=-99.873 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, 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 p7NMrM5bh8pk for ; Tue, 13 Jul 2010 19:13:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79D5C3A63CB for ; Tue, 13 Jul 2010 19:13:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYrQG-0000he-Ax for v6ops-data0@psg.com; Wed, 14 Jul 2010 02:10:08 +0000 Received: from [2607:f8c8:4:1025::236] (helo=mail.ttora.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYrQE-0000h3-2f for v6ops@ops.ietf.org; Wed, 14 Jul 2010 02:10:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veznat.com; i=bob@veznat.com; q=dns/txt; s=one; t=1279073339; x=1310609339; h=mime-version:date:message-id:subject:from:to; z=MIME-Version:=201.0|Date:=20Tue,=2013=20Jul=202010=2019: 09:47=20-0700|Message-ID:=20|Subject:=20IPv6=20email =20reflector|From:=20Bob=20Van=20Zant=20 |To:=20v6ops@ops.ietf.org; bh=hZ4O5G8Gp7nNAFMzYfyIBDmJNV9jIN+JNCen/03P+Do=; b=MIYm/x1Ij9GD4e8HbOQ6hkhxmtQNBe8k9MdJGRflveS3L2z77KebQL31 POsBSf254phJzAMMDlKYCrK9RRvU96+jr98dh6uqBtQDVfhoBP5Mai2IT TRJUCETRIj2IfFhIkNMvum0yycr0+jf9cefIYS1HQ4QZE/9bt5N87fJUX g=; X-MID: 5841804 X-IronPort-AV: E=Sophos;i="4.55,199,1278313200"; d="scan'208";a="5841804" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by mail.ttora.com with ESMTP/TLS/RC4-MD5; 13 Jul 2010 19:08:41 -0700 Received: by vws16 with SMTP id 16so4071578vws.11 for ; Tue, 13 Jul 2010 19:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.249.138 with SMTP id mk10mr4173161qcb.298.1279073387241; Tue, 13 Jul 2010 19:09:47 -0700 (PDT) Received: by 10.229.38.70 with HTTP; Tue, 13 Jul 2010 19:09:47 -0700 (PDT) Date: Tue, 13 Jul 2010 19:09:47 -0700 Message-ID: Subject: IPv6 email reflector From: Bob Van Zant To: v6ops@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I setup a reflector a few weeks ago that helps email users identify whether or not they're sending over IPv6 and also clues them in to what their DNS looks like from the outside world. To use it simply send an empty email to ipv6@test-ipv6.veznat.com It'll reply to the email showing you the Received headers as well as dig -t mx output for your domain. Nothing too terribly fancy. Feel free to provide feedback or enhancement requests. Use it but please don't abuse it :-). -Bob From owner-v6ops@ops.ietf.org Wed Jul 14 00:02:14 2010 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 5AE303A682F for ; Wed, 14 Jul 2010 00:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.685 X-Spam-Level: X-Spam-Status: No, score=-101.685 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUP-bjqPEvMK for ; Wed, 14 Jul 2010 00:02:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E4373A67C2 for ; Wed, 14 Jul 2010 00:02:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYvtf-0005Kx-Lv for v6ops-data0@psg.com; Wed, 14 Jul 2010 06:56:47 +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.72 (FreeBSD)) (envelope-from ) id 1OYvtd-0005KP-0P for v6ops@ops.ietf.org; Wed, 14 Jul 2010 06:56:45 +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 CA77416E44C; Wed, 14 Jul 2010 08:58:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1279090691; bh=m7UCeHjzcKqpAVJ2AGiswDuVqW9wJfAKenJUzlUetMw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FjxZCe7mr7jdkN0DBoNt++SUBgBXzpjWQnj1nDkdHROMbNH6tx8UX48+4Zy2o4F/l zm39msb3KTch4AZk906gHiZ3AkYqd2CThFnf9HII4w/wBJIun90FFpEMwb0ha57wO7 tVy2USbqPP2K92s3H9B7Nlfzu9kwjGU1TUgVsCc7xEHP064sNoL/6VrCC2ftU1uSok IOzhBUO0o/XpE2AhLHWXo3oio7QG2/0Mf7CHlEkQJVsvVpyoktj9hAGJPh/rXR7ktp iLjgpEPJ7yY7glQUosC5miZ9E//kl++pyYkSgVFZfdA0S+azFaeb51gN+AytJn32rd 8yuMn3RwX6YNw== Message-ID: <4C3D5F9F.4010206@unfix.org> Date: Wed, 14 Jul 2010 08:56:31 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Bob Van Zant CC: v6ops@ops.ietf.org Subject: Re: IPv6 email reflector 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: On 2010-07-14 04:09, Bob Van Zant wrote: > I setup a reflector a few weeks ago that helps email users identify > whether or not they're sending over IPv6 and also clues them in to > what their DNS looks like from the outside world. > > To use it simply send an empty email to ipv6@test-ipv6.veznat.com > > It'll reply to the email showing you the Received headers as well as > dig -t mx output for your domain. > > Nothing too terribly fancy. Feel free to provide feedback or > enhancement requests. Use it but please don't abuse it :-). Congratulations, you have just set up an automatic spammer for the millions of spammers out there, they spam you, and you spam back the spoofed email address. You do realize that this email list is nicely indexed all around the world I hope and that spammers can easily also read the above email address? People who configure mail servers can check the log files of their mail servers. Others can when sending mail to another person, just ask that person to cut&paste the headers back and hey, presto you know which parts went over IPv6 or not. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Jul 14 00:50:21 2010 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 EFEF03A68B2 for ; Wed, 14 Jul 2010 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0hDDvw8Na0r for ; Wed, 14 Jul 2010 00:50:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1509E3A6855 for ; Wed, 14 Jul 2010 00:50:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYwhe-000BzU-E8 for v6ops-data0@psg.com; Wed, 14 Jul 2010 07:48:26 +0000 Received: from [2a00:801::217:8ff:fe5b:81eb] (helo=uplift.swm.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYwhb-000Bx3-SM for v6ops@ops.ietf.org; Wed, 14 Jul 2010 07:48:24 +0000 Received: by uplift.swm.pp.se (Postfix, from userid 501) id EB137A6; Wed, 14 Jul 2010 09:48:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E87C9A2; Wed, 14 Jul 2010 09:48:21 +0200 (CEST) Date: Wed, 14 Jul 2010 09:48:21 +0200 (CEST) From: Mikael Abrahamsson To: Jeroen Massar cc: Bob Van Zant , v6ops@ops.ietf.org Subject: Re: IPv6 email reflector In-Reply-To: <4C3D5F9F.4010206@unfix.org> Message-ID: References: <4C3D5F9F.4010206@unfix.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 14 Jul 2010, Jeroen Massar wrote: > Congratulations, you have just set up an automatic spammer for the > millions of spammers out there, they spam you, and you spam back the > spoofed email address. Well, actually as far as I could see the email one gets back doesn't really contain any subject/body from the original email, so the use for spammers is limited (?). -- Mikael Abrahamsson email: swmike@swm.pp.se From owner-v6ops@ops.ietf.org Wed Jul 14 00:55:53 2010 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 1F8443A6855 for ; Wed, 14 Jul 2010 00:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAIvIkowrCuc for ; Wed, 14 Jul 2010 00:55:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BFE53A682F for ; Wed, 14 Jul 2010 00:55:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYwoE-000Cur-6w for v6ops-data0@psg.com; Wed, 14 Jul 2010 07:55:14 +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.72 (FreeBSD)) (envelope-from ) id 1OYwoB-000CuX-Nw for v6ops@ops.ietf.org; Wed, 14 Jul 2010 07:55:12 +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 9993316E475; Wed, 14 Jul 2010 09:56:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1279094199; bh=/YhCIoCnTyTCGoUi9f/fY/HFwmdYP9VNbD3YP8CQOgw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dbAjZKhE0LpbliZd21zk0oJSQVGnabW7SWQMPu5KAvzFSVtnHjK6D7UA1QS3XjcDX wgrzA+QyUKp5LPsHlEQC2vPz82JwlHtFm9Or8ifmvk9f+/8cD4GmLB+Y1JIq99f4UE ouROB1JXe4qWrgJbePmnqORMNShGoyAfQYK+0HyeSGERky1n4Uf9KjrOQJuMTJihkd IyaGc2hvtme/n7l4sGVsj4Qfxjkc2duicrAX5SAtLHtVlS9IljCClCczwFn3+k73bv 2qTlXzq1SDr6OZ17GsA0jPY2VxTcjTa7lnqPiT8xswqVHB+3yRj5jogvuXDRdOB91d ozoMjA5WnfR/A== Message-ID: <4C3D6D52.2010301@unfix.org> Date: Wed, 14 Jul 2010 09:54:58 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Mikael Abrahamsson CC: Bob Van Zant , v6ops@ops.ietf.org Subject: Re: IPv6 email reflector References: <4C3D5F9F.4010206@unfix.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-14 09:48, Mikael Abrahamsson wrote: > On Wed, 14 Jul 2010, Jeroen Massar wrote: > >> Congratulations, you have just set up an automatic spammer for the >> millions of spammers out there, they spam you, and you spam back the >> spoofed email address. > > Well, actually as far as I could see the email one gets back doesn't > really contain any subject/body from the original email, so the use for > spammers is limited (?). It is another mail in your mailbox that should not be there in the first place. Same issue as with DSNs, mails should be rejected at DATA time so that the sending SMTP server has the handle the issue, not by the receiving SMTP server which then accepts it and then decided it doesn't want it. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Jul 14 04:16:34 2010 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 E353C3A6A3B for ; Wed, 14 Jul 2010 04:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.547 X-Spam-Level: X-Spam-Status: No, score=-109.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_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 gI9M62qNziBy for ; Wed, 14 Jul 2010 04:16:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE3ED3A6A4A for ; Wed, 14 Jul 2010 04:16:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYzuu-000FFz-NM for v6ops-data0@psg.com; Wed, 14 Jul 2010 11:14:20 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYzus-000FEs-F0 for v6ops@ops.ietf.org; Wed, 14 Jul 2010 11:14:18 +0000 Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF84PUyrR7Hu/2dsb2JhbACfaHGkYJpWgl2CRwSIUA X-IronPort-AV: E=Sophos;i="4.55,201,1278288000"; d="scan'208";a="267413789" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2010 11:14:09 +0000 Received: from 206-186-52-219.scenicsolutionsgroup.com (sjc-vpn2-923.cisco.com [10.21.115.155]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6EBE1OO010857; Wed, 14 Jul 2010 11:14:03 GMT Received: from [127.0.0.1] by 206-186-52-219.scenicsolutionsgroup.com (PGP Universal service); Wed, 14 Jul 2010 07:14:08 -0400 X-PGP-Universal: processed; by 206-186-52-219.scenicsolutionsgroup.com on Wed, 14 Jul 2010 07:14:08 -0400 Subject: Re: IPv6 email reflector Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: Date: Wed, 14 Jul 2010 07:13:55 -0400 Cc: v6ops@ops.ietf.org Message-Id: <8697BB6B-E85C-4B8F-A0FB-C896F9FAA48D@cisco.com> References: To: Bob Van Zant X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I guess Jeroen's point is that you would do well to apply some form of = policy to it, such as not responding to blacklisted addresses. Although at this point I would guess that there are not a lot of IPv6 = Bots (that will come, but is not status quo today); having this = available would probably encourage their development :-) On Jul 13, 2010, at 10:09 PM, Bob Van Zant wrote: > I setup a reflector a few weeks ago that helps email users identify > whether or not they're sending over IPv6 and also clues them in to > what their DNS looks like from the outside world. >=20 > To use it simply send an empty email to ipv6@test-ipv6.veznat.com >=20 > It'll reply to the email showing you the Received headers as well as > dig -t mx output for your domain. >=20 > Nothing too terribly fancy. Feel free to provide feedback or > enhancement requests. Use it but please don't abuse it :-). >=20 > -Bob >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Jul 14 04:16:42 2010 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 4D22C3A6A3B for ; Wed, 14 Jul 2010 04:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.349 X-Spam-Level: X-Spam-Status: No, score=-108.349 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VFQlr9Vb3o8 for ; Wed, 14 Jul 2010 04:16:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1676B3A6A35 for ; Wed, 14 Jul 2010 04:16:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYzrr-000EdG-I9 for v6ops-data0@psg.com; Wed, 14 Jul 2010 11:11:11 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYzrp-000Ecs-0F for v6ops@ops.ietf.org; Wed, 14 Jul 2010 11:11:09 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF84PUyrRN+J/2dsb2JhbACfaHGkYJpWgmyCOASIUA X-IronPort-AV: E=Sophos;i="4.55,201,1278288000"; d="scan'208";a="558988694" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 14 Jul 2010 11:11:08 +0000 Received: from 206-186-52-219.scenicsolutionsgroup.com (sjc-vpn2-923.cisco.com [10.21.115.155]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6EBAxkZ011698; Wed, 14 Jul 2010 11:11:01 GMT Received: from [127.0.0.1] by 206-186-52-219.scenicsolutionsgroup.com (PGP Universal service); Wed, 14 Jul 2010 07:11:08 -0400 X-PGP-Universal: processed; by 206-186-52-219.scenicsolutionsgroup.com on Wed, 14 Jul 2010 07:11:08 -0400 Subject: Re: IPv6 email reflector Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <4C3D6D52.2010301@unfix.org> Date: Wed, 14 Jul 2010 07:10:53 -0400 Cc: Mikael Abrahamsson , Bob Van Zant , v6ops@ops.ietf.org Message-Id: References: <4C3D5F9F.4010206@unfix.org> <4C3D6D52.2010301@unfix.org> To: Jeroen Massar X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Well, I would agree, but there are issues. The receiver often cannot = make that determination without having first received the email, in = order to check its DKIM signature or apply content heuristics. It is = possible to null route identified bots at the network layer, to reject = their sending attempt by RST'ing the TCP connection that it opens, or to = do the equivalent with their SMTP connection, but only before the email = has been transferred. The only information that can be done on is the = unverified email address of the sender (in SMTP) or the IP address of = the device sending it. That's not a lot of information. What Ironport and other spam management devices do is filter out spam in = a trusted intermediary. That fails to leave the problem at the bot, but = it does prevent the user from having to do it. The issue there is false = positives and false negatives. Cisco tells me that upwards of 95% of = email directed toward me is dropped by Ironport, meaning that I only = deal with a daily average of about 60/day, the majority of which is = dealt with by my Beysian filter. I can check for false positives or = negatives there, but cannot in traffic dropped by Ironport. What is it about this conversation that seems two layers higher than = IPv6? :-) On Jul 14, 2010, at 3:54 AM, Jeroen Massar wrote: > On 2010-07-14 09:48, Mikael Abrahamsson wrote: >> On Wed, 14 Jul 2010, Jeroen Massar wrote: >>=20 >>> Congratulations, you have just set up an automatic spammer for the >>> millions of spammers out there, they spam you, and you spam back the >>> spoofed email address. >>=20 >> Well, actually as far as I could see the email one gets back doesn't >> really contain any subject/body from the original email, so the use = for >> spammers is limited (?). >=20 > It is another mail in your mailbox that should not be there in the = first > place. >=20 > Same issue as with DSNs, mails should be rejected at DATA time so that > the sending SMTP server has the handle the issue, not by the receiving > SMTP server which then accepts it and then decided it doesn't want it. >=20 > Greets, > Jeroen >=20 >=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Jul 14 04:27:11 2010 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 960003A6842 for ; Wed, 14 Jul 2010 04:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 i2MFNab6Mmkl for ; Wed, 14 Jul 2010 04:27:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B0E63A696E for ; Wed, 14 Jul 2010 04:27:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZ06D-000H7A-06 for v6ops-data0@psg.com; Wed, 14 Jul 2010 11:26:01 +0000 Received: from [130.37.15.35] (helo=stereo.hq.phicoh.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZ06A-000H62-5g for v6ops@ops.ietf.org; Wed, 14 Jul 2010 11:25:58 +0000 Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1OZ068-0001dYC; Wed, 14 Jul 2010 13:25 +0200 Message-Id: To: Jeroen Massar Cc: v6ops@ops.ietf.org Subject: Re: IPv6 email reflector From: Philip Homburg References: <4C3D5F9F.4010206@unfix.org> <4C3D6D52.2010301@unfix.org> In-reply-to: Your message of "Wed, 14 Jul 2010 09:54:58 +0200 ." <4C3D6D52.2010301@unfix.org> Date: Wed, 14 Jul 2010 13:25:53 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: In your letter dated Wed, 14 Jul 2010 09:54:58 +0200 you wrote: >> Well, actually as far as I could see the email one gets back doesn't >> really contain any subject/body from the original email, so the use for >> spammers is limited (?). > >It is another mail in your mailbox that should not be there in the first >place. > >Same issue as with DSNs, mails should be rejected at DATA time so that >the sending SMTP server has the handle the issue, not by the receiving >SMTP server which then accepts it and then decided it doesn't want it. I think it is better use of terminology to distinguish between spam and back-scatter. The reason is that spam is done on purpose, and back-scatter is incidental. And that leads to a different security analysis. So I can imagine that with some precautions, like rate limiting the output of the reflector to prevent DoS attacks, and some requirements on the request (to prevent back-scatter) the reflector may be quite safe to run. From owner-v6ops@ops.ietf.org Wed Jul 14 08:50:54 2010 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 A36A53A6968 for ; Wed, 14 Jul 2010 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.416 X-Spam-Level: X-Spam-Status: No, score=-99.416 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJVg2cap9RPE for ; Wed, 14 Jul 2010 08:50:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FFED3A686D for ; Wed, 14 Jul 2010 08:50:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZ49L-0003xn-CG for v6ops-data0@psg.com; Wed, 14 Jul 2010 15:45:31 +0000 Received: from [2607:f8c8:4:1025::236] (helo=mail.ttora.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZ49I-0003xJ-CB for v6ops@ops.ietf.org; Wed, 14 Jul 2010 15:45:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veznat.com; i=bob@veznat.com; q=dns/txt; s=one; t=1279122261; x=1310658261; h=mime-version:in-reply-to:references:date:message-id: subject:from:to:cc:content-transfer-encoding; z=MIME-Version:=201.0|In-Reply-To:=20<4C3D5F9F.4010206@unf ix.org>|References:=20=0D=0A=09<4C3D5F9F.4010206@unf ix.org>|Date:=20Wed,=2014=20Jul=202010=2008:45:22=20-0700 |Message-ID:=20|Subject:=20Re:=20IPv6=20email=20refl ector|From:=20Bob=20Van=20Zant=20|To:=20J eroen=20Massar=20|Cc:=20v6ops@ops.ietf. org|Content-Transfer-Encoding:=20quoted-printable; bh=ZzxYAfy4JkfvS9pdZUB2ns2YVH2oh+nMC/HXYWHmgSw=; b=sMQKw2knP9uCISndCx/PxO9Ims7A3aMZP+iXADJdyKjcJa/AekHKVFIV WfCOKq9WJNhzqkpPL06kowEEf081Qo8Bsp5MAl5FbRi48mezan7v53E2Q 8O0qLeSqG9LrZK1TmV2hBAENUJnD2jCOuq2Jb6/GBv79uBhr8RDyU5HSq Y=; X-MID: 5843544 X-IronPort-AV: E=Sophos;i="4.55,202,1278313200"; d="scan'208";a="5843544" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail.ttora.com with ESMTP/TLS/RC4-MD5; 14 Jul 2010 08:44:18 -0700 Received: by fxm8 with SMTP id 8so5346359fxm.11 for ; Wed, 14 Jul 2010 08:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.91.20 with SMTP id o20mr2276402fgb.18.1279122323474; Wed, 14 Jul 2010 08:45:23 -0700 (PDT) Received: by 10.229.38.70 with HTTP; Wed, 14 Jul 2010 08:45:22 -0700 (PDT) In-Reply-To: <4C3D5F9F.4010206@unfix.org> References: <4C3D5F9F.4010206@unfix.org> Date: Wed, 14 Jul 2010 08:45:22 -0700 Message-ID: Subject: Re: IPv6 email reflector From: Bob Van Zant To: Jeroen Massar Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks for your feedback, Jeroen. There were 3 main security threats that I tried to address when setting this up: 1. Someone overloading my MTA 2. Someone finding a way to turn it into an open relay 3. People getting blasted with backscatter Realistically there's not a lot I can do to avoid someone overloading my MTA. I have very stringent throttling in place on this machine but a distributed attack would put those defenses to shame. In any case this affects only me. The box simply isn't an open relay. We've known for a long time how to avoid creating an open relay and this simply isn't an open relay. This leaves backscatter as the primary concern. As others have pointed out no spammer is going to use this machine as the starting point for a spam campaign. It completely throws away the original email leaving nothing of value for the spammer. The most likely scenario is that the reflector email address gets scraped from mailing list archives like these ones and is then used as the recipient of a spam campaign. Spammers rarely use their own email address in the mail from and so, yes, that forged sender would receive backscatter. The defenses in place here are numerous. The outermost MTA in this setup is an IronPort appliance and for this particular address the settings are dialed way down to prevent abuse. Both IP reputation and content-based spam scanning (and virus scanning) are applied and any hint of spam is simply discarded. Even people with good IP reputation are severely limited in the number of tests they can run. Add all of this to the fact that I'm continually monitoring the use of the system to look for signs of abuse. It's my IP address' reputation on the line and I even put my email address into the body of the reply message. At the end of the day I think it provides a valuable service for folks trying to setup IPv6 email. I hope others will as well. -Bob On Tue, Jul 13, 2010 at 11:56 PM, Jeroen Massar wrote: > On 2010-07-14 04:09, Bob Van Zant wrote: >> I setup a reflector a few weeks ago that helps email users identify >> whether or not they're sending over IPv6 and also clues them in to >> what their DNS looks like from the outside world. >> >> To use it simply send an empty email to ipv6@test-ipv6.veznat.com >> >> It'll reply to the email showing you the Received headers as well as >> dig -t mx output for your domain. >> >> Nothing too terribly fancy. Feel free to provide feedback or >> enhancement requests. Use it but please don't abuse it :-). > > Congratulations, you have just set up an automatic spammer for the > millions of spammers out there, they spam you, and you spam back the > spoofed email address. > > You do realize that this email list is nicely indexed all around the > world I hope and that spammers can easily also read the above email addre= ss? > > People who configure mail servers can check the log files of their mail > servers. > > Others can when sending mail to another person, just ask that person to > cut&paste the headers back and hey, presto you know which parts went > over IPv6 or not. > > Greets, > =A0Jeroen > From owner-v6ops@ops.ietf.org Wed Jul 14 12:35:23 2010 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 393163A6A82 for ; Wed, 14 Jul 2010 12:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.802 X-Spam-Level: X-Spam-Status: No, score=-108.802 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 ciljFoTK-5jr for ; Wed, 14 Jul 2010 12:35:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D14D83A69E3 for ; Wed, 14 Jul 2010 12:35:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZ7et-000AYh-T8 for v6ops-data0@psg.com; Wed, 14 Jul 2010 19:30:19 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZ7eq-000AWN-FR for v6ops@ops.ietf.org; Wed, 14 Jul 2010 19:30:16 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAGOsPUyrRN+J/2dsb2JhbACBRJ4tcaYmml2FJASIUA X-IronPort-AV: E=Sophos;i="4.55,203,1278288000"; d="scan'208,217";a="559203658" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 14 Jul 2010 19:29:14 +0000 Received: from Freds-Computer.local (sjc-vpn5-272.cisco.com [10.21.89.16]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6EJT5fJ007902 for ; Wed, 14 Jul 2010 19:29:07 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 14 Jul 2010 15:29:13 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 14 Jul 2010 15:29:13 -0400 From: Fred Baker Subject: IPv6 Operations - IETF 78 Date: Wed, 14 Jul 2010 15:28:59 -0400 Message-Id: <87078391-1C81-4DD5-9CC4-49C259D11DCB@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: multipart/alternative; boundary=Apple-Mail-2-180828890 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-2-180828890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Checking: is this the right agenda? Any issues? IPv6 Operations - IETF 78 Monday 13:00-14:59 Agenda bashing =20 Mobile Networks Considerations for IPv6 Deployment 12-Jul-10, CIDR for IPv6: Address Aggregation 29-Jun-10, Advanced Requirements for IPv6 Customer Edge Routers 8-Jul-10, BBF Liaison Discussion https://datatracker.ietf.org/liaison/922/ Friday 13:00-14:59 Flexible DHCPv6 Prefix Delegation in Mobile Networks 10-May-10, Security Concerns With IP Tunneling 8-Mar-10, Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and = Proposed Mitigations 12-May-10, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 18-Jun-10, --Apple-Mail-2-180828890 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IPv6 Operations - IETF 77
Checking: is this the right agenda? Any issues?

IPv6 Operations - IETF 78

Monday 13:00-14:59

Agenda bashing
 
Mobile Networks Considerations for IPv6 Deployment
12-Jul-10, <draft-ietf-v6ops-v6-in-mobile-networks-01.txt>
CIDR for IPv6: Address Aggregation
29-Jun-10, <draft-azinger-cidrv6-00.txt>
Advanced Requirements for IPv6 Customer Edge Routers
8-Jul-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-03.txt>
BBF Liaison Discussion
https://datatracker.ietf.org/liaison/922/

Friday 13:00-14:59

Flexible DHCPv6 Prefix Delegation in Mobile Networks
10-May-10, <draft-sarikaya-v6ops-prefix-delegation-01.txt>
Security Concerns With IP Tunneling
8-Mar-10, <draft-ietf-v6ops-tunnel-security-concerns-02.txt>
Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
12-May-10, <draft-nakibly-v6ops-tunnel-loops-02.txt>
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
18-Jun-10, <draft-ietf-v6ops-incremental-cgn-01.txt>




--Apple-Mail-2-180828890-- From owner-v6ops@ops.ietf.org Wed Jul 14 17:06:59 2010 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 3AF043A68AC for ; Wed, 14 Jul 2010 17:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.58 X-Spam-Level: X-Spam-Status: No, score=-104.58 tagged_above=-999 required=5 tests=[AWL=2.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XocspCm38vaZ for ; Wed, 14 Jul 2010 17:06:49 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BC2DF3A6807 for ; Wed, 14 Jul 2010 17:06:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZBvn-000F0d-5X for v6ops-data0@psg.com; Thu, 15 Jul 2010 00:04:03 +0000 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZBvi-000Ezs-CE for v6ops@ops.ietf.org; Thu, 15 Jul 2010 00:03:58 +0000 Received: from dhcp-92.nokia.net (dhcp-92.nokia.net [192.103.16.92] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o6F03uwT020161 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 15 Jul 2010 00:03:57 GMT (envelope-from joelja@bogus.com) Message-ID: <4C3E506C.8000500@bogus.com> Date: Wed, 14 Jul 2010 17:03:56 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Fred Baker CC: Bob Van Zant , v6ops@ops.ietf.org Subject: Re: IPv6 email reflector References: <8697BB6B-E85C-4B8F-A0FB-C896F9FAA48D@cisco.com> In-Reply-To: <8697BB6B-E85C-4B8F-A0FB-C896F9FAA48D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 15 Jul 2010 00:03:57 +0000 (UTC) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 7/14/10 4:13 AM, Fred Baker wrote: > I guess Jeroen's point is that you would do well to apply some form > of policy to it, such as not responding to blacklisted addresses. > > Although at this point I would guess that there are not a lot of IPv6 > Bots (that will come, but is not status quo today); having this > available would probably encourage their development :-) we get plenty of spam over v6. windows machines with terredo or 6to4 are pretty flexible when it comes to protocol selection. > On Jul 13, 2010, at 10:09 PM, Bob Van Zant wrote: > >> I setup a reflector a few weeks ago that helps email users >> identify whether or not they're sending over IPv6 and also clues >> them in to what their DNS looks like from the outside world. >> >> To use it simply send an empty email to ipv6@test-ipv6.veznat.com >> >> It'll reply to the email showing you the Received headers as well >> as dig -t mx output for your domain. >> >> Nothing too terribly fancy. Feel free to provide feedback or >> enhancement requests. Use it but please don't abuse it :-). >> >> -Bob >> > > http://www.ipinc.net/IPv4.GIF > > > From owner-v6ops@ops.ietf.org Wed Jul 14 17:06:59 2010 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 E725B3A6807 for ; Wed, 14 Jul 2010 17:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLAvrWa0xwB0 for ; Wed, 14 Jul 2010 17:06:59 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EB4DE3A687F for ; Wed, 14 Jul 2010 17:06:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZBs5-000EYL-F1 for v6ops-data0@psg.com; Thu, 15 Jul 2010 00:00:13 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZBs2-000EXh-Lz for v6ops@ops.ietf.org; Thu, 15 Jul 2010 00:00:11 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6F005TA000835; Thu, 15 Jul 2010 09:00:05 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6F005618681; Thu, 15 Jul 2010 09:00:05 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6F0057O012643; Thu, 15 Jul 2010 09:00:05 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6F005WR006049; Thu, 15 Jul 2010 09:00:05 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6F005wd027101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 09:00:05 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6F004HM004945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 09:00:04 +0900 Message-ID: <4C3E4F83.2020905@mesh.ad.jp> Date: Thu, 15 Jul 2010 09:00:03 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations Subject: Re: IPv6 Operations - IETF 78 References: <87078391-1C81-4DD5-9CC4-49C259D11DCB@cisco.com> In-Reply-To: <87078391-1C81-4DD5-9CC4-49C259D11DCB@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I requested a slot for at Maastricht a while back for draft-kawamura-ipv6-isp-listings-00 (forgot to Cc list) Is v6ops a suitable place to discuss and get input? Regards, Seiichi Fred Baker wrote: > Checking: is this the right agenda? Any issues? > IPv6 Operations - IETF 78 > > Monday 13:00-14:59 > > Agenda bashing > > Mobile Networks Considerations for IPv6 Deployment > 12-Jul-10, > CIDR for IPv6: Address Aggregation > 29-Jun-10, > Advanced Requirements for IPv6 Customer Edge Routers > 8-Jul-10, > BBF Liaison Discussion > https://datatracker.ietf.org/liaison/922/ > Friday 13:00-14:59 > > Flexible DHCPv6 Prefix Delegation in Mobile Networks > 10-May-10, > Security Concerns With IP Tunneling > 8-Mar-10, > Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations > 12-May-10, > An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition > 18-Jun-10, > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkw+T4MACgkQcrhTYfxyMkJOwACfSb0kaVE1EncEOnOIH5w3n6ha +qYAnivvI69MJqmR6DxCOTezwwMJ9b6G =DUmV -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Jul 14 18:31:56 2010 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 60FDC3A69FF for ; Wed, 14 Jul 2010 18:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.15 X-Spam-Level: X-Spam-Status: No, score=-108.15 tagged_above=-999 required=5 tests=[AWL=-2.151, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kinf3H-LzLAW for ; Wed, 14 Jul 2010 18:31:55 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D77673A6A03 for ; Wed, 14 Jul 2010 18:31:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZDDM-000NnN-6w for v6ops-data0@psg.com; Thu, 15 Jul 2010 01:26:16 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZDDC-000NmI-0L for v6ops@ops.ietf.org; Thu, 15 Jul 2010 01:26:06 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIcAPkyrR7Hu/2dsb2JhbACfdnGlb5plhSQEiFA X-IronPort-AV: E=Sophos;i="4.55,204,1278288000"; d="scan'208";a="226456427" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2010 01:26:03 +0000 Received: from 206-186-52-219.scenicsolutionsgroup.com (sjc-vpn2-614.cisco.com [10.21.114.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6F1Ps0M014893; Thu, 15 Jul 2010 01:25:56 GMT Received: from [127.0.0.1] by 206-186-52-219.scenicsolutionsgroup.com (PGP Universal service); Wed, 14 Jul 2010 21:26:03 -0400 X-PGP-Universal: processed; by 206-186-52-219.scenicsolutionsgroup.com on Wed, 14 Jul 2010 21:26:03 -0400 Subject: Re: IPv6 Operations - IETF 78 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <4C3E4F83.2020905@mesh.ad.jp> Date: Wed, 14 Jul 2010 21:25:48 -0400 Cc: IPv6 Operations Message-Id: <239E4622-1736-4A14-931E-D23A5F1FB2A5@cisco.com> References: <87078391-1C81-4DD5-9CC4-49C259D11DCB@cisco.com> <4C3E4F83.2020905@mesh.ad.jp> To: Seiichi Kawamura X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Sorry, thanks. On Jul 14, 2010, at 8:00 PM, Seiichi Kawamura wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I requested a slot for at Maastricht > a while back for draft-kawamura-ipv6-isp-listings-00 > (forgot to Cc list) >=20 > Is v6ops a suitable place to discuss and get input? >=20 > Regards, > Seiichi >=20 > Fred Baker wrote: >> Checking: is this the right agenda? Any issues? >> IPv6 Operations - IETF 78 >>=20 >> Monday 13:00-14:59 >>=20 >> Agenda bashing >>=20 >> Mobile Networks Considerations for IPv6 Deployment >> 12-Jul-10, >> CIDR for IPv6: Address Aggregation >> 29-Jun-10, >> Advanced Requirements for IPv6 Customer Edge Routers >> 8-Jul-10, >> BBF Liaison Discussion >> https://datatracker.ietf.org/liaison/922/ >> Friday 13:00-14:59 >>=20 >> Flexible DHCPv6 Prefix Delegation in Mobile Networks >> 10-May-10, >> Security Concerns With IP Tunneling >> 8-Mar-10, >> Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement = and Proposed Mitigations >> 12-May-10, >> An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition >> 18-Jun-10, >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) >=20 > iEYEARECAAYFAkw+T4MACgkQcrhTYfxyMkJOwACfSb0kaVE1EncEOnOIH5w3n6ha > +qYAnivvI69MJqmR6DxCOTezwwMJ9b6G > =3DDUmV > -----END PGP SIGNATURE----- http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Jul 14 23:40:32 2010 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 94EC33A69A6 for ; Wed, 14 Jul 2010 23:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.042 X-Spam-Level: X-Spam-Status: No, score=-104.042 tagged_above=-999 required=5 tests=[AWL=2.557, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HTbdiRm8rfs for ; Wed, 14 Jul 2010 23:39:53 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0B3CE3A67E6 for ; Wed, 14 Jul 2010 23:39:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZI0Y-0003nv-Q0 for v6ops-data0@psg.com; Thu, 15 Jul 2010 06:33:22 +0000 Received: from [2001:14b8:400::130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZI0W-0003nS-Ib for v6ops@ops.ietf.org; Thu, 15 Jul 2010 06:33:20 +0000 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E1BA32CEB5; Thu, 15 Jul 2010 09:33:14 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m961BEXR4e+a; Thu, 15 Jul 2010 09:33:13 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8B5652CCC0; Thu, 15 Jul 2010 09:33:12 +0300 (EEST) Message-ID: <4C3EABA6.5010003@piuha.net> Date: Thu, 15 Jul 2010 08:33:10 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Dave Thaler CC: "draft-thaler-v6ops-teredo-extensions@tools.ietf.org" , 'IPv6 Operations' Subject: Re: AD review of draft-thaler-v6ops-teredo-extensions (part 2) References: <4BD74C42.4060704@piuha.net> <4BDDE6C7.5010700@piuha.net> <9B57C850BB53634CACEC56EF4853FF65341DCD3C@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF65341DCD62@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF65341DCD62@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dave, Thanks for the new version and for the responses. I'm happy with everything now, with one small exception*. I have asked the draft to be sent to IETF Last Call. Jari *) Its about the IANA text. I'm fine with no IANA actions, but then you should at least state in the draft what you stated in the e-mail. In any case, that is a small thing that we can deal with later. From owner-v6ops@ops.ietf.org Thu Jul 15 02:28:02 2010 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 E819F3A68B6 for ; Thu, 15 Jul 2010 02:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.254 X-Spam-Level: X-Spam-Status: No, score=-108.254 tagged_above=-999 required=5 tests=[AWL=-1.656, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UM5PtnWj3SO for ; Thu, 15 Jul 2010 02:28:01 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9FC5D3A6850 for ; Thu, 15 Jul 2010 02:28:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZKeV-000Om1-Q2 for v6ops-data0@psg.com; Thu, 15 Jul 2010 09:22:47 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZKeR-000Olb-Vv for v6ops@ops.ietf.org; Thu, 15 Jul 2010 09:22:44 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANtvPkyrR7Hu/2dsb2JhbACfbHGjRJpzhSQEiFA X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="scan'208,217";a="226634808" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2010 09:22:43 +0000 Received: from 206-186-52-219.scenicsolutionsgroup.com (sjc-vpn5-693.cisco.com [10.21.90.181]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6F9MYmB025344 for ; Thu, 15 Jul 2010 09:22:36 GMT Received: from [127.0.0.1] by 206-186-52-219.scenicsolutionsgroup.com (PGP Universal service); Thu, 15 Jul 2010 05:22:42 -0400 X-PGP-Universal: processed; by 206-186-52-219.scenicsolutionsgroup.com on Thu, 15 Jul 2010 05:22:42 -0400 From: Fred Baker Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: Agenda - second try... Date: Thu, 15 Jul 2010 05:22:27 -0400 In-Reply-To: <4EBDD373-9D10-475E-B580-A473FDF635DD@cisco.com> To: IPv6 Operations References: <4EBDD373-9D10-475E-B580-A473FDF635DD@cisco.com> Message-Id: <3BF42339-0226-4D18-9574-9DD5E2E0920E@cisco.com> X-Mailer: Apple Mail (2.1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-230837381 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-1-230837381 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 14, 2010, at 9:43 PM, Fred Baker wrote: > IPv6 Operations - IETF 78 >=20 > Monday 13:00-14:59 >=20 > Agenda bashing > =20 > Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement = and Proposed Mitigations > 12-May-10, > Security Concerns With IP Tunneling > 8-Mar-10, > Advanced Requirements for IPv6 Customer Edge Routers > 8-Jul-10, > IPv6 Multihoming without Network Address Translation > 25-May-10, > BBF Liaison > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D922 > CIDR for IPv6: Address Aggregation > 29-Jun-10, > Friday 13:00-14:59 >=20 > Mobile Networks Considerations for IPv6 Deployment > 12-Jul-10, > IPv6 Address Assignment to End Sites > 12-Jul-10, > Flexible DHCPv6 Prefix Delegation in Mobile Networks > 10-May-10, > An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition > 18-Jun-10, > A Basic Guideline for Listing ISPs that Run IPv6 > 11-Jun-10, --Apple-Mail-1-230837381 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 14, 2010, = at 9:43 PM, Fred Baker wrote:

IPv6 = Operations - IETF 78

Monday 13:00-14:59

Ro= uting Loop Attack using IPv6 Automatic Tunnels: Problem Statement and = Proposed Mitigations
12-May-10, = <draft-nakibly-v6ops-tunnel-loops-02.txt>
Security Concerns With IP Tunneling
8-Mar-10, = <draft-ietf-v6ops-tunnel-security-concerns-02.txt>
Advanced Requirements for IPv6 Customer Edge = Routers
8-Jul-10, = <draft-wbeebee-v6ops-ipv6-cpe-router-bis-03.txt>
= IPv6 Multihoming without Network Address = Translation
25-May-10, = <draft-troan-multihoming-without-nat66-00.txt>
BBF = Liaison
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D92= 2
CIDR for = IPv6: Address Aggregation
29-Jun-10, = <draft-azinger-cidrv6-00.txt>

Friday = 13:00-14:59

Mobile Networks Considerations for IPv6 = Deployment
12-Jul-10, = <draft-ietf-v6ops-v6-in-mobile-networks-01.txt>
<= b>IPv6 Address Assignment to End Sites
12-Jul-10, = <draft-narten-ipv6-3177bis-48boundary-05.txt>
Flexible DHCPv6 Prefix Delegation in Mobile = Networks
10-May-10, = <draft-sarikaya-v6ops-prefix-delegation-01.txt>
An= Incremental Carrier-Grade NAT (CGN) for IPv6 = Transition
18-Jun-10, = <draft-ietf-v6ops-incremental-cgn-01.txt>
A = Basic Guideline for Listing ISPs that Run = IPv6
11-Jun-10, = <draft-kawamura-ipv6-isp-listings-00.txt>

= --Apple-Mail-1-230837381-- From v6ops-archive@ietf.org Thu Jul 15 02:47:53 2010 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 F3A2B3A695D for ; Thu, 15 Jul 2010 02:47:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -70%\n X-Spam-Flag: NO X-Spam-Score: -26.251 X-Spam-Level: X-Spam-Status: No, score=-26.251 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_95=3, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 Se3jxSsOdigx for ; Thu, 15 Jul 2010 02:47:45 -0700 (PDT) Received: from 57-81-124-91.pool.ukrtel.net (57-81-124-91.pool.ukrtel.net [91.124.81.57]) by core3.amsl.com (Postfix) with SMTP id 2BDF93A6A0D for ; Thu, 15 Jul 2010 02:47:34 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -70% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100715094735.2BDF93A6A0D@core3.amsl.com> Date: Thu, 15 Jul 2010 02:47:34 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Thu Jul 15 08:42:16 2010 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 69D6F3A6AA2 for ; Thu, 15 Jul 2010 08:42:16 -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 VvCYOeQv8Kbi for ; Thu, 15 Jul 2010 08:42:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 664EA3A6B3D for ; Thu, 15 Jul 2010 08:42:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZQUd-000OYL-7t for v6ops-data0@psg.com; Thu, 15 Jul 2010 15:36:59 +0000 Received: from [2a01:e0b:1:97:2e0:f4ff:fe1b:b624] (helo=copper.chdir.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZQUZ-000OXt-Hn for v6ops@ops.ietf.org; Thu, 15 Jul 2010 15:36:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:Date:Message-ID: MIME-Version:Content-Type; bh=vMPBjVfngTYrePtDV5ni7sbKeB+ZEt02C7 zcHTs4Lrw=; b=mcBCL/1IeAdiWLF3eiVYxuQgFBSSG8lPYrmGDt3/kozFvu9j0M ytMd1gI+1oPOy6a9sz6aLzgYyTw2TkJ+12Tx6RSmBhZebtUOL+qjGaPOVIoO3VDz jKwj/dVplAIjRfccs1i+ne8nmzryDgoKKlPf7roP8fu09MkClt21LTVLY= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OZQUV-0007Aq-9Q; Thu, 15 Jul 2010 17:36:51 +0200 X-Hashcash: 1:20:100715:v6ops@ops.ietf.org::T3vU7j6kqfRMkaMl:00000000000000000000000000000000000000000001Ufz X-Hashcash: 1:20:100715:jhw@apple.com::8FIkv9C6fXYkD/xv:00002Zss From: arno@natisbad.org (Arnaud Ebalard) To: v6ops@ops.ietf.org Cc: "James Woodyatt" Subject: Review of draft-ietf-v6ops-cpe-simple-security-12 X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B Date: Thu, 15 Jul 2010 17:37:01 +0200 Message-ID: <87k4owbvtu.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I read the draft (except for SCTP and DCCP related parts). IMHO, it is in good shape. I have some comments inline below. They are mainly related to IPsec/IKE and MIPv6. Please, bear with me if some have already been discussed on the list; I have not followed associated discussions. > 2. Overview > > For the purposes of this document, residential Internet gateways are > assumed to be fairly simple devices with a limited subset of the full > range of possible features. They function as default routers > [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi > network, a bridge between two or more such segments. They have only > one interface by which they can access the Internet service at any > one time, using any of several possible sub-IP mechanisms including > tunnels and transition mechanisms. > > In referring to the security capabilities of residential gateways, it > is reasonable to distinguish between their "interior" network, i.e. > the local-area network, and their "exterior" networks, e.g. the > public Internet and the networks of Internet service providers. This > document is concerned only with the behavior of IP packet filters > that police the flow of traffic between the interior IPv6 network and > the exterior IPv6 networks of residential Internet gateways. > > The operational goals of security capabilities in Internet gateways > are described with more detail in "Local Network Protection for IPv6" > [RFC4864], but they can be summarized as follows. > > o Check all traffic to and from the public Internet for basic > sanity, e.g. anti-spoofing and "martian" [RFC4949] filters. > > o Allow tracking of applications usage by source and destination > transport addresses. s/transport/network/ ? > 3.1. Stateless Filters > > [snip] > > REC-8: By DEFAULT, inbound non-recursive DNS queries received on ^^^^^^^^^^^^^ Why non-recursive? What about recursive ones? In the end, is the integrated DNS resolver expected to process any kind of DNS solicitation originating from outside? > exterior interfaces MUST NOT be processed by any integrated DNS > resolving server. > > REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on > exterior interfaces MUST NOT be processed by any integrated DHCPv6 > server. > > 3.2. Connection-free Filters > > Some Internet applications use connection-free transport protocols > with no release semantics, e.g. UDP. These protocols pose a special > difficulty for stateful packet filters because most of the > application state is not carried at the transport level. State > records are created when communication is initiated and abandoned > when no further communication is detected after some period of time. > > 3.2.1. Internet Control and Management > > Recommendations for filtering ICMPv6 messages in firewall devices are > described separately in [RFC4890] and apply to residential gateways > with the additional recommendation that incoming "Destination > Unreachable" and "Packet Too Big" error messages that don't match any > filtering state should be dropped. > > REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination > Unreachable" and "Packet Too Big messages" containing IP headers that > do not match generic upper-layer transport state 3-tuples. I understand the purpose of the REC but I wanted to point the following just in case: if one decides to hardcode one of the other requirements without internally creating an "upper-layer transport state 3-tuples" (e.g. treat it statelessly), the result will be that associated ICMPv6 traffic may be dropped. The example I can provide is associated with the default pass-through rule for ESP (REC-21) which contain a MUST but REC-23 contains only a SHOULD for the use of a filter state record. I would like to avoid ESP-related traffic (e.g. PMTUD traffic) to get dropped. ESP does not seem to have the same kind of clarification than the one that REC-17 provides for UDP or REC-31 provides for TCP, i.e. something like "If a gateway forwards a ESP traffic flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record." Another solution would be to add a warning about related traffic in REC-21 or REC-23. Maybe the weird behavior of existing boxes made me paranoid. > 3.2.4. IPsec and Internet Key Exchange (IKE) > > The Internet protocol security suite (IPsec) offers greater > flexibility and better overall security than the simple security of > stateful packet filtering at network perimeters. Therefore, > residential IPv6 gateways need not prohibit IPsec traffic flows. > > REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT > prohibit the forwarding of packets, to and from legitimate node > addresses, with destination extension headers of type "Authenticated > Header (AH)" [RFC4302] in their outer IP extension header chain. > > REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT > prohibit the forwarding of packets, to and from legitimate node > addresses, with an upper layer protocol of type "Encapsulating > Security Payload (ESP)" [RFC4303] in their outer IP extension header > chain. > > Internet Key Exchange (IKE) is a secure mechanism for exchanging > cryptographic material. Residential IPv6 gateways are expected to > facilitate the use of IPsec security policies by allowing inbound IKE > flows. What about the following to replace the first sentence: Internet Key Exchange (IKE) is a secure mechanism for performing mutual authentication, exchanging cryptographic material and establishing IPsec Security Associations between peers. > 3.2.5. Mobility Support in IPv6 > > Mobility support in IPv6 [RFC3775] relies on the use of an > encapsulation mechanism in flows between mobile nodes and their > correspondent nodes, involving the use of the type 2 IPv6 routing > header and the Home Address destination header option. It also relies on Mobility Header (nh 135) passing through, for instance for required CoTI/CoT messages exchanged between the MN and the CN, before traffic using HAO in DestOpt or RH2 is exchanged. IMHO, there should be a REC to support MH to pass through. Even inbound MH traffic: more on that below. > In contrast > to mobility support in IPv4, mobility is a standard feature of IPv6, > and no security benefit is generally to be gained by denying > communications with either interior or exterior mobile nodes. > > REC-25: The state records for flows initiated by outbound packets > that bear a Home Address destination option [RFC3775] are > distinguished by the addition of the home address of the flow as well > as the interior Care-of address. IPv6 gateways MUST NOT prohibit the > forwarding of any inbound packets bearing type 2 routing headers, > which otherwise match a flow state record, and where A) the > destination matches the home address of the flow, and B) the Home > Address field in the routing header matches the interior Care-of > address of the flow. I think the last sentence is wrong. It should IMHO be: IPv6 gateways MUST NOT prohibit the forwarding of any inbound packets bearing type 2 routing headers, which otherwise match a flow state record, and where A) the address in the destination field of the IPv6 header matches the interior Care-of Address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the Home Address of the flow. In more details, when a RO packet (e.g. TCP, MH, UDP, ...) is received by an internal MN from an external CN, its on-wire format is the following: IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP This is what the CPE will see. Additionally, this REC-25 supports an internal MN exchanging RO traffic with an external CN: MN --------- CPE ----------------- Internet -------------- CN ---- IPv6(src=CoA, dst=CN)/DestOpt(HOA(hoa=HoA))/TCP ----> <--- IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP ------- *but does not* support an internal CN (or MN) accepting bindings for an external MN, i.e.: CN --------- CPE ----------------- Internet -------------- MN (CoA, HoA) <--- IPv6(src=CoA, dst=CN)/DestOpt(HOA(hoa=HoA))/TCP ----- ---- IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP ------> is that out of scope or is it just missing? If that is not out of scope, a specific REC may be needed or REC-25 may be extended. Additionally, for that to be useful, inbound MH traffic need to be authorized. There is also another unrelated point associated with this REC-25: using TCP as an example, the CPE may not see the 3-way handshake between a MN and a CN if the TCP connection establishment is done via the tunnel to the Home Agent. Later, when this TCP traffic is route optimized, no TCP state exist in the CPE. I understand that REC-25 covers that with the "any" keyword in "IPv6 gateways MUST NOT prohibit the forwarding of *any* inbound packets bearing type 2 routing headers, ..." but I don't think it will be obvious for someone not familiar with the protocol that standard TCP RECs do not apply here, i.e. that somehow REC-25 applies before stateful rules. Stating it explictly in the document may help. Cheers, a+ From owner-v6ops@ops.ietf.org Thu Jul 15 11:53:45 2010 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 C66243A69DA for ; Thu, 15 Jul 2010 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.453 X-Spam-Level: X-Spam-Status: No, score=-107.453 tagged_above=-999 required=5 tests=[AWL=-2.095, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, 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 KbF+PXQOfItB for ; Thu, 15 Jul 2010 11:53:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D0643A684F for ; Thu, 15 Jul 2010 11:53:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZTTh-000OJd-GT for v6ops-data0@psg.com; Thu, 15 Jul 2010 18:48:13 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZTTd-000OJD-II for v6ops@ops.ietf.org; Thu, 15 Jul 2010 18:48:10 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAEb0PkyrR7Hu/2dsb2JhbAAvgRSeIQhxpEaafYUkBIhQ X-IronPort-AV: E=Sophos;i="4.55,210,1278288000"; d="scan'208,217";a="226930403" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2010 18:48:08 +0000 Received: from 72.24.242.10.in-addr.arpa ([10.21.75.216]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6FIlu7T004339 for ; Thu, 15 Jul 2010 18:47:58 GMT Received: from [127.0.0.1] by 72.24.242.10.in-addr.arpa (PGP Universal service); Thu, 15 Jul 2010 11:48:08 -0700 X-PGP-Universal: processed; by 72.24.242.10.in-addr.arpa on Thu, 15 Jul 2010 11:48:08 -0700 From: Fred Baker Subject: 3rd time: IPv6 Operations Agenda - IETF 78 Date: Thu, 15 Jul 2010 08:35:03 -0400 Message-Id: <051543C7-2139-48B0-96AC-164CAA00153C@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: multipart/alternative; boundary=Apple-Mail-3-242392575 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-3-242392575 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IPv6 Operations - IETF 78 Monday 13:00-14:59 Agenda bashing =20 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and = Proposed Mitigations 12-May-10, Security Concerns With IP Tunneling 8-Mar-10, Mobile Networks Considerations for IPv6 Deployment 12-Jul-10, Advanced Requirements for IPv6 Customer Edge Routers 8-Jul-10, IPv6 Multihoming without Network Address Translation 25-May-10, BBF Liaison: Functional Requirements for Broadband Residential Gateway = Devices TR-124 Issue 2 Friday 13:00-14:59 CIDR for IPv6: Address Aggregation 29-Jun-10, IPv6 Address Assignment to End Sites 12-Jul-10, Flexible DHCPv6 Prefix Delegation in Mobile Networks 10-May-10, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 18-Jun-10, A Basic Guideline for Listing ISPs that Run IPv6 11-Jun-10, http://www.ipinc.net/IPv4.GIF --Apple-Mail-3-242392575 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IPv6 Operations Agenda - IETF 78

IPv6 Operations - IETF 78

Monday 13:00-14:59

Agenda bashing
 
Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
12-May-10, <draft-nakibly-v6ops-tunnel-loops-02.txt>
Security Concerns With IP Tunneling
8-Mar-10, <draft-ietf-v6ops-tunnel-security-concerns-02.txt>
Mobile Networks Considerations for IPv6 Deployment
12-Jul-10, <draft-ietf-v6ops-v6-in-mobile-networks-01.txt>
Advanced Requirements for IPv6 Customer Edge Routers
8-Jul-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-03.txt>
IPv6 Multihoming without Network Address Translation
25-May-10, <draft-troan-multihoming-without-nat66-00.txt>
BBF Liaison: Functional Requirements for Broadband Residential Gateway Devices
TR-124 Issue 2

Friday 13:00-14:59

CIDR for IPv6: Address Aggregation
29-Jun-10, <draft-azinger-cidrv6-00.txt>
IPv6 Address Assignment to End Sites
12-Jul-10, <draft-narten-ipv6-3177bis-48boundary-05.txt>
Flexible DHCPv6 Prefix Delegation in Mobile Networks
10-May-10, <draft-sarikaya-v6ops-prefix-delegation-01.txt>
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
18-Jun-10, <draft-ietf-v6ops-incremental-cgn-01.txt>
A Basic Guideline for Listing ISPs that Run IPv6
11-Jun-10, <draft-kawamura-ipv6-isp-listings-00.txt>




--Apple-Mail-3-242392575-- From v6ops-archive@ietf.org Fri Jul 16 01:26:53 2010 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 8F82D3A6912 for ; Fri, 16 Jul 2010 01:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.281 X-Spam-Level: * X-Spam-Status: No, score=1.281 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_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 bdn+VjXBAzAG for ; Fri, 16 Jul 2010 01:26:51 -0700 (PDT) Received: from athedsl-287182.home.otenet.gr (athedsl-285895.home.otenet.gr [85.73.164.101]) by core3.amsl.com (Postfix) with SMTP id A36FA3A69BF for ; Fri, 16 Jul 2010 01:26:45 -0700 (PDT) From: Google Pharmacy Subject: Hotels follow airline playbook To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100716082645.A36FA3A69BF@core3.amsl.com> Date: Fri, 16 Jul 2010 01:26:45 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Fri Jul 16 07:44:22 2010 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 296083A69DD for ; Fri, 16 Jul 2010 07:44:22 -0700 (PDT) X-Quarantine-ID: <43pvaJXsDE5v> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...rchive@ietf.org Pharmacy \256 Official Site -12%\n X-Spam-Flag: NO X-Spam-Score: -22.659 X-Spam-Level: X-Spam-Status: No, score=-22.659 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, FM_DDDD_TIMES_2=1.999, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_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 43pvaJXsDE5v for ; Fri, 16 Jul 2010 07:44:21 -0700 (PDT) Received: from ip108-139-173-82.adsl2.static.versatel.nl (ip108-139-173-82.adsl2.static.versatel.nl [82.173.139.108]) by core3.amsl.com (Postfix) with SMTP id 037723A6986 for ; Fri, 16 Jul 2010 07:44:20 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org Pharmacy ® Official Site -12% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100716-0, 16-07-2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100716144421.037723A6986@core3.amsl.com> Date: Fri, 16 Jul 2010 07:44:20 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From v6ops-archive@ietf.org Fri Jul 16 09:25:54 2010 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 87BFB3A67F3 for ; Fri, 16 Jul 2010 09:25:54 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -37%\n X-Spam-Flag: NO X-Spam-Score: -9.137 X-Spam-Level: X-Spam-Status: No, score=-9.137 tagged_above=-999 required=5 tests=[AWL=-7.169, BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_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 htXBJCM25nYt for ; Fri, 16 Jul 2010 09:25:53 -0700 (PDT) Received: from 123-36-179-94.pool.ukrtel.net (123-36-179-94.pool.ukrtel.net [94.179.36.123]) by core3.amsl.com (Postfix) with SMTP id 479A73A682A for ; Fri, 16 Jul 2010 09:25:50 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -37% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100716162550.479A73A682A@core3.amsl.com> Date: Fri, 16 Jul 2010 09:25:50 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From vlacaixa@yahoo.com Fri Jul 16 10:18:00 2010 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 E9F583A6AA2 for ; Fri, 16 Jul 2010 10:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.953 X-Spam-Level: *** X-Spam-Status: No, score=3.953 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAq-vRC8sNaX for ; Fri, 16 Jul 2010 10:18:00 -0700 (PDT) Received: from web46414.mail.sp1.yahoo.com (web46414.mail.sp1.yahoo.com [68.180.199.203]) by core3.amsl.com (Postfix) with SMTP id 071EC3A6A9F for ; Fri, 16 Jul 2010 10:18:00 -0700 (PDT) Received: (qmail 90775 invoked by uid 60001); 16 Jul 2010 17:18:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279300690; bh=w95wjgNqwuLlI7cSw+QrFUNjNndjsMJU/ba+NW7AoLM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Mq/9A2KVV8vMdBQZ4A2H1tziodVvlf8L5jmsxenLcKcI8OcC0exAtVeHyPL0Zbnen6aGaVTgdkZ7/Y4aG/jpLQtINDUym0jhXTRyTkIIsR0IA6Nkl/c3xgIlX0RfPDjNiW8cIjJhRdn6oYS9bjR74VaBBWmwEgPXyoatNQQIMx4= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=jSKJ0Uej9L94PSe4ngGaWNkcRS706TXnAZfNecMdpPz7hnNCwZ2L34ZosJV+RrQFjVrTkT4Qxdjw52Nl8jbn7WoT8ULbSi7WJ/oBSUJRoKeBMWkr5d+4g4e7ot6SJtbR2tc6EJaIGdmrqeYFctGai5zdqaqFUiGt7kHGG4bCo6o=; Message-ID: <187638.89638.qm@web46414.mail.sp1.yahoo.com> X-YMail-OSG: HTdZlZUVM1lvUTAmIV5DuCfqCV835zqVUEFYhBe5MneiOLz L7S17Iv6zGCtocEz6U9pTKQIcJxQwL7t_xVoJ64mstf5gOojB7Lt5pXeVuko qZ2J73AkUKV1ASMnoxLkejUnzoBHS39Tf7J937mwONkUMqAIF92U3Z5In.8o T_lC5BD9pVjOq_kF0qeHiQ.lFred6Yhdz44L8u1T7oE_F6P.bKPPvuaIIKhu NHqC5tRimAYan1xp79gvzM2r7xKSDrOw39VTv.ZbxyugshXZnkFc1vYC9XO6 PU5s44lkXsEGQkfPvhRWllN9tT3zkr9SSBsLNOS_YsFusuoSaNMzf.Il3nEH x0VcQ20Uu9mEEU1tSG7MyimEORGUsMAyhXIE2vJI- Received: from [110.164.217.234] by web46414.mail.sp1.yahoo.com via HTTP; Fri, 16 Jul 2010 10:18:10 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.104.276605 Date: Fri, 16 Jul 2010 10:18:10 -0700 (PDT) From: STATE LOTTERY COMPANY Reply-To: statelottpaycenter@hotmail.com Subject: =?utf-8?B?KCgo2YXYqNix2YjZgykpKSDYp9mE2KjYsdmK2K8g2KfZhNin2YTZg9iq2LE=?= =?utf-8?B?2YjZhtmKINmI2YHYp9iyIDIwMTAg2KzYp9im2LLYqSDYp9mE2K/ZiNmE2Kkg?= =?utf-8?B?2KfZhNmK2KfZhti12YrYqA==?= To: undisclosed recipients: ; MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-724994542-1279300690=:89638" --0-724994542-1279300690=:89638 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =D8=AC=D8=A7=D8=A6=D8=B2=D8=A9 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7= =D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=88=D8=B7=D9=86= =D9=8A. 2010 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8= =AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9= =8A =D8=A7=D9=84=D9=81=D8=A7=D8=A6=D8=B2=D8=A9. =C2=A0 =D8=B3=D9=8A=D8=AF=D9=8A =D8=A7=D9=84=D8=A7=D9=86=D8=AA=D8=A8=D8=A7=D9=87 /= =D8=B3=D9=8A=D8=AF=D8=AA=D9=8A =D8=8C =D9=86=D8=B9=D9=84=D9=86 =D9=84=D9=83=D9=85 =D8=A8=D8=B3=D8=B9=D8=A7=D8=AF= =D8=A9 =D9=86=D8=AA=D9=8A=D8=AC=D8=A9 =D8=A7=D9=84=D8=AA=D8=B9=D8=A7=D8=AF= =D9=84 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83= =D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=B9=D9=86=D9=88=D8=A7=D9=86 = =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D9=84=D9=84=D8=AA=D9=88= =D8=AC=D9=87 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A=D8=A7= =D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AD=D9=85=D9=88=D9=84 =D8=A7= =D9=84=D8=AA=D9=8A =D8=B9=D9=82=D8=AF=D8=AA =D9=81=D9=8A =D9=8A=D9=88=D9=84= =D9=8A=D9=88 2010 =D9=81=D9=8A =D8=A7=D9=84=D9=88=D9=84=D8=A7=D9=8A=D8=A7= =D8=AA =D8=A7=D9=84=D9=85=D8=AA=D8=AD=D8=AF=D8=A9 =D8=A7=D9=84=D8=A3=D9=85= =D8=B1=D9=8A=D9=83=D9=8A=D8=A9. =D9=86=D9=88=D8=AF =D8=A3=D9=86 =D8=A3=D8=AD=D9=8A=D8=B7=D9=83=D9=85 =D8=B9= =D9=84=D9=85=D8=A7 =D8=A8=D8=A3=D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF = =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84= =D8=AE=D8=A7=D8=B5 =D8=A8=D9=83 =D9=88=D9=81=D8=A7=D8=B2 500=D8=8C000 =D8= =AF=D9=88=D9=84=D8=A7=D8=B1 =D9=85=D9=86 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8= =A9 =D8=A8=D8=B1=D9=86=D8=A7=D9=85=D8=AC =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8= =B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AA=D9=86=D9=82=D9=84=D8=A9 =D9=84=D9= =8A. =D9=83=D9=86=D8=AA =D8=A7=D9=84=D9=85=D8=B4=D9=88=D8=B1=D8=A9 =D8=A5= =D9=84=D9=89 =D8=A7=D9=84=D8=A7=D8=AA=D8=B5=D8=A7=D9=84 =D8=A7=D9=84=D8=A5= =D9=82=D9=84=D9=8A=D9=85=D9=8A=D8=A9 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5=D8=A9 = =D8=A8=D9=83 =D9=8A=D8=AF=D8=B9=D9=8A =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7= =D8=B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=B9=D9=84=D9=89 = =D8=A7=D9=84=D9=81=D9=88=D8=B1 =D8=B9=D9=86 =D8=B7=D8=B1=D9=8A=D9=82 =D8=A7= =D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83=D8=AA=D8=B1= =D9=88=D9=86=D9=8A =D8=A3=D9=88 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D9=88= =D9=85=D9=84=D9=81 =D8=A7=D9=84=D9=85=D8=B7=D8=A7=D9=84=D8=A8=D8=A9 =D8=A7= =D9=84=D8=AE=D8=A7=D8=B5 =D8=A8=D9=83. 1. =D8=A7=D8=B3=D9=85=D9=83 : 2. =D8=A8=D9=84=D8=AF=D9=83=D9=85 / =D8=A7=D9=84=D8=AC=D9=86=D8=B3=D9=8A=D8= =A9 : 3. =D8=B1=D9=82=D9=85 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D8=A7=D9=84=D8= =AE=D8=A7=D8=B5 =D8=A8=D9=83 : 4. =D8=A8=D9=83 =D8=A7=D9=84=D8=B3=D9=86 : 5.Your =D8=A7=D9=84=D8=A7=D8=AD=D8=AA=D9=84=D8=A7=D9=84. 6. =D8=A7=D9=84=D8=AF=D9=8A=D9=86 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5. 7. =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8= =AA=D8=B1=D9=88=D9=86=D9=8A : 8. =D9=88=D9=83=D8=A7=D9=86 =D8=AA=D8=A7=D8=B1=D9=8A=D8=AE =D8=A5=D8=B1=D8= =B3=D8=A7=D9=84 =D9=87=D8=B0=D9=87 =D8=A7=D9=84=D8=B1=D8=B3=D8=A7=D9=84=D8= =A9 =D9=84=D9=83 : =D8=A5=D8=B1=D8=B3=D8=A7=D9=84 =D8=A7=D9=84=D9=85=D8=B9=D9=84=D9=88=D9=85= =D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=B0=D9=83=D9=88=D8=B1=D8=A9 =D8=A3=D8=B9= =D9=84=D8=A7=D9=87 =D9=84=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1= =D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D9=88=D9=83=D9=8A=D9=84 : =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8= =A7=D8=B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA= =D8=B1=D9=88=D9=86=D9=8A : statelottpaycenter@hotmail.com =D9=87=D8=A7=D8=AA=D9=81 : +66845389520 =D9=88=D9=82=D8=B9=D8=AA =D8=8C =D8=A5=D8=AF=D8=A7=D8=B1=D8=A9 =D9=85=D8=A7=D8=B1=D9=8A=D8=A7 =D8=AC=D9=86=D8=B3=D9=86 =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D9=86= =D8=B3=D9=82 2010 =C2=A0 STATE NATIONAL LOTTERY AWARD. 2010 EMAIL WINNING PROMO. =C2=A0 Attention Sir/Madam, We happily announce to you the result of electronic email Address draw of S= tate mobile lottery promo draws held on July=C2=A0 2010 in U.S.A. we wish to inform you that your email have won $500,000 from the state mobi= le Lottery Program me. You are advise to Contact your regional=20 claims Dr Eric Gibson immediately through=C2=A0 email or phone and file you= r claim . 1. Your Name: 2. Your Country/Nationality: 3. Your Phone No: 4. Your Age: 5.Your Occupation. 6. Your Religion. 7. Your Email: 8. The Date This Message Was sent To You: Send the above information to Dr Eric Gibson Agent: Dr Eric Gibson Email: statelottpaycenter@hotmail.com Phone: +66845389520 Signed, Management Maria jenson Lottery coordinator 2010 =0A=0A=0A --0-724994542-1279300690=:89638 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=D8=AC=D8=A7=D8=A6=D8=B2=D8=A9 =D8= =A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9= =8A=D8=A8 =D8=A7=D9=84=D9=88=D8=B7=D9=86=D9=8A.
2010 =D8=A7=D9=84=D8=A8= =D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86= =D9=8A =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D8=A7=D9=84=D9=81= =D8=A7=D8=A6=D8=B2=D8=A9.
 
=D8=B3=D9=8A=D8=AF=D9=8A =D8=A7=D9=84=D8=A7=D9=86=D8=AA=D8=A8=D8=A7=D9= =87 / =D8=B3=D9=8A=D8=AF=D8=AA=D9=8A =D8=8C
=D9=86=D8=B9=D9=84=D9=86 =D9=84=D9=83=D9=85 =D8=A8=D8=B3=D8=B9=D8=A7= =D8=AF=D8=A9 =D9=86=D8=AA=D9=8A=D8=AC=D8=A9 =D8=A7=D9=84=D8=AA=D8=B9=D8=A7= =D8=AF=D9=84 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84= =D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=B9=D9=86=D9=88=D8=A7= =D9=86 =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D9=84=D9=84=D8=AA= =D9=88=D8=AC=D9=87 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A= =D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AD=D9=85=D9=88=D9=84 = =D8=A7=D9=84=D8=AA=D9=8A =D8=B9=D9=82=D8=AF=D8=AA =D9=81=D9=8A =D9=8A=D9=88= =D9=84=D9=8A=D9=88 2010 =D9=81=D9=8A =D8=A7=D9=84=D9=88=D9=84=D8=A7=D9=8A= =D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=AA=D8=AD=D8=AF=D8=A9 =D8=A7=D9=84=D8=A3= =D9=85=D8=B1=D9=8A=D9=83=D9=8A=D8=A9.
=D9=86=D9=88=D8=AF =D8=A3=D9=86 = =D8=A3=D8=AD=D9=8A=D8=B7=D9=83=D9=85 =D8=B9=D9=84=D9=85=D8=A7 =D8=A8=D8=A3= =D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83= =D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=AE=D8=A7=D8=B5 =D8=A8=D9=83 = =D9=88=D9=81=D8=A7=D8=B2 500=D8=8C000 =D8=AF=D9=88=D9=84=D8=A7=D8=B1 =D9=85= =D9=86 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A8=D8=B1=D9=86=D8=A7=D9=85= =D8=AC =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85= =D8=AA=D9=86=D9=82=D9=84=D8=A9 =D9=84=D9=8A. =D9=83=D9=86=D8=AA =D8=A7=D9= =84=D9=85=D8=B4=D9=88=D8=B1=D8=A9 =D8=A5=D9=84=D9=89 =D8=A7=D9=84=D8=A7=D8= =AA=D8=B5=D8=A7=D9=84 =D8=A7=D9=84=D8=A5=D9=82=D9=84=D9=8A=D9=85=D9=8A=D8= =A9 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5=D8=A9 =D8=A8=D9=83
=D9=8A=D8=AF=D8=B9= =D9=8A =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1=D9=8A=D9=83 = =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=B9=D9=84=D9=89 =D8=A7=D9=84=D9=81= =D9=88=D8=B1 =D8=B9=D9=86 =D8=B7=D8=B1=D9=8A=D9=82 =D8=A7=D9=84=D8=A8=D8=B1= =D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A = =D8=A3=D9=88 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D9=88=D9=85=D9=84=D9=81 = =D8=A7=D9=84=D9=85=D8=B7=D8=A7=D9=84=D8=A8=D8=A9 =D8=A7=D9=84=D8=AE=D8=A7= =D8=B5 =D8=A8=D9=83.

1. =D8=A7=D8=B3=D9=85=D9=83 :
2. =D8=A8=D9=84=D8=AF=D9=83=D9=85= / =D8=A7=D9=84=D8=AC=D9=86=D8=B3=D9=8A=D8=A9 :
3. =D8=B1=D9=82=D9=85 = =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5 =D8=A8= =D9=83 :
4. =D8=A8=D9=83 =D8=A7=D9=84=D8=B3=D9=86 :
5.Your =D8=A7=D9= =84=D8=A7=D8=AD=D8=AA=D9=84=D8=A7=D9=84.
6. =D8=A7=D9=84=D8=AF=D9=8A=D9= =86 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5.
7. =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8= =AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A :
8. = =D9=88=D9=83=D8=A7=D9=86 =D8=AA=D8=A7=D8=B1=D9=8A=D8=AE =D8=A5=D8=B1=D8=B3= =D8=A7=D9=84 =D9=87=D8=B0=D9=87 =D8=A7=D9=84=D8=B1=D8=B3=D8=A7=D9=84=D8=A9 = =D9=84=D9=83 :
=D8=A5=D8=B1=D8=B3=D8=A7=D9=84 =D8=A7=D9=84=D9=85=D8=B9=D9=84=D9=88=D9= =85=D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=B0=D9=83=D9=88=D8=B1=D8=A9 =D8=A3=D8= =B9=D9=84=D8=A7=D9=87 =D9=84=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8= =B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86
=D9=88=D9=83=D9=8A= =D9=84 : =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1=D9=8A=D9= =83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86
=D8=A7=D9=84=D8=A8=D8=B1=D9=8A= =D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A : statelottpaycenter@hotmail.com=
=D9=87=D8=A7=D8=AA=D9=81 : +66845389520
=D9=88=D9=82=D8=B9=D8=AA =D8=8C
=D8=A5=D8=AF=D8=A7=D8=B1=D8=A9
=D9=85=D8=A7=D8=B1=D9=8A=D8=A7 =D8=AC=D9=86=D8=B3=D9=86
=D8=A7=D9= =84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D9=86=D8=B3=D9= =82 2010
 

STATE NATIONAL LOTTERY AWARD.
2010 EMAIL WINNING PROMO.
 
Attention Sir/Madam,
We happily announce to you the result of electronic email Address draw= of State mobile lottery promo draws held on July  2010 in U.S.A.
w= e wish to inform you that your email have won $500,000 from the state mobil= e Lottery Program me. You are advise to Contact your regional
claims Dr= Eric Gibson immediately through  email or phone and file your claim .=

1. Your Name:
2. Your Country/Nationality:
3. Your Phone No:=
4. Your Age:
5.Your Occupation.
6. Your Religion.
7. Your Emai= l:
8. The Date This Message Was sent To You:
Send the above information to Dr Eric Gibson
Agent: Dr Eric Gibson<= BR>Email: statelottpaycen= ter@hotmail.com
Phone: +66845389520
Signed,
Management
Maria jenson
Lottery coordinator 2010

= =0A=0A --0-724994542-1279300690=:89638-- From vlacaixa@yahoo.com Fri Jul 16 10:21:21 2010 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 471B03A6A6A for ; Fri, 16 Jul 2010 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.953 X-Spam-Level: *** X-Spam-Status: No, score=3.953 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S59fCIeyjks9 for ; Fri, 16 Jul 2010 10:21:20 -0700 (PDT) Received: from web46415.mail.sp1.yahoo.com (web46415.mail.sp1.yahoo.com [68.180.199.204]) by core3.amsl.com (Postfix) with SMTP id 509913A68DC for ; Fri, 16 Jul 2010 10:21:20 -0700 (PDT) Received: (qmail 83848 invoked by uid 60001); 16 Jul 2010 17:21:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279300888; bh=YHNeyuiRJx0e3B6iYJTjLTCIlL5YiccfrwNCD/0x7Ho=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SS1msu4cZsqbuqUu8xYiNkbw7ujkFArZ0GeUzqv81jDMr5rUsLsDxMv8cpGaCfftljvmgfDfm+FV3kSsSRr+SVgz66Lff2XSWyByWL5BNmpSk2jmTYK4W2yDAmhtR5CLm8rC6+wCDg+YVFW38yKPVDtfTfAb0CP1chrfD74TzCE= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=HM7qK1k6p/FmnXdWYL2h5KAinBMBIXDaKE/GKuJp5+m0XXJ9EiKH90Jy2QsPUo1EZVAazuFuJPH20FmbRl4eWF5kD8kWsWLG+gwd2rUr/wYEpLUCPLOZRiZQwNUAjxCj8rP6sZpAAxvtHY/RjNEs6aeECwCf2KIQTqHn6+GjQqo=; Message-ID: <86925.82239.qm@web46415.mail.sp1.yahoo.com> X-YMail-OSG: V70OPSMVM1lIJ2C6XqUF46wY7YrrFavhDU5K6F.EOYc3nVC nBqeWQeEXdzVWQMqSPq.Qz1Hlk6JCrhrHBDWUsM9bbp09ybee.mTNZ1iYpvH 2bFLqJR3yElvfjAbekjDMOPlbDUUUFuxdQIUl7k3aY1YnwCRn6Pf0U4GdpC3 l_jRWijlQW76P2chpgbHk7HreTs5QOXYQ5qGZC2GHiwkBgpMgob8j.aboSml YBboLVkyoLzbHjsxE5adF3iZqSrFFFMw6QlRZ4r0QlO737lcSGWkey0km9Nb P7iFbgp_..BVsK8fP6hWn4YQhjR7xEz.iwqWLdg31qNMhxNPJZqEY5XKVRWp ihhfnRZphdCKuEr9HBlw9mWFrbt60RKhFJMLgWZo- Received: from [110.164.217.234] by web46415.mail.sp1.yahoo.com via HTTP; Fri, 16 Jul 2010 10:21:27 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.104.276605 Date: Fri, 16 Jul 2010 10:21:27 -0700 (PDT) From: STATE LOTTERY COMPANY Reply-To: statelottpaycenter@hotmail.com Subject: =?utf-8?B?KCgo2YXYqNix2YjZgykpKSDYp9mE2KjYsdmK2K8g2KfZhNin2YTZg9iq2LE=?= =?utf-8?B?2YjZhtmKINmI2YHYp9iyIDIwMTAg2KzYp9im2LLYqSDYp9mE2K/ZiNmE2Kkg?= =?utf-8?B?2KfZhNmK2KfZhti12YrYqA==?= To: undisclosed recipients: ; MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-374024500-1279300887=:82239" --0-374024500-1279300887=:82239 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =D8=AC=D8=A7=D8=A6=D8=B2=D8=A9 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7= =D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=88=D8=B7=D9=86= =D9=8A. 2010 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8= =AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9= =8A =D8=A7=D9=84=D9=81=D8=A7=D8=A6=D8=B2=D8=A9. =C2=A0 =D8=B3=D9=8A=D8=AF=D9=8A =D8=A7=D9=84=D8=A7=D9=86=D8=AA=D8=A8=D8=A7=D9=87 /= =D8=B3=D9=8A=D8=AF=D8=AA=D9=8A =D8=8C =D9=86=D8=B9=D9=84=D9=86 =D9=84=D9=83=D9=85 =D8=A8=D8=B3=D8=B9=D8=A7=D8=AF= =D8=A9 =D9=86=D8=AA=D9=8A=D8=AC=D8=A9 =D8=A7=D9=84=D8=AA=D8=B9=D8=A7=D8=AF= =D9=84 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83= =D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=B9=D9=86=D9=88=D8=A7=D9=86 = =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D9=84=D9=84=D8=AA=D9=88= =D8=AC=D9=87 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A=D8=A7= =D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AD=D9=85=D9=88=D9=84 =D8=A7= =D9=84=D8=AA=D9=8A =D8=B9=D9=82=D8=AF=D8=AA =D9=81=D9=8A =D9=8A=D9=88=D9=84= =D9=8A=D9=88 2010 =D9=81=D9=8A =D8=A7=D9=84=D9=88=D9=84=D8=A7=D9=8A=D8=A7= =D8=AA =D8=A7=D9=84=D9=85=D8=AA=D8=AD=D8=AF=D8=A9 =D8=A7=D9=84=D8=A3=D9=85= =D8=B1=D9=8A=D9=83=D9=8A=D8=A9. =D9=86=D9=88=D8=AF =D8=A3=D9=86 =D8=A3=D8=AD=D9=8A=D8=B7=D9=83=D9=85 =D8=B9= =D9=84=D9=85=D8=A7 =D8=A8=D8=A3=D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF = =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84= =D8=AE=D8=A7=D8=B5 =D8=A8=D9=83 =D9=88=D9=81=D8=A7=D8=B2 500=D8=8C000 =D8= =AF=D9=88=D9=84=D8=A7=D8=B1 =D9=85=D9=86 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8= =A9 =D8=A8=D8=B1=D9=86=D8=A7=D9=85=D8=AC =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8= =B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AA=D9=86=D9=82=D9=84=D8=A9 =D9=84=D9= =8A. =D9=83=D9=86=D8=AA =D8=A7=D9=84=D9=85=D8=B4=D9=88=D8=B1=D8=A9 =D8=A5= =D9=84=D9=89 =D8=A7=D9=84=D8=A7=D8=AA=D8=B5=D8=A7=D9=84 =D8=A7=D9=84=D8=A5= =D9=82=D9=84=D9=8A=D9=85=D9=8A=D8=A9 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5=D8=A9 = =D8=A8=D9=83 =D9=8A=D8=AF=D8=B9=D9=8A =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7= =D8=B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=B9=D9=84=D9=89 = =D8=A7=D9=84=D9=81=D9=88=D8=B1 =D8=B9=D9=86 =D8=B7=D8=B1=D9=8A=D9=82 =D8=A7= =D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83=D8=AA=D8=B1= =D9=88=D9=86=D9=8A =D8=A3=D9=88 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D9=88= =D9=85=D9=84=D9=81 =D8=A7=D9=84=D9=85=D8=B7=D8=A7=D9=84=D8=A8=D8=A9 =D8=A7= =D9=84=D8=AE=D8=A7=D8=B5 =D8=A8=D9=83. 1. =D8=A7=D8=B3=D9=85=D9=83 : 2. =D8=A8=D9=84=D8=AF=D9=83=D9=85 / =D8=A7=D9=84=D8=AC=D9=86=D8=B3=D9=8A=D8= =A9 : 3. =D8=B1=D9=82=D9=85 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D8=A7=D9=84=D8= =AE=D8=A7=D8=B5 =D8=A8=D9=83 : 4. =D8=A8=D9=83 =D8=A7=D9=84=D8=B3=D9=86 : 5.Your =D8=A7=D9=84=D8=A7=D8=AD=D8=AA=D9=84=D8=A7=D9=84. 6. =D8=A7=D9=84=D8=AF=D9=8A=D9=86 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5. 7. =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8= =AA=D8=B1=D9=88=D9=86=D9=8A : 8. =D9=88=D9=83=D8=A7=D9=86 =D8=AA=D8=A7=D8=B1=D9=8A=D8=AE =D8=A5=D8=B1=D8= =B3=D8=A7=D9=84 =D9=87=D8=B0=D9=87 =D8=A7=D9=84=D8=B1=D8=B3=D8=A7=D9=84=D8= =A9 =D9=84=D9=83 : =D8=A5=D8=B1=D8=B3=D8=A7=D9=84 =D8=A7=D9=84=D9=85=D8=B9=D9=84=D9=88=D9=85= =D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=B0=D9=83=D9=88=D8=B1=D8=A9 =D8=A3=D8=B9= =D9=84=D8=A7=D9=87 =D9=84=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1= =D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D9=88=D9=83=D9=8A=D9=84 : =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8= =A7=D8=B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA= =D8=B1=D9=88=D9=86=D9=8A : statelottpaycenter@hotmail.com =D9=87=D8=A7=D8=AA=D9=81 : +66845389520 =D9=88=D9=82=D8=B9=D8=AA =D8=8C =D8=A5=D8=AF=D8=A7=D8=B1=D8=A9 =D9=85=D8=A7=D8=B1=D9=8A=D8=A7 =D8=AC=D9=86=D8=B3=D9=86 =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D9=86= =D8=B3=D9=82 2010 =C2=A0 STATE NATIONAL LOTTERY AWARD. 2010 EMAIL WINNING PROMO. =C2=A0 Attention Sir/Madam, We happily announce to you the result of electronic email Address draw of S= tate mobile lottery promo draws held on July=C2=A0 2010 in U.S.A. we wish to inform you that your email have won $500,000 from the state mobi= le Lottery Program me. You are advise to Contact your regional=20 claims Dr Eric Gibson immediately through=C2=A0 email or phone and file you= r claim . 1. Your Name: 2. Your Country/Nationality: 3. Your Phone No: 4. Your Age: 5.Your Occupation. 6. Your Religion. 7. Your Email: 8. The Date This Message Was sent To You: Send the above information to Dr Eric Gibson Agent: Dr Eric Gibson Email: statelottpaycenter@hotmail.com Phone: +66845389520 Signed, Management Maria jenson Lottery coordinator 2010 =0A=0A=0A --0-374024500-1279300887=:82239 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=D8=AC=D8=A7=D8=A6=D8=B2=D8=A9 =D8= =A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9= =8A=D8=A8 =D8=A7=D9=84=D9=88=D8=B7=D9=86=D9=8A.
2010 =D8=A7=D9=84=D8=A8= =D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86= =D9=8A =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D8=A7=D9=84=D9=81= =D8=A7=D8=A6=D8=B2=D8=A9.
 
=D8=B3=D9=8A=D8=AF=D9=8A =D8=A7=D9=84=D8=A7=D9=86=D8=AA=D8=A8=D8=A7=D9= =87 / =D8=B3=D9=8A=D8=AF=D8=AA=D9=8A =D8=8C
=D9=86=D8=B9=D9=84=D9=86 =D9=84=D9=83=D9=85 =D8=A8=D8=B3=D8=B9=D8=A7= =D8=AF=D8=A9 =D9=86=D8=AA=D9=8A=D8=AC=D8=A9 =D8=A7=D9=84=D8=AA=D8=B9=D8=A7= =D8=AF=D9=84 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84= =D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=B9=D9=86=D9=88=D8=A7= =D9=86 =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D9=84=D9=84=D8=AA= =D9=88=D8=AC=D9=87 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A= =D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AD=D9=85=D9=88=D9=84 = =D8=A7=D9=84=D8=AA=D9=8A =D8=B9=D9=82=D8=AF=D8=AA =D9=81=D9=8A =D9=8A=D9=88= =D9=84=D9=8A=D9=88 2010 =D9=81=D9=8A =D8=A7=D9=84=D9=88=D9=84=D8=A7=D9=8A= =D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=AA=D8=AD=D8=AF=D8=A9 =D8=A7=D9=84=D8=A3= =D9=85=D8=B1=D9=8A=D9=83=D9=8A=D8=A9.
=D9=86=D9=88=D8=AF =D8=A3=D9=86 = =D8=A3=D8=AD=D9=8A=D8=B7=D9=83=D9=85 =D8=B9=D9=84=D9=85=D8=A7 =D8=A8=D8=A3= =D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83= =D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=AE=D8=A7=D8=B5 =D8=A8=D9=83 = =D9=88=D9=81=D8=A7=D8=B2 500=D8=8C000 =D8=AF=D9=88=D9=84=D8=A7=D8=B1 =D9=85= =D9=86 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A8=D8=B1=D9=86=D8=A7=D9=85= =D8=AC =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85= =D8=AA=D9=86=D9=82=D9=84=D8=A9 =D9=84=D9=8A. =D9=83=D9=86=D8=AA =D8=A7=D9= =84=D9=85=D8=B4=D9=88=D8=B1=D8=A9 =D8=A5=D9=84=D9=89 =D8=A7=D9=84=D8=A7=D8= =AA=D8=B5=D8=A7=D9=84 =D8=A7=D9=84=D8=A5=D9=82=D9=84=D9=8A=D9=85=D9=8A=D8= =A9 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5=D8=A9 =D8=A8=D9=83
=D9=8A=D8=AF=D8=B9= =D9=8A =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1=D9=8A=D9=83 = =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=B9=D9=84=D9=89 =D8=A7=D9=84=D9=81= =D9=88=D8=B1 =D8=B9=D9=86 =D8=B7=D8=B1=D9=8A=D9=82 =D8=A7=D9=84=D8=A8=D8=B1= =D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A = =D8=A3=D9=88 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D9=88=D9=85=D9=84=D9=81 = =D8=A7=D9=84=D9=85=D8=B7=D8=A7=D9=84=D8=A8=D8=A9 =D8=A7=D9=84=D8=AE=D8=A7= =D8=B5 =D8=A8=D9=83.

1. =D8=A7=D8=B3=D9=85=D9=83 :
2. =D8=A8=D9=84=D8=AF=D9=83=D9=85= / =D8=A7=D9=84=D8=AC=D9=86=D8=B3=D9=8A=D8=A9 :
3. =D8=B1=D9=82=D9=85 = =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5 =D8=A8= =D9=83 :
4. =D8=A8=D9=83 =D8=A7=D9=84=D8=B3=D9=86 :
5.Your =D8=A7=D9= =84=D8=A7=D8=AD=D8=AA=D9=84=D8=A7=D9=84.
6. =D8=A7=D9=84=D8=AF=D9=8A=D9= =86 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5.
7. =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8= =AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A :
8. = =D9=88=D9=83=D8=A7=D9=86 =D8=AA=D8=A7=D8=B1=D9=8A=D8=AE =D8=A5=D8=B1=D8=B3= =D8=A7=D9=84 =D9=87=D8=B0=D9=87 =D8=A7=D9=84=D8=B1=D8=B3=D8=A7=D9=84=D8=A9 = =D9=84=D9=83 :
=D8=A5=D8=B1=D8=B3=D8=A7=D9=84 =D8=A7=D9=84=D9=85=D8=B9=D9=84=D9=88=D9= =85=D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=B0=D9=83=D9=88=D8=B1=D8=A9 =D8=A3=D8= =B9=D9=84=D8=A7=D9=87 =D9=84=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8= =B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86
=D9=88=D9=83=D9=8A= =D9=84 : =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1=D9=8A=D9= =83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86
=D8=A7=D9=84=D8=A8=D8=B1=D9=8A= =D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A : statelottpaycenter@hotmail.com=
=D9=87=D8=A7=D8=AA=D9=81 : +66845389520
=D9=88=D9=82=D8=B9=D8=AA =D8=8C
=D8=A5=D8=AF=D8=A7=D8=B1=D8=A9
=D9=85=D8=A7=D8=B1=D9=8A=D8=A7 =D8=AC=D9=86=D8=B3=D9=86
=D8=A7=D9= =84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D9=86=D8=B3=D9= =82 2010
 

STATE NATIONAL LOTTERY AWARD.
2010 EMAIL WINNING PROMO.
 
Attention Sir/Madam,
We happily announce to you the result of electronic email Address draw= of State mobile lottery promo draws held on July  2010 in U.S.A.
w= e wish to inform you that your email have won $500,000 from the state mobil= e Lottery Program me. You are advise to Contact your regional
claims Dr= Eric Gibson immediately through  email or phone and file your claim .=

1. Your Name:
2. Your Country/Nationality:
3. Your Phone No:=
4. Your Age:
5.Your Occupation.
6. Your Religion.
7. Your Emai= l:
8. The Date This Message Was sent To You:
Send the above information to Dr Eric Gibson
Agent: Dr Eric Gibson<= BR>Email: statelottpaycen= ter@hotmail.com
Phone: +66845389520
Signed,
Management
Maria jenson
Lottery coordinator 2010

= =0A=0A=0A=0A=0A=0A=0A=0A --0-374024500-1279300887=:82239-- From vlacaixa@yahoo.com Fri Jul 16 10:21:25 2010 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 21F163A68DD for ; Fri, 16 Jul 2010 10:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.953 X-Spam-Level: *** X-Spam-Status: No, score=3.953 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUk0X6WMHtrQ for ; Fri, 16 Jul 2010 10:21:25 -0700 (PDT) Received: from web46415.mail.sp1.yahoo.com (web46415.mail.sp1.yahoo.com [68.180.199.204]) by core3.amsl.com (Postfix) with SMTP id 075F63A68DC for ; Fri, 16 Jul 2010 10:21:25 -0700 (PDT) Received: (qmail 83848 invoked by uid 60001); 16 Jul 2010 17:21:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279300888; bh=YHNeyuiRJx0e3B6iYJTjLTCIlL5YiccfrwNCD/0x7Ho=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SS1msu4cZsqbuqUu8xYiNkbw7ujkFArZ0GeUzqv81jDMr5rUsLsDxMv8cpGaCfftljvmgfDfm+FV3kSsSRr+SVgz66Lff2XSWyByWL5BNmpSk2jmTYK4W2yDAmhtR5CLm8rC6+wCDg+YVFW38yKPVDtfTfAb0CP1chrfD74TzCE= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=HM7qK1k6p/FmnXdWYL2h5KAinBMBIXDaKE/GKuJp5+m0XXJ9EiKH90Jy2QsPUo1EZVAazuFuJPH20FmbRl4eWF5kD8kWsWLG+gwd2rUr/wYEpLUCPLOZRiZQwNUAjxCj8rP6sZpAAxvtHY/RjNEs6aeECwCf2KIQTqHn6+GjQqo=; Message-ID: <86925.82239.qm@web46415.mail.sp1.yahoo.com> X-YMail-OSG: V70OPSMVM1lIJ2C6XqUF46wY7YrrFavhDU5K6F.EOYc3nVC nBqeWQeEXdzVWQMqSPq.Qz1Hlk6JCrhrHBDWUsM9bbp09ybee.mTNZ1iYpvH 2bFLqJR3yElvfjAbekjDMOPlbDUUUFuxdQIUl7k3aY1YnwCRn6Pf0U4GdpC3 l_jRWijlQW76P2chpgbHk7HreTs5QOXYQ5qGZC2GHiwkBgpMgob8j.aboSml YBboLVkyoLzbHjsxE5adF3iZqSrFFFMw6QlRZ4r0QlO737lcSGWkey0km9Nb P7iFbgp_..BVsK8fP6hWn4YQhjR7xEz.iwqWLdg31qNMhxNPJZqEY5XKVRWp ihhfnRZphdCKuEr9HBlw9mWFrbt60RKhFJMLgWZo- Received: from [110.164.217.234] by web46415.mail.sp1.yahoo.com via HTTP; Fri, 16 Jul 2010 10:21:27 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.104.276605 Date: Fri, 16 Jul 2010 10:21:27 -0700 (PDT) From: STATE LOTTERY COMPANY Reply-To: statelottpaycenter@hotmail.com Subject: =?utf-8?B?KCgo2YXYqNix2YjZgykpKSDYp9mE2KjYsdmK2K8g2KfZhNin2YTZg9iq2LE=?= =?utf-8?B?2YjZhtmKINmI2YHYp9iyIDIwMTAg2KzYp9im2LLYqSDYp9mE2K/ZiNmE2Kkg?= =?utf-8?B?2KfZhNmK2KfZhti12YrYqA==?= To: undisclosed recipients: ; MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-374024500-1279300887=:82239" --0-374024500-1279300887=:82239 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =D8=AC=D8=A7=D8=A6=D8=B2=D8=A9 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7= =D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=88=D8=B7=D9=86= =D9=8A. 2010 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8= =AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9= =8A =D8=A7=D9=84=D9=81=D8=A7=D8=A6=D8=B2=D8=A9. =C2=A0 =D8=B3=D9=8A=D8=AF=D9=8A =D8=A7=D9=84=D8=A7=D9=86=D8=AA=D8=A8=D8=A7=D9=87 /= =D8=B3=D9=8A=D8=AF=D8=AA=D9=8A =D8=8C =D9=86=D8=B9=D9=84=D9=86 =D9=84=D9=83=D9=85 =D8=A8=D8=B3=D8=B9=D8=A7=D8=AF= =D8=A9 =D9=86=D8=AA=D9=8A=D8=AC=D8=A9 =D8=A7=D9=84=D8=AA=D8=B9=D8=A7=D8=AF= =D9=84 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83= =D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=B9=D9=86=D9=88=D8=A7=D9=86 = =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D9=84=D9=84=D8=AA=D9=88= =D8=AC=D9=87 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A=D8=A7= =D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AD=D9=85=D9=88=D9=84 =D8=A7= =D9=84=D8=AA=D9=8A =D8=B9=D9=82=D8=AF=D8=AA =D9=81=D9=8A =D9=8A=D9=88=D9=84= =D9=8A=D9=88 2010 =D9=81=D9=8A =D8=A7=D9=84=D9=88=D9=84=D8=A7=D9=8A=D8=A7= =D8=AA =D8=A7=D9=84=D9=85=D8=AA=D8=AD=D8=AF=D8=A9 =D8=A7=D9=84=D8=A3=D9=85= =D8=B1=D9=8A=D9=83=D9=8A=D8=A9. =D9=86=D9=88=D8=AF =D8=A3=D9=86 =D8=A3=D8=AD=D9=8A=D8=B7=D9=83=D9=85 =D8=B9= =D9=84=D9=85=D8=A7 =D8=A8=D8=A3=D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF = =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84= =D8=AE=D8=A7=D8=B5 =D8=A8=D9=83 =D9=88=D9=81=D8=A7=D8=B2 500=D8=8C000 =D8= =AF=D9=88=D9=84=D8=A7=D8=B1 =D9=85=D9=86 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8= =A9 =D8=A8=D8=B1=D9=86=D8=A7=D9=85=D8=AC =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8= =B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AA=D9=86=D9=82=D9=84=D8=A9 =D9=84=D9= =8A. =D9=83=D9=86=D8=AA =D8=A7=D9=84=D9=85=D8=B4=D9=88=D8=B1=D8=A9 =D8=A5= =D9=84=D9=89 =D8=A7=D9=84=D8=A7=D8=AA=D8=B5=D8=A7=D9=84 =D8=A7=D9=84=D8=A5= =D9=82=D9=84=D9=8A=D9=85=D9=8A=D8=A9 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5=D8=A9 = =D8=A8=D9=83 =D9=8A=D8=AF=D8=B9=D9=8A =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7= =D8=B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=B9=D9=84=D9=89 = =D8=A7=D9=84=D9=81=D9=88=D8=B1 =D8=B9=D9=86 =D8=B7=D8=B1=D9=8A=D9=82 =D8=A7= =D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83=D8=AA=D8=B1= =D9=88=D9=86=D9=8A =D8=A3=D9=88 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D9=88= =D9=85=D9=84=D9=81 =D8=A7=D9=84=D9=85=D8=B7=D8=A7=D9=84=D8=A8=D8=A9 =D8=A7= =D9=84=D8=AE=D8=A7=D8=B5 =D8=A8=D9=83. 1. =D8=A7=D8=B3=D9=85=D9=83 : 2. =D8=A8=D9=84=D8=AF=D9=83=D9=85 / =D8=A7=D9=84=D8=AC=D9=86=D8=B3=D9=8A=D8= =A9 : 3. =D8=B1=D9=82=D9=85 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D8=A7=D9=84=D8= =AE=D8=A7=D8=B5 =D8=A8=D9=83 : 4. =D8=A8=D9=83 =D8=A7=D9=84=D8=B3=D9=86 : 5.Your =D8=A7=D9=84=D8=A7=D8=AD=D8=AA=D9=84=D8=A7=D9=84. 6. =D8=A7=D9=84=D8=AF=D9=8A=D9=86 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5. 7. =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8= =AA=D8=B1=D9=88=D9=86=D9=8A : 8. =D9=88=D9=83=D8=A7=D9=86 =D8=AA=D8=A7=D8=B1=D9=8A=D8=AE =D8=A5=D8=B1=D8= =B3=D8=A7=D9=84 =D9=87=D8=B0=D9=87 =D8=A7=D9=84=D8=B1=D8=B3=D8=A7=D9=84=D8= =A9 =D9=84=D9=83 : =D8=A5=D8=B1=D8=B3=D8=A7=D9=84 =D8=A7=D9=84=D9=85=D8=B9=D9=84=D9=88=D9=85= =D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=B0=D9=83=D9=88=D8=B1=D8=A9 =D8=A3=D8=B9= =D9=84=D8=A7=D9=87 =D9=84=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1= =D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D9=88=D9=83=D9=8A=D9=84 : =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8= =A7=D8=B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA= =D8=B1=D9=88=D9=86=D9=8A : statelottpaycenter@hotmail.com =D9=87=D8=A7=D8=AA=D9=81 : +66845389520 =D9=88=D9=82=D8=B9=D8=AA =D8=8C =D8=A5=D8=AF=D8=A7=D8=B1=D8=A9 =D9=85=D8=A7=D8=B1=D9=8A=D8=A7 =D8=AC=D9=86=D8=B3=D9=86 =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D9=86= =D8=B3=D9=82 2010 =C2=A0 STATE NATIONAL LOTTERY AWARD. 2010 EMAIL WINNING PROMO. =C2=A0 Attention Sir/Madam, We happily announce to you the result of electronic email Address draw of S= tate mobile lottery promo draws held on July=C2=A0 2010 in U.S.A. we wish to inform you that your email have won $500,000 from the state mobi= le Lottery Program me. You are advise to Contact your regional=20 claims Dr Eric Gibson immediately through=C2=A0 email or phone and file you= r claim . 1. Your Name: 2. Your Country/Nationality: 3. Your Phone No: 4. Your Age: 5.Your Occupation. 6. Your Religion. 7. Your Email: 8. The Date This Message Was sent To You: Send the above information to Dr Eric Gibson Agent: Dr Eric Gibson Email: statelottpaycenter@hotmail.com Phone: +66845389520 Signed, Management Maria jenson Lottery coordinator 2010 =0A=0A=0A --0-374024500-1279300887=:82239 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=D8=AC=D8=A7=D8=A6=D8=B2=D8=A9 =D8= =A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9= =8A=D8=A8 =D8=A7=D9=84=D9=88=D8=B7=D9=86=D9=8A.
2010 =D8=A7=D9=84=D8=A8= =D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86= =D9=8A =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D8=A7=D9=84=D9=81= =D8=A7=D8=A6=D8=B2=D8=A9.
 
=D8=B3=D9=8A=D8=AF=D9=8A =D8=A7=D9=84=D8=A7=D9=86=D8=AA=D8=A8=D8=A7=D9= =87 / =D8=B3=D9=8A=D8=AF=D8=AA=D9=8A =D8=8C
=D9=86=D8=B9=D9=84=D9=86 =D9=84=D9=83=D9=85 =D8=A8=D8=B3=D8=B9=D8=A7= =D8=AF=D8=A9 =D9=86=D8=AA=D9=8A=D8=AC=D8=A9 =D8=A7=D9=84=D8=AA=D8=B9=D8=A7= =D8=AF=D9=84 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84= =D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=B9=D9=86=D9=88=D8=A7= =D9=86 =D8=A7=D9=84=D8=AA=D8=B1=D9=88=D9=8A=D8=AC=D9=8A =D9=84=D9=84=D8=AA= =D9=88=D8=AC=D9=87 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A7=D9=84=D9=8A= =D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D8=AD=D9=85=D9=88=D9=84 = =D8=A7=D9=84=D8=AA=D9=8A =D8=B9=D9=82=D8=AF=D8=AA =D9=81=D9=8A =D9=8A=D9=88= =D9=84=D9=8A=D9=88 2010 =D9=81=D9=8A =D8=A7=D9=84=D9=88=D9=84=D8=A7=D9=8A= =D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=AA=D8=AD=D8=AF=D8=A9 =D8=A7=D9=84=D8=A3= =D9=85=D8=B1=D9=8A=D9=83=D9=8A=D8=A9.
=D9=86=D9=88=D8=AF =D8=A3=D9=86 = =D8=A3=D8=AD=D9=8A=D8=B7=D9=83=D9=85 =D8=B9=D9=84=D9=85=D8=A7 =D8=A8=D8=A3= =D9=86 =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83= =D8=AA=D8=B1=D9=88=D9=86=D9=8A =D8=A7=D9=84=D8=AE=D8=A7=D8=B5 =D8=A8=D9=83 = =D9=88=D9=81=D8=A7=D8=B2 500=D8=8C000 =D8=AF=D9=88=D9=84=D8=A7=D8=B1 =D9=85= =D9=86 =D8=A7=D9=84=D8=AF=D9=88=D9=84=D8=A9 =D8=A8=D8=B1=D9=86=D8=A7=D9=85= =D8=AC =D8=A7=D9=84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85= =D8=AA=D9=86=D9=82=D9=84=D8=A9 =D9=84=D9=8A. =D9=83=D9=86=D8=AA =D8=A7=D9= =84=D9=85=D8=B4=D9=88=D8=B1=D8=A9 =D8=A5=D9=84=D9=89 =D8=A7=D9=84=D8=A7=D8= =AA=D8=B5=D8=A7=D9=84 =D8=A7=D9=84=D8=A5=D9=82=D9=84=D9=8A=D9=85=D9=8A=D8= =A9 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5=D8=A9 =D8=A8=D9=83
=D9=8A=D8=AF=D8=B9= =D9=8A =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1=D9=8A=D9=83 = =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86 =D8=B9=D9=84=D9=89 =D8=A7=D9=84=D9=81= =D9=88=D8=B1 =D8=B9=D9=86 =D8=B7=D8=B1=D9=8A=D9=82 =D8=A7=D9=84=D8=A8=D8=B1= =D9=8A=D8=AF =D8=A7=D9=84=D8=A7=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A = =D8=A3=D9=88 =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D9=88=D9=85=D9=84=D9=81 = =D8=A7=D9=84=D9=85=D8=B7=D8=A7=D9=84=D8=A8=D8=A9 =D8=A7=D9=84=D8=AE=D8=A7= =D8=B5 =D8=A8=D9=83.

1. =D8=A7=D8=B3=D9=85=D9=83 :
2. =D8=A8=D9=84=D8=AF=D9=83=D9=85= / =D8=A7=D9=84=D8=AC=D9=86=D8=B3=D9=8A=D8=A9 :
3. =D8=B1=D9=82=D9=85 = =D8=A7=D9=84=D9=87=D8=A7=D8=AA=D9=81 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5 =D8=A8= =D9=83 :
4. =D8=A8=D9=83 =D8=A7=D9=84=D8=B3=D9=86 :
5.Your =D8=A7=D9= =84=D8=A7=D8=AD=D8=AA=D9=84=D8=A7=D9=84.
6. =D8=A7=D9=84=D8=AF=D9=8A=D9= =86 =D8=A7=D9=84=D8=AE=D8=A7=D8=B5.
7. =D8=A7=D9=84=D8=A8=D8=B1=D9=8A=D8= =AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A :
8. = =D9=88=D9=83=D8=A7=D9=86 =D8=AA=D8=A7=D8=B1=D9=8A=D8=AE =D8=A5=D8=B1=D8=B3= =D8=A7=D9=84 =D9=87=D8=B0=D9=87 =D8=A7=D9=84=D8=B1=D8=B3=D8=A7=D9=84=D8=A9 = =D9=84=D9=83 :
=D8=A5=D8=B1=D8=B3=D8=A7=D9=84 =D8=A7=D9=84=D9=85=D8=B9=D9=84=D9=88=D9= =85=D8=A7=D8=AA =D8=A7=D9=84=D9=85=D8=B0=D9=83=D9=88=D8=B1=D8=A9 =D8=A3=D8= =B9=D9=84=D8=A7=D9=87 =D9=84=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8= =B1=D9=8A=D9=83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86
=D9=88=D9=83=D9=8A= =D9=84 : =D8=A7=D9=84=D8=AF=D9=83=D8=AA=D9=88=D8=B1 =D8=A7=D8=B1=D9=8A=D9= =83 =D8=AC=D9=8A=D8=A8=D8=B3=D9=88=D9=86
=D8=A7=D9=84=D8=A8=D8=B1=D9=8A= =D8=AF =D8=A7=D9=84=D8=A5=D9=84=D9=83=D8=AA=D8=B1=D9=88=D9=86=D9=8A : statelottpaycenter@hotmail.com=
=D9=87=D8=A7=D8=AA=D9=81 : +66845389520
=D9=88=D9=82=D8=B9=D8=AA =D8=8C
=D8=A5=D8=AF=D8=A7=D8=B1=D8=A9
=D9=85=D8=A7=D8=B1=D9=8A=D8=A7 =D8=AC=D9=86=D8=B3=D9=86
=D8=A7=D9= =84=D9=8A=D8=A7=D9=86=D8=B5=D9=8A=D8=A8 =D8=A7=D9=84=D9=85=D9=86=D8=B3=D9= =82 2010
 

STATE NATIONAL LOTTERY AWARD.
2010 EMAIL WINNING PROMO.
 
Attention Sir/Madam,
We happily announce to you the result of electronic email Address draw= of State mobile lottery promo draws held on July  2010 in U.S.A.
w= e wish to inform you that your email have won $500,000 from the state mobil= e Lottery Program me. You are advise to Contact your regional
claims Dr= Eric Gibson immediately through  email or phone and file your claim .=

1. Your Name:
2. Your Country/Nationality:
3. Your Phone No:=
4. Your Age:
5.Your Occupation.
6. Your Religion.
7. Your Emai= l:
8. The Date This Message Was sent To You:
Send the above information to Dr Eric Gibson
Agent: Dr Eric Gibson<= BR>Email: statelottpaycen= ter@hotmail.com
Phone: +66845389520
Signed,
Management
Maria jenson
Lottery coordinator 2010

= =0A=0A=0A=0A=0A=0A=0A=0A --0-374024500-1279300887=:82239-- From owner-v6ops@ops.ietf.org Fri Jul 16 13:18:08 2010 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 BDE503A6B4D for ; Fri, 16 Jul 2010 13:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.62 X-Spam-Level: X-Spam-Status: No, score=-108.62 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 ZQOLonqsxCVK for ; Fri, 16 Jul 2010 13:18:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1563B3A680F for ; Fri, 16 Jul 2010 13:18:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZrGF-000Jgs-O6 for v6ops-data0@psg.com; Fri, 16 Jul 2010 20:11:55 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OZrGA-000JgV-Js for v6ops@ops.ietf.org; Fri, 16 Jul 2010 20:11:51 +0000 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FADtZQEyrRN+K/2dsb2JhbACBRJFxjDdxpQyabYJegkYEg36EUg X-IronPort-AV: E=Sophos;i="4.55,216,1278288000"; d="scan'208,217";a="344733023" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2010 20:11:49 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6GKBeRj013636 for ; Fri, 16 Jul 2010 20:11:41 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 16 Jul 2010 13:11:48 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 16 Jul 2010 13:11:48 -0700 From: Fred Baker Subject: FYI: Current state of drafts in this working group Date: Fri, 16 Jul 2010 13:11:33 -0700 Message-Id: <18757824-9AFF-4F14-9CCA-6CFAD1E81F11@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: multipart/alternative; boundary=Apple-Mail-4-356183409 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-4-356183409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii from http://datatracker.ietf.org/doc datatracker.ietf.org Sign In=20 Working Groups Applications Internet Ops & Mgmt RAI Routing Security Transport Active WGs Concluded WGs Non-WG Lists Drafts & RFCs Search Submit a draft Meetings Agenda Materials Past Proceedings Upcoming Other Documents IPR Disclosures Liaison Statements IESG Agenda Related Sites Main IETF site IETF tools IAB RFC Editor IASA/IAOC/Trust IANA IRTF Version 3.00, 2010-07-16 Internet-Drafts and RFCs Name/number/title: Types: RFCs Internet-Drafts (active) Internet-Drafts (expired/replaced/withdrawn) Advanced Search Document Title Date Status Area Director Active Internet-Drafts draft-baker-v6ops-greynet-04 IPv4 and IPv6 Greynets 2010-07-05=20 new In Last Call (ends 2010-08-06) (for 7 days) Ron = Bonica draft-gundavelli-v6ops-l2-unicast-00 Unicast Transmission of IPv6 = Multicast Messages on Link-layer 2010-02-15 I-D Exists =09= draft-ietf-v6ops-cpe-simple-security-12 Recommended Simple Security = Capabilities in Customer Premises Equipment for Providing Residential = IPv6 Internet Service 2010-06-22 Publication Requested (for 2 = days) Ron Bonica draft-ietf-v6ops-incremental-cgn-01 An Incremental Carrier-Grade NAT = (CGN) for IPv6 Transition 2010-06-18 I-D Exists =09 draft-ietf-v6ops-ipv6-cpe-router-06 Basic Requirements for IPv6 = Customer Edge Routers 2010-06-04 In Last Call (ends 2010-07-26) = (for 4 days) Ron Bonica draft-ietf-v6ops-isp-scenarios-00 Emerging Service Provider = Scenarios for IPv6 Deployment 2010-04-15 Publication Requested = (for 2 days) Ron Bonica draft-ietf-v6ops-ra-guard-06 IPv6 RA-Guard 2010-06-15 IESG = Evaluation::Revised ID Needed (for 1 day)=09 Ron Bonica draft-ietf-v6ops-rogue-ra-01 Rogue IPv6 Router Advertisement Problem = Statement 2010-06-07 IESG Evaluation::Revised ID Needed (for = 1 day)=09 Ron Bonica draft-ietf-v6ops-tunnel-security-concerns-02 Security Concerns With = IP Tunneling 2010-03-08 I-D Exists =09 draft-ietf-v6ops-v6-in-mobile-networks-01 Mobile Networks = Considerations for IPv6 Deployment 2010-07-12=20 new I-D Exists =09 draft-ietf-v6ops-v6inixp-09 IPv6 Deployment in Internet Exchange = Points (IXPs) 2010-07-15=20 new Approved-announcement to be sent (for 1 day) Ron = Bonica draft-jiang-v6ops-nc-protection-01 Neighbor Cache Protection in = Neighbor Discover Protocol 2010-03-02 I-D Exists =09 draft-korhonen-v6ops-3gpp-eps-03 IPv6 in 3GPP Evolved Packet = System 2010-06-09 I-D Exists =09 draft-krishnan-v6ops-teredo-update-10 Teredo Security Updates = 2010-06-03 RFC Ed Queue (for 39 days)=20 RFC Editor State: EDIT Jari Arkko draft-nakibly-v6ops-tunnel-loops-02 Routing Loop Attack using IPv6 = Automatic Tunnels: Problem Statement and Proposed Mitigations = 2010-05-12 I-D Exists =09 draft-sarikaya-v6ops-prefix-delegation-01 Flexible DHCPv6 Prefix = Delegation in Mobile Networks 2010-05-10 I-D Exists =09 draft-thaler-v6ops-teredo-extensions-07 Teredo Extensions = 2010-07-12=20 new In Last Call (ends 2010-08-12) (for 1 day)=09 Jari Arkko draft-wbeebee-v6ops-ipv6-cpe-router-bis-03 Advanced Requirements = for IPv6 Customer Edge Routers 2010-07-08=20 new I-D Exists =09 http://www.ipinc.net/IPv4.GIF --Apple-Mail-4-356183409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Internet-Drafts and RFCs

=20
Version 3.00, 2010-07-16

Internet-Drafts and RFCs

= RFCs
Internet-Drafts (active)
= Internet-Drafts (expired/replaced/withdrawn)
3D"" Advanced
Additional search criteria:
=20
::
=20 =20
DocumentTitleDateStatusArea Director
Active Internet-Drafts
draft-baker-v6ops-greynet-04 IPv4 and IPv6 Greynets 2010-07-05
new 		In Last Call (ends 2010-08-06) (for 7 days) Ron Bonica
draft-gundavelli-v6ops-l2= -unicast-00 Unicast Transmission of IPv6 Multicast Messages on = Link-layer 2010-02-15 I-D Exists=20
draft-ietf-v6ops-cpe-s= imple-security-12 Recommended Simple Security Capabilities in Customer = Premises Equipment for Providing Residential IPv6 Internet Service 2010-06-22 Publication Requested (for 2 days) Ron Bonica
draft-ietf-v6ops-increment= al-cgn-01 An Incremental Carrier-Grade NAT (CGN) for IPv6 = Transition 2010-06-18 I-D Exists=20
draft-ietf-v6ops-ipv6-cpe-= router-06 Basic Requirements for IPv6 Customer Edge = Routers 2010-06-04 In Last Call (ends 2010-07-26) (for 4 days) Ron Bonica
draft-ietf-v6ops-isp-scenari= os-00 Emerging Service Provider Scenarios for IPv6 = Deployment 2010-04-15 Publication Requested (for 2 days) Ron Bonica
draft-ietf-v6ops-ra-guard-06 IPv6 RA-Guard 2010-06-15 IESG Evaluation::Revised ID Needed (for 1 day)
Ron Bonica
draft-ietf-v6ops-rogue-ra-01 Rogue IPv6 Router Advertisement Problem = Statement 2010-06-07 IESG Evaluation::Revised ID Needed (for 1 day)
Ron Bonica
draft-ietf-v6ops-= tunnel-security-concerns-02 Security Concerns With IP Tunneling 2010-03-08 I-D Exists=20
draft-ietf-v6ops-v6-= in-mobile-networks-01 Mobile Networks Considerations for IPv6 = Deployment 2010-07-12
new 		I-D Exists=20
draft-ietf-v6ops-v6inixp-09= IPv6 Deployment in Internet Exchange Points = (IXPs) 2010-07-15
= new 		Approved-announcement to be sent (for 1 day) Ron Bonica
draft-jiang-v6ops-nc-protec= tion-01 Neighbor Cache Protection in Neighbor Discover = Protocol 2010-03-02 I-D Exists=20
draft-korhonen-v6ops-3gpp-eps= -03 IPv6 in 3GPP Evolved Packet System 2010-06-09 I-D Exists=20
draft-krishnan-v6ops-ter= edo-update-10 Teredo Security Updates 2010-06-03 RFC Ed Queue (for 39 days)
RFC Editor State: EDIT 		Jari Arkko
draft-nakibly-v6ops-tunnel= -loops-02 Routing Loop Attack using IPv6 Automatic Tunnels: = Problem Statement and Proposed Mitigations 2010-05-12 I-D Exists=20
draft-sarikaya-v6ops= -prefix-delegation-01 Flexible DHCPv6 Prefix Delegation in Mobile = Networks 2010-05-10 I-D Exists=20
draft-thaler-v6ops-ter= edo-extensions-07 Teredo Extensions 2010-07-12
new 		In Last Call (ends 2010-08-12) (for 1 day)
Jari Arkko
draft-wbeebee-v6ops= -ipv6-cpe-router-bis-03 Advanced Requirements for IPv6 Customer Edge = Routers 2010-07-08
new 		I-D Exists=20
= =20 =20




= --Apple-Mail-4-356183409-- From v6ops-archive@ietf.org Sat Jul 17 07:02:52 2010 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 6E9AE3A683A for ; Sat, 17 Jul 2010 07:02:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -41%\n X-Spam-Flag: NO X-Spam-Score: -17.755 X-Spam-Level: X-Spam-Status: No, score=-17.755 tagged_above=-999 required=5 tests=[AWL=-4.214, BAYES_95=3, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 QL4UAzSk2O1S for ; Sat, 17 Jul 2010 07:02:45 -0700 (PDT) Received: from 101-46-112-92.pool.ukrtel.net (101-46-112-92.pool.ukrtel.net [92.112.46.101]) by core3.amsl.com (Postfix) with SMTP id 6D8373A685A for ; Sat, 17 Jul 2010 07:02:41 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -41% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100717140242.6D8373A685A@core3.amsl.com> Date: Sat, 17 Jul 2010 07:02:41 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Sat Jul 17 18:11:43 2010 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 A8B013A6A31 for ; Sat, 17 Jul 2010 18:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc2lSpKWYRjR for ; Sat, 17 Jul 2010 18:11:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D81D3A6A35 for ; Sat, 17 Jul 2010 18:11:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OaIBk-000DqN-9X for v6ops-data0@psg.com; Sun, 18 Jul 2010 00:57:04 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OaIBg-000Dpi-PW for v6ops@ops.ietf.org; Sun, 18 Jul 2010 00:57:01 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADvuQUyrR7H+/2dsb2JhbACfcXGkT5l1hSUEhACEV4I0 X-IronPort-AV: E=Sophos;i="4.55,220,1278288000"; d="scan'208";a="227856624" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 18 Jul 2010 00:56:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6I0uxGY019091; Sun, 18 Jul 2010 00:56:59 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 17:56:59 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Sun, 18 Jul 2010 00:56:58 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Sat, 17 Jul 2010 17:58:40 -0700 Subject: Re: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt From: Sri Gundavelli To: IPv6 Operations CC: Stig Venaas Message-ID: Thread-Topic: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt Thread-Index: AcsmFFxNk6Ntts6ipk+C17/0b0cd/g== In-Reply-To: <4B79A004.40506@venaas.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2010 00:56:59.0127 (UTC) FILETIME=[202DE070:01CB2614] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks to Stig for his review of the draft. Will reword the below text, should be in -01 version. Sri ------ Forwarded Message From: Stig Venaas Date: Mon, 15 Feb 2010 13:03:29 -0800 To: Sri Gundavelli Subject: Re: L2 Unicast of multicast messages - ID >> I think the document is fine. I've followed some of the previous >> discussion on this topic. Just one comment. >> >> In section 3 it says: >> >> address in the link-layer header will be an unicast address. It >> is up to to the system architecture as when to transmit a IPv6 >> multicast message as an link-layer unicast message, as long as >> there is no real impact to the multicast communication. >> >> This sentence is pretty vague. Especially "no real impact", not sure >> what that means. And what do you mean by "multicast communication". >> >> Also, the reason you may want the system architecture to transmit >> unicast, is that it has a positive impact on the communication, right? >> If whether you use unicast or not has no impact, then this would be >> pointless ;) >> > > :) My point is that, if the usage of the semantic is used in the right away, > there should be any impact to the multicast communication. If I'm hosting > two IPv6 VLAN's on the same 802.11 link, if the AP ensures the RA's are > segregated and sent to the right groups, its to me no impact to multicast > communication. But, I see your point, this needs to worded correctly. I > will fix this in -01 version, posted it a hour back. Sorry I was a bit late. I think the draft is good. Just trying to be a bit difficult here :) But I think it can be made clearer. Stig From rsvp-archiven@lists.ietf.org Sat Jul 17 21:13:02 2010 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 1A5C33A6A56 for ; Sat, 17 Jul 2010 21:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.944 X-Spam-Level: X-Spam-Status: No, score=0.944 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch3Fdpz1ipnH for ; Sat, 17 Jul 2010 21:13:01 -0700 (PDT) Received: from 20percent.org (unknown [89.165.165.139]) by core3.amsl.com (Postfix) with SMTP id E5A073A6A55 for ; Sat, 17 Jul 2010 21:12:58 -0700 (PDT) From: v6ops-archive@lists.ietf.org To: v6ops-archive@lists.ietf.org Subject: v6ops-archive@lists.ietf.org, My fav male pilules MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100718041259.E5A073A6A55@core3.amsl.com> Date: Sat, 17 Jul 2010 21:12:58 -0700 (PDT)
Click here.

Dear v6ops-archive@lists.ietf.org
From v6ops-archive@ietf.org Sun Jul 18 08:50:39 2010 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 BAA603A6A69 for ; Sun, 18 Jul 2010 08:50:39 -0700 (PDT) X-Quarantine-ID: <2nZq+0DgVb58> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -34%\n X-Spam-Flag: NO X-Spam-Score: -11.652 X-Spam-Level: X-Spam-Status: No, score=-11.652 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_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 2nZq+0DgVb58 for ; Sun, 18 Jul 2010 08:50:38 -0700 (PDT) Received: from a206-196.adsl.paltel.net (a206-196.adsl.paltel.net [213.6.206.196]) by core3.amsl.com (Postfix) with SMTP id 72EB13A6982 for ; Sun, 18 Jul 2010 08:50:30 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -34% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100718155032.72EB13A6982@core3.amsl.com> Date: Sun, 18 Jul 2010 08:50:30 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Mon Jul 19 18:43:12 2010 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 B05333A6BD3 for ; Mon, 19 Jul 2010 18:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=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 VmiXAq7SLEXi for ; Mon, 19 Jul 2010 18:43:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 635EF3A6BB0 for ; Mon, 19 Jul 2010 18:43:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dX-0002t7-6V for v6ops-data0@psg.com; Tue, 20 Jul 2010 01:28:47 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dU-0002sr-Oc for v6ops@ops.ietf.org; Tue, 20 Jul 2010 01:28:44 +0000 Received: by pwi7 with SMTP id 7so4289278pwi.11 for ; Mon, 19 Jul 2010 18:28:35 -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=sIwFArOm975tlSK1MWYUfcHVhEIl5Bpsc1bTnt2G2Ws=; b=ROZkyil9qRPK/3Rj3r0chALxFS6T2tKiLXBg1bucQc24gGRtbJlTlfHMK4WSRrX1xH Z/vDDZyQmxyjVM2bwXgI9gOCiJ2ktAn4z91Si5Jlp93EdO7yT6cZHic8n7wL1TnteWEo qjSekVY7ZHlLhV01rHeMPBuTHL1wwbp0ChvFE= 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=UyIcxSRn+f1iAdYY730QEngd4n1ec0i+JFCxotthbr6leMEsD0QeaK2Z02sG7yAnjR 2YTp4cS63Qk1jxCi1tt4zXPmLJF1Vq7T37X6aVz6AjtdeDV5hPnlKMdd8VLsdb36WZec tDg2ObECDRaKQKWPwQUxUR0dR1Ebug3GINnfY= Received: by 10.142.144.2 with SMTP id r2mr7154937wfd.262.1279589315426; Mon, 19 Jul 2010 18:28:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g37sm17689174rvb.5.2010.07.19.18.28.32 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 18:28:34 -0700 (PDT) Message-ID: <4C44FBBB.3020401@gmail.com> Date: Tue, 20 Jul 2010 13:28:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> In-Reply-To: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 03:19, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? Summary ------- This short draft proposes guidelines for use by listing sites that report on the level of IPv6 support from various ISPs. There are a number of such sites, and they don't all report on the same criteria, so the draft proposes seven common criteria, split into 'basic' and 'advanced'. I believe this document is useful, but it needs some debate about the exact criteria proposed, and it needs discussion with the people operating existing listing sites. If they don't agree, the document is going nowhere. More detail ----------- It seems like a good idea for all these listing sites to use common criteria. Whether they would do so in practice is another question. (How many ISPs do you know who refer to RFC 4084 in their sales literature?) That's why the sites need to be involved in the discussion. The list of criteria needs some debate in the WG. For example, there is no check whether IPv6-only clients would be satisfied. So as it stands, an ISP could get a green light according to this draft, but its IPv6-only users couldn't get SMTP service (for example). On the other hand, for practical reasons, there should not be too many criteria. There's no security text. There needs to be something if this is to proceed as an RFC. We could discuss whether any security-related criteria should be added; if not, we need to say why not. The draft is short enough that there's no point in a section-by-section review. There are a few places where the RFC Editor would need to tidy up the English. Brian Carpenter From owner-v6ops@ops.ietf.org Mon Jul 19 20:34:27 2010 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 A86233A69D5 for ; Mon, 19 Jul 2010 20:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.016 X-Spam-Level: X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=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 oxOR6S0TrBeE for ; Mon, 19 Jul 2010 20:34:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1537B3A69D1 for ; Mon, 19 Jul 2010 20:34:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob3SQ-000Fyn-Iq for v6ops-data0@psg.com; Tue, 20 Jul 2010 03:25:26 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob3SN-000FyR-MB for v6ops@ops.ietf.org; Tue, 20 Jul 2010 03:25:23 +0000 Received: by pvg12 with SMTP id 12so4330663pvg.11 for ; Mon, 19 Jul 2010 20:25:23 -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=Vfxpk3i0hAxXnYqh2BfP5ZKfTvn8tH1aqH0Apt8by4c=; b=HVvDcPxMDQfPlgSo+2CAku5AfTxwX64uoz5lYuIY4e/2/CA3jtHz7Pr9XSo7i4frmE vgUimSrD4lBWSeKeAnytwQ4GBm/uOwTUCLOuHjkoqk2ErVmmcqY61K/UoBO/Vl1qOICF N9/5HYs9nzQ8FkQVxsU/FyDhqkHHbW59ImuJQ= 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=Z/EEaJgQaYvIcshMFtCNleGc7i3mnzLlMKnBG8YCcmJPJh0VqU6kBfxo0iyKoNqOyl MujA9Iss1s2SjaX1CMA42sqv4JGP7CAphgg0IN8mywDdY8fCwTnsrkJ8Fb/GrgbhklX1 GzN0n92MMbMqhSRGv7Lcr83UQNGx1BC6bNXP8= Received: by 10.142.162.17 with SMTP id k17mr8252167wfe.324.1279596323087; Mon, 19 Jul 2010 20:25:23 -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 21sm7214826wfi.5.2010.07.19.20.25.20 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 20:25:21 -0700 (PDT) Message-ID: <4C45171D.8090506@gmail.com> Date: Tue, 20 Jul 2010 15:25:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-nakibly-v6ops-tunnel-loops review References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> In-Reply-To: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 02:48, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\ Summary ------- This draft proposes mitigation techniques for malicious loops formed using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms. The draft doesn't recommend a choice of technique. I think that for the work to go forward, the WG would need to agree on a recommendation. Otherwise, the world will shrug its shoulders. Details ------- Several IPv6 transition aids rely on automatic tunneling of IPv6 in IPv4. If an attacker succeeds in making two such methods link up with each other head-to-tail, a loop will form, and will consume all available resources. With manually configured tunnels, such a loop will be excluded by construction, but with automatic tunnels, an attacker can (under certain conditions) create a packet that a tunnel egress will feed back into regular IPv6 routing such that it ends up back in the tunnel again, until its hop limit expires. Section 2 describes the attack scenario. I find the terminology rather confusing: 1. For each tunnel, there is an object called "the tunnel router". I assume this is supposed to be the encapsulating ingress router. But it isn't stated clearly. 2. Tunnels have egress decapsulators. Their role is not described very clearly, but is assumed to be understood. 3. There's a reference to destination hosts being "in" the tunnel. ("The attack is ... initiated by sending an IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...") But hosts aren't in tunnels. They are outside the tunnel, beyond the egress router. [OK, some hosts do their own decapsulation, but then one can separate their decapsulator from their IPv6 stack, and anyway such hosts are not routers and will not forward packets back into the network.] So does this mean "destined to a fictitious end point that appears to be reached via T2"? There's a similar problem in the very first sentence of section 2: " In this section we shall denote an IPv6 address of a tunnel's node by the prefix of the tunnel and the IPv4 address of the node, i.e., Addr(Prefix, IPv4). " Does that mean " In this section we shall denote an IPv6 address of a node reached via a given tunnel by the prefix of the tunnel and the IPv4 address of the node, i.e., Addr(Prefix, IPv4). " ? 4. The description in section 2 then states that a packet to IPv6 address (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the tunnel egress, but that R1 erroneously treats it as if it came from tunnel T1. It isn't made very clear that this happens *because* the whole of the IPv4 Internet acts as a shared link layer as far as these automatic tunneling techniques are concerned. Therefore, R1 can only rely on the (dubious) addresses in the packet headers to figure out what to do next, and what it does is send the packet back to R2, because that's what the IPv6 prefix tells it to do. As far as I can see, the return packet from R1 to R2 could be sent by native IPv6 if such connectivity exists, but is more likely to be sent via tunnel T1, which is what R1 probably uses to provide global v6 access. The draft should make this point clear, anyway. Section 3 of the draft describes three possible mitigation strategies. 1. Checking the embedded IPv4 addresses explicitly in the tunnel end points. This is fairly straightforward and would fix the problem in most cases, but creates some overhead. Configuration would be needed to deal with 6rd and with RFC1918-based tunnels. 2. Checking that the end point exists, by various techniques. I am more pessimistic about these options than the author seems to be. 3. Use different protocol numbers for different tunnel types. This would be hard to deploy - in fact I think it's hopeless, since backwards compatibility with proto 41 would have to be kept. By the way, is it sufficient if either R1 or R2 makes the checks? Brian Carpenter From rsvp-archiven@lists.ietf.org Mon Jul 19 22:14:28 2010 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 F2C583A67F1 for ; Mon, 19 Jul 2010 22:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_95=3, 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, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, 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_XBL=3.033, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_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 Tpc4UnQ5ESdJ for ; Mon, 19 Jul 2010 22:14:20 -0700 (PDT) Received: from 77-239-174-177.static.vega-ua.net (77-239-174-177.static.vega-ua.net [77.239.174.177]) by core3.amsl.com (Postfix) with SMTP id AB2143A6BA3 for ; Mon, 19 Jul 2010 22:14:02 -0700 (PDT) From: v6ops-archive@lists.ietf.org To: v6ops-archive@lists.ietf.org Subject: v6ops-archive@lists.ietf.org, More stiffness of your manhood means more pleasure you and your girl get! MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100720051416.AB2143A6BA3@core3.amsl.com> Date: Mon, 19 Jul 2010 22:14:02 -0700 (PDT)
Click here.

Dear v6ops-archive@lists.ietf.org
From v6ops-archive@ietf.org Tue Jul 20 05:42:34 2010 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 A5D533A69E6 for ; Tue, 20 Jul 2010 05:42:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...rchive@ietf.org Pharmacy \256 Official Site -20%\n X-Spam-Flag: NO X-Spam-Score: -18.136 X-Spam-Level: X-Spam-Status: No, score=-18.136 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 G4G265TW68Wv for ; Tue, 20 Jul 2010 05:42:33 -0700 (PDT) Received: from 189874378.rec.megazon.com.br (189874378.rec.megazon.com.br [189.87.43.78]) by core3.amsl.com (Postfix) with SMTP id 18FFC3A69E8 for ; Tue, 20 Jul 2010 05:42:31 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org Pharmacy ® Official Site -20% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100720124232.18FFC3A69E8@core3.amsl.com> Date: Tue, 20 Jul 2010 05:42:31 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Tue Jul 20 07:53:41 2010 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 B5FF93A6981 for ; Tue, 20 Jul 2010 07:53:41 -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 PVag6RyHPQFy for ; Tue, 20 Jul 2010 07:53:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6718F3A69EF for ; Tue, 20 Jul 2010 07:53:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObE0c-000536-Fi for v6ops-data0@psg.com; Tue, 20 Jul 2010 14:41:26 +0000 Received: from [2001:670:87:a::107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObE0X-00050V-Vq for v6ops@ops.ietf.org; Tue, 20 Jul 2010 14:41:22 +0000 Received: from [IPv6:2a01:3f0:1::226:bbff:fe1d:8912] (unknown [IPv6:2a01:3f0:1:0:226:bbff:fe1d:8912]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 84FB42E027 for ; Tue, 20 Jul 2010 16:11:01 +0200 (CEST) From: Lindqvist Kurt Erik Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15983-681965742" Content-Transfer-Encoding: 7bit Subject: draft-kawamura-ipv6-isp-listings-00.txt Date: Tue, 20 Jul 2010 16:41:16 +0200 Message-Id: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> To: IPv6 v6ops Mime-Version: 1.0 (Apple Message framework v1081) X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-15983-681965742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have read the above documents and have some general comments and then = some more nit like comments. General comments:=20 ----------------- In general it might be good with a document outlining some basic = checklists to determine the level of IPv6 readiness in a service = provider. However, I doubt the value of listing some of the current = programs and what methodology they are currently using. These change, = and keeping the document uptodate so it's meaningful might be hard and = of little value. Also, there are some existing discussion on how to = track IPv6 deployment - some of this was discussed at the RIPE meeting = in Prague = http://www.ripe.net/ripe/meetings/ripe-60/presentations/Aben-IPv6_at_web_c= lients_and_caching_resolvers.pdf and from what I understand similar = discussions where held at the Google IPv6 day.=20 Now, that type of measurement is not the same type of checklist / = certification program as the I-D describes, but this brings me to what I = believe is the biggest flaw of section 3 - it doesn't say much about = actual deployment. Rather, the barrier is very low. For example in 3.3 = it mentions an allocated or PI block. If this is for an ISP, a PI block = is useless as the intention of PI is to not suballocate. I would set the = requirement to PA bock only. Further - I believe the Basic class = described in 3.3 should at least require sub-allocations of IPV6 = prefixes, otherwise it's hard to argue that an ISP has 'deployed' IPv6. = As for the Advance class in 3.4, I would suggest that an ISP provides = more than basic services (i.e DNS) over IPv6 to end-users and/or the = Internet in general.=20 Still, while I am somewhat agreeing with a standardized measurement of = IPv6 readiness in an AS/ISP I think that it's more useful to work on = measuring actually deployed clients that can be observed and publishing = that data. Even better would be standardized quality measures of these = deployments. There are many drawbacks on doing this based on only = observed data at a server side ala looking at a web-server, but as = Lorenzo and Google have shown in many presentations, at least it gives = data to do a risk assessment for a service operator.=20 If this document could combine some level of Basic recommendations along = the lines of "Have PA, hvae done X sub-delegations, provides Y services" = together with a standard collection mechanism/schema (perhaps that is = really a different document) similar to what RIPE does, what Google = does, or even better- a format or method that would allow sharing of = data, content/service operators could build a matrix and we could see = the progress and quality of IPv6 deployment.=20 I know that several content providers have been thinking of how they = could best measure IPv6 deployment effects on their services, and I am = sure there is a lot of thinking out there that might be worth tapping = into.=20 Nits:=20 ----- Fist of all there are quite a few abbreviations that are not expanded = when first used, like LIR. Secondly, the two paragraphs : > 1. Introduction >=20 >=20 > There are many web sites that give listings of IPv6 enabled service > providers, or rate ISPs according to their IPv6 enabledness. The > following are few examples of currently known programs. >=20 > IPv6 Enabled Program=20 > http://ipv6forum.org/ipv6_enabled/ >=20 >=20 > IPv6 Ripeness=20 > http://labs.ripe.net/content/ipv6-ripeness/ >=20 >=20 > SixXS=20 > http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers >=20 >=20 > IPv6 to Standard=20 > http://ipv6-to-standard.org/ >=20 >=20 > Hurricane Electric Free IPv6 Certification > =20 > http://ipv6.he.net/certification/ ...and.... >=20 > 2. Summary of the Current Situation >=20 >=20 > The following are the list of currently known programs that list or > rate ISPs according to a guideline that each has determined. >=20 >=20 > IPv6 Enabled Program=20 > http://ipv6forum.org/ipv6_enabled/ >=20 >=20 > IPv6 Ripeness=20 > http://labs.ripe.net/content/ipv6-ripeness/ >=20 >=20 > SixXS=20 > http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers >=20 >=20 > IPv6 to Standard=20 > http://ipv6-to-standard.org/ >=20 >=20 > Hurricane Electric Free IPv6 Certification > =20 > http://ipv6.he.net/certification/ >=20 >=20 > note: the following description of each program is not yet = complete. are repetitions that doesn't really add to the document.=20 Best regards, - kurtis - --Apple-Mail-15983-681965742 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxFtYwACgkQAFdZ6xrc/t5tiQCeP4ZSEiROK3iC1Sia0KBIX+lc MnEAnjw0wrpnewb552FT76AyL00/vHP3 =0b9s -----END PGP SIGNATURE----- --Apple-Mail-15983-681965742-- From owner-v6ops@ops.ietf.org Tue Jul 20 08:12:43 2010 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 07BBA3A6A0B for ; Tue, 20 Jul 2010 08:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.405 X-Spam-Level: X-Spam-Status: No, score=-108.405 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6, 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 P80liSanuPiF for ; Tue, 20 Jul 2010 08:12:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A08F93A68B5 for ; Tue, 20 Jul 2010 08:12:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObEQE-00090R-EQ for v6ops-data0@psg.com; Tue, 20 Jul 2010 15:07:54 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObEQB-0008zk-Jy for v6ops@ops.ietf.org; Tue, 20 Jul 2010 15:07:51 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPpXRUyrR7Ht/2dsb2JhbACfbXGlXZsshTIEhACEWQ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2010 15:05:50 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KF5g3H010488; Tue, 20 Jul 2010 15:05:44 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 20 Jul 2010 08:05:50 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 20 Jul 2010 08:05:50 -0700 Subject: Re: draft-nakibly-v6ops-tunnel-loops review Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <4C45171D.8090506@gmail.com> Date: Tue, 20 Jul 2010 08:05:36 -0700 Cc: IPv6 Operations Message-Id: References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> <4C45171D.8090506@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks much for the review. Looks like it at least needs an update = before being finalized. Question for you. Would you consider an updated version of the document = ready for WGLC, or do we need further discussion on it? Apart from the = beauty of the prose, are the notions proposed sound? On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote: > On 2010-07-16 02:48, Fred Baker wrote: >> Could I interest you in doing a thorough review of = draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\ >=20 > Summary > ------- >=20 > This draft proposes mitigation techniques for malicious loops formed > using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms. >=20 > The draft doesn't recommend a choice of technique. I think that for = the > work to go forward, the WG would need to agree on a recommendation. > Otherwise, the world will shrug its shoulders. >=20 > Details > ------- >=20 > Several IPv6 transition aids rely on automatic tunneling of IPv6 in > IPv4. If an attacker succeeds in making two such methods link up > with each other head-to-tail, a loop will form, and will consume all > available resources. With manually configured tunnels, such a loop > will be excluded by construction, but with automatic tunnels, an = attacker > can (under certain conditions) create a packet that a tunnel egress > will feed back into regular IPv6 routing such that it ends up back > in the tunnel again, until its hop limit expires. >=20 > Section 2 describes the attack scenario. I find the terminology > rather confusing: >=20 > 1. For each tunnel, there is an object called "the tunnel router". > I assume this is supposed to be the encapsulating ingress router. > But it isn't stated clearly. >=20 > 2. Tunnels have egress decapsulators. Their role is not described > very clearly, but is assumed to be understood. >=20 > 3. There's a reference to destination hosts being "in" the tunnel. > ("The attack is ... initiated by sending an > IPv6 packet (packet 0 in Figure 1) destined to an end point in = T2...") >=20 > But hosts aren't in tunnels. They are outside the tunnel, beyond the > egress router. [OK, some hosts do their own decapsulation, but then = one > can separate their decapsulator from their IPv6 stack, and anyway such > hosts are not routers and will not forward packets back into the = network.] >=20 > So does this mean "destined to a fictitious end point that appears > to be reached via T2"? >=20 > There's a similar problem in the very first sentence of section 2: >=20 > " In this section we shall denote an IPv6 address of a tunnel's node = by > the prefix of the tunnel and the IPv4 address of the node, i.e., > Addr(Prefix, IPv4). " >=20 > Does that mean >=20 > " In this section we shall denote an IPv6 address of a node reached = via > a given tunnel by the prefix of the tunnel and the IPv4 address of = the node, i.e., > Addr(Prefix, IPv4). " ? >=20 > 4. The description in section 2 then states that a packet to IPv6 = address > (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as = the > tunnel egress, but that R1 erroneously treats it as if it came from = tunnel T1. > It isn't made very clear that this happens *because* the whole of the = IPv4 > Internet acts as a shared link layer as far as these automatic = tunneling > techniques are concerned. Therefore, R1 can only rely on the (dubious) > addresses in the packet headers to figure out what to do next, and = what it > does is send the packet back to R2, because that's what the IPv6 = prefix tells > it to do. >=20 > As far as I can see, the return packet from R1 to R2 could be sent by > native IPv6 if such connectivity exists, but is more likely to be sent > via tunnel T1, which is what R1 probably uses to provide global v6 = access. > The draft should make this point clear, anyway. >=20 > Section 3 of the draft describes three possible mitigation strategies. >=20 > 1. Checking the embedded IPv4 addresses explicitly in the tunnel end = points. > This is fairly straightforward and would fix the problem in most = cases, but > creates some overhead. Configuration would be needed to deal with 6rd > and with RFC1918-based tunnels. >=20 > 2. Checking that the end point exists, by various techniques. I am = more > pessimistic about these options than the author seems to be. >=20 > 3. Use different protocol numbers for different tunnel types. This = would > be hard to deploy - in fact I think it's hopeless, since backwards > compatibility with proto 41 would have to be kept. >=20 > By the way, is it sufficient if either R1 or R2 makes the checks? >=20 > Brian Carpenter http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Tue Jul 20 09:25:04 2010 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 F120F3A6998 for ; Tue, 20 Jul 2010 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.953 X-Spam-Level: X-Spam-Status: No, score=-108.953 tagged_above=-999 required=5 tests=[AWL=-0.458, 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 FOWeFY9blhGC for ; Tue, 20 Jul 2010 09:25:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 900E83A6897 for ; Tue, 20 Jul 2010 09:25:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObFUb-000IxH-AU for v6ops-data0@psg.com; Tue, 20 Jul 2010 16:16:29 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObFUV-000IwO-P2 for v6ops@ops.ietf.org; Tue, 20 Jul 2010 16:16:26 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ5oRUyrR7H+/2dsb2JhbACfbXGlfJsvhTIEhACEWQ Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 16:14:22 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KGEFHL005580; Tue, 20 Jul 2010 16:14:17 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 20 Jul 2010 09:14:22 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 20 Jul 2010 09:14:22 -0700 Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> Date: Tue, 20 Jul 2010 09:14:08 -0700 Cc: IPv6 v6ops Message-Id: <1DBA7193-6825-4191-B32A-1919A6F99C30@cisco.com> References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> To: Lindqvist Kurt Erik X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks for this. We will have a discussion in the coming working group = meeting, and will I hope continue discussion in the mailer.=20 On Jul 20, 2010, at 7:41 AM, Lindqvist Kurt Erik wrote: >=20 > I have read the above documents and have some general comments and = then some more nit like comments. >=20 > General comments:=20 > ----------------- >=20 > In general it might be good with a document outlining some basic = checklists to determine the level of IPv6 readiness in a service = provider. However, I doubt the value of listing some of the current = programs and what methodology they are currently using. These change, = and keeping the document uptodate so it's meaningful might be hard and = of little value. Also, there are some existing discussion on how to = track IPv6 deployment - some of this was discussed at the RIPE meeting = in Prague = http://www.ripe.net/ripe/meetings/ripe-60/presentations/Aben-IPv6_at_web_c= lients_and_caching_resolvers.pdf and from what I understand similar = discussions where held at the Google IPv6 day.=20 >=20 > Now, that type of measurement is not the same type of checklist / = certification program as the I-D describes, but this brings me to what I = believe is the biggest flaw of section 3 - it doesn't say much about = actual deployment. Rather, the barrier is very low. For example in 3.3 = it mentions an allocated or PI block. If this is for an ISP, a PI block = is useless as the intention of PI is to not suballocate. I would set the = requirement to PA bock only. Further - I believe the Basic class = described in 3.3 should at least require sub-allocations of IPV6 = prefixes, otherwise it's hard to argue that an ISP has 'deployed' IPv6. = As for the Advance class in 3.4, I would suggest that an ISP provides = more than basic services (i.e DNS) over IPv6 to end-users and/or the = Internet in general.=20 >=20 > Still, while I am somewhat agreeing with a standardized measurement of = IPv6 readiness in an AS/ISP I think that it's more useful to work on = measuring actually deployed clients that can be observed and publishing = that data. Even better would be standardized quality measures of these = deployments. There are many drawbacks on doing this based on only = observed data at a server side ala looking at a web-server, but as = Lorenzo and Google have shown in many presentations, at least it gives = data to do a risk assessment for a service operator.=20 >=20 > If this document could combine some level of Basic recommendations = along the lines of "Have PA, hvae done X sub-delegations, provides Y = services" together with a standard collection mechanism/schema (perhaps = that is really a different document) similar to what RIPE does, what = Google does, or even better- a format or method that would allow sharing = of data, content/service operators could build a matrix and we could see = the progress and quality of IPv6 deployment.=20 >=20 > I know that several content providers have been thinking of how they = could best measure IPv6 deployment effects on their services, and I am = sure there is a lot of thinking out there that might be worth tapping = into.=20 >=20 > Nits:=20 > ----- >=20 > Fist of all there are quite a few abbreviations that are not expanded = when first used, like LIR. Secondly, the two paragraphs : >=20 >> 1. Introduction >>=20 >>=20 >> There are many web sites that give listings of IPv6 enabled service >> providers, or rate ISPs according to their IPv6 enabledness. The >> following are few examples of currently known programs. >>=20 >> IPv6 Enabled Program=20 >> http://ipv6forum.org/ipv6_enabled/ >>=20 >>=20 >> IPv6 Ripeness=20 >> http://labs.ripe.net/content/ipv6-ripeness/ >>=20 >>=20 >> SixXS=20 >> http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers >>=20 >>=20 >> IPv6 to Standard=20 >> http://ipv6-to-standard.org/ >>=20 >>=20 >> Hurricane Electric Free IPv6 Certification >>=20 >> http://ipv6.he.net/certification/ >=20 >=20 > ...and.... >=20 >>=20 >> 2. Summary of the Current Situation >>=20 >>=20 >> The following are the list of currently known programs that list or >> rate ISPs according to a guideline that each has determined. >>=20 >>=20 >> IPv6 Enabled Program=20 >> http://ipv6forum.org/ipv6_enabled/ >>=20 >>=20 >> IPv6 Ripeness=20 >> http://labs.ripe.net/content/ipv6-ripeness/ >>=20 >>=20 >> SixXS=20 >> http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers >>=20 >>=20 >> IPv6 to Standard=20 >> http://ipv6-to-standard.org/ >>=20 >>=20 >> Hurricane Electric Free IPv6 Certification >>=20 >> http://ipv6.he.net/certification/ >>=20 >>=20 >> note: the following description of each program is not yet = complete. >=20 > are repetitions that doesn't really add to the document.=20 >=20 > Best regards, >=20 > - kurtis - >=20 >=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Tue Jul 20 10:58:22 2010 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 F05163A6B35 for ; Tue, 20 Jul 2010 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.03 X-Spam-Level: X-Spam-Status: No, score=-109.03 tagged_above=-999 required=5 tests=[AWL=-0.535, 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 dU-CEZgCzy+H for ; Tue, 20 Jul 2010 10:58:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 063823A6A92 for ; Tue, 20 Jul 2010 10:58:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObGwJ-0006MK-Vx for v6ops-data0@psg.com; Tue, 20 Jul 2010 17:49:12 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObGwG-0006Lp-S4 for v6ops@ops.ietf.org; Tue, 20 Jul 2010 17:49:08 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAN9RUyrRN+J/2dsb2JhbACfbXGld5s1hTIEhACEWQ Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 17:42:06 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KHfwWD025627 for ; Tue, 20 Jul 2010 17:42:00 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 20 Jul 2010 10:42:06 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 20 Jul 2010 10:42:06 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Subject: draft-nakibly-v6ops-tunnel-loops discussion From: Fred Baker In-Reply-To: <4C45171D.8090506@gmail.com> Date: Tue, 20 Jul 2010 10:41:52 -0700 Message-Id: References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> <4C45171D.8090506@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote: > The draft doesn't recommend a choice of technique. I think that for = the work to go forward, the WG would need to agree on a recommendation. = Otherwise, the world will shrug its shoulders. Following up on Brian's excellent review. Let's discuss this. In view of = draft-arkko-ipv6-transition-guidelines and = draft-ietf-v6ops-tunnel-security-concerns, do we need this draft? Should = we prefer it to one of the others? Is there something specific we would = like this document to recommend?= From owner-v6ops@ops.ietf.org Tue Jul 20 11:05:34 2010 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 15F753A6B32 for ; Tue, 20 Jul 2010 11:05: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 DfT8N7d6ns2U for ; Tue, 20 Jul 2010 11:05:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83B393A6B3E for ; Tue, 20 Jul 2010 11:05:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObH9v-0008tQ-Rh for v6ops-data0@psg.com; Tue, 20 Jul 2010 18:03:15 +0000 Received: from [199.106.114.251] (helo=wolverine02.qualcomm.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObH9r-0008so-HE for v6ops@ops.ietf.org; Tue, 20 Jul 2010 18:03:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279648989; x=1311184989; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Arnaud=20Ebalard=20,=20"v6ops@o ps.ietf.org"=0D=0A=09|CC:=20James=20W oodyatt=20|Date:=20Tue,=2020=20Jul=202010 =2011:02:49=20-0700|Subject:=20RE:=20Review=20of=20draft- ietf-v6ops-cpe-simple-security-12|Thread-Topic:=20Review =20of=20draft-ietf-v6ops-cpe-simple-security-12 |Thread-Index:=20AcskNs9m+4cx1w3BTOCoWQRrznLMWwD+++mw |Message-ID:=20|References:=20<87k4owbvtu. fsf@small.ssi.corp>|In-Reply-To:=20<87k4owbvtu.fsf@small. ssi.corp>|Accept-Language:=20en-US|Content-Language:=20en -US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0; bh=QNtWd7/livTJyJAJSSLtbuLSnjrhQ4bydFkmKyX0yQw=; b=insE2gkGgtqOHFmiKXSkZLLx/tc8szLvmL5TuBRGThtUkXwudYb+J6X8 MU+BG4zG4CDOJMCMCkm1cKf1npgq6NJcmWmKo6SlNo078ua1SP8rKorr1 opJjf4H0Stg9CM76lmyN6AeOA5tlnCr+Sp0ViIfiyNisutgsTzID3ajPF E=; X-IronPort-AV: E=McAfee;i="5400,1158,6049"; a="47913439" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 20 Jul 2010 11:02:49 -0700 X-IronPort-AV: E=Sophos;i="4.55,232,1278313200"; d="scan'208";a="83165121" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jul 2010 11:02:49 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 11:02:51 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 20 Jul 2010 11:02:51 -0700 From: "Laganier, Julien" To: Arnaud Ebalard , "v6ops@ops.ietf.org" CC: James Woodyatt Date: Tue, 20 Jul 2010 11:02:49 -0700 Subject: RE: Review of draft-ietf-v6ops-cpe-simple-security-12 Thread-Topic: Review of draft-ietf-v6ops-cpe-simple-security-12 Thread-Index: AcskNs9m+4cx1w3BTOCoWQRrznLMWwD+++mw Message-ID: References: <87k4owbvtu.fsf@small.ssi.corp> In-Reply-To: <87k4owbvtu.fsf@small.ssi.corp> 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: Hi Arnaud & James, I have a follow-up comment inline below: > Hi, >=20 > I read the draft (except for SCTP and DCCP related parts). IMHO, it is > in good shape. I have some comments inline below. They are mainly > related to IPsec/IKE and MIPv6. >=20 > Please, bear with me if some have already been discussed on the list; I > have not followed associated discussions. [...] > > 3.2.4. IPsec and Internet Key Exchange (IKE) > > > > The Internet protocol security suite (IPsec) offers greater > > flexibility and better overall security than the simple security > of > > stateful packet filtering at network perimeters. Therefore, > > residential IPv6 gateways need not prohibit IPsec traffic flows. > > > > REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT > > prohibit the forwarding of packets, to and from legitimate node > > addresses, with destination extension headers of type > "Authenticated > > Header (AH)" [RFC4302] in their outer IP extension header chain. > > > > REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT > > prohibit the forwarding of packets, to and from legitimate node > > addresses, with an upper layer protocol of type "Encapsulating > > Security Payload (ESP)" [RFC4303] in their outer IP extension > header > > chain. =20 > > 3.2.5. Mobility Support in IPv6 > > > > Mobility support in IPv6 [RFC3775] relies on the use of an > > encapsulation mechanism in flows between mobile nodes and their > > correspondent nodes, involving the use of the type 2 IPv6 routing > > header and the Home Address destination header option. >=20 > It also relies on Mobility Header (nh 135) passing through, for > instance for required CoTI/CoT messages exchanged between the MN and > the CN, before traffic using HAO in DestOpt or RH2 is exchanged. IMHO, > there should be a REC to support MH to pass through. Even inbound MH traf= fic: > more on that below. >=20 >=20 > > In contrast to mobility support in IPv4, mobility is a standard feature= of > > IPv6 and no security benefit is generally to be gained by denying > > communications with either interior or exterior mobile nodes. > > > > REC-25: The state records for flows initiated by outbound packets > > that bear a Home Address destination option [RFC3775] are > > distinguished by the addition of the home address of the flow as > > well as the interior Care-of address. IPv6 gateways MUST NOT prohib= it > > the forwarding of any inbound packets bearing type 2 routing headers= , > > which otherwise match a flow state record, and where A) the > > destination matches the home address of the flow, and B) the Home > > Address field in the routing header matches the interior Care-of > > address of the flow. >=20 > I think the last sentence is wrong. It should IMHO be: >=20 > IPv6 gateways MUST NOT prohibit the forwarding of any inbound > packets bearing type 2 routing headers, which otherwise match a > flow state record, and where A) the address in the destination > field of the IPv6 header matches the interior Care-of Address of > the flow, and B) the Home Address field in the Type 2 Routing > Header matches the Home Address of the flow. >=20 > In more details, when a RO packet (e.g. TCP, MH, UDP, ...) is received > by an internal MN from an external CN, its on-wire format is the > following: >=20 > IPv6(src=3DCN,dst=3DCoA)/RH2(HomeAddress=3DHoA)/TCP >=20 > This is what the CPE will see. >=20 > Additionally, this REC-25 supports an internal MN exchanging RO traffic > with an external CN: >=20 > MN --------- CPE ----------------- Internet -------------- CN >=20 > ---- IPv6(src=3DCoA, dst=3DCN)/DestOpt(HOA(hoa=3DHoA))/TCP ----> > <--- IPv6(src=3DCN,dst=3DCoA)/RH2(HomeAddress=3DHoA)/TCP ------- >=20 > *but does not* support an internal CN (or MN) accepting bindings for an > external MN, i.e.: >=20 >=20 > CN --------- CPE ----------------- Internet -------------- MN (CoA, > HoA) >=20 > <--- IPv6(src=3DCoA, dst=3DCN)/DestOpt(HOA(hoa=3DHoA))/TCP ----- > ---- IPv6(src=3DCN,dst=3DCoA)/RH2(HomeAddress=3DHoA)/TCP ------> >=20 > is that out of scope or is it just missing? If that is not out of scope, > a specific REC may be needed or REC-25 may be extended. Additionally, > for that to be useful, inbound MH traffic need to be authorized. >=20 > There is also another unrelated point associated with this REC-25: > using TCP as an example, the CPE may not see the 3-way handshake between = a MN > and a CN if the TCP connection establishment is done via the tunnel to > the Home Agent. Later, when this TCP traffic is route optimized, no TCP > state exist in the CPE. Irrespective of whether bidirectional tunneling through the Home Agent or r= oute optimization is used, there is an additional issue with a mobile node = moving from a network behind a first CPE to another network behind a second= CPE: If the upper layer protocol (e.g., TCP) state is established when the= MN is behind a first CPE, if later on the MN moves behind a second CPE, th= e second CPE will not have any state for the upper layer protocol.=20 > I understand that REC-25 covers that with the > "any" keyword in "IPv6 gateways MUST NOT prohibit the forwarding of > *any* inbound packets bearing type 2 routing headers, ..." but I don't > think it will be obvious for someone not familiar with the protocol > that standard TCP RECs do not apply here, i.e. that somehow REC-25 applie= s > before stateful rules. Stating it explictly in the document may help. As a result, and in a similar fashion to what Arnaud wrote just above, I be= lieve all traffic to and from the mobile node should be passed through the = CPE, whether it is encapsulated with IP-in-IP in the case of bidirectional = tunneling through the Home Agent or with HAO/RH2 in the case of Route Optim= ized traffic. Note that none of this traffic will be processed by the Mobile Node unless = the Mobile Node has a will to decapsulate inner packets. Mobile IPv6 mandat= es that the MN processes no inbound encapsulated packets unless it has a bi= nding cache entry with the correspondent.=20 --julien From owner-v6ops@ops.ietf.org Tue Jul 20 11:51:53 2010 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 AB5FB3A691B for ; Tue, 20 Jul 2010 11:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[AWL=3.699, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 JOHFf2aSHk2E for ; Tue, 20 Jul 2010 11:51:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 833933A67E7 for ; Tue, 20 Jul 2010 11:51:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObHq7-000EuL-CB for v6ops-data0@psg.com; Tue, 20 Jul 2010 18:46:51 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObHq4-000Eu0-KR for v6ops@ops.ietf.org; Tue, 20 Jul 2010 18:46:48 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 18:44:47 +0000 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.14.3) with ESMTP id o6KIilLl003837 for ; Tue, 20 Jul 2010 18:44:47 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 11:37:56 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 19:04:39 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 21:04:37 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 01:46:53 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1kmWU007582; Tue, 20 Jul 2010 01:46:52 GMT X-from-outside-Cisco: 147.28.0.62 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAGudREyTHAA+kWdsb2JhbACDIJxGCBUBAQEBCQsKBxEFHahbiTQ7ghCGKy6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,229,1278288000"; d="scan'208";a="165607387" Received: from psg.com ([147.28.0.62]) by sj-inbound-e.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 01:46:18 +0000 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dX-0002t7-6V for v6ops-data0@psg.com; Tue, 20 Jul 2010 01:28:47 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dU-0002sr-Oc for v6ops@ops.ietf.org; Tue, 20 Jul 2010 01:28:44 +0000 Received: by pwi7 with SMTP id 7so4289278pwi.11 for ; Mon, 19 Jul 2010 18:28:35 -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=sIwFArOm975tlSK1MWYUfcHVhEIl5Bpsc1bTnt2G2Ws=; b=ROZkyil9qRPK/3Rj3r0chALxFS6T2tKiLXBg1bucQc24gGRtbJlTlfHMK4WSRrX1xH Z/vDDZyQmxyjVM2bwXgI9gOCiJ2ktAn4z91Si5Jlp93EdO7yT6cZHic8n7wL1TnteWEo qjSekVY7ZHlLhV01rHeMPBuTHL1wwbp0ChvFE= 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=UyIcxSRn+f1iAdYY730QEngd4n1ec0i+JFCxotthbr6leMEsD0QeaK2Z02sG7yAnjR 2YTp4cS63Qk1jxCi1tt4zXPmLJF1Vq7T37X6aVz6AjtdeDV5hPnlKMdd8VLsdb36WZec tDg2ObECDRaKQKWPwQUxUR0dR1Ebug3GINnfY= Received: by 10.142.144.2 with SMTP id r2mr7154937wfd.262.1279589315426; Mon, 19 Jul 2010 18:28:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g37sm17689174rvb.5.2010.07.19.18.28.32 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 18:28:34 -0700 (PDT) Message-ID: <4C44FBBB.3020401@gmail.com> Date: Tue, 20 Jul 2010 13:28:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> In-Reply-To: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 20 Jul 2010 02:04:37.0935 (UTC) FILETIME=[E83E53F0:01CB27AF] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 03:19, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? Summary ------- This short draft proposes guidelines for use by listing sites that report on the level of IPv6 support from various ISPs. There are a number of such sites, and they don't all report on the same criteria, so the draft proposes seven common criteria, split into 'basic' and 'advanced'. I believe this document is useful, but it needs some debate about the exact criteria proposed, and it needs discussion with the people operating existing listing sites. If they don't agree, the document is going nowhere. More detail ----------- It seems like a good idea for all these listing sites to use common criteria. Whether they would do so in practice is another question. (How many ISPs do you know who refer to RFC 4084 in their sales literature?) That's why the sites need to be involved in the discussion. The list of criteria needs some debate in the WG. For example, there is no check whether IPv6-only clients would be satisfied. So as it stands, an ISP could get a green light according to this draft, but its IPv6-only users couldn't get SMTP service (for example). On the other hand, for practical reasons, there should not be too many criteria. There's no security text. There needs to be something if this is to proceed as an RFC. We could discuss whether any security-related criteria should be added; if not, we need to say why not. The draft is short enough that there's no point in a section-by-section review. There are a few places where the RFC Editor would need to tidy up the English. Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 20 11:51:59 2010 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 7BED33A691B for ; Tue, 20 Jul 2010 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=2.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, 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 4CoSPpA6eWYS for ; Tue, 20 Jul 2010 11:51:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CAEEF3A6C36 for ; Tue, 20 Jul 2010 11:51:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObHrp-000F8M-8H for v6ops-data0@psg.com; Tue, 20 Jul 2010 18:48:37 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObHrm-000F7v-6e for v6ops@ops.ietf.org; Tue, 20 Jul 2010 18:48:34 +0000 Authentication-Results: sj-iport-3.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2010 18:48:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KImTe1021052 for ; Tue, 20 Jul 2010 18:48:33 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 11:40:10 -0700 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 20:35:38 -0700 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 03:35:37 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K3ZVWe002526; Tue, 20 Jul 2010 03:35:37 GMT X-from-outside-Cisco: 147.28.0.62 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcBALq2REyTHAA+lGdsb2JhbACDIJxGCBUBAQEBCQsICREFHadgiTQ7ghCGJi6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,230,1278288000"; d="scan'208";a="205263785" Received: from psg.com ([147.28.0.62]) by sj-inbound-f.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 03:35:36 +0000 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob3SQ-000Fyn-Iq for v6ops-data0@psg.com; Tue, 20 Jul 2010 03:25:26 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob3SN-000FyR-MB for v6ops@ops.ietf.org; Tue, 20 Jul 2010 03:25:23 +0000 Received: by pvg12 with SMTP id 12so4330663pvg.11 for ; Mon, 19 Jul 2010 20:25:23 -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=Vfxpk3i0hAxXnYqh2BfP5ZKfTvn8tH1aqH0Apt8by4c=; b=HVvDcPxMDQfPlgSo+2CAku5AfTxwX64uoz5lYuIY4e/2/CA3jtHz7Pr9XSo7i4frmE vgUimSrD4lBWSeKeAnytwQ4GBm/uOwTUCLOuHjkoqk2ErVmmcqY61K/UoBO/Vl1qOICF N9/5HYs9nzQ8FkQVxsU/FyDhqkHHbW59ImuJQ= 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=Z/EEaJgQaYvIcshMFtCNleGc7i3mnzLlMKnBG8YCcmJPJh0VqU6kBfxo0iyKoNqOyl MujA9Iss1s2SjaX1CMA42sqv4JGP7CAphgg0IN8mywDdY8fCwTnsrkJ8Fb/GrgbhklX1 GzN0n92MMbMqhSRGv7Lcr83UQNGx1BC6bNXP8= Received: by 10.142.162.17 with SMTP id k17mr8252167wfe.324.1279596323087; Mon, 19 Jul 2010 20:25:23 -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 21sm7214826wfi.5.2010.07.19.20.25.20 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 20:25:21 -0700 (PDT) Message-ID: <4C45171D.8090506@gmail.com> Date: Tue, 20 Jul 2010 15:25:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-nakibly-v6ops-tunnel-loops review References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> In-Reply-To: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 20 Jul 2010 03:35:38.0061 (UTC) FILETIME=[9EBB6FD0:01CB27BC] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 02:48, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\ Summary ------- This draft proposes mitigation techniques for malicious loops formed using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms. The draft doesn't recommend a choice of technique. I think that for the work to go forward, the WG would need to agree on a recommendation. Otherwise, the world will shrug its shoulders. Details ------- Several IPv6 transition aids rely on automatic tunneling of IPv6 in IPv4. If an attacker succeeds in making two such methods link up with each other head-to-tail, a loop will form, and will consume all available resources. With manually configured tunnels, such a loop will be excluded by construction, but with automatic tunnels, an attacker can (under certain conditions) create a packet that a tunnel egress will feed back into regular IPv6 routing such that it ends up back in the tunnel again, until its hop limit expires. Section 2 describes the attack scenario. I find the terminology rather confusing: 1. For each tunnel, there is an object called "the tunnel router". I assume this is supposed to be the encapsulating ingress router. But it isn't stated clearly. 2. Tunnels have egress decapsulators. Their role is not described very clearly, but is assumed to be understood. 3. There's a reference to destination hosts being "in" the tunnel. ("The attack is ... initiated by sending an IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...") But hosts aren't in tunnels. They are outside the tunnel, beyond the egress router. [OK, some hosts do their own decapsulation, but then one can separate their decapsulator from their IPv6 stack, and anyway such hosts are not routers and will not forward packets back into the network.] So does this mean "destined to a fictitious end point that appears to be reached via T2"? There's a similar problem in the very first sentence of section 2: " In this section we shall denote an IPv6 address of a tunnel's node by the prefix of the tunnel and the IPv4 address of the node, i.e., Addr(Prefix, IPv4). " Does that mean " In this section we shall denote an IPv6 address of a node reached via a given tunnel by the prefix of the tunnel and the IPv4 address of the node, i.e., Addr(Prefix, IPv4). " ? 4. The description in section 2 then states that a packet to IPv6 address (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the tunnel egress, but that R1 erroneously treats it as if it came from tunnel T1. It isn't made very clear that this happens *because* the whole of the IPv4 Internet acts as a shared link layer as far as these automatic tunneling techniques are concerned. Therefore, R1 can only rely on the (dubious) addresses in the packet headers to figure out what to do next, and what it does is send the packet back to R2, because that's what the IPv6 prefix tells it to do. As far as I can see, the return packet from R1 to R2 could be sent by native IPv6 if such connectivity exists, but is more likely to be sent via tunnel T1, which is what R1 probably uses to provide global v6 access. The draft should make this point clear, anyway. Section 3 of the draft describes three possible mitigation strategies. 1. Checking the embedded IPv4 addresses explicitly in the tunnel end points. This is fairly straightforward and would fix the problem in most cases, but creates some overhead. Configuration would be needed to deal with 6rd and with RFC1918-based tunnels. 2. Checking that the end point exists, by various techniques. I am more pessimistic about these options than the author seems to be. 3. Use different protocol numbers for different tunnel types. This would be hard to deploy - in fact I think it's hopeless, since backwards compatibility with proto 41 would have to be kept. By the way, is it sufficient if either R1 or R2 makes the checks? Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 20 13:47:21 2010 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 3C35F3A690C for ; Tue, 20 Jul 2010 13:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.083 X-Spam-Level: X-Spam-Status: No, score=-5.083 tagged_above=-999 required=5 tests=[AWL=2.812, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 qtnHiN5QPFPL for ; Tue, 20 Jul 2010 13:47:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CA9E3A67BD for ; Tue, 20 Jul 2010 13:47:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObJb3-0004UF-BH for v6ops-data0@psg.com; Tue, 20 Jul 2010 20:39:25 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObJb0-0004Tm-66 for v6ops@ops.ietf.org; Tue, 20 Jul 2010 20:39:22 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 20:39:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKdENo027173 for ; Tue, 20 Jul 2010 20:39:18 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:16:03 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 13:05:31 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 14:43:55 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 19:43:47 +0000 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KJhFO7007887 for ; Tue, 20 Jul 2010 19:43:47 GMT Received: from unknown (HELO smtp-outbound.ironport.com) ([173.37.8.42]) by ams-iport-1.cisco.com with ESMTP; 20 Jul 2010 19:43:37 +0000 Received: from smtp.soma.ironport.com (HELO c601.soma.ironport.com) ([192.168.60.201]) by smtp-colo-in.ironport.com with ESMTP/TLS/RC4-SHA; 20 Jul 2010 12:43:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBAF+ZRUyTHAA+gmdsb2JhbACDIJxLCBUBAQsLCAcTBR2mSYk0O4IQhhsuiFQBAQMFgSGDGXMEiFmCNQ X-IronPort-AV: E=McAfee;i="5400,1158,6049"; a="292510021" X-IronPort-AV: E=Sophos;i="4.55,234,1278313200"; d="scan'208";a="292510021" Received: from psg.com ([147.28.0.62]) by soma-c601.ironport.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 12:43:33 -0700 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObHq7-000EuL-CB for v6ops-data0@psg.com; Tue, 20 Jul 2010 18:46:51 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObHq4-000Eu0-KR for v6ops@ops.ietf.org; Tue, 20 Jul 2010 18:46:48 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 18:44:47 +0000 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.14.3) with ESMTP id o6KIilLl003837 for ; Tue, 20 Jul 2010 18:44:47 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 11:37:56 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 19:04:39 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 21:04:37 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 01:46:53 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1kmWU007582; Tue, 20 Jul 2010 01:46:52 GMT X-from-outside-Cisco: 147.28.0.62 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAGudREyTHAA+kWdsb2JhbACDIJxGCBUBAQEBCQsKBxEFHahbiTQ7ghCGKy6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,229,1278288000"; d="scan'208";a="165607387" Received: from psg.com ([147.28.0.62]) by sj-inbound-e.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 01:46:18 +0000 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dX-0002t7-6V for v6ops-data0@psg.com; Tue, 20 Jul 2010 01:28:47 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dU-0002sr-Oc for v6ops@ops.ietf.org; Tue, 20 Jul 2010 01:28:44 +0000 Received: by pwi7 with SMTP id 7so4289278pwi.11 for ; Mon, 19 Jul 2010 18:28:35 -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=sIwFArOm975tlSK1MWYUfcHVhEIl5Bpsc1bTnt2G2Ws=; b=ROZkyil9qRPK/3Rj3r0chALxFS6T2tKiLXBg1bucQc24gGRtbJlTlfHMK4WSRrX1xH Z/vDDZyQmxyjVM2bwXgI9gOCiJ2ktAn4z91Si5Jlp93EdO7yT6cZHic8n7wL1TnteWEo qjSekVY7ZHlLhV01rHeMPBuTHL1wwbp0ChvFE= 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=UyIcxSRn+f1iAdYY730QEngd4n1ec0i+JFCxotthbr6leMEsD0QeaK2Z02sG7yAnjR 2YTp4cS63Qk1jxCi1tt4zXPmLJF1Vq7T37X6aVz6AjtdeDV5hPnlKMdd8VLsdb36WZec tDg2ObECDRaKQKWPwQUxUR0dR1Ebug3GINnfY= Received: by 10.142.144.2 with SMTP id r2mr7154937wfd.262.1279589315426; Mon, 19 Jul 2010 18:28:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g37sm17689174rvb.5.2010.07.19.18.28.32 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 18:28:34 -0700 (PDT) Message-ID: <4C44FBBB.3020401@gmail.com> Date: Tue, 20 Jul 2010 13:28:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> In-Reply-To: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 20 Jul 2010 02:04:37.0935 (UTC) FILETIME=[E83E53F0:01CB27AF] List-ID: Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 03:19, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? Summary ------- This short draft proposes guidelines for use by listing sites that report on the level of IPv6 support from various ISPs. There are a number of such sites, and they don't all report on the same criteria, so the draft proposes seven common criteria, split into 'basic' and 'advanced'. I believe this document is useful, but it needs some debate about the exact criteria proposed, and it needs discussion with the people operating existing listing sites. If they don't agree, the document is going nowhere. More detail ----------- It seems like a good idea for all these listing sites to use common criteria. Whether they would do so in practice is another question. (How many ISPs do you know who refer to RFC 4084 in their sales literature?) That's why the sites need to be involved in the discussion. The list of criteria needs some debate in the WG. For example, there is no check whether IPv6-only clients would be satisfied. So as it stands, an ISP could get a green light according to this draft, but its IPv6-only users couldn't get SMTP service (for example). On the other hand, for practical reasons, there should not be too many criteria. There's no security text. There needs to be something if this is to proceed as an RFC. We could discuss whether any security-related criteria should be added; if not, we need to say why not. The draft is short enough that there's no point in a section-by-section review. There are a few places where the RFC Editor would need to tidy up the English. Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 20 15:18:45 2010 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 31B483A68A2 for ; Tue, 20 Jul 2010 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[AWL=2.499, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 4ePFYKrdMpJu for ; Tue, 20 Jul 2010 15:18:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECCEC3A65A5 for ; Tue, 20 Jul 2010 15:18:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObL0N-000EhF-Qc for v6ops-data0@psg.com; Tue, 20 Jul 2010 22:09:39 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObL0K-000Egb-3U for v6ops@ops.ietf.org; Tue, 20 Jul 2010 22:09:36 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 22:09:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KM94p7029194 for ; Tue, 20 Jul 2010 22:09:32 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 14:57:36 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 19:04:39 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 21:04:37 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 01:46:53 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1kmWU007582; Tue, 20 Jul 2010 01:46:52 GMT X-from-outside-Cisco: 147.28.0.62 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAGudREyTHAA+kWdsb2JhbACDIJxGCBUBAQEBCQsKBxEFHahbiTQ7ghCGKy6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,229,1278288000"; d="scan'208";a="165607387" Received: from psg.com ([147.28.0.62]) by sj-inbound-e.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 01:46:18 +0000 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dX-0002t7-6V for v6ops-data0@psg.com; Tue, 20 Jul 2010 01:28:47 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dU-0002sr-Oc for v6ops@ops.ietf.org; Tue, 20 Jul 2010 01:28:44 +0000 Received: by pwi7 with SMTP id 7so4289278pwi.11 for ; Mon, 19 Jul 2010 18:28:35 -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=sIwFArOm975tlSK1MWYUfcHVhEIl5Bpsc1bTnt2G2Ws=; b=ROZkyil9qRPK/3Rj3r0chALxFS6T2tKiLXBg1bucQc24gGRtbJlTlfHMK4WSRrX1xH Z/vDDZyQmxyjVM2bwXgI9gOCiJ2ktAn4z91Si5Jlp93EdO7yT6cZHic8n7wL1TnteWEo qjSekVY7ZHlLhV01rHeMPBuTHL1wwbp0ChvFE= 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=UyIcxSRn+f1iAdYY730QEngd4n1ec0i+JFCxotthbr6leMEsD0QeaK2Z02sG7yAnjR 2YTp4cS63Qk1jxCi1tt4zXPmLJF1Vq7T37X6aVz6AjtdeDV5hPnlKMdd8VLsdb36WZec tDg2ObECDRaKQKWPwQUxUR0dR1Ebug3GINnfY= Received: by 10.142.144.2 with SMTP id r2mr7154937wfd.262.1279589315426; Mon, 19 Jul 2010 18:28:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g37sm17689174rvb.5.2010.07.19.18.28.32 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 18:28:34 -0700 (PDT) Message-ID: <4C44FBBB.3020401@gmail.com> Date: Tue, 20 Jul 2010 13:28:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> In-Reply-To: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 20 Jul 2010 02:04:37.0935 (UTC) FILETIME=[E83E53F0:01CB27AF] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 03:19, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? Summary ------- This short draft proposes guidelines for use by listing sites that report on the level of IPv6 support from various ISPs. There are a number of such sites, and they don't all report on the same criteria, so the draft proposes seven common criteria, split into 'basic' and 'advanced'. I believe this document is useful, but it needs some debate about the exact criteria proposed, and it needs discussion with the people operating existing listing sites. If they don't agree, the document is going nowhere. More detail ----------- It seems like a good idea for all these listing sites to use common criteria. Whether they would do so in practice is another question. (How many ISPs do you know who refer to RFC 4084 in their sales literature?) That's why the sites need to be involved in the discussion. The list of criteria needs some debate in the WG. For example, there is no check whether IPv6-only clients would be satisfied. So as it stands, an ISP could get a green light according to this draft, but its IPv6-only users couldn't get SMTP service (for example). On the other hand, for practical reasons, there should not be too many criteria. There's no security text. There needs to be something if this is to proceed as an RFC. We could discuss whether any security-related criteria should be added; if not, we need to say why not. The draft is short enough that there's no point in a section-by-section review. There are a few places where the RFC Editor would need to tidy up the English. Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 20 15:18:53 2010 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 C6EB13A68A2 for ; Tue, 20 Jul 2010 15:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 JGygBaT5oIiS for ; Tue, 20 Jul 2010 15:18:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEC033A6892 for ; Tue, 20 Jul 2010 15:18:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObL3w-000FFi-A3 for v6ops-data0@psg.com; Tue, 20 Jul 2010 22:13:20 +0000 Received: from [64.78.22.237] (helo=EXPFE100-2.exc.icann.org) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObL3t-000FE8-V0 for v6ops@ops.ietf.org; Tue, 20 Jul 2010 22:13:18 +0000 Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 20 Jul 2010 15:13:16 -0700 From: Leo Vegoda To: IPv6 Operations Date: Tue, 20 Jul 2010 15:13:16 -0700 Subject: draft-azinger-cidrv6-00 Thread-Topic: draft-azinger-cidrv6-00 Thread-Index: AcsoWMCr+CEgLl/JRs6fOOYSZyiWmg== Message-ID: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I have been reading draft-azinger-cidrv6-00 and have a couple of comments o= n it for the list. Firstly, in section 4, I think it would be useful to note that RIRs should = aim to aggregate an ISPs second and later allocation with earlier allocatio= ns. I believe this is already done but it would be good to recommend it. I'= d like to suggest the second sentence below be added. "RIRs initial and subsequent allocation policy to service providers should = allow for a minimum of 2 years worth of usage based on historical or busine= ss plan projections. Further, RIRs should implement practices that maximise= the potential for subsequent allocations to be made contiguous with previo= us allocations." Also, in section 10 it is recommended that "Internet Registries should seve= rely limit or eliminate [...] PI assignments". There are obviously reasons = for the current policies allowing IPv6 PI assignments but the potential for= significant routing table growth has not been removed, so I wonder whether= it would make sense to request the RIR communities to review the impact of= PI assignment policies on the rate of routing table growth on a regular ba= sis.=20 Regards, Leo= From owner-v6ops@ops.ietf.org Tue Jul 20 17:46:36 2010 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 EF2C83A6951 for ; Tue, 20 Jul 2010 17:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.609 X-Spam-Level: X-Spam-Status: No, score=-5.609 tagged_above=-999 required=5 tests=[AWL=2.286, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 1xg4ucWyVP6Q for ; Tue, 20 Jul 2010 17:46:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF1AA3A6838 for ; Tue, 20 Jul 2010 17:46:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObNIM-00048Y-02 for v6ops-data0@psg.com; Wed, 21 Jul 2010 00:36:22 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObNII-00047Q-SA for v6ops@ops.ietf.org; Wed, 21 Jul 2010 00:36:19 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2010 00:28:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6L0SkWE007782 for ; Wed, 21 Jul 2010 00:28:47 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 16:07:02 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 19:04:33 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 01:46:53 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1kmWV007582; Tue, 20 Jul 2010 01:46:53 GMT X-from-outside-Cisco: 147.28.0.62 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAGudREyTHAA+kWdsb2JhbACDIJxGCBUBAQEBCQsKBxEFHahbiTQ7ghCGKy6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,229,1278288000"; d="scan'208";a="165607387" Received: from psg.com ([147.28.0.62]) by sj-inbound-e.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 01:46:18 +0000 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dX-0002t7-6V for v6ops-data0@psg.com; Tue, 20 Jul 2010 01:28:47 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob1dU-0002sr-Oc for v6ops@ops.ietf.org; Tue, 20 Jul 2010 01:28:44 +0000 Received: by pwi7 with SMTP id 7so4289278pwi.11 for ; Mon, 19 Jul 2010 18:28:35 -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=sIwFArOm975tlSK1MWYUfcHVhEIl5Bpsc1bTnt2G2Ws=; b=ROZkyil9qRPK/3Rj3r0chALxFS6T2tKiLXBg1bucQc24gGRtbJlTlfHMK4WSRrX1xH Z/vDDZyQmxyjVM2bwXgI9gOCiJ2ktAn4z91Si5Jlp93EdO7yT6cZHic8n7wL1TnteWEo qjSekVY7ZHlLhV01rHeMPBuTHL1wwbp0ChvFE= 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=UyIcxSRn+f1iAdYY730QEngd4n1ec0i+JFCxotthbr6leMEsD0QeaK2Z02sG7yAnjR 2YTp4cS63Qk1jxCi1tt4zXPmLJF1Vq7T37X6aVz6AjtdeDV5hPnlKMdd8VLsdb36WZec tDg2ObECDRaKQKWPwQUxUR0dR1Ebug3GINnfY= Received: by 10.142.144.2 with SMTP id r2mr7154937wfd.262.1279589315426; Mon, 19 Jul 2010 18:28:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g37sm17689174rvb.5.2010.07.19.18.28.32 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 18:28:34 -0700 (PDT) Message-ID: <4C44FBBB.3020401@gmail.com> Date: Tue, 20 Jul 2010 13:28:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> In-Reply-To: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 20 Jul 2010 02:04:33.0717 (UTC) FILETIME=[E5BAB650:01CB27AF] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 03:19, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? Summary ------- This short draft proposes guidelines for use by listing sites that report on the level of IPv6 support from various ISPs. There are a number of such sites, and they don't all report on the same criteria, so the draft proposes seven common criteria, split into 'basic' and 'advanced'. I believe this document is useful, but it needs some debate about the exact criteria proposed, and it needs discussion with the people operating existing listing sites. If they don't agree, the document is going nowhere. More detail ----------- It seems like a good idea for all these listing sites to use common criteria. Whether they would do so in practice is another question. (How many ISPs do you know who refer to RFC 4084 in their sales literature?) That's why the sites need to be involved in the discussion. The list of criteria needs some debate in the WG. For example, there is no check whether IPv6-only clients would be satisfied. So as it stands, an ISP could get a green light according to this draft, but its IPv6-only users couldn't get SMTP service (for example). On the other hand, for practical reasons, there should not be too many criteria. There's no security text. There needs to be something if this is to proceed as an RFC. We could discuss whether any security-related criteria should be added; if not, we need to say why not. The draft is short enough that there's no point in a section-by-section review. There are a few places where the RFC Editor would need to tidy up the English. Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 20 19:50:01 2010 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 328773A672E for ; Tue, 20 Jul 2010 19:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=2.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 fiHysZCSPQrV for ; Tue, 20 Jul 2010 19:49:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 932933A6843 for ; Tue, 20 Jul 2010 19:49:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObPD1-000IFG-6O for v6ops-data0@psg.com; Wed, 21 Jul 2010 02:38:59 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObPCy-000IEV-Aj for v6ops@ops.ietf.org; Wed, 21 Jul 2010 02:38:56 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2010 02:16:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6L2FkE4011588 for ; Wed, 21 Jul 2010 02:16:37 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:45:58 -0700 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 18:41:50 -0700 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 01:28:35 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1S0BB027108 for ; Tue, 20 Jul 2010 01:28:35 GMT X-from-outside-Cisco: 74.125.83.179 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0CAE2YRExKfVOzk2dsb2JhbACDIJxGCBUBAQEBCQkKCREDH6kGiTQ7ghCGKi6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,229,1278288000"; d="scan'208";a="205250293" Received: from mail-pv0-f179.google.com ([74.125.83.179]) by sj-inbound-f.cisco.com with ESMTP; 20 Jul 2010 01:28:35 +0000 Received: by pvh11 with SMTP id 11so2465351pvh.38 for ; Mon, 19 Jul 2010 18:28:35 -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=sIwFArOm975tlSK1MWYUfcHVhEIl5Bpsc1bTnt2G2Ws=; b=ROZkyil9qRPK/3Rj3r0chALxFS6T2tKiLXBg1bucQc24gGRtbJlTlfHMK4WSRrX1xH Z/vDDZyQmxyjVM2bwXgI9gOCiJ2ktAn4z91Si5Jlp93EdO7yT6cZHic8n7wL1TnteWEo qjSekVY7ZHlLhV01rHeMPBuTHL1wwbp0ChvFE= 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=UyIcxSRn+f1iAdYY730QEngd4n1ec0i+JFCxotthbr6leMEsD0QeaK2Z02sG7yAnjR 2YTp4cS63Qk1jxCi1tt4zXPmLJF1Vq7T37X6aVz6AjtdeDV5hPnlKMdd8VLsdb36WZec tDg2ObECDRaKQKWPwQUxUR0dR1Ebug3GINnfY= Received: by 10.142.144.2 with SMTP id r2mr7154937wfd.262.1279589315426; Mon, 19 Jul 2010 18:28:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g37sm17689174rvb.5.2010.07.19.18.28.32 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 18:28:34 -0700 (PDT) Message-ID: <4C44FBBB.3020401@gmail.com> Date: Tue, 20 Jul 2010 13:28:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> In-Reply-To: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2010 01:41:50.0033 (UTC) FILETIME=[B8E90C10:01CB27AC] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 03:19, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? Summary ------- This short draft proposes guidelines for use by listing sites that report on the level of IPv6 support from various ISPs. There are a number of such sites, and they don't all report on the same criteria, so the draft proposes seven common criteria, split into 'basic' and 'advanced'. I believe this document is useful, but it needs some debate about the exact criteria proposed, and it needs discussion with the people operating existing listing sites. If they don't agree, the document is going nowhere. More detail ----------- It seems like a good idea for all these listing sites to use common criteria. Whether they would do so in practice is another question. (How many ISPs do you know who refer to RFC 4084 in their sales literature?) That's why the sites need to be involved in the discussion. The list of criteria needs some debate in the WG. For example, there is no check whether IPv6-only clients would be satisfied. So as it stands, an ISP could get a green light according to this draft, but its IPv6-only users couldn't get SMTP service (for example). On the other hand, for practical reasons, there should not be too many criteria. There's no security text. There needs to be something if this is to proceed as an RFC. We could discuss whether any security-related criteria should be added; if not, we need to say why not. The draft is short enough that there's no point in a section-by-section review. There are a few places where the RFC Editor would need to tidy up the English. Brian Carpenter From owner-v6ops@ops.ietf.org Tue Jul 20 19:50:43 2010 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 35C613A672E for ; Tue, 20 Jul 2010 19:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-3.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_13=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 OIEcQzXcngDv for ; Tue, 20 Jul 2010 19:50:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 289943A6843 for ; Tue, 20 Jul 2010 19:50:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObPEH-000IOC-7y for v6ops-data0@psg.com; Wed, 21 Jul 2010 02:40:17 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObPEE-000IMU-2w for v6ops@ops.ietf.org; Wed, 21 Jul 2010 02:40:14 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6L2e5lU013272; Wed, 21 Jul 2010 11:40:05 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6L2e5Z13224; Wed, 21 Jul 2010 11:40:05 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6L2e4Np020764; Wed, 21 Jul 2010 11:40:04 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6L2e4Ug003451; Wed, 21 Jul 2010 11:40:04 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6L2e4P9022267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 11:40:04 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6L2e4YC005322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 11:40:04 +0900 Message-ID: <4C465E03.3060104@mesh.ad.jp> Date: Wed, 21 Jul 2010 11:40:03 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian E Carpenter CC: IPv6 Operations , Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> <4C44FBBB.3020401@gmail.com> In-Reply-To: <4C44FBBB.3020401@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian Thanks for the review. Appologies for the very roughly written draft. My comments inline Brian E Carpenter wrote: > On 2010-07-16 03:19, Fred Baker wrote: >> Could I interest you in doing a thorough review of draft-kawamura-ipv6-isp-listings and commenting to v6ops? > > Summary > ------- > > This short draft proposes guidelines for use by listing sites that report on > the level of IPv6 support from various ISPs. There are a number of such > sites, and they don't all report on the same criteria, so the draft proposes > seven common criteria, split into 'basic' and 'advanced'. > > I believe this document is useful, but it needs some debate about the exact > criteria proposed, and it needs discussion with the people operating > existing listing sites. If they don't agree, the document is going nowhere. I agree with you. I am talking with a few people on the IPv6 forum. I believe some of them will be at Maatricht, hopefully they will stay until Friday. That's only one of the list makers, so I should go and contact more. > > More detail > ----------- > > It seems like a good idea for all these listing sites to use common criteria. > Whether they would do so in practice is another question. (How many ISPs > do you know who refer to RFC 4084 in their sales literature?) That's why > the sites need to be involved in the discussion. > > The list of criteria needs some debate in the WG. For example, there is > no check whether IPv6-only clients would be satisfied. So as it stands, > an ISP could get a green light according to this draft, but its IPv6-only > users couldn't get SMTP service (for example). On the other hand, for > practical reasons, there should not be too many criteria. This kind of discussion is exactly what I wanted to have at Maastricht. To what extent, would and ISP need to cover for their service to be called a "working IPv6 ISP"? SMTP? DNS caches? Would a single home tunnel transited ISP be equally considered IPv6? For example, some ISPs can choose to provide SMTP via IPv4 only but their MX must be dual stacked for their users to communicate with the global internet. > There's no security text. There needs to be something if this is to proceed > as an RFC. We could discuss whether any security-related criteria should > be added; if not, we need to say why not. > > The draft is short enough that there's no point in a section-by-section > review. There are a few places where the RFC Editor would need to tidy up > the English. I agree with these comments. Thanks. Regards, Seiichi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxGXgIACgkQcrhTYfxyMkI/KgCgjBZm2aI0uc70looZgBYbOpcR VyAAn0GrVKT30UBT58ZtVpGPfIioGiml =htBa -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Jul 20 20:13:08 2010 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 1D1EC3A68DE for ; Tue, 20 Jul 2010 20:13:07 -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.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 tOcAroQ3+5tv for ; Tue, 20 Jul 2010 20:13:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C9393A67AE for ; Tue, 20 Jul 2010 20:13:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObPe8-000LUG-8L for v6ops-data0@psg.com; Wed, 21 Jul 2010 03:07:00 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObPe5-000LTZ-4D for v6ops@ops.ietf.org; Wed, 21 Jul 2010 03:06:57 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6L36R79005666; Wed, 21 Jul 2010 12:06:27 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6L36Rl05028; Wed, 21 Jul 2010 12:06:27 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6L36QZj021616; Wed, 21 Jul 2010 12:06:26 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6L36QcP006300; Wed, 21 Jul 2010 12:06:26 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6L36QhV022756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 12:06:26 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6L36Q5W005730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 12:06:26 +0900 Message-ID: <4C466431.10004@mesh.ad.jp> Date: Wed, 21 Jul 2010 12:06:25 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lindqvist Kurt Erik CC: IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> In-Reply-To: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Kurt Thanks for the review Lindqvist Kurt Erik wrote: > I have read the above documents and have some general comments and then some more nit like comments. > > General comments: > ----------------- > > In general it might be good with a document outlining some basic checklists to determine > the level of IPv6 readiness in a service provider. However, I doubt the value > of listing some of the current programs and what methodology they are currently using. > These change, and keeping the document uptodate so it's meaningful might be hard and > of little value. I agree. The lists on this draft are noted here for reference and starting a discussion. If this were to be an RFC, its not much worth listing them on the document. > Now, that type of measurement is not the same type of checklist / certification > program as the I-D describes, but this brings me to what I believe is the > biggest flaw of section 3 - it doesn't say much about actual deployment. ] > Rather, the barrier is very low. For example in 3.3 it mentions an > allocated or PI block. If this is for an ISP, a PI block is useless as the intention > of PI is to not suballocate. I would set the requirement to PA bock only. Good point. I agree with this. > Further - I believe the Basic class described in 3.3 should at least require > sub-allocations of IPV6 prefixes, otherwise it's hard to argue that an ISP > has 'deployed' IPv6. As for the Advance class in 3.4, I would suggest that an Also agree here. > ISP provides more than basic services (i.e DNS) over IPv6 to end-users and/or the Internet in general. Agree also. > Still, while I am somewhat agreeing with a standardized measurement of IPv6 readiness in an > AS/ISP I think that it's more useful to work on measuring actually deployed > clients that can be observed and publishing that data. Even better would be > standardized quality measures of these deployments. There are many drawbacks > on doing this based on only observed data at a server side ala looking at > a web-server, but as Lorenzo and Google have shown in many presentations, > at least it gives data to do a risk assessment for a service operator. I think that would be interesting work too. What I hear from small ISPs these days is that they want a minimum list of things to do to be able to communicate with the IPv6 world. Bringing an ISP to be fully dual stacked will take years. I think a minimum guideline would be useful (is there one out there already?), and if these lists would measure readiness according to minimum guidelines that would be even better. > If this document could combine some level of Basic recommendations along the lines of > "Have PA, hvae done X sub-delegations, provides Y services" together with a standard > collection mechanism/schema (perhaps that is really a different document) similar to > what RIPE does, what Google does, or even better- a format or method that would allow > sharing of data, content/service operators could build a matrix and we could see the > progress and quality of IPv6 deployment. This sounds very cool. Although I admit I don't know too much about measurement. Regards, Seiichi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxGZDAACgkQcrhTYfxyMkKXDgCfUcAIThjMhLBSKXjK/D7qW2TP xaEAnieR+/7XH/+abJt9ApPjSJvLlLQf =gsgG -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Jul 20 21:00:13 2010 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 C31E93A6884 for ; Tue, 20 Jul 2010 21:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-1.715, 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 N4hq2Bad6TFy for ; Tue, 20 Jul 2010 21:00:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D29033A67AE for ; Tue, 20 Jul 2010 21:00:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObQMi-0000aO-5A for v6ops-data0@psg.com; Wed, 21 Jul 2010 03:53:04 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObQMf-0000Ze-LI for v6ops@ops.ietf.org; Wed, 21 Jul 2010 03:53:01 +0000 Received: by gwj17 with SMTP id 17so5419536gwj.11 for ; Tue, 20 Jul 2010 20:52:38 -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=2BcQt1gp9YOsZG9ZPZ84yWaKDotd94lGkcTGO201ffA=; b=dPonw6ssXopjvQgur7AQeVD4v9elrKVMfbzn0Fab9DQHwDsT1gg0LU9ME5szqt5lZX 86Z30IHHyzf1q+muO1Owv4fpmys5DaGmaHoMk55fuWLQ9y+KBbnmQc3/9K5Vvzylqsa2 eBAX8wF+wlcfK0Wf8PaKZJMZ8WCwe3i5bj89w= 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=Zx5kl+2/JizihYoidzVtMgSVvW/GTVt6JapChGu/hJyKsHTFdSW7kaOf1m6JCh8lp/ UDglPtfFliQUeZDgM7yM9H73c+FFcTXvBoSQysLHCpMQ/9Vcv04mazY91LOIyjvY7PIB CRGQx0wBPxvcp8eBtAfBzTFu93E+5PfDlZEL0= Received: by 10.151.59.13 with SMTP id m13mr1623164ybk.94.1279684358328; Tue, 20 Jul 2010 20:52:38 -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 m11sm7441701ybn.4.2010.07.20.20.52.35 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 20:52:37 -0700 (PDT) Message-ID: <4C466F0C.90309@gmail.com> Date: Wed, 21 Jul 2010 15:52:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations Subject: Re: draft-nakibly-v6ops-tunnel-loops discussion References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> <4C45171D.8090506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-21 05:41, Fred Baker wrote: > On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote: >> The draft doesn't recommend a choice of technique. I think that for the work to go forward, the WG would need to agree on a recommendation. Otherwise, the world will shrug its shoulders. > > Following up on Brian's excellent review. Let's discuss this. In view of draft-arkko-ipv6-transition-guidelines and draft-ietf-v6ops-tunnel-security-concerns, do we need this draft? Should we prefer it to one of the others? Is there something specific we would like this document to recommend? The word 'loop' does not occur in draft-ietf-v6ops-tunnel-security-concerns, from which I deduce that draft-nakibly covers a disjoint problem space. I suppose in theory the two documents could be merged, but from a practical viewpoint it seems better to keep them separate. Also, I think draft-nakibly is too specific to consider it as really intersecting with draft-arkko. Whatever models we recommend in draft-arkko, some people will be running automatic tunnels for years, so the exposure to loops will exist. Actually it seems that the Security Considerations in draft-arkko should perhaps refer to draft-ietf-v6ops-tunnel-security-concerns and to draft-nakibly. My $0.02 Brian From owner-v6ops@ops.ietf.org Tue Jul 20 21:00:22 2010 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 7AA453A699F for ; Tue, 20 Jul 2010 21:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=-2.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=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 vl4coisIujWO for ; Tue, 20 Jul 2010 21:00:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3251C3A6869 for ; Tue, 20 Jul 2010 21:00:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObQRO-00015z-Ml for v6ops-data0@psg.com; Wed, 21 Jul 2010 03:57:54 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObQRL-00015N-Vt for v6ops@ops.ietf.org; Wed, 21 Jul 2010 03:57:52 +0000 Received: by iwn8 with SMTP id 8so6790129iwn.11 for ; Tue, 20 Jul 2010 20:57:42 -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=8lu02tbiiDC/lYTVKaj484HKBndWRv2GkTWnl/1NxpQ=; b=HD+QiPzmH1SHXUDxS2B3Tc96oD84QCLcrRNj7Juma9QhtU2RCT/EXTnryW3WK88ldM yjywXluq5Gbm4vUyUoblPcbJR9ruQn01Duq6LBuq1VCLqLusy58qoVHX65IsAz67nCMI uXSEn8yfHaQtnrcMVOHwoz+jS+p5NBTyRPgMI= 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=Cta3cL8XJrKX58tywP+SJXwLpjtQ/nmAk7Y5GsVpOLKTjSaf22WMGat8ValihqjIXq 6MyTnirgNLhq+qIaAsA1wjhZa+IKK94dEnxXwPqwgL5EQ+EuxMpfxLKsl2fzTg5/na4z jcwk1zGoYAQdgNo5tVNMSSl8QmthJmU1mkr+U= Received: by 10.231.191.142 with SMTP id dm14mr7703196ibb.74.1279684661773; Tue, 20 Jul 2010 20:57:41 -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 e8sm28242480ibb.20.2010.07.20.20.57.39 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 20:57:40 -0700 (PDT) Message-ID: <4C46703C.5020506@gmail.com> Date: Wed, 21 Jul 2010 15:57:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations Subject: Re: draft-nakibly-v6ops-tunnel-loops review References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> <4C45171D.8090506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, IMHO this is indeed sound work. As I said, even if it's to be informational, I think there should be some sort of choice made among the solutions, or at least a summary of the pros and cons. So I think we need progress on that before a WGLC. Brian On 2010-07-21 03:05, Fred Baker wrote: > Thanks much for the review. Looks like it at least needs an update before being finalized. > > Question for you. Would you consider an updated version of the document ready for WGLC, or do we need further discussion on it? Apart from the beauty of the prose, are the notions proposed sound? > > On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote: > >> On 2010-07-16 02:48, Fred Baker wrote: >>> Could I interest you in doing a thorough review of draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\ >> Summary >> ------- >> >> This draft proposes mitigation techniques for malicious loops formed >> using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms. >> >> The draft doesn't recommend a choice of technique. I think that for the >> work to go forward, the WG would need to agree on a recommendation. >> Otherwise, the world will shrug its shoulders. >> >> Details >> ------- >> >> Several IPv6 transition aids rely on automatic tunneling of IPv6 in >> IPv4. If an attacker succeeds in making two such methods link up >> with each other head-to-tail, a loop will form, and will consume all >> available resources. With manually configured tunnels, such a loop >> will be excluded by construction, but with automatic tunnels, an attacker >> can (under certain conditions) create a packet that a tunnel egress >> will feed back into regular IPv6 routing such that it ends up back >> in the tunnel again, until its hop limit expires. >> >> Section 2 describes the attack scenario. I find the terminology >> rather confusing: >> >> 1. For each tunnel, there is an object called "the tunnel router". >> I assume this is supposed to be the encapsulating ingress router. >> But it isn't stated clearly. >> >> 2. Tunnels have egress decapsulators. Their role is not described >> very clearly, but is assumed to be understood. >> >> 3. There's a reference to destination hosts being "in" the tunnel. >> ("The attack is ... initiated by sending an >> IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...") >> >> But hosts aren't in tunnels. They are outside the tunnel, beyond the >> egress router. [OK, some hosts do their own decapsulation, but then one >> can separate their decapsulator from their IPv6 stack, and anyway such >> hosts are not routers and will not forward packets back into the network.] >> >> So does this mean "destined to a fictitious end point that appears >> to be reached via T2"? >> >> There's a similar problem in the very first sentence of section 2: >> >> " In this section we shall denote an IPv6 address of a tunnel's node by >> the prefix of the tunnel and the IPv4 address of the node, i.e., >> Addr(Prefix, IPv4). " >> >> Does that mean >> >> " In this section we shall denote an IPv6 address of a node reached via >> a given tunnel by the prefix of the tunnel and the IPv4 address of the node, i.e., >> Addr(Prefix, IPv4). " ? >> >> 4. The description in section 2 then states that a packet to IPv6 address >> (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the >> tunnel egress, but that R1 erroneously treats it as if it came from tunnel T1. >> It isn't made very clear that this happens *because* the whole of the IPv4 >> Internet acts as a shared link layer as far as these automatic tunneling >> techniques are concerned. Therefore, R1 can only rely on the (dubious) >> addresses in the packet headers to figure out what to do next, and what it >> does is send the packet back to R2, because that's what the IPv6 prefix tells >> it to do. >> >> As far as I can see, the return packet from R1 to R2 could be sent by >> native IPv6 if such connectivity exists, but is more likely to be sent >> via tunnel T1, which is what R1 probably uses to provide global v6 access. >> The draft should make this point clear, anyway. >> >> Section 3 of the draft describes three possible mitigation strategies. >> >> 1. Checking the embedded IPv4 addresses explicitly in the tunnel end points. >> This is fairly straightforward and would fix the problem in most cases, but >> creates some overhead. Configuration would be needed to deal with 6rd >> and with RFC1918-based tunnels. >> >> 2. Checking that the end point exists, by various techniques. I am more >> pessimistic about these options than the author seems to be. >> >> 3. Use different protocol numbers for different tunnel types. This would >> be hard to deploy - in fact I think it's hopeless, since backwards >> compatibility with proto 41 would have to be kept. >> >> By the way, is it sufficient if either R1 or R2 makes the checks? >> >> Brian Carpenter > > http://www.ipinc.net/IPv4.GIF > > From owner-v6ops@ops.ietf.org Tue Jul 20 23:35:21 2010 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 395C73A69E9 for ; Tue, 20 Jul 2010 23:35:21 -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 BFnyncM-b+b3 for ; Tue, 20 Jul 2010 23:35:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 385633A63C9 for ; Tue, 20 Jul 2010 23:35:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObSjx-000JP8-4Q for v6ops-data0@psg.com; Wed, 21 Jul 2010 06:25:13 +0000 Received: from [2001:670:87:a::107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObSju-000JOh-1f for v6ops@ops.ietf.org; Wed, 21 Jul 2010 06:25:10 +0000 Received: from [IPv6:2a01:3f0:1::226:bbff:fe1d:8912] (unknown [IPv6:2a01:3f0:1:0:226:bbff:fe1d:8912]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id 51FEC2E027; Wed, 21 Jul 2010 07:54:46 +0200 (CEST) Subject: Re: draft-kawamura-ipv6-isp-listings review Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16902-738592665" From: Lindqvist Kurt Erik In-Reply-To: <4C465E03.3060104@mesh.ad.jp> Date: Wed, 21 Jul 2010 08:25:03 +0200 Cc: Brian E Carpenter , IPv6 Operations , Fred Baker Content-Transfer-Encoding: 7bit Message-Id: References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> <4C44FBBB.3020401@gmail.com> <4C465E03.3060104@mesh.ad.jp> To: Seiichi Kawamura X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16902-738592665 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 jul 2010, at 04.40, Seiichi Kawamura wrote: >=20 > This kind of discussion is exactly what I wanted to have at = Maastricht. > To what extent, would and ISP need to cover for their service to be > called a "working IPv6 ISP"? SMTP? DNS caches? Would a single home > tunnel transited ISP be equally considered IPv6? For example, > some ISPs can choose to provide SMTP via IPv4 only but their MX must = be > dual stacked for their users to communicate with the global internet. Personally I believe the criteria for an ISP to be "v6" is that they = have a PA block and that they are giving out customer assignments. I = would prefer a requirement of native (i.e dual-stack or v6 only) = upstream connection.=20 Best regards, - kurtis - --Apple-Mail-16902-738592665 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxGkr8ACgkQAFdZ6xrc/t6W3gCfXaSA6LNqm+eQ6BFYEYKmUMWS qK0AnjHsxSh8U5ws3VeqlZo3LDXP4Bse =7ark -----END PGP SIGNATURE----- --Apple-Mail-16902-738592665-- From owner-v6ops@ops.ietf.org Tue Jul 20 23:35:22 2010 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 8E48C3A69E9 for ; Tue, 20 Jul 2010 23:35:22 -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 SRIkSMY1DO7H for ; Tue, 20 Jul 2010 23:35:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C12C3A682E for ; Tue, 20 Jul 2010 23:35:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObSn8-000Jpc-Qv for v6ops-data0@psg.com; Wed, 21 Jul 2010 06:28:30 +0000 Received: from [2001:670:87:a::107] (helo=eckero.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObSn6-000JoF-8B for v6ops@ops.ietf.org; Wed, 21 Jul 2010 06:28:28 +0000 Received: from [IPv6:2a01:3f0:1::226:bbff:fe1d:8912] (unknown [IPv6:2a01:3f0:1:0:226:bbff:fe1d:8912]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by eckero.kurtis.pp.se (Postfix) with ESMTPSA id F3FEA2E027; Wed, 21 Jul 2010 07:58:05 +0200 (CEST) Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16903-738792287" From: Lindqvist Kurt Erik In-Reply-To: <4C466431.10004@mesh.ad.jp> Date: Wed, 21 Jul 2010 08:28:22 +0200 Cc: IPv6 v6ops Content-Transfer-Encoding: 7bit Message-Id: References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> To: Seiichi Kawamura X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16903-738792287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 jul 2010, at 05.06, Seiichi Kawamura wrote: >>=20 >> Still, while I am somewhat agreeing with a standardized measurement = of IPv6 readiness in an=20 >> AS/ISP I think that it's more useful to work on measuring actually = deployed >> clients that can be observed and publishing that data. Even better = would be >> standardized quality measures of these deployments. There are many = drawbacks >> on doing this based on only observed data at a server side ala = looking at >> a web-server, but as Lorenzo and Google have shown in many = presentations, >> at least it gives data to do a risk assessment for a service = operator. >=20 > I think that would be interesting work too. >=20 > What I hear from small ISPs these days is > that they want a minimum list of things to do to be > able to communicate with the IPv6 world. >=20 > Bringing an ISP to be fully dual stacked will take years. So I suggest that minumum is=20 - PA Block - Customer Assignments - DNS resolvers IPv6 capable - Native (v6 only or dual-stack) upstream connection - SMTP relay / Submission IPv6 - IMAP/POP IPv6 With that you can run on v6. The last two I am not to determined on, but = then a gradually increasing list of services that is supporting IPv6=20 - Native transport to customers - Web - Jabber - SIP - etc > I think a minimum guideline would be useful (is there one out there = already?), and Not that I know of.=20 Best regards, - kurtis - --Apple-Mail-16903-738792287 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxGk4YACgkQAFdZ6xrc/t6izgCglDkG+33kT6U8hxVZXwHLuW3L 1xIAnRhxnqfo/kUtFkPfh4AXEPllYcqz =u8LE -----END PGP SIGNATURE----- --Apple-Mail-16903-738792287-- From owner-v6ops@ops.ietf.org Wed Jul 21 04:24:43 2010 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 B74EE3A696B for ; Wed, 21 Jul 2010 04:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[AWL=1.937, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, 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 m1fLBcffP7oH for ; Wed, 21 Jul 2010 04:24:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4268E3A6A07 for ; Wed, 21 Jul 2010 04:24:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObXEd-000BNO-8E for v6ops-data0@psg.com; Wed, 21 Jul 2010 11:13:11 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObXEa-000BMh-9D for v6ops@ops.ietf.org; Wed, 21 Jul 2010 11:13:08 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=@gmail.com Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2010 09:28:57 +0000 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.14.3) with ESMTP id o6L9StS2015477 for ; Wed, 21 Jul 2010 09:28:57 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 11:40:10 -0700 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 20:35:38 -0700 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 03:35:38 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K3ZbB1010385; Tue, 20 Jul 2010 03:35:37 GMT X-from-outside-Cisco: 147.28.0.62 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcBALq2REyTHAA+lGdsb2JhbACDIJxGCBUBAQEBCQsICREFHadgiTQ7ghCGJi6IVAEBAwWBIYMJcwSIVg X-IronPort-AV: E=Sophos;i="4.55,230,1278288000"; d="scan'208";a="205263785" Received: from psg.com ([147.28.0.62]) by sj-inbound-f.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2010 03:35:36 +0000 Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob3SQ-000Fyn-Iq for v6ops-data0@psg.com; Tue, 20 Jul 2010 03:25:26 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob3SN-000FyR-MB for v6ops@ops.ietf.org; Tue, 20 Jul 2010 03:25:23 +0000 Received: by pvg12 with SMTP id 12so4330663pvg.11 for ; Mon, 19 Jul 2010 20:25:23 -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=Vfxpk3i0hAxXnYqh2BfP5ZKfTvn8tH1aqH0Apt8by4c=; b=HVvDcPxMDQfPlgSo+2CAku5AfTxwX64uoz5lYuIY4e/2/CA3jtHz7Pr9XSo7i4frmE vgUimSrD4lBWSeKeAnytwQ4GBm/uOwTUCLOuHjkoqk2ErVmmcqY61K/UoBO/Vl1qOICF N9/5HYs9nzQ8FkQVxsU/FyDhqkHHbW59ImuJQ= 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=Z/EEaJgQaYvIcshMFtCNleGc7i3mnzLlMKnBG8YCcmJPJh0VqU6kBfxo0iyKoNqOyl MujA9Iss1s2SjaX1CMA42sqv4JGP7CAphgg0IN8mywDdY8fCwTnsrkJ8Fb/GrgbhklX1 GzN0n92MMbMqhSRGv7Lcr83UQNGx1BC6bNXP8= Received: by 10.142.162.17 with SMTP id k17mr8252167wfe.324.1279596323087; Mon, 19 Jul 2010 20:25:23 -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 21sm7214826wfi.5.2010.07.19.20.25.20 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 20:25:21 -0700 (PDT) Message-ID: <4C45171D.8090506@gmail.com> Date: Tue, 20 Jul 2010 15:25:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations CC: Fred Baker Subject: Re: draft-nakibly-v6ops-tunnel-loops review References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> In-Reply-To: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: X-OriginalArrivalTime: 20 Jul 2010 03:35:38.0295 (UTC) FILETIME=[9EDF2470:01CB27BC] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-16 02:48, Fred Baker wrote: > Could I interest you in doing a thorough review of draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\ Summary ------- This draft proposes mitigation techniques for malicious loops formed using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms. The draft doesn't recommend a choice of technique. I think that for the work to go forward, the WG would need to agree on a recommendation. Otherwise, the world will shrug its shoulders. Details ------- Several IPv6 transition aids rely on automatic tunneling of IPv6 in IPv4. If an attacker succeeds in making two such methods link up with each other head-to-tail, a loop will form, and will consume all available resources. With manually configured tunnels, such a loop will be excluded by construction, but with automatic tunnels, an attacker can (under certain conditions) create a packet that a tunnel egress will feed back into regular IPv6 routing such that it ends up back in the tunnel again, until its hop limit expires. Section 2 describes the attack scenario. I find the terminology rather confusing: 1. For each tunnel, there is an object called "the tunnel router". I assume this is supposed to be the encapsulating ingress router. But it isn't stated clearly. 2. Tunnels have egress decapsulators. Their role is not described very clearly, but is assumed to be understood. 3. There's a reference to destination hosts being "in" the tunnel. ("The attack is ... initiated by sending an IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...") But hosts aren't in tunnels. They are outside the tunnel, beyond the egress router. [OK, some hosts do their own decapsulation, but then one can separate their decapsulator from their IPv6 stack, and anyway such hosts are not routers and will not forward packets back into the network.] So does this mean "destined to a fictitious end point that appears to be reached via T2"? There's a similar problem in the very first sentence of section 2: " In this section we shall denote an IPv6 address of a tunnel's node by the prefix of the tunnel and the IPv4 address of the node, i.e., Addr(Prefix, IPv4). " Does that mean " In this section we shall denote an IPv6 address of a node reached via a given tunnel by the prefix of the tunnel and the IPv4 address of the node, i.e., Addr(Prefix, IPv4). " ? 4. The description in section 2 then states that a packet to IPv6 address (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the tunnel egress, but that R1 erroneously treats it as if it came from tunnel T1. It isn't made very clear that this happens *because* the whole of the IPv4 Internet acts as a shared link layer as far as these automatic tunneling techniques are concerned. Therefore, R1 can only rely on the (dubious) addresses in the packet headers to figure out what to do next, and what it does is send the packet back to R2, because that's what the IPv6 prefix tells it to do. As far as I can see, the return packet from R1 to R2 could be sent by native IPv6 if such connectivity exists, but is more likely to be sent via tunnel T1, which is what R1 probably uses to provide global v6 access. The draft should make this point clear, anyway. Section 3 of the draft describes three possible mitigation strategies. 1. Checking the embedded IPv4 addresses explicitly in the tunnel end points. This is fairly straightforward and would fix the problem in most cases, but creates some overhead. Configuration would be needed to deal with 6rd and with RFC1918-based tunnels. 2. Checking that the end point exists, by various techniques. I am more pessimistic about these options than the author seems to be. 3. Use different protocol numbers for different tunnel types. This would be hard to deploy - in fact I think it's hopeless, since backwards compatibility with proto 41 would have to be kept. By the way, is it sufficient if either R1 or R2 makes the checks? Brian Carpenter From owner-v6ops@ops.ietf.org Wed Jul 21 08:48:56 2010 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 0E6213A692C for ; Wed, 21 Jul 2010 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOdo050dbkJY for ; Wed, 21 Jul 2010 08:48:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EF603A67F4 for ; Wed, 21 Jul 2010 08:48:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObbMn-0002Fo-GJ for v6ops-data0@psg.com; Wed, 21 Jul 2010 15:37:53 +0000 Received: from n67.bullet.mail.sp1.yahoo.com ([98.136.44.47]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObbMj-0002FB-Md for v6ops@ops.ietf.org; Wed, 21 Jul 2010 15:37:50 +0000 Received: from [216.252.122.217] by n67.bullet.mail.sp1.yahoo.com with NNFMP; 21 Jul 2010 15:37:49 -0000 Received: from [98.136.44.171] by t2.bullet.sp1.yahoo.com with NNFMP; 21 Jul 2010 15:37:49 -0000 Received: from [127.0.0.1] by omp612.mail.sp1.yahoo.com with NNFMP; 21 Jul 2010 15:37:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93891.71858.bm@omp612.mail.sp1.yahoo.com Received: (qmail 91872 invoked by uid 60001); 21 Jul 2010 15:37:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279726668; bh=73PkPXUAce3UW0AT9sjNpTQN9Tpx0R9rpUoGUXnt6ks=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XnKjsbrBoZy7mFDYtoRXU4/qYN2xngOBqqucY6f4kKfIGJvD7j54nwWjwiiFFMw80yvbL0ZjZ900qvFqaFMg4HY0gOLZwp7CT1/ejHHdFBkCMK26+Mei3LMf+27tzZMnSJ8aijTHRzKhAradQ7375Kg5SpYoRM+l1IVwe4PJzaM= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wVb51RBggOLfD0A4U044bZ6R0wjnr6BAyQz3gsnkVIDlYGWPouWLRKGpxeqBNREVoiyfCU5GRGXNNq9EMHdt8VVTPnPpTfCTZouyaWr9Ig+6KX4/DqnuwxJhzzlFTfZ3Q6vZeKf7OTHJMDnizIRWKkzArkhFsmOBUzBaRBpaakA=; Message-ID: <791846.90823.qm@web45514.mail.sp1.yahoo.com> X-YMail-OSG: raSLLhgVM1lHA.EK3nJ.o0mXIKbrL2Rr5vLe8V6910fa96C QQpoD1f42PpIvUnmOOqDsIQ913EPJhfsyrPfJ8kdBlvC5FVBZQPM7uxTPMd6 .pKJBJ5t7F3KrcfszhIT0PtS7qdAaN8aKkB4xPKOc2qCd1cb5AECl5ZyVwsV 61bNRbM4QtumbHWvHIwfq6G79EUElupaxP4UYLLcPeuCOVa3THG9SldBpnUJ F6whhaJYN3Jq9UOgoRH604jIw9k4b3zRltFcfwfAO.fqkYsPwBmkmGazYwsq UVItu7aaBqApXbfGGQg1E_kCw Received: from [93.172.143.202] by web45514.mail.sp1.yahoo.com via HTTP; Wed, 21 Jul 2010 08:37:48 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> <4C45171D.8090506@gmail.com> <4C46703C.5020506@gmail.com> Date: Wed, 21 Jul 2010 08:37:48 -0700 (PDT) From: Gabi Nakibly Subject: Re: draft-nakibly-v6ops-tunnel-loops review To: Brian E Carpenter , Fred Baker Cc: IPv6 Operations In-Reply-To: <4C46703C.5020506@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Brian,=0AThanks for the thorough review.=A0I agree that a summary of the pr= os and cons of =0Athe solutions is in order.=A0=A0Nonetheless, I believe th= at making a clear choice =0Aamong the solutions may be hard to do=A0since i= n=A0different situations=A0different =0Asolutions may preferable. =0A=0A=0A= Gabi=0A=0A=0A=0A----- Original Message ----=0A> From: Brian E Carpenter =0A> To: Fred Baker =0A> Cc: IPv6= Operations =0A> Sent: Wed, July 21, 2010 5:57:48 AM=0A= > Subject: Re: draft-nakibly-v6ops-tunnel-loops review=0A> =0A> Fred,=0A> = =0A> IMHO this is indeed sound work. As I said, even if it's to be informat= ional,=0A> I think there should be some sort of choice made among the solut= ions, or=0A> at least a summary of the pros and cons. So I think we need pr= ogress on=0A> that before a WGLC.=0A> =0A> =A0 =A0 Brian=0A> =0A> On 2010-0= 7-21 03:05, Fred Baker wrote:=0A> > Thanks much for the review. Looks like = it at least needs an update before =0A>being finalized.=0A> > =0A> > Questi= on for you. Would you consider an updated version of the document ready =0A= >for WGLC, or do we need further discussion on it? Apart from the beauty of= the =0A>prose, are the notions proposed sound?=0A> > =0A> > On Jul 19, 201= 0, at 8:25 PM, Brian E Carpenter wrote:=0A> > =0A> >> On 2010-07-16 02:48, = Fred Baker wrote:=0A> >>> Could I interest you in doing a thorough review o= f =0A>draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\=0A> >> Sum= mary=0A> >> -------=0A> >>=0A> >> This draft proposes mitigation techniques= for malicious loops formed=0A> >> using a mixture of automatic IPv6-in-IPv= 4 tunnel mechanisms.=0A> >>=0A> >> The draft doesn't recommend a choice of = technique. I think that for the=0A> >> work to go forward, the WG would nee= d to agree on a recommendation.=0A> >> Otherwise, the world will shrug its = shoulders.=0A> >>=0A> >> Details=0A> >> -------=0A> >>=0A> >> Several IPv6 = transition aids rely on automatic tunneling of IPv6 in=0A> >> IPv4. If an a= ttacker succeeds in making two such methods link up=0A> >> with each other = head-to-tail, a loop will form, and will consume all=0A> >> available resou= rces. With manually configured tunnels, such a loop=0A> >> will be excluded= by construction, but with automatic tunnels, an attacker=0A> >> can (under= certain conditions) create a packet that a tunnel egress=0A> >> will feed = back into regular IPv6 routing such that it ends up back=0A> >> in the tunn= el again, until its hop limit expires.=0A> >>=0A> >> Section 2 describes th= e attack scenario. I find the terminology=0A> >> rather confusing:=0A> >>= =0A> >> 1. For each tunnel, there is an object called "the tunnel router".= =0A> >> I assume this is supposed to be the encapsulating ingress router.= =0A> >> But it isn't stated clearly.=0A> >>=0A> >> 2. Tunnels have egress d= ecapsulators. Their role is not described=0A> >> very clearly, but is assum= ed to be understood.=0A> >>=0A> >> 3. There's a reference to destination ho= sts being "in" the tunnel.=0A> >> ("The attack is ... initiated by sending = an=0A> >>=A0 IPv6 packet (packet 0 in Figure 1) destined to an end point in= T2...")=0A> >>=0A> >> But hosts aren't in tunnels. They are outside the tu= nnel, beyond the=0A> >> egress router. [OK, some hosts do their own decapsu= lation, but then one=0A> >> can separate their decapsulator from their IPv6= stack, and anyway such=0A> >> hosts are not routers and will not forward p= ackets back into the network.]=0A> >>=0A> >> So does this mean=A0 "destined= to a fictitious end point that appears=0A> >> to be reached via T2"?=0A> >= >=0A> >> There's a similar problem in the very first sentence of section 2:= =0A> >>=0A> >> " In this section we shall denote an IPv6 address of a tunne= l's node by=0A> >>=A0 the prefix of the tunnel and the IPv4 address of the = node, i.e.,=0A> >>=A0 Addr(Prefix, IPv4). "=0A> >>=0A> >> Does that mean=0A= > >>=0A> >> " In this section we shall denote an IPv6 address of a node rea= ched via=0A> >>=A0 a given tunnel by the prefix of the tunnel and the IPv4 = address of the =0A>node, i.e.,=0A> >>=A0 Addr(Prefix, IPv4). " ?=0A> >>=0A>= >> 4. The description in section 2 then states that a packet to IPv6 addre= ss=0A> >> (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router = R1 as the=0A> >> tunnel egress, but that R1 erroneously treats it as if it = came from tunnel =0A>T1.=0A> >> It isn't made very clear that this happens = *because* the whole of the IPv4=0A> >> Internet acts as a shared link layer= as far as these automatic tunneling=0A> >> techniques are concerned. There= fore, R1 can only rely on the (dubious)=0A> >> addresses in the packet head= ers to figure out what to do next, and what it=0A> >> does is send the pack= et back to R2, because that's what the IPv6 prefix =0A>tells=0A> >> it to d= o.=0A> >>=0A> >> As far as I can see, the return packet from R1 to R2 could= be sent by=0A> >> native IPv6 if such connectivity exists, but is more lik= ely to be sent=0A> >> via tunnel T1, which is what R1 probably uses to prov= ide global v6 access.=0A> >> The draft should make this point clear, anyway= .=0A> >>=0A> >> Section 3 of the draft describes three possible mitigation = strategies.=0A> >>=0A> >> 1. Checking the embedded IPv4 addresses explicitl= y in the tunnel end =0Apoints.=0A> >> This is fairly straightforward and wo= uld fix the problem in most cases, but=0A> >> creates some overhead. Config= uration would be needed to deal with 6rd=0A> >> and with RFC1918-based tunn= els.=0A> >>=0A> >> 2. Checking that the end point exists, by various techni= ques. I am more=0A> >> pessimistic about these options than the author seem= s to be.=0A> >>=0A> >> 3. Use different protocol numbers for different tunn= el types. This would=0A> >> be hard to deploy - in fact I think it's hopele= ss, since backwards=0A> >> compatibility with proto 41 would have to be kep= t.=0A> >>=0A> >> By the way, is it sufficient if either R1 or R2 makes the = checks?=0A> >>=0A> >>=A0 Brian Carpenter=0A> > =0A> > http://www.ipinc.net/= IPv4.GIF=0A> > =0A> > =0A> =0A> =0A=0A=0A From owner-v6ops@ops.ietf.org Wed Jul 21 13:34:42 2010 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 79E593A6821 for ; Wed, 21 Jul 2010 13:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=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 nRr1rgChEjUG for ; Wed, 21 Jul 2010 13:32:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 603D93A6B78 for ; Wed, 21 Jul 2010 13:30:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObfnV-000J2o-Qr for v6ops-data0@psg.com; Wed, 21 Jul 2010 20:21:45 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObfnS-000J2V-20 for v6ops@ops.ietf.org; Wed, 21 Jul 2010 20:21:42 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6LKLcCJ017094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jul 2010 15:21:39 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6LKLcNr019841; Wed, 21 Jul 2010 13:21:38 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6LKLbCa019819 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 21 Jul 2010 13:21:37 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 21 Jul 2010 13:21:37 -0700 From: "Templin, Fred L" To: Gabi Nakibly , Brian E Carpenter , Fred Baker CC: IPv6 Operations Date: Wed, 21 Jul 2010 13:21:36 -0700 Subject: RE: draft-nakibly-v6ops-tunnel-loops review Thread-Topic: draft-nakibly-v6ops-tunnel-loops review Thread-Index: Acso7ijG36rB/5RASmOm6gDExfr+gAAI5fFA Message-ID: References: <1975C274-CE6B-4A20-B6EE-87CE995CA8E6@cisco.com> <4C45171D.8090506@gmail.com> <4C46703C.5020506@gmail.com> <791846.90823.qm@web45514.mail.sp1.yahoo.com> In-Reply-To: <791846.90823.qm@web45514.mail.sp1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behal= f Of Gabi Nakibly > Sent: Wednesday, July 21, 2010 8:38 AM > To: Brian E Carpenter; Fred Baker > Cc: IPv6 Operations > Subject: Re: draft-nakibly-v6ops-tunnel-loops review >=20 > Brian, > Thanks for the thorough review.=A0I agree that a summary of the pros and = cons of > the solutions is in order.=A0=A0Nonetheless, I believe that making a clea= r choice > among the solutions may be hard to do=A0since in=A0different situations= =A0different > solutions may preferable. I believe the situation for ISATAP router can be handled best by the Section 3.2.3 Neighbor Reachability Check. I believe it should be the recommended solution for ISATAP, and we should just come right out and say this. Fred fred.l.templin@boeing.com > Gabi >=20 >=20 >=20 > ----- Original Message ---- > > From: Brian E Carpenter > > To: Fred Baker > > Cc: IPv6 Operations > > Sent: Wed, July 21, 2010 5:57:48 AM > > Subject: Re: draft-nakibly-v6ops-tunnel-loops review > > > > Fred, > > > > IMHO this is indeed sound work. As I said, even if it's to be informati= onal, > > I think there should be some sort of choice made among the solutions, o= r > > at least a summary of the pros and cons. So I think we need progress on > > that before a WGLC. > > > > =A0 =A0 Brian > > > > On 2010-07-21 03:05, Fred Baker wrote: > > > Thanks much for the review. Looks like it at least needs an update be= fore > >being finalized. > > > > > > Question for you. Would you consider an updated version of the docume= nt ready > >for WGLC, or do we need further discussion on it? Apart from the beauty = of the > >prose, are the notions proposed sound? > > > > > > On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote: > > > > > >> On 2010-07-16 02:48, Fred Baker wrote: > > >>> Could I interest you in doing a thorough review of > >draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\ > > >> Summary > > >> ------- > > >> > > >> This draft proposes mitigation techniques for malicious loops formed > > >> using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms. > > >> > > >> The draft doesn't recommend a choice of technique. I think that for = the > > >> work to go forward, the WG would need to agree on a recommendation. > > >> Otherwise, the world will shrug its shoulders. > > >> > > >> Details > > >> ------- > > >> > > >> Several IPv6 transition aids rely on automatic tunneling of IPv6 in > > >> IPv4. If an attacker succeeds in making two such methods link up > > >> with each other head-to-tail, a loop will form, and will consume all > > >> available resources. With manually configured tunnels, such a loop > > >> will be excluded by construction, but with automatic tunnels, an att= acker > > >> can (under certain conditions) create a packet that a tunnel egress > > >> will feed back into regular IPv6 routing such that it ends up back > > >> in the tunnel again, until its hop limit expires. > > >> > > >> Section 2 describes the attack scenario. I find the terminology > > >> rather confusing: > > >> > > >> 1. For each tunnel, there is an object called "the tunnel router". > > >> I assume this is supposed to be the encapsulating ingress router. > > >> But it isn't stated clearly. > > >> > > >> 2. Tunnels have egress decapsulators. Their role is not described > > >> very clearly, but is assumed to be understood. > > >> > > >> 3. There's a reference to destination hosts being "in" the tunnel. > > >> ("The attack is ... initiated by sending an > > >>=A0 IPv6 packet (packet 0 in Figure 1) destined to an end point in T2= ...") > > >> > > >> But hosts aren't in tunnels. They are outside the tunnel, beyond the > > >> egress router. [OK, some hosts do their own decapsulation, but then = one > > >> can separate their decapsulator from their IPv6 stack, and anyway su= ch > > >> hosts are not routers and will not forward packets back into the net= work.] > > >> > > >> So does this mean=A0 "destined to a fictitious end point that appear= s > > >> to be reached via T2"? > > >> > > >> There's a similar problem in the very first sentence of section 2: > > >> > > >> " In this section we shall denote an IPv6 address of a tunnel's node= by > > >>=A0 the prefix of the tunnel and the IPv4 address of the node, i.e., > > >>=A0 Addr(Prefix, IPv4). " > > >> > > >> Does that mean > > >> > > >> " In this section we shall denote an IPv6 address of a node reached = via > > >>=A0 a given tunnel by the prefix of the tunnel and the IPv4 address o= f the > >node, i.e., > > >>=A0 Addr(Prefix, IPv4). " ? > > >> > > >> 4. The description in section 2 then states that a packet to IPv6 ad= dress > > >> (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 = as the > > >> tunnel egress, but that R1 erroneously treats it as if it came from = tunnel > >T1. > > >> It isn't made very clear that this happens *because* the whole of th= e IPv4 > > >> Internet acts as a shared link layer as far as these automatic tunne= ling > > >> techniques are concerned. Therefore, R1 can only rely on the (dubiou= s) > > >> addresses in the packet headers to figure out what to do next, and w= hat it > > >> does is send the packet back to R2, because that's what the IPv6 pre= fix > >tells > > >> it to do. > > >> > > >> As far as I can see, the return packet from R1 to R2 could be sent b= y > > >> native IPv6 if such connectivity exists, but is more likely to be se= nt > > >> via tunnel T1, which is what R1 probably uses to provide global v6 a= ccess. > > >> The draft should make this point clear, anyway. > > >> > > >> Section 3 of the draft describes three possible mitigation strategie= s. > > >> > > >> 1. Checking the embedded IPv4 addresses explicitly in the tunnel end > points. > > >> This is fairly straightforward and would fix the problem in most cas= es, but > > >> creates some overhead. Configuration would be needed to deal with 6r= d > > >> and with RFC1918-based tunnels. > > >> > > >> 2. Checking that the end point exists, by various techniques. I am m= ore > > >> pessimistic about these options than the author seems to be. > > >> > > >> 3. Use different protocol numbers for different tunnel types. This w= ould > > >> be hard to deploy - in fact I think it's hopeless, since backwards > > >> compatibility with proto 41 would have to be kept. > > >> > > >> By the way, is it sufficient if either R1 or R2 makes the checks? > > >> > > >>=A0 Brian Carpenter > > > > > > http://www.ipinc.net/IPv4.GIF > > > > > > > > > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 21 14:18:15 2010 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 284513A6BBE for ; Wed, 21 Jul 2010 14:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.694, 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 HhjFjLiwOSq9 for ; Wed, 21 Jul 2010 14:18:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3659D3A6BB8 for ; Wed, 21 Jul 2010 14:18:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obgav-000PFs-Sd for v6ops-data0@psg.com; Wed, 21 Jul 2010 21:12:50 +0000 Received: from [76.96.30.40] (helo=qmta04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obgat-000PFa-Q0 for v6ops@ops.ietf.org; Wed, 21 Jul 2010 21:12:47 +0000 Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta04.emeryville.ca.mail.comcast.net with comcast id kjXT1e0041bwxycA4lClYY; Wed, 21 Jul 2010 21:12:45 +0000 Received: from [10.21.70.107] ([128.107.239.233]) by omta18.emeryville.ca.mail.comcast.net with comcast id klCU1e00B52qHCY8elCZ6D; Wed, 21 Jul 2010 21:12:43 +0000 Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> Date: Wed, 21 Jul 2010 23:12:27 +0200 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <80841A74-46DB-41CB-800B-D9D9634D884F@tony.li> References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> To: Leo Vegoda X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Leo, > Firstly, in section 4, I think it would be useful to note that RIRs = should aim to aggregate an ISPs second and later allocation with earlier = allocations. I believe this is already done but it would be good to = recommend it. I'd like to suggest the second sentence below be added. >=20 > "RIRs initial and subsequent allocation policy to service providers = should allow for a minimum of 2 years worth of usage based on historical = or business plan projections. Further, RIRs should implement practices = that maximise the potential for subsequent allocations to be made = contiguous with previous allocations." >=20 > Also, in section 10 it is recommended that "Internet Registries should = severely limit or eliminate [...] PI assignments". There are obviously = reasons for the current policies allowing IPv6 PI assignments but the = potential for significant routing table growth has not been removed, so = I wonder whether it would make sense to request the RIR communities to = review the impact of PI assignment policies on the rate of routing table = growth on a regular basis.=20 The authors concur and unless there is some dissent from the list, we'll = amend accordingly. Tony From owner-v6ops@ops.ietf.org Wed Jul 21 16:14:38 2010 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 76B673A68A4 for ; Wed, 21 Jul 2010 16:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE17SNk2QnKP for ; Wed, 21 Jul 2010 16:14:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37D2B3A693A for ; Wed, 21 Jul 2010 16:14:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObiN5-000Dga-5p for v6ops-data0@psg.com; Wed, 21 Jul 2010 23:06:39 +0000 Received: from [2001:1bb8:2004:150::2] (helo=mail.acquirer.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObiN2-000Dg2-9S for v6ops@ops.ietf.org; Wed, 21 Jul 2010 23:06:36 +0000 X-Envelope-To: v6ops@ops.ietf.org Received: from [10.230.100.60] (woozles.foobar.org [10.230.100.60]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id o6LN3PvF044649 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Jul 2010 00:03:31 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4C477CC7.3040604@inex.ie> Date: Thu, 22 Jul 2010 00:03:35 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Leo Vegoda CC: IPv6 Operations Subject: Re: draft-azinger-cidrv6-00 References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> In-Reply-To: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> 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 20/07/2010 23:13, Leo Vegoda wrote: > Also, in section 10 it is recommended that "Internet Registries > should severely limit or eliminate [...] PI assignments". RIRs carry out the policies set by their constituents, and cannot arbitrarily limit assignments unless there is scope within their policies to do so In addition, until such time as there is a viable alternative for end-user multi-homing in ipv6, I'm not sure if making a recommendation like section 10 is actually going to achieve anything - other than raising eyebrows. Section 5.2: Projections. Um, I don't believe that a projection for 2040 adds anything here. As the authors note, an S curve seems more likely at this stage, so adding an arbitrary number which is a similar order of magnitude to the population of the earth doesn't really lend credibility to the table :-) Section 5.1: Analysis. > Thus, the bulk of the routing table growth appears to be due to PI > prefix injection. No doubt it is. Provider level aggregation will ensure that the N provider associated prefixes that most providers have been allocated today will be be reduced to 1. Would it be useful to adopt a potential modeling premise that posits that most PI ipv4 holders today will take out an ipv6 block in the future, and see where that leads? Section 5: it may be useful to flesh out traffic engineering issues here. This has the potential to increase prefix numbers from 1 back to N, and my gut feeling is that this is going be the #2 prefix source after PI. Nick From owner-v6ops@ops.ietf.org Wed Jul 21 22:41:50 2010 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 2819A3A6862 for ; Wed, 21 Jul 2010 22:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 8XqflHOSA-+X for ; Wed, 21 Jul 2010 22:41:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22CFD3A6881 for ; Wed, 21 Jul 2010 22:41:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OboKb-0006bw-Ek for v6ops-data0@psg.com; Thu, 22 Jul 2010 05:28:29 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OboKY-0006Zi-Uc for v6ops@ops.ietf.org; Thu, 22 Jul 2010 05:28:27 +0000 Received: by iwn8 with SMTP id 8so8408514iwn.11 for ; Wed, 21 Jul 2010 22:28:26 -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=aJJtiJDydh4Q+aqLjqVxiDU7dbBTl+rOB3FtKnUJsg8=; b=Dd5q+BzwX4lOAC1waV38scsXjTiKRB4kCaeeuNYrrQCHB4M0eYkyUitTCd+daW4uhz oHgI0WD/42Q+YBb19KhKVrlk+geTABAHcRd19LR4ntVlbZKJD0GV+10DCqKpWt4PyLjb X+U2lvu+OM1OwC0LjmQDkUFjDEY/9Ti3TfUxw= 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=toFIPWgAaLjkKBn5siJPWpwZvPnbUzmu9FGOYM3HK6OuFtg0B0XZvqf14/EpElNjXc G42MM1IRMadMVchWXWnIV/ITes+znLDi4OvH+MYd55gz3242E9fkkdw1o5Fje8+JKK6R erf81TmZGxLp2jOatDuyUxFW1M808RIxuzogg= Received: by 10.231.30.130 with SMTP id u2mr1192040ibc.111.1279776506296; Wed, 21 Jul 2010 22:28:26 -0700 (PDT) Received: from [10.1.1.3] ([121.98.142.15]) by mx.google.com with ESMTPS id e8sm29532766ibb.2.2010.07.21.22.28.22 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 22:28:25 -0700 (PDT) Message-ID: <4C47D6F3.1080900@gmail.com> Date: Thu, 22 Jul 2010 17:28:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard CC: Leo Vegoda , IPv6 Operations Subject: Re: draft-azinger-cidrv6-00 References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> In-Reply-To: <4C477CC7.3040604@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 2010-07-22 11:03, Nick Hilliard wrote: > In addition, until such time as there is a viable alternative for > end-user multi-homing in ipv6, I'm not sure if making a recommendation > like section 10 is actually going to achieve anything - other than > raising eyebrows. Other eyebrows are already raised by the prospect of ten million BGP4 routes. It's really odd that the RIR constituencies aren't more worried about that. Brian From owner-v6ops@ops.ietf.org Thu Jul 22 01:20:15 2010 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 872353A69DD for ; Thu, 22 Jul 2010 01:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.660, 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 s8SjBUs3yJlx for ; Thu, 22 Jul 2010 01:20:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07B503A69D1 for ; Thu, 22 Jul 2010 01:20:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obqqv-0001FF-4w for v6ops-data0@psg.com; Thu, 22 Jul 2010 08:10:01 +0000 Received: from [76.96.27.228] (helo=qmta15.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obqqs-0001Ef-Ok for v6ops@ops.ietf.org; Thu, 22 Jul 2010 08:09:58 +0000 Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id kw9W1e0021GXsucAFw9wB5; Thu, 22 Jul 2010 08:09:56 +0000 Received: from sjc-vpn7-614.cisco.com ([128.107.239.233]) by omta07.emeryville.ca.mail.comcast.net with comcast id kw9h1e00152qHCY8Uw9kkd; Thu, 22 Jul 2010 08:09:54 +0000 Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4C477CC7.3040604@inex.ie> Date: Thu, 22 Jul 2010 10:09:40 +0200 Cc: Leo Vegoda , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Nick, >> Also, in section 10 it is recommended that "Internet Registries >> should severely limit or eliminate [...] PI assignments". >=20 > RIRs carry out the policies set by their constituents, and cannot = arbitrarily limit assignments unless there is scope within their = policies to do so The whole point is to give the RIRs the technical requirements so that = they can set effective policies. > In addition, until such time as there is a viable alternative for = end-user multi-homing in ipv6, I'm not sure if making a recommendation = like section 10 is actually going to achieve anything - other than = raising eyebrows. As you may know, there are several proposals being discussed. Our point = is to raise the issue with RIRs and ensure that they understand that = this technology is becoming available. > Section 5.2: Projections. >=20 > Um, I don't believe that a projection for 2040 adds anything here. As = the authors note, an S curve seems more likely at this stage, so adding = an arbitrary number which is a similar order of magnitude to the = population of the earth doesn't really lend credibility to the table :-) Again, we are not claiming that this will be the growth rate. We are = simply pointing out the mathematical implications of a sustained 54% = rate. The number is not arbitrary in the least, it simply shows the = implications of where we might be in 30 years. > Section 5.1: Analysis. >=20 >> Thus, the bulk of the routing table growth appears to be due to PI >> prefix injection. >=20 > No doubt it is. Provider level aggregation will ensure that the N = provider associated prefixes that most providers have been allocated = today will be be reduced to 1. Would it be useful to adopt a potential = modeling premise that posits that most PI ipv4 holders today will take = out an ipv6 block in the future, and see where that leads? Obviously, that leads us to a baseline of 350K routes. If done quickly, = that would accelerate the growth rate. > Section 5: it may be useful to flesh out traffic engineering issues = here. This has the potential to increase prefix numbers from 1 back to = N, and my gut feeling is that this is going be the #2 prefix source = after PI. I concur that it will be a contributor. TE is already discussed in the = problem statement (draft-narten-radir-problem-statement-05). Tony From owner-v6ops@ops.ietf.org Thu Jul 22 01:26:18 2010 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 46EF23A681F for ; Thu, 22 Jul 2010 01:26:18 -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 SA-OoMOAlkwY for ; Thu, 22 Jul 2010 01:26:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFF1A3A677C for ; Thu, 22 Jul 2010 01:26:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obr28-0002rf-SB for v6ops-data0@psg.com; Thu, 22 Jul 2010 08:21:36 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obr25-0002qx-W3 for v6ops@ops.ietf.org; Thu, 22 Jul 2010 08:21:34 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIacR0xAZnwM/2dsb2JhbACfdnGlXpsbhTYEiFk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2010 08:21:03 +0000 Received: from Freds-Computer.local (rtp-vpn1-1060.cisco.com [10.82.228.36]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6M8KtT4015213; Thu, 22 Jul 2010 08:20:57 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 22 Jul 2010 04:21:03 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 22 Jul 2010 04:21:03 -0400 Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <4C47D6F3.1080900@gmail.com> Date: Thu, 22 Jul 2010 04:20:48 -0400 Cc: Nick Hilliard , Leo Vegoda , IPv6 Operations Message-Id: <0D33CF81-5DC0-4E4D-B8D5-61278008B4CB@cisco.com> References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> <4C47D6F3.1080900@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 22, 2010, at 1:28 AM, Brian E Carpenter wrote: > On 2010-07-22 11:03, Nick Hilliard wrote: >> In addition, until such time as there is a viable alternative for = end-user multi-homing in ipv6, I'm not sure if making a recommendation = like section 10 is actually going to achieve anything - other than = raising eyebrows. >=20 > Other eyebrows are already raised by the prospect of ten million BGP4 = routes. It's really odd that the RIR constituencies aren't more worried = about that. Well, there are mitigations. They know how to aggregate routes, they now = have routers with actual memory in them, links and processing are fast = enough that they don't see delays in convergence induced from that = source (convergence delays continue to happen, but other reasons are = more dominant). I think your average ISP tends to think that his vendors will solve = that. Speaking from the perspective of one of the obvious vendors, I'm = certainly willing to sell them memory as well; that's "just capex", = expensive and something they love to hate, but a one-time purchase. And, = by the way, not a primary driver of the cost of equipment - there are = other things much more expensive than memory. What is driving the RIR discussions is the desire of edge networks to be = independent of their providers, not captive to them. They don't want to = have to adjust (renumber, reroute) their networks when they change = providers. The fundamental failing of shim6 (and for that matter, of = lisp) is that it moves a lot of complexity from the transit networks, = who know how to manage it, to the edge networks, who don't. Yes, it = minimizes the number of routes in the transit domains by making them = provider-allocated; it maximizes the routing for the edge network, = because there are multiple instances of an almost-identical route for = each subnet in the edge domain. The edge networks see a provider tie and = more-complex routing as net negatives. That is what is driving the discussion of ILNP etc. GSE enables the = transit domains to have the relative simplicity of a PA network while = giving the edge networks the relative simplicity of a PI prefix, and all = the while enabling any system in the network to reliably address any = other system in the network (unlike IPv4/IPv4 NAT) using a stateless = (and therefore load-sharable and stable) prefix translation. There are = some applications one doesn't run across prefix translation boundaries = (anything that carries and cares about the prefix) and some things = sensible people do in applications (SIP and HTTP refers use names, not = addresses, for example); if you obey the rules, it works, and if you = don't, you created your problem and you know how to solve it.= From owner-v6ops@ops.ietf.org Thu Jul 22 01:30:34 2010 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 8972F3A6A17 for ; Thu, 22 Jul 2010 01:30:24 -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 2k9iKfKR-QP8 for ; Thu, 22 Jul 2010 01:29:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 899873A69F8 for ; Thu, 22 Jul 2010 01:29:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obr7u-0003bu-BZ for v6ops-data0@psg.com; Thu, 22 Jul 2010 08:27:34 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obr7s-0003bU-5C for v6ops@ops.ietf.org; Thu, 22 Jul 2010 08:27:32 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPKdR0xAZnwN/2dsb2JhbACfdnGlXJsbhTYEiFk Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 08:27:30 +0000 Received: from Freds-Computer.local (rtp-vpn1-1060.cisco.com [10.82.228.36]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6M8RMjS012233; Thu, 22 Jul 2010 08:27:25 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 22 Jul 2010 04:27:30 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 22 Jul 2010 04:27:30 -0400 Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: Date: Thu, 22 Jul 2010 04:27:16 -0400 Cc: Nick Hilliard , Leo Vegoda , IPv6 Operations Message-Id: <81DB556B-B767-43DE-961B-4069F899BAB5@cisco.com> References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> To: Tony Li X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 22, 2010, at 4:09 AM, Tony Li wrote: > Again, we are not claiming that this will be the growth rate. We are = simply pointing out the mathematical implications of a sustained 54% = rate. The number is not arbitrary in the least, it simply shows the = implications of where we might be in 30 years. Personally and speaking for myself, I don't see why the 54% growth rate = would be sustained. Basically, you have a lot of folks that don't have = an IPv6 prefix but that have an IPv4 prefix mirroring their IPv4 = connectivity. I would expect IPv6 prefix growth to be similar to IPv4 = prefix growth in the long haul, not to vastly outweigh it.= From owner-v6ops@ops.ietf.org Thu Jul 22 01:32:34 2010 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 49CFB3A69E0 for ; Thu, 22 Jul 2010 01:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9FigS9koMFf for ; Thu, 22 Jul 2010 01:32:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E46F3A69EB for ; Thu, 22 Jul 2010 01:30:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obr8H-0003fE-1O for v6ops-data0@psg.com; Thu, 22 Jul 2010 08:27:57 +0000 Received: from [2001:608:2:81::2] (helo=mobil.space.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obr8E-0003ey-VV for v6ops@ops.ietf.org; Thu, 22 Jul 2010 08:27:55 +0000 Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id CEFCBF81DE for ; Thu, 22 Jul 2010 10:27:53 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id AD15CF81A8 for ; Thu, 22 Jul 2010 10:27:53 +0200 (CEST) Received: (qmail 77606 invoked by uid 1007); 22 Jul 2010 10:27:53 +0200 Date: Thu, 22 Jul 2010 10:27:53 +0200 From: Gert Doering To: Lindqvist Kurt Erik Cc: Seiichi Kawamura , IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt Message-ID: <20100722082753.GS73473@Space.Net> References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, On Wed, Jul 21, 2010 at 08:28:22AM +0200, Lindqvist Kurt Erik wrote: > > Bringing an ISP to be fully dual stacked will take years. > > So I suggest that minumum is > > - PA Block > - Customer Assignments > - DNS resolvers IPv6 capable > - Native (v6 only or dual-stack) upstream connection > - SMTP relay / Submission IPv6 Seconded. These are the most crucial blocks for an ISP to enable useful IPv6 connectivity for his customers. > - IMAP/POP IPv6 I'm not sure about this - yes, if the ISP offers hosted mail services for the customer, but this is already going into the "individual products" section. A pure transit ISP might not need that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 Jul 22 05:48:13 2010 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 334373A6971 for ; Thu, 22 Jul 2010 05:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_LOW=-1, 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 Kwb-1HqLHI08 for ; Thu, 22 Jul 2010 05:48:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1DB153A688E for ; Thu, 22 Jul 2010 05:48:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obv04-000EIc-CL for v6ops-data0@psg.com; Thu, 22 Jul 2010 12:35:44 +0000 Received: from [62.225.183.131] (helo=tcmail83.telekom.de) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obv01-000EHs-1c for v6ops@ops.ietf.org; Thu, 22 Jul 2010 12:35:41 +0000 Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 22 Jul 2010 14:35:36 +0200 Received: from S4DE9JSAACY.ost.t-com.de ([10.125.177.233]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 14:35:34 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Jul 2010 14:35:33 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt Thread-Index: AcsmFFxNk6Ntts6ipk+C17/0b0cd/gDhPx/Q References: <4B79A004.40506@venaas.com> From: To: , Cc: X-OriginalArrivalTime: 22 Jul 2010 12:35:34.0676 (UTC) FILETIME=[61721540:01CB299A] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Sri, had a read of your I-D right now and think that it is a very interesting = and useful work. I see also some applicability in the BBF context for = handling of RAs in a N:1 VLAN scenario for instance. Unfortunately I don't recall the status of the I-D after the last IETF, = is it on the road to become a WG item? I would vote for that. Kind regards Olaf=20 > -----Urspr=FCngliche Nachricht----- > Von: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] Im Auftrag von Sri Gundavelli > Gesendet: Sonntag, 18. Juli 2010 02:59 > An: IPv6 Operations > Cc: Stig Venaas > Betreff: Re: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt=20 >=20 > Thanks to Stig for his review of the draft. Will reword the=20 > below text, > should be in -01 version. >=20 > Sri >=20 >=20 >=20 >=20 > ------ Forwarded Message > From: Stig Venaas > Date: Mon, 15 Feb 2010 13:03:29 -0800 > To: Sri Gundavelli > Subject: Re: L2 Unicast of multicast messages - ID >=20 > >> I think the document is fine. I've followed some of the previous > >> discussion on this topic. Just one comment. > >> > >> In section 3 it says: > >> > >> address in the link-layer header will be an unicast=20 > address. It > >> is up to to the system architecture as when to=20 > transmit a IPv6 > >> multicast message as an link-layer unicast message,=20 > as long as > >> there is no real impact to the multicast communication. > >> > >> This sentence is pretty vague. Especially "no real=20 > impact", not sure > >> what that means. And what do you mean by "multicast communication". > >> > >> Also, the reason you may want the system architecture to transmit > >> unicast, is that it has a positive impact on the=20 > communication, right? > >> If whether you use unicast or not has no impact, then this would be > >> pointless ;) > >> > >=20 > > :) My point is that, if the usage of the semantic is used=20 > in the right away, > > there should be any impact to the multicast communication.=20 > If I'm hosting > > two IPv6 VLAN's on the same 802.11 link, if the AP ensures=20 > the RA's are > > segregated and sent to the right groups, its to me no=20 > impact to multicast > > communication. But, I see your point, this needs to worded=20 > correctly. I > > will fix this in -01 version, posted it a hour back. >=20 > Sorry I was a bit late. I think the draft is good. Just trying to be a > bit difficult here :) But I think it can be made clearer. >=20 > Stig >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jul 22 06:52:21 2010 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 C8D5F3A6B3F for ; Thu, 22 Jul 2010 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEtGtQmtb8-8 for ; Thu, 22 Jul 2010 06:52:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC3B13A6B4E for ; Thu, 22 Jul 2010 06:52:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obw3K-000PVX-Fv for v6ops-data0@psg.com; Thu, 22 Jul 2010 13:43:10 +0000 Received: from [2001:1bb8:2004:150::2] (helo=mail.acquirer.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obw3H-000PU3-Jv for v6ops@ops.ietf.org; Thu, 22 Jul 2010 13:43:08 +0000 X-Envelope-To: v6ops@ops.ietf.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id o6MDh2uf079853 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Jul 2010 14:43:03 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4C484AE6.9020400@inex.ie> Date: Thu, 22 Jul 2010 14:43:02 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100719 Shredder/3.2a1pre MIME-Version: 1.0 To: Tony Li CC: IPv6 Operations Subject: Re: draft-azinger-cidrv6-00 References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> In-Reply-To: X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 22/07/2010 09:09, Tony Li wrote: > The whole point is to give the RIRs the technical requirements so that > they can set effective policies. This is a sensible approach, although Fred really hit the nail on the head in his previous email ("What is driving the RIR discussions..."). > Again, we are not claiming that this will be the growth rate. We are > simply pointing out the mathematical implications of a sustained 54% > rate. The number is not arbitrary in the least, it simply shows the > implications of where we might be in 30 years. I meant arbitrary cut-off point rather than arbitrary number, but look, this is a bike-shed issue. The point I was trying to make was that having a malthusian growth table doesn't really add anything to the I-D, which brings us back to your point above. If the RIRs need to be given technical ammo to help them formulate aggregation and dfz prefix-count limitation policies, then the more realistic the models provided, the more likely people will be to pay attention to them. A demonstration of unconstrained exponential growth is not useful from this point of view. Nick From owner-v6ops@ops.ietf.org Thu Jul 22 08:42:43 2010 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 86EC13A6814 for ; Thu, 22 Jul 2010 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.086 X-Spam-Level: X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_44=1, J_BACKHAIR_46=1, 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 f-PvSIlqfzim for ; Thu, 22 Jul 2010 08:42:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C40A3A67B3 for ; Thu, 22 Jul 2010 08:42:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obxm7-000JqU-32 for v6ops-data0@psg.com; Thu, 22 Jul 2010 15:33:31 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obxm3-000Jpk-Sn for v6ops@ops.ietf.org; Thu, 22 Jul 2010 15:33:28 +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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6MFXOCb010101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Jul 2010 08:33:25 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6MFXOgL015457 for ; Thu, 22 Jul 2010 08:33:24 -0700 (PDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6MFXOYq015429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 22 Jul 2010 08:33:24 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Thu, 22 Jul 2010 08:33:23 -0700 From: "Templin, Fred L" To: IPv6 Operations Date: Thu, 22 Jul 2010 08:33:21 -0700 Subject: Review of 'draft-ietf-v6ops-tunnel-security-concerns-02' Thread-Topic: Review of 'draft-ietf-v6ops-tunnel-security-concerns-02' Thread-Index: AcsprIZO4Pi5Eh+MTD6r2KIAnuIEHwABiohA Message-ID: References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> <4C484AE6.9020400@inex.ie> In-Reply-To: <4C484AE6.9020400@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, Please see below for my review of this document. Fred B. suggested posting this directly to the list. Thanks - Fred fred.l.templin@boeing.com Review of 'draft-ietf-v6ops-tunnel-security-concerns-02' ******************************************************** 1) Section 2.1.1, on first use of the terms the document should say more about what is meant by "defense in depth" and "security gaps". Is it about ingress filtering? Is it about something else? 2) Section 2.2.2, please cite RFC2827 and RFC3704 upon first mention of ingress filtering. Also check that the terms ingress and egress are being used in the correct way. For example, RFC2827 refers to ingress filtering as checking the outgoing source address, which seems to be the opposite of what is being represented in this document. 3) Section 2.2.2, sentence structure at end of first sentence. Suggest changing to: "... are done to mitigate attacks and to make it easier to identify the source of a packet; they are also considered to be a good practice." 4) Throughout the document, it seems that there is an assumption that only host<->host and host<->router tunneling is considered, i.e., it does not seem to consider router<->router tunneling. In particular, the use of the term "tunnel client" seems to always be associated with a host and not another router. Is router<->router tunneling considered as out-of-scope for this document? The document should state the scope up front. 5) Section 3.1.2, first sentence of final paragraph, change to "The other approach is to find tunneled packets to block in the same way as would be done for inspecting native packets (Section 3.2)." 6) Section 3.1.2, final sentence of final paragraph, change to "However, this faces the same difficulties..." 7) Section 3.2.2, first sentence of third paragraph, change to "The implication of this latter case is that ..." 8) Section 3.2.3, first sentence, change to "As illustrated above, it should be clear that inspecting the contents of tunneled data packets that are not easily identified (e.g., those without a well-known UDP or TCP port) is highly complex ..." 9) Section 4.1.2, paragraph beginning "(By the virtue of the tunnel ... based on the outer IP.)". It seems odd to see a new paragraph beginning with a parenthetical sentence. Also, the paragraph itself seems to have excessive parentheticals. 10) Section 4.2.2, item 1. This concern is true not only for tunnels but also for any service that keeps a NAT port open indefinitely, for example through static administrative configuration. NAT pin-holing concerns are therefore a more broad-reaching subject and not specific to tunnels.=20 11) Section 4.2.2, item 2, final sentence, this concern is specific to the native routing and addressing of the inner network layer protocol, so the use or non-use of tunneling to reach the inner network layer destination is irrelevant. Suggest removing this sentence. =20 12) Section 4.2.2, item 3, change first sentence to "The tunnel protocol may contain more messages..." since the use of tunneling does not always result in more messages and longer path lengths. 13) Sections 4.1.3, 4.2.3 and 4.3.3, the recommendations seem too broad. Minimization of some types of tunnels may be appropriate, while use of other tunnel types may be beneficial and not subject to these broader concerns. 14) Section 6.1, this section seems to assume reliance on the DNS and bases some of the vulnerabilities on the possibility for DNS spoofing. However, if the tunnel client has a way to determine tunnel server addresses via some secure means that does not involve the DNS then some aspects of these vulnerabilities are mitigated. Perhaps this can be captured in Section 6.1.3 in some way. 15) Section 7, final sentence before bulleted list, change to "Several measures can be taken in order to secure the operation of IPv6 tunnels, including:" From owner-v6ops@ops.ietf.org Thu Jul 22 11:12:41 2010 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 322CD3A67AF for ; Thu, 22 Jul 2010 11:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 kHQpCd9MrKHd for ; Thu, 22 Jul 2010 11:12:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7AD93A6872 for ; Thu, 22 Jul 2010 11:12:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oc04V-000HXs-0V for v6ops-data0@psg.com; Thu, 22 Jul 2010 18:00:39 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oc04S-000HXQ-Pm for v6ops@ops.ietf.org; Thu, 22 Jul 2010 18:00:36 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 7A995D4EDFC; Thu, 22 Jul 2010 11:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TGs6Hkn2opz; Thu, 22 Jul 2010 11:00:32 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 9B030D4EDED; Thu, 22 Jul 2010 11:00:32 -0700 (PDT) Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4C47D6F3.1080900@gmail.com> Date: Thu, 22 Jul 2010 11:00:31 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <30F802D2-87C8-4A8C-A4CE-85DD3918008D@virtualized.org> References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> <4C47D6F3.1080900@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 21, 2010, at 10:28 PM, Brian E Carpenter wrote: > Other eyebrows are already raised by the prospect of ten million > BGP4 routes. It's really odd that the RIR constituencies aren't more > worried about that. It is the RIR constituencies that are creating and approving the = policies that are encouraging that prospect. Relying on the RIRs to = protect the routing system is ... questionable since the RIR's role is = (should be?) limited to the allocation and recording of registration = information about those allocations. Efforts by the RIRs to implement = policies that limit de-aggregation or deny provider independent space to = leaf networks has generally (and not surprisingly) resulted in those = polices being rejected by the RIR communities. =20 With the likely proliferation of multi-homing in the future (since = people will be becoming more and more dependent on the Internet always = being available) not to mention the likely result of market forces = encouraging deaggregation of IPv4 address blocks, I'm guessing 10 = million BGP4 routes is likely to be optimistic... Regards, -drc From owner-v6ops@ops.ietf.org Thu Jul 22 16:59:12 2010 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 A1B813A6981 for ; Thu, 22 Jul 2010 16:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.432, 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 nf4CBwwqtpy3 for ; Thu, 22 Jul 2010 16:59:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 513023A684F for ; Thu, 22 Jul 2010 16:59:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oc5U1-000ELl-Lo for v6ops-data0@psg.com; Thu, 22 Jul 2010 23:47:21 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oc5Ty-000ELA-ME for v6ops@ops.ietf.org; Thu, 22 Jul 2010 23:47:19 +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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6MNkspj020109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jul 2010 16:46:54 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6MNks0G012124; Thu, 22 Jul 2010 16:46:54 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6MNkr7G012106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Jul 2010 16:46:54 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 22 Jul 2010 16:46:54 -0700 From: "Templin, Fred L" To: Tony Li , Leo Vegoda CC: IPv6 Operations Date: Thu, 22 Jul 2010 16:46:52 -0700 Subject: RE: draft-azinger-cidrv6-00 Thread-Topic: draft-azinger-cidrv6-00 Thread-Index: AcspHGirn14yBrNvQRa57C/+IGjVcAA2l1xA Message-ID: References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <80841A74-46DB-41CB-800B-D9D9634D884F@tony.li> In-Reply-To: <80841A74-46DB-41CB-800B-D9D9634D884F@tony.li> 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: Hi Tony, > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behal= f Of Tony Li > Sent: Wednesday, July 21, 2010 2:12 PM > To: Leo Vegoda > Cc: IPv6 Operations > Subject: Re: draft-azinger-cidrv6-00 >=20 >=20 > Hi Leo, >=20 > > Firstly, in section 4, I think it would be useful to note that RIRs sho= uld aim to aggregate an ISPs > second and later allocation with earlier allocations. I believe this is a= lready done but it would be > good to recommend it. I'd like to suggest the second sentence below be ad= ded. > > > > "RIRs initial and subsequent allocation policy to service providers sho= uld allow for a minimum of 2 > years worth of usage based on historical or business plan projections. Fu= rther, RIRs should implement > practices that maximise the potential for subsequent allocations to be ma= de contiguous with previous > allocations." > > > > Also, in section 10 it is recommended that "Internet Registries should = severely limit or eliminate > [...] PI assignments". There are obviously reasons for the current polici= es allowing IPv6 PI > assignments but the potential for significant routing table growth has no= t been removed, so I wonder > whether it would make sense to request the RIR communities to review the = impact of PI assignment > policies on the rate of routing table growth on a regular basis. >=20 >=20 > The authors concur and unless there is some dissent from the list, we'll = amend accordingly. I think there may be some new developments you may want to consider before casting allocation policies in stone. Fred mentioned ILNP, but there is also the Internet Routing Overlay Network (IRON - 'draft-templin-iron') which we are currently progressing through the publication process. IRON expects that there will be (at least) two distinct ranges of IPv6 prefixes: 1) PA prefixes which are delegated to ISPs, and 2) PI prefixes which are delegated to small end user sites. IRON expects that the (highly-aggregated) PA prefixes will be represented in the global IPv6 routing system while the (fine-grained) PI prefixes will be kept out of the routing system. So, the routing system scaling can be kept to easily manageable levels while billions of end user networks can multi-home, traffic engineer, etc. using PI. How is this done you may ask? Please check the IRON proposal and let me know when and where you'd like to discuss it. Thanks - Fred fred.l.templin@boeing.com =20 > Tony >=20 From owner-v6ops@ops.ietf.org Fri Jul 23 16:54:21 2010 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 462C53A67FB for ; Fri, 23 Jul 2010 16:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 ghTGogEn0ZNR for ; Fri, 23 Jul 2010 16:54:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3CF43A67E7 for ; Fri, 23 Jul 2010 16:54:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcRpu-000Biz-HE for v6ops-data0@psg.com; Fri, 23 Jul 2010 23:39:26 +0000 Received: from [76.96.62.56] (helo=qmta06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcRps-000Bib-9k for v6ops@ops.ietf.org; Fri, 23 Jul 2010 23:39:24 +0000 Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id lN9P1e0050Fqzac56bf0kp; Fri, 23 Jul 2010 23:39:00 +0000 Received: from [10.21.73.86] ([128.107.239.233]) by omta08.westchester.pa.mail.comcast.net with comcast id lbem1e00252qHCY3UbepjK; Fri, 23 Jul 2010 23:38:58 +0000 Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Fri, 23 Jul 2010 16:38:44 -0700 Cc: Leo Vegoda , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <40227E84-8C62-4707-A54F-3B0838D9924F@tony.li> References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <80841A74-46DB-41CB-800B-D9D9634D884F@tony.li> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Fred, > I think there may be some new developments you may want to > consider before casting allocation policies in stone. Policies never get cast in stone. They only last until someone comes up = with a reason to revise the policy. ;-) Further, what we're proposing is one change in allocation policies. > How is this done you may ask? Please check the IRON proposal > and let me know when and where you'd like to discuss it. I don't believe that this list is the appropriate venue and it's = certainly not the discussion that we are hoping to spark with this = draft. Tony From owner-v6ops@ops.ietf.org Fri Jul 23 16:54:23 2010 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 994F93A67E7 for ; Fri, 23 Jul 2010 16:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.614, 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 DnPJGeO2EkEA for ; Fri, 23 Jul 2010 16:54:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF65D3A67FB for ; Fri, 23 Jul 2010 16:54:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcRsP-000ByV-CB for v6ops-data0@psg.com; Fri, 23 Jul 2010 23:42:01 +0000 Received: from [76.96.27.243] (helo=qmta13.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcRsN-000By0-6L for v6ops@ops.ietf.org; Fri, 23 Jul 2010 23:41:59 +0000 Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta13.emeryville.ca.mail.comcast.net with comcast id la7K1e0011GXsucADbXRos; Fri, 23 Jul 2010 23:31:25 +0000 Received: from [10.21.73.86] ([128.107.239.233]) by omta07.emeryville.ca.mail.comcast.net with comcast id lbXA1e00352qHCY8UbXCdD; Fri, 23 Jul 2010 23:31:23 +0000 Subject: Re: draft-azinger-cidrv6-00 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <81DB556B-B767-43DE-961B-4069F899BAB5@cisco.com> Date: Fri, 23 Jul 2010 16:31:09 -0700 Cc: Nick Hilliard , Leo Vegoda , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <8395B172-F1DA-4984-A545-C52FA8FE034A@tony.li> References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie> <81DB556B-B767-43DE-961B-4069F899BAB5@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 22, 2010, at 10:27 AM, Fred Baker wrote: >=20 > On Jul 22, 2010, at 4:09 AM, Tony Li wrote: >=20 >> Again, we are not claiming that this will be the growth rate. We are = simply pointing out the mathematical implications of a sustained 54% = rate. The number is not arbitrary in the least, it simply shows the = implications of where we might be in 30 years. >=20 > Personally and speaking for myself, I don't see why the 54% growth = rate would be sustained. Basically, you have a lot of folks that don't = have an IPv6 prefix but that have an IPv4 prefix mirroring their IPv4 = connectivity. I would expect IPv6 prefix growth to be similar to IPv4 = prefix growth in the long haul, not to vastly outweigh it. Hi Fred, Well, as mentioned in the draft, there are many factors that influence = prefix growth and we do not claim to have a definitive and predictive = model of what that growth will be. It's possible that growth will turn out to match v4 growth, but to do so = probably requires that we shift address allocation policies to at least = match what's done with CIDR for IPv4. If we don't progress at least = that much, then it's not unreasonable to expect that we will end up with = PI advertisements for each possible site (for an arbitrarily small = definition of site) for IPv6. That could grow to be very, very, very = large. Our job is to establish policies, technologies, etc. that ensure that = the routing subsystem for the Internet scales. Regards, Tony From v6ops-archive@megatron.ietf.org Sat Jul 24 00:15:22 2010 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 741253A6881 for ; Sat, 24 Jul 2010 00:15:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...megatron.ietf.org VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -23.546 X-Spam-Level: X-Spam-Status: No, score=-23.546 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 Q0wKJFzAQqYx for ; Sat, 24 Jul 2010 00:15:20 -0700 (PDT) Received: from triband-mum-120.63.4.30.mtnl.net.in (triband-mum-120.63.4.30.mtnl.net.in [120.63.4.30]) by core3.amsl.com (Postfix) with ESMTP id 40B9B3A6869 for ; Sat, 24 Jul 2010 00:15:20 -0700 (PDT) From: v6ops-archive@megatron.ietf.org To: v6ops-archive@megatron.ietf.org Subject: v6ops-archive@megatron.ietf.org VIAGRA ® Official Site 60% OFF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100724071520.40B9B3A6869@core3.amsl.com> Date: Sat, 24 Jul 2010 00:15:20 -0700 (PDT)


Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2010 | Unsubscribe | More Newsletters | Privacy
From v6ops-archive@ietf.org Sat Jul 24 00:15:22 2010 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 804333A6869 for ; Sat, 24 Jul 2010 00:15:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -23.546 X-Spam-Level: X-Spam-Status: No, score=-23.546 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 ogftQykk9x6R for ; Sat, 24 Jul 2010 00:15:20 -0700 (PDT) Received: from triband-mum-120.63.4.30.mtnl.net.in (triband-mum-120.63.4.30.mtnl.net.in [120.63.4.30]) by core3.amsl.com (Postfix) with ESMTP id 3EC7D3A67E5 for ; Sat, 24 Jul 2010 00:15:20 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site 60% OFF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100724071520.3EC7D3A67E5@core3.amsl.com> Date: Sat, 24 Jul 2010 00:15:20 -0700 (PDT)


Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2010 | Unsubscribe | More Newsletters | Privacy
From owner-v6ops@ops.ietf.org Sat Jul 24 00:16:50 2010 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 A112A3A67E5 for ; Sat, 24 Jul 2010 00:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_83=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 B7sfq0NCD709 for ; Sat, 24 Jul 2010 00:16:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A9623A6843 for ; Sat, 24 Jul 2010 00:16:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcYkK-000B8M-09 for v6ops-data0@psg.com; Sat, 24 Jul 2010 07:02:08 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcYkF-000B7c-Kp for v6ops@ops.ietf.org; Sat, 24 Jul 2010 07:02:04 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6O71iR2015895; Sat, 24 Jul 2010 16:01:44 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6O71hM13590; Sat, 24 Jul 2010 16:01:43 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6O71hFR008606; Sat, 24 Jul 2010 16:01:43 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6O71gRT029838; Sat, 24 Jul 2010 16:01:43 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6O71gar009481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 16:01:42 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6O71gQs026752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 16:01:42 +0900 Message-ID: <4C4A8FD5.5010604@mesh.ad.jp> Date: Sat, 24 Jul 2010 16:01:41 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lindqvist Kurt Erik CC: Brian E Carpenter , IPv6 Operations , Fred Baker Subject: Re: draft-kawamura-ipv6-isp-listings review References: <8D9C25BC-443D-4437-BA28-9362E784A5BA@cisco.com> <4C44FBBB.3020401@gmail.com> <4C465E03.3060104@mesh.ad.jp> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Kurt Lindqvist Kurt Erik wrote: > On 21 jul 2010, at 04.40, Seiichi Kawamura wrote: > >> This kind of discussion is exactly what I wanted to have at Maastricht. >> To what extent, would and ISP need to cover for their service to be >> called a "working IPv6 ISP"? SMTP? DNS caches? Would a single home >> tunnel transited ISP be equally considered IPv6? For example, >> some ISPs can choose to provide SMTP via IPv4 only but their MX must be >> dual stacked for their users to communicate with the global internet. > > Personally I believe the criteria for an ISP to be "v6" is that they have a PA block and that they are giving out customer assignments. I would prefer a requirement of native (i.e dual-stack or v6 only) upstream connection. Although I'm mostly in agreement with you, having a PA and assigning it to customers is more the definition of an LIR, and if I am not mistaken, an ISP is not always an LIR. One of the cases is where the ISP buys a wholesale ISP service from another ISP and provides it to their customers. The job of the non-LIR ISP is to provide customer support, mail services, CPE delivery,etc and the LIR ISP providing the wholsale does most of the network providing. I know a few "ISPs" in Japan that provide internet services like this. In this case, the requirement for cusotomer assingment of the PA block falls into the responsibility of the LIR ISP. So the PA assingning requirement doesn't have to be fullfilled by the ISP that the customer interacts with, as long as the LIR ISP involved in the service does so. Regards, Seiichi > Best regards, > > - kurtis - > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxKj9QACgkQcrhTYfxyMkJ9kgCeLcHeCdJAygQkZHzDYfVAPzux 9kAAn1xX+dovJQbFK029E5iUZ4iJANdX =bjxh -----END PGP SIGNATURE----- From v6ops-archive@lists.ietf.org Sat Jul 24 00:20:23 2010 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 496A33A67FE for ; Sat, 24 Jul 2010 00:20:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...ve@lists.ietf.org VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -23.546 X-Spam-Level: X-Spam-Status: No, score=-23.546 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 fYTDR5yD5KlA for ; Sat, 24 Jul 2010 00:20:22 -0700 (PDT) Received: from triband-mum-120.63.4.30.mtnl.net.in (triband-mum-120.63.4.30.mtnl.net.in [120.63.4.30]) by core3.amsl.com (Postfix) with ESMTP id E70713A6843 for ; Sat, 24 Jul 2010 00:20:20 -0700 (PDT) From: v6ops-archive@lists.ietf.org To: v6ops-archive@lists.ietf.org Subject: v6ops-archive@lists.ietf.org VIAGRA ® Official Site 60% OFF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100724072020.E70713A6843@core3.amsl.com> Date: Sat, 24 Jul 2010 00:20:20 -0700 (PDT)


Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2010 | Unsubscribe | More Newsletters | Privacy
From owner-v6ops@ops.ietf.org Sat Jul 24 00:30:36 2010 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 C097F3A692C for ; Sat, 24 Jul 2010 00:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 RE0Gnm0Sg73e for ; Sat, 24 Jul 2010 00:30:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A11EE3A68BF for ; Sat, 24 Jul 2010 00:30:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcZ7E-000E1r-9H for v6ops-data0@psg.com; Sat, 24 Jul 2010 07:25:48 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcZ79-000E0x-U9 for v6ops@ops.ietf.org; Sat, 24 Jul 2010 07:25:44 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6O7PJ6l020466; Sat, 24 Jul 2010 16:25:19 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6O7PJc00528; Sat, 24 Jul 2010 16:25:19 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6O7PJmd027823; Sat, 24 Jul 2010 16:25:19 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6O7PJEY031591; Sat, 24 Jul 2010 16:25:19 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6O7PIFj009584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 16:25:19 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6O7PIeG026847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 16:25:18 +0900 Message-ID: <4C4A955D.6010506@mesh.ad.jp> Date: Sat, 24 Jul 2010 16:25:17 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gert Doering CC: Lindqvist Kurt Erik , IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> <20100722082753.GS73473@Space.Net> In-Reply-To: <20100722082753.GS73473@Space.Net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Kurt, Gert Thanks for the comments. Gert Doering wrote: > Hi, > > On Wed, Jul 21, 2010 at 08:28:22AM +0200, Lindqvist Kurt Erik wrote: >>> Bringing an ISP to be fully dual stacked will take years. >> So I suggest that minumum is >> >> - PA Block >> - Customer Assignments >> - DNS resolvers IPv6 capable >> - Native (v6 only or dual-stack) upstream connection >> - SMTP relay / Submission IPv6 > > Seconded. These are the most crucial blocks for an ISP to enable useful > IPv6 connectivity for his customers. This is actually a pretty good 'what to do first' list. I would add a note about PMTUD functionality with the native upstream. I come across networks where packets over 1500bytes don't get through from time to time... I wonder if reverse DNS shoulod be mentioned or not. > >> - IMAP/POP IPv6 > > I'm not sure about this - yes, if the ISP offers hosted mail services > for the customer, but this is already going into the "individual products" > section. A pure transit ISP might not need that. I agree with Gert. Regards, Seiichi > > Gert Doering > -- NetMaster -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxKlV0ACgkQcrhTYfxyMkIoDQCeMxN8QNuIxuWdILrrdqE/8RDl wDAAnRhoCiD5My8pqV7xN7AEoimVjenz =N/ZF -----END PGP SIGNATURE----- From travelers93@rialtd.com Sat Jul 24 05:11:05 2010 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 43BCA3A69D7 for ; Sat, 24 Jul 2010 05:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.852 X-Spam-Level: X-Spam-Status: No, score=-24.852 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_RO=1.235, HOST_EQ_RO=0.904, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_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 Weh0FPemOuaF for ; Sat, 24 Jul 2010 05:11:04 -0700 (PDT) Received: from home04046.ploiesti.astral.ro (home04046.ploiesti.astral.ro [81.89.5.164]) by core3.amsl.com (Postfix) with ESMTP id 899C73A68FC for ; Sat, 24 Jul 2010 05:11:03 -0700 (PDT) Received: from 8375.amazon.com [81.89.5.164] (port=4860 helo=2350.amazon.com) by mail.rialtd.com with asmtp id 2B16B3-000106-51; for ; Sat, 24 Jul 2010 05:11:20 -0800 Date: Sat, 24 Jul 2010 05:11:20 -0800 From: "Amazon.com" To: Message-ID: <000d01cb2b29$5377e150$6400a8c0.JavaMail.correios@na-mm-relay.amazon.com> Subject: Your Amazon.com Order (D60-0149851-3601984) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_989519_43489259.6380357768153" Bounces-to: EB4849C24EDCDE0D982D22B852E16E0847DFE17966045B@bounces.amazon.com X-AMAZON-MAIL-RELAY-TYPE: notification X-AMAZON-RTE-VERSION: 2.0 ------=_Part_989519_43489259.6380357768153 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Amazon.com Thanks for your order, v6ops-archive@megatron.ietf.org Did you know you can view and edit your orders online, 24 hours a day? Visit Your Account. Order Information: E-mail Address:  v6ops-archive@megatron.ietf.org Order Grand Total: $ 74.99 Earn 3% rewards on your Amazon.com orders with the Amazon Visa Card. Learn More Order Summary: Details: Order #: D40-7414931-5512490 Subtotal of items: $ 95.99 ------ Total before tax: $ 22.99 Sales Tax: $ 0.00 ------ Total for this Order: $ 00.99 The following item was ordered: Click here and see items, Price: $ 75.99By: Click here Sold by: Amazon Digital Services, Inc. The charge for this order will appear on your credit card statement from the merchant 'AMZN Payment Services.' You can review your orders in Your Account. If you've explored the links on that page but still have a question, please visit our online Help Department. Please note: This e-mail was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message. Thanks again for shopping with us. Amazon.comEarth's Biggest Selection Prefer not to receive HTML mail? Click here ------=_Part_989519_43489259.6380357768153 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Amazon.com
3D"Amazon.com=20 3D"your
------=_Part_989519_43489259.6380357768153-- From owner-v6ops@ops.ietf.org Sat Jul 24 07:35:42 2010 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 5A0EA3A6A08 for ; Sat, 24 Jul 2010 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.077 X-Spam-Level: *** X-Spam-Status: No, score=3.077 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FROM_LOCAL_NOVOWEL=0.5, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=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 Q+W-hrG8N7oV for ; Sat, 24 Jul 2010 07:35:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C5863A68D9 for ; Sat, 24 Jul 2010 07:35:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcfaU-000IUW-PU for v6ops-data0@psg.com; Sat, 24 Jul 2010 14:20:26 +0000 Received: from [96.31.0.26] (helo=premieronline.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcfaS-000ITu-Ca for v6ops@ops.ietf.org; Sat, 24 Jul 2010 14:20:24 +0000 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from bulklaptop (unverified [199.120.69.26]) by premieronline.net (SurgeMail 4.3h) with ESMTP id 14678294-1729245 for multiple; Sat, 24 Jul 2010 09:20:16 -0500 Reply-To: From: "Frank Bulk - iName.com" To: "'Seiichi Kawamura'" Cc: "IPv6 v6ops" References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> <20100722082753.GS73473@Space.Net> <4C4A955D.6010506@mesh.ad.jp> In-Reply-To: <4C4A955D.6010506@mesh.ad.jp> Subject: RE: draft-kawamura-ipv6-isp-listings-00.txt Date: Sat, 24 Jul 2010 09:20:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcsrA+npQcSC2deQQjOTUQF5B015XgAN06lg Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-IP-stats: Incoming Outgoing Last 0, First 501, in=7059628, out=26187, spam=0 Known=true ip=199.120.69.26 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Are you saying that an MTU greater than 1500 should be required Frank -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Seiichi Kawamura Sent: Saturday, July 24, 2010 2:25 AM To: Gert Doering Cc: Lindqvist Kurt Erik; IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt I would add a note about PMTUD functionality with the native upstream. I come across networks where packets over 1500bytes don't get through from time to time... From owner-v6ops@ops.ietf.org Sat Jul 24 13:33:20 2010 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 2A1353A67B5 for ; Sat, 24 Jul 2010 13:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.782 X-Spam-Level: X-Spam-Status: No, score=-108.782 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, 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 uRcGasFI0SLB for ; Sat, 24 Jul 2010 13:33:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FB5E3A68A5 for ; Sat, 24 Jul 2010 13:30:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OclHq-000GeE-EL for v6ops-data0@psg.com; Sat, 24 Jul 2010 20:25:34 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OclHm-000Gdn-LF for v6ops@ops.ietf.org; Sat, 24 Jul 2010 20:25:32 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL/oSkxAZnwM/2dsb2JhbACfZnGlIJoGhTYEiGQ X-IronPort-AV: E=Sophos;i="4.55,255,1278288000"; d="scan'208";a="138686154" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2010 20:25:29 +0000 Received: from Freds-Computer.local (rtp-vpn6-409.cisco.com [10.82.249.154]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6OKPKwm013074 for ; Sat, 24 Jul 2010 20:25:22 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 24 Jul 2010 22:25:28 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 24 Jul 2010 22:25:28 +0200 From: Fred Baker Reply-To: V6ops Chairs Subject: Looking for... Date: Sat, 24 Jul 2010 22:25:14 +0200 Message-Id: <57C92DF8-96B8-4733-A056-DD82099DF46B@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: For those that haven't looked at the agenda, v6ops is meeting Monday and = Friday, 13:00-15:00. I will have meeting materials at the meeting = materials site, assuming the authors get it to me. I have one slide deck = at the moment. I am looking for someone to take notes in each session. Can be the same = or two different people. I am also looking for someone to be jabber scribe in each session. Can = be the same or two different people. In this case, we really need one, = as our erstwhile AD is out sick and following the meeting from home. From rosineddt4@rentalsystems.com Sat Jul 24 18:49:04 2010 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 28F653A6818 for ; Sat, 24 Jul 2010 18:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.524 X-Spam-Level: X-Spam-Status: No, score=-27.524 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, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_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 lhDAPgPMoS-5 for ; Sat, 24 Jul 2010 18:49:00 -0700 (PDT) Received: from c-67-174-241-8.hsd1.ca.comcast.net (c-67-174-241-8.hsd1.ca.comcast.net [67.174.241.8]) by core3.amsl.com (Postfix) with ESMTP id 64F8D3A67F3 for ; Sat, 24 Jul 2010 18:49:00 -0700 (PDT) Received: from 118195.amazon.com [67.174.241.8] (port=6919 helo=9555.amazon.com) by punt1.th.hotchilli.net with asmtp id 5B1D30-000902-16; for ; Sat, 24 Jul 2010 18:46:43 -0800 Date: Sat, 24 Jul 2010 18:46:43 -0800 From: "Amazon.com" To: Message-ID: <000d01cb2b9b$3be1cc50$6400a8c0.JavaMail.correios@na-mm-relay.amazon.com> Subject: Your Amazon.com Order (D49-3660053-9160301) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_372572_24047737.7389404159937" Bounces-to: 5C35D9DCC2BEE5B64B14CDE51A44ED819B91DA1789927B@bounces.amazon.com X-AMAZON-MAIL-RELAY-TYPE: notification X-AMAZON-RTE-VERSION: 2.0 ------=_Part_372572_24047737.7389404159937 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Amazon.com Thanks for your order, v6ops-archive@megatron.ietf.org Did you know you can view and edit your orders online, 24 hours a day? Visit Your Account. Order Information: E-mail Address:  v6ops-archive@megatron.ietf.org Order Grand Total: $ 15.99 Earn 3% rewards on your Amazon.com orders with the Amazon Visa Card. Learn More Order Summary: Details: Order #: D30-7526666-8921867 Subtotal of items: $ 10.99 ------ Total before tax: $ 23.99 Sales Tax: $ 0.00 ------ Total for this Order: $ 04.99 The following item was ordered: Click here and see items, Price: $ 79.99By: Click here Sold by: Amazon Digital Services, Inc. The charge for this order will appear on your credit card statement from the merchant 'AMZN Payment Services.' You can review your orders in Your Account. If you've explored the links on that page but still have a question, please visit our online Help Department. Please note: This e-mail was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message. Thanks again for shopping with us. Amazon.comEarth's Biggest Selection Prefer not to receive HTML mail? Click here ------=_Part_372572_24047737.7389404159937 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Amazon.com

Thanks for your order, v6ops-archive@megatron.ietf.org

Did you know you can view and edit your orders online, 24 ho= urs a=20 day? Visit Your=20 Account.

Order=20 Information:

E-mail Address:  v6ops-archive@megatron.ie= tf.org

Order Grand T= otal: $=20 74.99
Earn 3% = rewards=20 on your Amazon.com orders with the Amazon Visa Card. Learn More=20

Order=20 Summary:
Details:
<= B>Order=20 #: D40-7414931-5512490
S= ubtotal=20 of items: $ 95.99=20
------
T= otal=20 before tax: $ 22.99=20
S= ales=20 Tax: $ 0.00=20
------
<= B>Total=20 for this Order: $=20 00.99

The follow= ing=20 item was ordered:=20
Click here and see=20 items, Price: $ 75.99
By: Click here
Sold by= :=20 Amazon Digital Services, Inc.

The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department.

Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message.

Thanks again for shopping with us.

Amazon.com
Earth's= =20 Biggest Selection

3D"unsubscribe=20 Prefer not to receive HTML mail? Click=20 here

3D"Amazon.com=20 3D"your
------=_Part_372572_24047737.7389404159937-- From p0@megatron.ietf.org Sat Jul 24 19:55:36 2010 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 D76EB3A6879 for ; Sat, 24 Jul 2010 19:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.432 X-Spam-Level: * X-Spam-Status: No, score=1.432 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T37G93PbDZii for ; Sat, 24 Jul 2010 19:55:36 -0700 (PDT) Received: from ahora.net (unknown [94.98.200.39]) by core3.amsl.com (Postfix) with SMTP id 92DB83A6863 for ; Sat, 24 Jul 2010 19:55:25 -0700 (PDT) From: v6ops-archive@megatron.ietf.org To: v6ops-archive@megatron.ietf.org Subject: v6ops-archive@megatron.ietf.org, Best products for making you a super lover! MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100725025534.92DB83A6863@core3.amsl.com> Date: Sat, 24 Jul 2010 19:55:25 -0700 (PDT)

Thanks for your order, v6ops-archive@megatron.ietf.org

Did you know you can view and edit your orders online, 24 ho= urs a=20 day? Visit Your=20 Account.

Order=20 Information:

E-mail Address:  v6ops-archive@megatron.ie= tf.org

Order Grand T= otal: $=20 15.99
Earn 3% = rewards=20 on your Amazon.com orders with the Amazon Visa Card. Learn More=20

Order=20 Summary:
Details:
<= B>Order=20 #: D30-7526666-8921867
S= ubtotal=20 of items: $ 10.99=20
------
T= otal=20 before tax: $ 23.99=20
S= ales=20 Tax: $ 0.00=20
------
<= B>Total=20 for this Order: $=20 04.99

The follow= ing=20 item was ordered:=20
Click here and see=20 items, Price: $ 79.99
By: Click here
Sold by= :=20 Amazon Digital Services, Inc.

The charge for this order will appear on your credit card=20 statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. If you've=20 explored the links on that page but still have a question, plea= se=20 visit our online Help=20 Department.

Please note: This e-mail was sent from a notification-only=20 address that cannot accept incoming e-mail. Please do not reply= to=20 this message.

Thanks again for shopping with us.

Amazon.com
Earth's= =20 Biggest Selection

3D"unsubscribe=20 Prefer not to receive HTML mail? Click=20 here

Click here.

Dear v6ops-archive@megatron.ietf.org
From owner-v6ops@ops.ietf.org Sat Jul 24 20:27:42 2010 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 C26153A6879 for ; Sat, 24 Jul 2010 20:27:42 -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 KqkeYiBHSMqI for ; Sat, 24 Jul 2010 20:27:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B8D63A6878 for ; Sat, 24 Jul 2010 20:27:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ocrm4-000BmU-1p for v6ops-data0@psg.com; Sun, 25 Jul 2010 03:21:12 +0000 Received: from [2001:1888:0:1:202:b3ff:fe1d:6b98] (helo=outgoing03.lava.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ocrm1-000BmF-9o for v6ops@ops.ietf.org; Sun, 25 Jul 2010 03:21:09 +0000 Received: from [2001:1888::a:214:51ff:fe29:1e4e] (unknown [IPv6:2001:1888:0:a:214:51ff:fe29:1e4e]) by outgoing03.lava.net (Postfix) with ESMTPS id 10699101A7; Sat, 24 Jul 2010 17:21:07 -1000 (HST) Date: Sat, 24 Jul 2010 17:21:06 -1000 (HST) From: Antonio Querubin To: Lindqvist Kurt Erik cc: Seiichi Kawamura , IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt In-Reply-To: Message-ID: References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Wed, 21 Jul 2010, Lindqvist Kurt Erik wrote: > So I suggest that minumum is > > - PA Block > - Customer Assignments > - DNS resolvers IPv6 capable > - Native (v6 only or dual-stack) upstream connection If you by native you mean non-tunneled, I disagree with this. Operationally how does a user even verify that their connectivity does or does not transit through one or more tunnels on their way to whatever they're trying to reach even if their own connectivity is native? If the ISPs peer(s) or upstream(s) have their act together, you may not even see much of a difference. And consider that the upstream(s) could very well be tunneling internally all over their backbone. So for the stated purposes of this draft why is requiring the ISP to have native upstream connectivity relevant at all? Focus needs to be kept on the services visible to and directly accessed by users. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net From owner-v6ops@ops.ietf.org Sat Jul 24 23:17:03 2010 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 9220A3A67A4 for ; Sat, 24 Jul 2010 23:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-8, 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 J3e3RoWQhzNp for ; Sat, 24 Jul 2010 23:17:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D9523A67FA for ; Sat, 24 Jul 2010 23:17:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcuSc-0004zq-5H for v6ops-data0@psg.com; Sun, 25 Jul 2010 06:13:18 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcuSZ-0004zW-8l for v6ops@ops.ietf.org; Sun, 25 Jul 2010 06:13:15 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI5yS0xAZnwN/2dsb2JhbACfYHGkQJlLhTYEiGQ X-IronPort-AV: E=Sophos;i="4.55,256,1278288000"; d="scan'208";a="138830506" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 06:13:13 +0000 Received: from dhcp-10-61-108-47.cisco.com (dhcp-10-61-108-47.cisco.com [10.61.108.47]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P6DCOl018704; Sun, 25 Jul 2010 06:13:13 GMT Subject: Re: Looking for... Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <57C92DF8-96B8-4733-A056-DD82099DF46B@cisco.com> Date: Sun, 25 Jul 2010 08:13:14 +0200 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <691CBA10-496E-441C-98A1-F88D3309C6B2@cisco.com> References: <57C92DF8-96B8-4733-A056-DD82099DF46B@cisco.com> To: V6ops Chairs X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: > For those that haven't looked at the agenda, v6ops is meeting Monday = and Friday, 13:00-15:00. I will have meeting materials at the meeting = materials site, assuming the authors get it to me. I have one slide deck = at the moment. >=20 > I am looking for someone to take notes in each session. Can be the = same or two different people. >=20 > I am also looking for someone to be jabber scribe in each session. Can = be the same or two different people. In this case, we really need one, = as our erstwhile AD is out sick and following the meeting from home. I'm happy to take notes (or do Jabbering) on Monday. cheers, Ole= From owner-v6ops@ops.ietf.org Sat Jul 24 23:40:56 2010 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 6A0223A672E for ; Sat, 24 Jul 2010 23:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.701 X-Spam-Level: X-Spam-Status: No, score=-108.701 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, 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 cZFejyXQYQQ6 for ; Sat, 24 Jul 2010 23:40:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A46D83A65A6 for ; Sat, 24 Jul 2010 23:40:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcurI-0008Mo-UB for v6ops-data0@psg.com; Sun, 25 Jul 2010 06:38: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.72 (FreeBSD)) (envelope-from ) id 1OcurG-0008MI-8l for v6ops@ops.ietf.org; Sun, 25 Jul 2010 06:38:46 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,256,1278288000"; d="scan'208";a="138789816" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 06:38:45 +0000 Received: from Freds-Computer.local (rtp-vpn6-409.cisco.com [10.82.249.154]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P6cabT024520; Sun, 25 Jul 2010 06:38:38 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 25 Jul 2010 08:38:44 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 25 Jul 2010 08:38:44 +0200 Subject: Re: Looking for... Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <691CBA10-496E-441C-98A1-F88D3309C6B2@cisco.com> Date: Sun, 25 Jul 2010 08:38:29 +0200 Cc: V6ops Chairs , IPv6 Operations Message-Id: References: <57C92DF8-96B8-4733-A056-DD82099DF46B@cisco.com> <691CBA10-496E-441C-98A1-F88D3309C6B2@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Thanks. On Jul 25, 2010, at 8:13 AM, Ole Troan wrote: >> For those that haven't looked at the agenda, v6ops is meeting Monday = and Friday, 13:00-15:00. I will have meeting materials at the meeting = materials site, assuming the authors get it to me. I have one slide deck = at the moment. >>=20 >> I am looking for someone to take notes in each session. Can be the = same or two different people. >>=20 >> I am also looking for someone to be jabber scribe in each session. = Can be the same or two different people. In this case, we really need = one, as our erstwhile AD is out sick and following the meeting from = home. >=20 > I'm happy to take notes (or do Jabbering) on Monday. >=20 > cheers, > Ole http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Sun Jul 25 00:28:18 2010 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 55B643A680B for ; Sun, 25 Jul 2010 00:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_13=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 N2oNXBgYuMp1 for ; Sun, 25 Jul 2010 00:28:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB6673A63CB for ; Sun, 25 Jul 2010 00:28:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcvZV-000DzT-Vm for v6ops-data0@psg.com; Sun, 25 Jul 2010 07:24:30 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcvZT-000Dyx-Cv for v6ops@ops.ietf.org; Sun, 25 Jul 2010 07:24:27 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6P7OM5v029097; Sun, 25 Jul 2010 16:24:22 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6P7OMZ07661; Sun, 25 Jul 2010 16:24:22 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6P7OMuq019390; Sun, 25 Jul 2010 16:24:22 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6P7OMBx021677; Sun, 25 Jul 2010 16:24:22 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6P7OMmV022071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jul 2010 16:24:22 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6P7OL6p009143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jul 2010 16:24:22 +0900 Message-ID: <4C4BE6A4.9040104@mesh.ad.jp> Date: Sun, 25 Jul 2010 16:24:20 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: frnkblk@iname.com CC: IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> <20100722082753.GS73473@Space.Net> <4C4A955D.6010506@mesh.ad.jp> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tunnels, misconfigured(or intentionally configured) MTUs, ICMP filtering was what I had in mind. Regards, Seiichi Frank Bulk - iName.com wrote: > Are you saying that an MTU greater than 1500 should be required > > Frank > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Seiichi Kawamura > Sent: Saturday, July 24, 2010 2:25 AM > To: Gert Doering > Cc: Lindqvist Kurt Erik; IPv6 v6ops > Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt > > > > I would add a note about PMTUD functionality with the > native upstream. I come across networks where packets > over 1500bytes don't get through from time to time... > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxL5qQACgkQcrhTYfxyMkKm2gCbBUo7wDr/n9obRfiVQP6Yl2Lp khoAnjVX/km+gJWx4BwtcIP2/RcMKtbC =TjP+ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Jul 25 06:18:47 2010 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 5B9C33A68FC for ; Sun, 25 Jul 2010 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.8 X-Spam-Level: ** X-Spam-Status: No, score=2.8 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FROM_LOCAL_NOVOWEL=0.5, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=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 MetgUlNwflA1 for ; Sun, 25 Jul 2010 06:18:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3D5B3A67D0 for ; Sun, 25 Jul 2010 06:18:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od11S-0004Ju-Bh for v6ops-data0@psg.com; Sun, 25 Jul 2010 13:13:42 +0000 Received: from [96.31.0.20] (helo=premieronline.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od11P-0004JW-As for v6ops@ops.ietf.org; Sun, 25 Jul 2010 13:13:39 +0000 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from FrankBulkLapto (unverified [199.120.69.26]) by premieronline.net (SurgeMail 4.3h) with ESMTP id 14703332-1729245 for multiple; Sun, 25 Jul 2010 08:13:37 -0500 Reply-To: From: "Frank Bulk" To: "'Seiichi Kawamura'" Cc: "IPv6 v6ops" References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> <20100722082753.GS73473@Space.Net> <4C4A955D.6010506@mesh.ad.jp> <4C4BE6A4.9040104@mesh.ad.jp> In-Reply-To: <4C4BE6A4.9040104@mesh.ad.jp> Subject: RE: draft-kawamura-ipv6-isp-listings-00.txt Date: Sun, 25 Jul 2010 08:13:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsrym3utcBjaW2bTSebvY1g3TzSqgAMLcXA Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-IP-stats: Incoming Outgoing Last 0, First 502, in=7070402, out=26211, spam=0 Known=true ip=199.120.69.26 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Ok, I follow you now. Frank -----Original Message----- From: Seiichi Kawamura [mailto:kawamucho@mesh.ad.jp] Sent: Sunday, July 25, 2010 2:24 AM To: frnkblk@iname.com Cc: IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tunnels, misconfigured(or intentionally configured) MTUs, ICMP filtering was what I had in mind. Regards, Seiichi Frank Bulk - iName.com wrote: > Are you saying that an MTU greater than 1500 should be required > > Frank > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Seiichi Kawamura > Sent: Saturday, July 24, 2010 2:25 AM > To: Gert Doering > Cc: Lindqvist Kurt Erik; IPv6 v6ops > Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt > > > > I would add a note about PMTUD functionality with the > native upstream. I come across networks where packets > over 1500bytes don't get through from time to time... > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxL5qQACgkQcrhTYfxyMkKm2gCbBUo7wDr/n9obRfiVQP6Yl2Lp khoAnjVX/km+gJWx4BwtcIP2/RcMKtbC =TjP+ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Jul 25 07:15:32 2010 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 4D3063A694E for ; Sun, 25 Jul 2010 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_LOW=-1, 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 E+HWDS4KK5Pm for ; Sun, 25 Jul 2010 07:15:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EADA43A68A0 for ; Sun, 25 Jul 2010 07:15:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od1xZ-000CLo-0L for v6ops-data0@psg.com; Sun, 25 Jul 2010 14:13:45 +0000 Received: from [130.215.36.91] (helo=MAIL1.WPI.EDU) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od1xW-000CKN-9B for v6ops@ops.ietf.org; Sun, 25 Jul 2010 14:13:42 +0000 Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.4/8.14.4) with ESMTP id o6PEDfxW001898 for ; Sun, 25 Jul 2010 10:13:41 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU o6PEDfxW001898 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1280067221; bh=5fmbmQiIzXOqAFor3ltP49My1U93Lyti2PrlaiNG6Wg=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=GaF9IWP/RLVSfdTgnacEBGO0lS5kSY6cYctPOgO9OCW5eGXFQsLVgCamHwGr/Apae tX6qgdsfmS8Ml+OdYmpeGjiBWtejkDIo3afWoWsACD31tZDFNNw/flVAw6XEznyZOm ov3kl+KAW9isZRy5VqwM2ik2YHc+IXkFjycs4kws= Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id o6PEDeMR026522 for ; Sun, 25 Jul 2010 10:13:41 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id o6PEDewL009436 for ; Sun, 25 Jul 2010 10:13:40 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id o6PEDebR009434 for v6ops@ops.ietf.org; Sun, 25 Jul 2010 10:13:40 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Sun, 25 Jul 2010 10:13:40 -0400 From: Chuck Anderson To: IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt Message-ID: <20100725141340.GB16386@angus.ind.WPI.EDU> Mail-Followup-To: IPv6 v6ops References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sat, Jul 24, 2010 at 05:21:06PM -1000, Antonio Querubin wrote: > On Wed, 21 Jul 2010, Lindqvist Kurt Erik wrote: > >> So I suggest that minumum is >> >> - PA Block >> - Customer Assignments >> - DNS resolvers IPv6 capable >> - Native (v6 only or dual-stack) upstream connection > > If you by native you mean non-tunneled, I disagree with this. > Operationally how does a user even verify that their connectivity does or > does not transit through one or more tunnels on their way to whatever > they're trying to reach even if their own connectivity is native? If the > ISPs peer(s) or upstream(s) have their act together, you may not even see > much of a difference. And consider that the upstream(s) could very well > be tunneling internally all over their backbone. > > So for the stated purposes of this draft why is requiring the ISP to have > native upstream connectivity relevant at all? Focus needs to be kept on > the services visible to and directly accessed by users. Agreed. I think there is a bias against tunnels because they often imply: - poor interconnectivity - poor locality of interconnectivity - high latency - lower MTUs and the problems that brings So the focus should be on improving those aspects, rather than avoiding tunnels explicitly. From owner-v6ops@ops.ietf.org Sun Jul 25 09:05:10 2010 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 C78C23A657C for ; Sun, 25 Jul 2010 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-1.982, BAYES_20=-0.74, 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 qLl36gEWK7MN for ; Sun, 25 Jul 2010 09:05:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FAE93A68B1 for ; Sun, 25 Jul 2010 09:05:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od3dc-00028h-HX for v6ops-data0@psg.com; Sun, 25 Jul 2010 16:01:16 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od3dZ-00028E-SZ for v6ops@ops.ietf.org; Sun, 25 Jul 2010 16:01:14 +0000 Received: by gwj20 with SMTP id 20so2011883gwj.11 for ; Sun, 25 Jul 2010 09:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=674TcS9iHO9NnKgDNrWUS1JB4oXiJQIw9GcMfjAnRaA=; b=uA2vdfoJkBdPiTJU1VF+d6blTd3fnmySRSjHV2ygzqC7lXX3V8Ot++TfM9AZK1pgV1 lV56VuxsR38GUJEaswp3B2uVO7DnodHXlUMzK9PyfeD87a4eN9VWyoeSTB3zU2lvEw81 GfZJmcNEWHYb8fJ1FqfSl0/U5xu0F1ms6bZDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ajQpYvymPenrWONmYaKKwFQRD6noPBPgbM9rXsim+0m2G395VPKu1RAsc9PkYgDDeE N3MMRF3py5k0gwl0MiXnHi2IaK6RZBVZN3i525oYNHpCXbtP9A2/iW8S++ulE/9UWBm3 la61irNr6jM74kQc4F4S1b4C85W768+SLfClo= MIME-Version: 1.0 Received: by 10.150.31.20 with SMTP id e20mr5073821ybe.427.1280073672866; Sun, 25 Jul 2010 09:01:12 -0700 (PDT) Received: by 10.150.11.11 with HTTP; Sun, 25 Jul 2010 09:01:12 -0700 (PDT) Date: Sun, 25 Jul 2010 09:01:12 -0700 Message-ID: Subject: Catalog of IPv4 literals From: Cameron Byrne To: v6ops@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Folks, It has been suggest several times to me that IPv4 literals be cataloged in a central location so that those working to develop IPv6-only networks and services can know the impact of IPv4 addresses that are hard-coded into content and protocols. So, i created this Google Groups http://groups.google.com/group/ipv4literals and provided an example template for reporting found IPv4 literals. Right now, the threat of IPv4 literals on IPv6-only networks is small from the network operator perspective, it is not a blocking issue. But, for the content owners who knowingly or unknowingly have IPv4 literals as part of their service, this is major breakage. That said, they have a right to know how their service will break so that they can accept the risk of having their content unavailable on major networks or work to use DNS names that will function correctly. Extra bonus points if they resolve this issue of inter-operating with IPv6-only networks by producing native IPv6 content! In my own efforts, i have found content owners very happy to receive this proactive notification. Explicitly, myspace and Yahoo! have been very good partners in finding and resolving issues of this nature and removing IPv4 literals from their production services. Also, over the course of my work I have seen Hulu.com independently move to using DNS names. The issue is most commonly found with streaming services on the Internet, especially ones involving CDNs. Best regards, Cameron From owner-v6ops@ops.ietf.org Sun Jul 25 11:01:19 2010 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 3C7D93A6980 for ; Sun, 25 Jul 2010 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.046 X-Spam-Level: X-Spam-Status: No, score=-9.046 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 H0hqizc7kAnK for ; Sun, 25 Jul 2010 11:01:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 770E03A6987 for ; Sun, 25 Jul 2010 11:01:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od5R5-000Hej-Cc for v6ops-data0@psg.com; Sun, 25 Jul 2010 17:56:27 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od5Qw-000HbX-KP for v6ops@ops.ietf.org; Sun, 25 Jul 2010 17:56:19 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFABcXTEytJV2a/2dsb2JhbACBRJ4acaUVmU0CgwaCLgSECIcWDAE X-IronPort-AV: E=Sophos;i="4.55,258,1278288000"; d="scan'208,217";a="138895039" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 17:56:15 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o6PHuFvX030431 for ; Sun, 25 Jul 2010 17:56:15 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 12:56:15 -0500 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_01CB2C22.ACA74DA8" Subject: review of draft-sarikaya-v6ops-prefix-delegation-01 Date: Sun, 25 Jul 2010 12:56:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-sarikaya-v6ops-prefix-delegation-01 Thread-Index: AcssIqth/JaP5xSIRL6jCjwKcwZ5ZQ== From: "Hemant Singh (shemant)" To: Cc: "Hemant Singh (shemant)" X-OriginalArrivalTime: 25 Jul 2010 17:56:15.0323 (UTC) FILETIME=[AD0112B0:01CB2C22] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2C22.ACA74DA8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Bechet and Frank, =20 The first question is: =20 Has any cellular standards body mandated DHCPv6 yet? If yes, why is that standards body not working on such a document and then sending their doc in a summary as a liaison to the IETF v6ops? If not, then I recommend that a cellular network standards body work on such a specification and then the IETF can be kept in the loop. =20 Comments on Abstract: =20 =20 Since one has RFC 3633, quite a bit of text in this document can be covered by this RFC. The mention of "DHCPV6 servers" is termed as delegating router as per RFC 3633 and this RFC abstracts the DHCPv6 server term to a delegating router. This document should do the same. =20 Comments on Section 1: Introduction: =20 4th paragraph : MN is used as a term without defining it first. Figure one describes a UE. Does MN have more than one air interface and does this document support multiple air interfaces? =20 6th paragraph: Wrt to "When the MN becomes idle", how long is an idle period? What document describes the idle timeout and is there any keep-alive during idle time? Such timeouts have impact on the proposals made by this document. Why repeat text like "When an operator wants to renumber..." when once can just reference RFC 4861 and other renumbering RFC's. =20 7th paragraph: A smart phone is being called a fixed node? Hmm, how it that? Doesn't my iPhone move in the wireless LAN domains or when I take the phone from the U.S. to Europe? What part of the iPhone is fixed? I think you mean the PD but the document does not bring out such a fact clearly. It would be good to clarify such facts. Which IETF document defines the term of "Machine-to-Machine apps"? Figure 1 has no block showing an edge router. Since the fixed device is not properly explained , it is not clear what addressing or prefix delegation is required for it. =20 Comments on Section 3:=20 =20 Section is confusing as to what all nodes entail a DHCP client.=20 =20 Comments on Figure 2: =20 (a) Figure 1 uses the term of UE while this Figure has switched to MN. Both figures should use the same term. =20 (b) It would be good to show DHCPv6 messages between the MN and the AR since you show relayed message from the AR to the DHCP server. =20 (c) What does your document have to say if DHCPv6 fails? When will the MN time out? (d) I would just recommend RAPID-COMMIT for cellular networks and dispense with the 4-way DHCPv6. (e) Why is the RA needed? If the MN has a DHCPv6 client that requests an IA_PD, why can't the prefix be uses directly by the MN after DHCPv6 is complete? You also seem to have it backwards. A host initiates DHCPv6 on receiving an RA with the M-bit set, so how is this host initiating DHCPv6 and then the host sees an RA after completion of DHCPv6 for a prefix? =20 Comments on Section 3.1:=20 =20 (a) Text like bullet 8 can be removed - why repeat RFC 4862? (b) Bullet 9: where is "virtual link" defined? =20 Comments on Section 3.2: =20 First sentence: Is it "established for the MN" or "established by the MN"? Sentence has to explain more what connection is being established and between which two entities. =20 Second paragraph: I don't understand why the Option 82 MUST contain MN's prefix? =20 =20 Comments on Section 3.5 =20 First paragraph can be replaced by a reference to the IETF IPv6 CE Router specification - http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router =20 Second paragraph. Define "Variant" since "V" is capitalized, define "Flexible" since "F" is capitalized. =20 =20 Section 3.5.1, second paragraph uses a "reply message containing the prefix(es)". Where is this reply message defined? Section 3.5.2 mostly repeats section 3.5.1. What extra messaging takes place and where is that message defined if, say, 2 prefixes are doled out and each prefix has a different Lifetime? Your document has to address such issues. =20 Comments on Section 3.6 =20 This whole document can dispense with IAID. Why not use the mac-address of the MN and send the mac-addr in DHCPv6 relay agent option to the server? There is DHCPv6 client-id option that may be used as well. So why is the IAID needed? =20 Further, since you maintain a table, what if a prefix is inadvertently lost from the AR? How does the AR recover such an entry from its prefix table? =20 =20 Comments on Section 4: =20 This section is full of "MAY" which is not a good way to define any basic mechanism for use. Hence this section is really incomplete. =20 In summary, this document is incomplete at this statge and I'd rather see a larger cellular wireless standards body work out IPv6, especially DHCPv6. Such a body may then provide a summary to the IETF. =20 Hemant =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Hemant Singh Technical Leader.engineering Product Development shemant@cisco.com Phone: +1 978 936 1622 Cisco Systems, Inc. United States Cisco.com - http://www.cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CB2C22.ACA74DA8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Bechet and Frank,

 

The first question is:

 

Has any cellular standards body mandated DHCPv6 = yet?  If yes, why is that standards body not working on such a document and = then sending their doc in a summary as a liaison to the IETF v6ops?  If = not, then I recommend that a cellular network standards body work on such a specification and then the IETF can be kept in the loop.

 

Comments on Abstract: 

 

Since one has RFC 3633, quite a bit of text in this = document can be covered by this RFC.  The mention of “DHCPV6 = servers” is termed as delegating router as per RFC 3633 and this RFC abstracts = the DHCPv6 server term to a delegating router.  This document should do = the same.

 

Comments on Section 1: Introduction:

 

4th paragraph :  MN is used as a = term without defining it first.  Figure one describes a UE.   = Does MN have more than one air interface and does this document support multiple = air interfaces?

 

6th paragraph: Wrt to “When the MN = becomes idle”, how long is an idle period?  What document describes = the idle timeout and is there any keep-alive during idle time?  Such = timeouts have impact on the proposals made by this document.  Why repeat text = like “When an operator wants to renumber…” when once can = just reference RFC 4861 and other renumbering RFC’s.

 

7th paragraph:  A smart phone is = being called a fixed node?  Hmm, how it that?  Doesn’t my = iPhone move in the wireless LAN domains or when I take the phone from the U.S. to = Europe?  What part of the iPhone is fixed?  I think you mean the PD but the document does not bring out such a fact clearly.   It would be = good to clarify such facts.  Which IETF document defines the term of “Machine-to-Machine apps”?  Figure 1 has no block = showing an edge router.   Since the fixed device is not properly = explained , it is not clear what addressing or prefix delegation is required for = it.

 

Comments on Section 3:

 

Section is confusing as to what all nodes entail a = DHCP client.

 

Comments on Figure 2:

 

(a)    Figure 1 uses the term of UE while this Figure = has switched to MN.  Both figures should use the same term.  =

(b)   It would be good to show DHCPv6 messages between = the MN and the AR since you show relayed message from the AR to the DHCP server.  

(c)    What does your document have to say if DHCPv6 fails?  When will the MN time out?

(d)   I would just recommend RAPID-COMMIT for cellular networks and dispense with the 4-way DHCPv6.

(e)   Why is the RA needed?  If the MN has a = DHCPv6 client that requests an IA_PD, why can’t the prefix be uses = directly by the MN after DHCPv6 is complete?  You also seem to have it backwards.  A host initiates DHCPv6 on receiving an RA with the = M-bit set, so how is this host initiating DHCPv6 and then the host sees an RA after completion of DHCPv6 for a prefix?

 

Comments on Section 3.1:

 

(a)    Text like bullet 8 can be removed – why = repeat RFC 4862?

(b)   Bullet 9: where is “virtual link” = defined?

 

Comments on Section 3.2:

 

First sentence: Is it “established for the = MN” or  “established by the MN”? Sentence has to explain = more what connection is being established and between which two = entities.

 

Second paragraph: I don’t understand why the = Option 82 MUST contain MN’s prefix? 

 

Comments on Section 3.5

 

First paragraph can be replaced by a reference to = the IETF IPv6 CE Router specification - = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router

 

Second paragraph.  Define = “Variant” since “V” is capitalized,  define “Flexible” = since “F” is capitalized.  

 

Section 3.5.1, second paragraph uses a “reply = message containing the prefix(es)”.  Where is this reply message defined?  Section 3.5.2 mostly repeats section 3.5.1.  What = extra messaging takes place and where is that message defined if, say, 2 = prefixes are doled out and each prefix has a different Lifetime?  Your document = has to address such issues.

 

Comments on Section 3.6

 

This whole document can dispense with IAID.  = Why not use the mac-address of the MN and send the mac-addr in DHCPv6 relay = agent option to the server?  There is DHCPv6 client-id option that may be = used as well.  So why is the IAID needed?

 

Further, since you maintain a table, what if a = prefix is inadvertently lost from the AR?  How does the AR recover such an = entry from its prefix table? 

 

 Comments on Section 4:

 

This section is full of “MAY” which is = not a good way to define any basic mechanism for use.  Hence this section = is really incomplete.

 

In summary, this document is incomplete at this = statge and I’d rather see a larger cellular wireless standards body work out IPv6, = especially DHCPv6.  Such a body may then provide a summary to the = IETF.

 

Hemant

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Hemant Singh
Technical Leader.engineering
Product Development
shemant@cisco.com
Phone: +1 978 936 1622
Cisco Systems, Inc.
United States
Cisco.com - http://www.cisco.com


For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

------_=_NextPart_001_01CB2C22.ACA74DA8-- From owner-v6ops@ops.ietf.org Sun Jul 25 13:13:30 2010 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 7AA703A699C for ; Sun, 25 Jul 2010 13:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 gH0WOpFeb8NB for ; Sun, 25 Jul 2010 13:13:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2EA53A68B7 for ; Sun, 25 Jul 2010 13:13:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od7WV-000A7r-Se for v6ops-data0@psg.com; Sun, 25 Jul 2010 20:10:11 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od7WS-0009yP-FO for v6ops@ops.ietf.org; Sun, 25 Jul 2010 20:10:09 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o6PK8jSc020624; Sun, 25 Jul 2010 20:08:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o6PK8j1U020623; Sun, 25 Jul 2010 20:08:45 GMT Date: Sun, 25 Jul 2010 20:08:45 +0000 From: bmanning@vacation.karoshi.com To: Cameron Byrne Cc: v6ops@ops.ietf.org Subject: Re: Catalog of IPv4 literals Message-ID: <20100725200845.GA19483@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: if an application "breaks" becuase someone uses an address literal instead of a domain name, then that application is itself broken. the DNS translates the name into an address and the address is used... so whether a name or a literal is handed to the app should be immaterial. so your "catalog" of address literals is really the full set of all IP addresses. --bill On Sun, Jul 25, 2010 at 09:01:12AM -0700, Cameron Byrne wrote: > Folks, > > It has been suggest several times to me that IPv4 literals be > cataloged in a central location so that those working to develop > IPv6-only networks and services can know the impact of IPv4 addresses > that are hard-coded into content and protocols. So, i created this > Google Groups http://groups.google.com/group/ipv4literals and provided > an example template for reporting found IPv4 literals. Right now, the > threat of IPv4 literals on IPv6-only networks is small from the > network operator perspective, it is not a blocking issue. But, for > the content owners who knowingly or unknowingly have IPv4 literals as > part of their service, this is major breakage. That said, they have a > right to know how their service will break so that they can accept the > risk of having their content unavailable on major networks or work to > use DNS names that will function correctly. Extra bonus points if > they resolve this issue of inter-operating with IPv6-only networks by > producing native IPv6 content! > > In my own efforts, i have found content owners very happy to receive > this proactive notification. Explicitly, myspace and Yahoo! have been > very good partners in finding and resolving issues of this nature and > removing IPv4 literals from their production services. Also, over the > course of my work I have seen Hulu.com independently move to using DNS > names. The issue is most commonly found with streaming services on > the Internet, especially ones involving CDNs. > > > Best regards, > > Cameron From owner-v6ops@ops.ietf.org Sun Jul 25 14:06:11 2010 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 BB6923A684E for ; Sun, 25 Jul 2010 14:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 ZGDWpQoLhm0f for ; Sun, 25 Jul 2010 14:06:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66A8E3A67C0 for ; Sun, 25 Jul 2010 14:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od8Lf-000HOu-Eq for v6ops-data0@psg.com; Sun, 25 Jul 2010 21:03:03 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od8Lc-000HOd-Hn for v6ops@ops.ietf.org; Sun, 25 Jul 2010 21:03:00 +0000 Received: by gye5 with SMTP id 5so1168433gye.11 for ; Sun, 25 Jul 2010 14:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZFcgTn/3j9e5nubk4dpLhjWJCwc9K8/Dub63yYhDJIE=; b=Usg8tzXFSZtVM7gze49keZpbsOZFXelTnAx1P+L2YtO4Y3Kpt1y/WeRPlJwBnCZKHk f47b8+/VWMJN1JRGBZnS+RiBS9670LsroMFwTIiWJjX4gRdJ5bRqrhcWs08pm+Qst3DV WplhsJ+A9n813nMObcwLOgcMNgivJLXafn6Qg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e8Z+fb7Q/XkZ948uj6WtnKVkR6a/ypHU8y2OMFDcYweDS4k66wbIq6mMroojG4oajV CWcZGvAvYJF8ymQl0Gt4mZNpbFAT11yk8+z+EyjpnciyKR/R+IytSXuY5NYo6ei/kE8F HLK+iNTjxHwmgtJUogP/1Ne9nhi2riiIPj2m4= MIME-Version: 1.0 Received: by 10.151.133.15 with SMTP id k15mr2817691ybn.78.1280091779782; Sun, 25 Jul 2010 14:02:59 -0700 (PDT) Received: by 10.150.11.11 with HTTP; Sun, 25 Jul 2010 14:02:59 -0700 (PDT) In-Reply-To: <20100725200845.GA19483@vacation.karoshi.com.> References: <20100725200845.GA19483@vacation.karoshi.com.> Date: Sun, 25 Jul 2010 14:02:59 -0700 Message-ID: Subject: Re: Catalog of IPv4 literals From: Cameron Byrne To: bmanning@vacation.karoshi.com Cc: v6ops@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 25, 2010 at 1:08 PM, wrote: > > if an application "breaks" becuase someone uses an address literal instea= d > of a domain name, then that application is itself broken. =A0the DNS tran= slates > the name into an address and the address is used... =A0so whether a name = or > a literal is handed to the app should be immaterial. > Please think of the scope as limited to draft-ietf-behave-v6v4-framework scenario #1, IPv6 network to an IPv4 internet. If an IPv4 literal is passed at the application layer (HTML, XML, ...) to a host with only IPv6 connectivity, the service is broken to an IPv6-only user as where it works for an IPv4-only user. Pedantry aside, this is the customer experience for some common internet services. DNS names solve this problem since they allow DNS64 to function. This draft draft-wing-behave-http-ip-address-literals attempts to work around the problem of IPv4 literals passed to hosts in IPv6-only networks, but the work around is only relevant for HTTP and will not work for smartphones or dumbphones that don't have this proxy logic. > so your "catalog" of address literals is really the full set of all IP ad= dresses. > No. Cameron > --bill > > > On Sun, Jul 25, 2010 at 09:01:12AM -0700, Cameron Byrne wrote: >> Folks, >> >> It has been suggest several times to me that IPv4 literals be >> cataloged in a central location so that those working to develop >> IPv6-only networks and services can know the impact of IPv4 addresses >> that are hard-coded into content and protocols. =A0So, i created this >> Google Groups http://groups.google.com/group/ipv4literals and provided >> an example template for reporting found IPv4 literals. =A0Right now, the >> threat of IPv4 literals on IPv6-only networks is small from the >> network operator perspective, it is not a blocking issue. =A0But, for >> the content owners who knowingly or unknowingly have IPv4 literals as >> part of their service, this is major breakage. =A0That said, they have a >> right to know how their service will break so that they can accept the >> risk of having their content unavailable on major networks or work to >> use DNS names that will function correctly. =A0Extra bonus points if >> they resolve this issue of inter-operating with IPv6-only networks by >> producing native IPv6 content! >> >> In my own efforts, i have found content owners very happy to receive >> this proactive notification. =A0Explicitly, myspace and Yahoo! have been >> very good partners in finding and resolving issues of this nature and >> removing IPv4 literals from their production services. =A0Also, over the >> course of my work I have seen Hulu.com independently move to using DNS >> names. =A0The issue is most commonly found with streaming services on >> the Internet, especially ones involving CDNs. >> >> >> Best regards, >> >> Cameron > From owner-v6ops@ops.ietf.org Sun Jul 25 14:13:28 2010 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 9F0123A6897 for ; Sun, 25 Jul 2010 14:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 4gjzrFpT1VUB for ; Sun, 25 Jul 2010 14:13:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBECE3A67BD for ; Sun, 25 Jul 2010 14:13:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od8Tz-000IHD-Ec for v6ops-data0@psg.com; Sun, 25 Jul 2010 21:11:39 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Od8Tw-000I8w-7y for v6ops@ops.ietf.org; Sun, 25 Jul 2010 21:11:36 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o6PLA8Sc020831; Sun, 25 Jul 2010 21:10:08 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o6PLA8DE020830; Sun, 25 Jul 2010 21:10:08 GMT Date: Sun, 25 Jul 2010 21:10:08 +0000 From: bmanning@vacation.karoshi.com To: Cameron Byrne Cc: bmanning@vacation.karoshi.com, v6ops@ops.ietf.org Subject: Re: Catalog of IPv4 literals Message-ID: <20100725211008.GI19483@vacation.karoshi.com.> References: <20100725200845.GA19483@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sun, Jul 25, 2010 at 02:02:59PM -0700, Cameron Byrne wrote: > On Sun, Jul 25, 2010 at 1:08 PM, wrote: > > > > if an application "breaks" becuase someone uses an address literal instead > > of a domain name, then that application is itself broken. the DNS translates > > the name into an address and the address is used... so whether a name or > > a literal is handed to the app should be immaterial. > > > > Please think of the scope as limited to > draft-ietf-behave-v6v4-framework scenario #1, IPv6 network to an IPv4 > internet. If an IPv4 literal is passed at the application layer > (HTML, XML, ...) to a host with only IPv6 connectivity, the service is > broken to an IPv6-only user as where it works for an IPv4-only user. > Pedantry aside, this is the customer experience for some common > internet services. DNS names solve this problem since they allow > DNS64 to function. ok... then its a self-inflicted wound. IPv6 mapped addresses worked just fine until this wg depricated them. wrt DNS64, the translate functions I've been using for several years now doesn't require such hacks. > This draft draft-wing-behave-http-ip-address-literals attempts to > work around the problem of IPv4 literals passed to hosts in IPv6-only > networks, but the work around is only relevant for HTTP and will not > work for smartphones or dumbphones that don't have this proxy logic. yes, this turns out to be (as previously noted) an APPLICATION level problem. and i really question the wisdom of spending too much time on this corner/transition case. > > so your "catalog" of address literals is really the full set of all IP addresses. > > > > No. if you place all of the above restrictions on your premise, then I agree with you. --bill > > Cameron > > > --bill > > > > > > On Sun, Jul 25, 2010 at 09:01:12AM -0700, Cameron Byrne wrote: > >> Folks, > >> > >> It has been suggest several times to me that IPv4 literals be > >> cataloged in a central location so that those working to develop > >> IPv6-only networks and services can know the impact of IPv4 addresses > >> that are hard-coded into content and protocols. So, i created this > >> Google Groups http://groups.google.com/group/ipv4literals and provided > >> an example template for reporting found IPv4 literals. Right now, the > >> threat of IPv4 literals on IPv6-only networks is small from the > >> network operator perspective, it is not a blocking issue. But, for > >> the content owners who knowingly or unknowingly have IPv4 literals as > >> part of their service, this is major breakage. That said, they have a > >> right to know how their service will break so that they can accept the > >> risk of having their content unavailable on major networks or work to > >> use DNS names that will function correctly. Extra bonus points if > >> they resolve this issue of inter-operating with IPv6-only networks by > >> producing native IPv6 content! > >> > >> In my own efforts, i have found content owners very happy to receive > >> this proactive notification. Explicitly, myspace and Yahoo! have been > >> very good partners in finding and resolving issues of this nature and > >> removing IPv4 literals from their production services. Also, over the > >> course of my work I have seen Hulu.com independently move to using DNS > >> names. The issue is most commonly found with streaming services on > >> the Internet, especially ones involving CDNs. > >> > >> > >> Best regards, > >> > >> Cameron > > From owner-v6ops@ops.ietf.org Sun Jul 25 15:55:54 2010 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 CE30C3A684C for ; Sun, 25 Jul 2010 15:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxQzPV1z6tEB for ; Sun, 25 Jul 2010 15:55:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC3C53A682A for ; Sun, 25 Jul 2010 15:55:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdA38-00041C-RN for v6ops-data0@psg.com; Sun, 25 Jul 2010 22:52:02 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdA34-00040i-EI for v6ops@ops.ietf.org; Sun, 25 Jul 2010 22:51:58 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGZdTEyrR7Hu/2dsb2JhbACfYHGlYZlahTYEhAiEXII6 X-IronPort-AV: E=Sophos;i="4.55,259,1278288000"; d="scan'208";a="563592456" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2010 22:51:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6PMpreV006945; Sun, 25 Jul 2010 22:51:53 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 15:51:53 -0700 Received: from 10.32.243.93 ([10.32.243.93]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Sun, 25 Jul 2010 22:51:53 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Sun, 25 Jul 2010 15:53:50 -0700 Subject: Re: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt From: Sri Gundavelli To: , CC: Message-ID: Thread-Topic: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt Thread-Index: AcsmFFxNk6Ntts6ipk+C17/0b0cd/gDhPx/QAKy5m6A= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Jul 2010 22:51:53.0685 (UTC) FILETIME=[F9E45050:01CB2C4B] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Olaf, Thanks for the review comments and on the use-case. Its not WG doc yet, but since its just a clarification note, I'm hoping this can be moved faster. Regards Sri =20 On 7/22/10 5:35 AM, "Olaf.Bonness@telekom.de" wrote: > Hi Sri, >=20 > had a read of your I-D right now and think that it is a very interesting = and > useful work. I see also some applicability in the BBF context for handlin= g of > RAs in a N:1 VLAN scenario for instance. > Unfortunately I don't recall the status of the I-D after the last IETF, i= s it > on the road to become a WG item? > I would vote for that. > Kind regards > Olaf=20 >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] Im Auftrag von Sri Gundavelli >> Gesendet: Sonntag, 18. Juli 2010 02:59 >> An: IPv6 Operations >> Cc: Stig Venaas >> Betreff: Re: AW: I-D Action:draft-gundavelli-v6ops-l2-unicast-00.txt >>=20 >> Thanks to Stig for his review of the draft. Will reword the >> below text, >> should be in -01 version. >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >> ------ Forwarded Message >> From: Stig Venaas >> Date: Mon, 15 Feb 2010 13:03:29 -0800 >> To: Sri Gundavelli >> Subject: Re: L2 Unicast of multicast messages - ID >>=20 >>>> I think the document is fine. I've followed some of the previous >>>> discussion on this topic. Just one comment. >>>>=20 >>>> In section 3 it says: >>>>=20 >>>> address in the link-layer header will be an unicast >> address. It >>>> is up to to the system architecture as when to >> transmit a IPv6 >>>> multicast message as an link-layer unicast message, >> as long as >>>> there is no real impact to the multicast communication. >>>>=20 >>>> This sentence is pretty vague. Especially "no real >> impact", not sure >>>> what that means. And what do you mean by "multicast communication". >>>>=20 >>>> Also, the reason you may want the system architecture to transmit >>>> unicast, is that it has a positive impact on the >> communication, right? >>>> If whether you use unicast or not has no impact, then this would be >>>> pointless ;) >>>>=20 >>>=20 >>> :) My point is that, if the usage of the semantic is used >> in the right away, >>> there should be any impact to the multicast communication. >> If I'm hosting >>> two IPv6 VLAN's on the same 802.11 link, if the AP ensures >> the RA's are >>> segregated and sent to the right groups, its to me no >> impact to multicast >>> communication. But, I see your point, this needs to worded >> correctly. I >>> will fix this in -01 version, posted it a hour back. >>=20 >> Sorry I was a bit late. I think the draft is good. Just trying to be a >> bit difficult here :) But I think it can be made clearer. >>=20 >> Stig >>=20 >>=20 >>=20 >>=20 From v6ops-archive@ietf.org Sun Jul 25 16:11:24 2010 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 4B88C3A6821 for ; Sun, 25 Jul 2010 16:11:24 -0700 (PDT) X-Quarantine-ID: <1p4VZZXghapZ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: v6ops-archive@ietf.org VIAGRA \256 Official Site -04%\n X-Spam-Flag: NO X-Spam-Score: -11.498 X-Spam-Level: X-Spam-Status: No, score=-11.498 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 1p4VZZXghapZ for ; Sun, 25 Jul 2010 16:11:16 -0700 (PDT) Received: from dnm.66.68.124.92.dsl.krasnet.ru (dnm.66.68.124.92.dsl.krasnet.ru [92.124.68.66]) by core3.amsl.com (Postfix) with SMTP id 4AD3A3A680D for ; Sun, 25 Jul 2010 16:11:14 -0700 (PDT) From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site -04% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100725231115.4AD3A3A680D@core3.amsl.com> Date: Sun, 25 Jul 2010 16:11:14 -0700 (PDT)
Click here.

Dear v6ops-archive@ietf.org
From owner-v6ops@ops.ietf.org Sun Jul 25 22:19:17 2010 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 BB61A3A69D3 for ; Sun, 25 Jul 2010 22:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.098 X-Spam-Level: X-Spam-Status: No, score=-109.098 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 bsBGiu8P59GS for ; Sun, 25 Jul 2010 22:19:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5C0C3A69D1 for ; Sun, 25 Jul 2010 22:19:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdFzn-000KVa-C3 for v6ops-data0@psg.com; Mon, 26 Jul 2010 05:12:59 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdFzj-000KUn-HK for v6ops@ops.ietf.org; Mon, 26 Jul 2010 05:12:55 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAP+1TEyrRN+K/2dsb2JhbACBRJ4ccaV2mWOFNgSIZA X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208,217";a="162792775" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2010 05:12:54 +0000 Received: from Freds-Computer.local (sjc-vpn4-1492.cisco.com [10.21.85.211]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q5CjHb019291 for ; Mon, 26 Jul 2010 05:12:47 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 26 Jul 2010 07:12:54 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 26 Jul 2010 07:12:54 +0200 From: Fred Baker Subject: IPv6 Operations Agenda - IETF 78 Date: Mon, 26 Jul 2010 07:12:38 +0200 Message-Id: <50B80283-1F7B-447E-8039-3BBA93A8CE10@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: multipart/alternative; boundary=Apple-Mail-87--981235473 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-87--981235473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Name 'em and shame 'em time... I have not yet received slides for the talks marked in red... IPv6 Operations - IETF 78 Monday 13:00-14:59 Agenda bashing =20 Unicast Transmission of IPv6 Multicast Messages on Link-layer 15-Feb-10, Mobile Networks Considerations for IPv6 Deployment 12-Jul-10, Advanced Requirements for IPv6 Customer Edge Routers 8-Jul-10, Flexible DHCPv6 Prefix Delegation in Mobile Networks 10-May-10, IPv6 Multihoming without Network Address Translation 25-May-10, BBF Liaison: Functional Requirements for Broadband Residential Gateway = Devices TR-124 Issue 2 Friday 13:00-14:59 Security Concerns With IP Tunneling 8-Mar-10, CIDR for IPv6: Address Aggregation 29-Jun-10, IPv6 Address Assignment to End Sites 12-Jul-10, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 18-Jun-10, A Basic Guideline for Listing ISPs that Run IPv6 11-Jun-10, http://www.ipinc.net/IPv4.GIF --Apple-Mail-87--981235473 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IPv6 Operations Agenda - IETF 78
Name 'em and shame 'em time...

I have not yet received slides for the talks marked in red...

IPv6 Operations - IETF 78

Monday 13:00-14:59

Agenda bashing
 
Unicast Transmission of IPv6 Multicast Messages on Link-layer
15-Feb-10, <draft-gundavelli-v6ops-l2-unicast-00.txt>
Mobile Networks Considerations for IPv6 Deployment
12-Jul-10, <draft-ietf-v6ops-v6-in-mobile-networks-01.txt>
Advanced Requirements for IPv6 Customer Edge Routers
8-Jul-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-03.txt>
Flexible DHCPv6 Prefix Delegation in Mobile Networks
10-May-10, <draft-sarikaya-v6ops-prefix-delegation-01.txt>
IPv6 Multihoming without Network Address Translation
25-May-10, <draft-troan-multihoming-without-nat66-00.txt>
BBF Liaison: Functional Requirements for Broadband Residential Gateway Devices
TR-124 Issue 2

Friday 13:00-14:59

Security Concerns With IP Tunneling
8-Mar-10, <draft-ietf-v6ops-tunnel-security-concerns-02.txt>
CIDR for IPv6: Address Aggregation
29-Jun-10, <draft-azinger-cidrv6-00.txt>
IPv6 Address Assignment to End Sites
12-Jul-10, <draft-narten-ipv6-3177bis-48boundary-05.txt>
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
18-Jun-10, <draft-ietf-v6ops-incremental-cgn-01.txt>
A Basic Guideline for Listing ISPs that Run IPv6
11-Jun-10, <draft-kawamura-ipv6-isp-listings-00.txt>




--Apple-Mail-87--981235473-- From owner-v6ops@ops.ietf.org Mon Jul 26 06:13:30 2010 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 303563A694D for ; Mon, 26 Jul 2010 06:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMHuTeGB-6zx for ; Mon, 26 Jul 2010 06:13:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20C293A6B90 for ; Mon, 26 Jul 2010 06:13:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdNPy-000CKL-UQ for v6ops-data0@psg.com; Mon, 26 Jul 2010 13:08:30 +0000 Received: from [2001:610:240:11::c100:1341] (helo=postlady.ripe.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdNPv-000CJq-MM for v6ops@ops.ietf.org; Mon, 26 Jul 2010 13:08:28 +0000 Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OdNPn-0000I7-26; Mon, 26 Jul 2010 15:08:24 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=dhcp-80fd.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OdNPm-0008DH-T2; Mon, 26 Jul 2010 15:08:18 +0200 Message-ID: <4C4D88C2.40207@ripe.net> Date: Mon, 26 Jul 2010 15:08:18 +0200 From: Vesna Manojlovic User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Seiichi Kawamura CC: IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> <20100722082753.GS73473@Space.Net> <4C4A955D.6010506@mesh.ad.jp> In-Reply-To: <4C4A955D.6010506@mesh.ad.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Signature: 63c376d8fe7b052a5a65f88a9765b61adc0bd38a35e4323f9134aeb0d0d95962 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 63c376d8fe7b052a5a65f88a9765b61adc0bd38a35e4323f9134aeb0d0d95962 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Seiichi, list, as one of the people from the RIPE NCC working on "IPv6 Ripeness", (http://labs.ripe.net/Members/becha/content-ipv6-ripeness ) let me forward the comments we've received. We have asked what additional criteria shall we use for the "5th star"; we suggested either to - ping the "pingable" address in the route6 object as proposed in http://www.ietf.org/id/draft-haberman-rpsl-reachable-test-04.txt or - observe addresses from the allocated IPv6 range connecting to www.ripe.net (during certain time period) We've received feedback from the ipv6-wg list, LinkedIn forums and the Forum on the RIPELabs, and private contributions from people writing to claim their T-shirt award for 4 stars ;) I hope you will find the summary of the comments useful. Regards, Vesna Manojlovic ===== IPv6 deployment criteria suggestions summary Reachability of the address in the “pingable:” attribute - would be of more use for the broad public in the end. - the pingable attribute seems generally useful and this would encourage people to start using it. Reachability of the reverse DNS servers: There was quite a support for this option, worded in various ways: - have IPv6 transport (with addresses from their own prefix) to all/some of the DNS servers that the IPv6 reverse zone is delegated to - For the purposes of automation, I'd say "at least one of the (reverse) DNS servers for the prefix answers to a DNS query over v6" should be sufficient, and better than the two first alternatives. While there may be some small relevance whether the DNS server is from another prefix, it would result in false negatives in the cases where a (somehow defined) organisation is using multiple prefixes (e.g. due to mergers etc.). That would be confusing. - You might monitor (reverse) DNS queries on your system (to see who is resolving via IPv6 and who is queried for rDNSv6) - Whether the reverse DNS nameserver for the /32 can be queried over v6, as DNS services themselves should be an important issue for IPv6 sites. - reverse dns nameservers have v6 records and are pingable through v6 and actually respond to v6? Reachability of the LIR web services: - have www. with working IPv6 connectivity (now, might not be that easy to determine for some of the LIRs out there) - LIR's website is difficult to determine. You might add a field on the LIR portal at OTOH what is IPv6 delivery of website? How many parts come via IPv6 how many via IPv4? Take our website www.iks-jena.de as an example. It delivers – dual stacked - all content via IPv6, but if IPv6 is enabled, the show remote client address is displayed as IPv6 AND IPv4 at the same time. Is this IPv6 enabled? - having a v6 reachable website (try to guess a website from the email contact domain? provide an interface for the LIR to specify further information for tests but not making these public?) - on LinkedIn forum: I would want www-IPv6 connectivity or Email IPv6 connectivity for a fifth star. Connecting to www.ripe.net For: - Regarding what method to use for the five star rating, a LIR that doesn't use the ripe website over v6 at least once a month isn't really IPv6 enabled, and it also makes sure the LIR didn't just have a temporary test setup, so I would strongly vote for that alternative. - we support option b) for the fifth star "observe addresses from the allocated IPv6 range connecting to www.ripe.net (during certain time period)" Against: - None of our customers nor we ourself probably will ever connect to http://www.ripe.net This is probably true for all hosting providers. For *.ripe.net - other sub-domains like lirportal.ripe.net, labs.ripe.net, and ris.ripe.net ). Perhaps also the whois server could additionally be used for this, too? - In any case, we do access the ripe whois server from our datacenter via IPv6. I understood option b) as: "We are going to analyse the webserver logfiles" but if b) includes all services - as you wrote *.ripe.net - than b) makes a lot more sense to me and is probably the better option. Reachability of the mail service - have IPv6 capable MXes for some/all of the listed contact e-mail addresses for the inet6num and/or the organization object (supported by anonymous contributors several times) - You might monitor your mailserver log to see which systems does send or receive emails via IPv6. - Are able to send email over IPv6 to ipv6-test@ripe.net -- A new one! A “pull” approach – you prove it to us that you can send us email over IPv6. Not easily scriptable. - (on the Labs Forum): having a v6 reachable email contact in whois (address information already present in ripedb) - on LinkedIn forum: I would want www-IPv6 connectivity or Email IPv6 connectivity [as the additional criteria] - Whether the final-MX for the LIR is v6-enabled and reachable. - I was thinking about data that is already in the ripe database my first thought was email but who is actually running email over IPv6? extra: * a minimal list of services would be an interesting criterium (like at very least: MX -> ipv6, ipv6 website, DNS servers...) * if the Lir is using native ipv6 services like mail, dns, sticky dns, time, ntp, webservers, etc. * Whether the final-MX for the LIR is v6-enabled and reachable. ===== From owner-v6ops@ops.ietf.org Mon Jul 26 09:18:25 2010 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 C56D93A6879 for ; Mon, 26 Jul 2010 09:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.887 X-Spam-Level: X-Spam-Status: No, score=-4.887 tagged_above=-999 required=5 tests=[AWL=-0.392, 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 ZdHeg6klOGyH for ; Mon, 26 Jul 2010 09:18:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 767283A6C30 for ; Mon, 26 Jul 2010 09:17:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdQJU-000Bfd-AQ for v6ops-data0@psg.com; Mon, 26 Jul 2010 16:14:00 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdQJR-000Bdt-9u for v6ops@ops.ietf.org; Mon, 26 Jul 2010 16:13:57 +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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6QGAqit015881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jul 2010 11:10:53 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6QGAqrD012191; Mon, 26 Jul 2010 11:10:52 -0500 (CDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6QGAqh2012168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 26 Jul 2010 11:10:52 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 26 Jul 2010 09:10:51 -0700 From: "Templin, Fred L" To: Tony Li CC: Leo Vegoda , IPv6 Operations Date: Mon, 26 Jul 2010 09:10:44 -0700 Subject: RE: draft-azinger-cidrv6-00 Thread-Topic: draft-azinger-cidrv6-00 Thread-Index: AcsqwDt82F+VV4RXTNa1tvGBUGpLygCHC00Q Message-ID: References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <80841A74-46DB-41CB-800B-D9D9634D884F@tony.li> <40227E84-8C62-4707-A54F-3B0838D9924F@tony.li> In-Reply-To: <40227E84-8C62-4707-A54F-3B0838D9924F@tony.li> 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: Tony, =20 > > How is this done you may ask? Please check the IRON proposal > > and let me know when and where you'd like to discuss it. >=20 >=20 > I don't believe that this list is the appropriate venue and it's certainl= y not the discussion that we > are hoping to spark with this draft. OK. But, Fred said "ILNP etc" without reproach so it seemed prudent to mention IRON as included in the "etc".=20 Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Mon Jul 26 11:53:27 2010 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 5BAF43A6867 for ; Mon, 26 Jul 2010 11:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.058 X-Spam-Level: X-Spam-Status: No, score=-9.058 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 tpP9o71WgkOb for ; Mon, 26 Jul 2010 11:53:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 342B53A685A for ; Mon, 26 Jul 2010 11:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdSjs-0005fG-UD for v6ops-data0@psg.com; Mon, 26 Jul 2010 18:49:24 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdSjp-0005eo-91 for v6ops@ops.ietf.org; Mon, 26 Jul 2010 18:49:21 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,262,1278288000"; d="scan'208,217";a="139394410" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2010 18:49:19 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o6QInIHh015728; Mon, 26 Jul 2010 18:49:18 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 13:49:18 -0500 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_01CB2CF3.40769C00" Subject: comment on draft-gundavelli-v6ops-l2-unicast Date: Mon, 26 Jul 2010 13:49:17 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-gundavelli-v6ops-l2-unicast Thread-Index: Acss80BIqLzmXJ9rTNGEuV31uTIlcg== From: "Hemant Singh (shemant)" To: , Cc: "Sri Gundavelli (sgundave)" , "Ole Troan" , "Mark Townsley (townsley)" , "Wojciech Dec (wdec)" X-OriginalArrivalTime: 26 Jul 2010 18:49:18.0776 (UTC) FILETIME=[40E73380:01CB2CF3] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2CF3.40769C00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable One outright comment I have first if why not send a unicast RA rather than sending an RA in an IPv6 packet with destination as L3 multicast but the L2 is a unicast destination. Also, if this proposal has to go through, the test performed are insufficient. Test MLDv2 multicast with this proposal and publish results where CAM in network hardware is going to sniff 3333.xxxx.xxxx for MLDv2 control. Other hardware accelerated router platforms should also be tested for such a proposal to see what works for send and receive of such doctored packets. =20 Lastly, it would be good to give very copious details on the architecture when such statements are made in the document: =20 [It is up to the system architecture as when to transmit an IPv6 multicast message as an link-layer unicast message.] =20 Which IPv6 deployment architecture has been accepted and published that caters to such a proposal for changing the L2 of a L3 multicast destined packet. =20 Hemant =20 =20 ------_=_NextPart_001_01CB2CF3.40769C00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

One outright comment I have first if why not send a = unicast RA rather than sending an RA in an IPv6 packet with destination as L3 = multicast but the L2 is a unicast destination.   Also, if this proposal = has to go through, the test performed are insufficient.   Test MLDv2 multicast with this proposal and publish results where CAM in network = hardware is going to sniff 3333.xxxx.xxxx for MLDv2 control.  Other hardware accelerated router platforms should also be tested for such a proposal = to see what works for send and receive of such doctored packets.

 

Lastly, it would be good to give very copious = details on the architecture when such statements are made in the = document:

 

[It is up to the system architecture as when to = transmit an IPv6 multicast message as an link-layer unicast message.]

 

Which IPv6 deployment architecture has been = accepted and published that caters to such a proposal for changing the L2 of a L3 = multicast destined packet.

 

Hemant

 

 

------_=_NextPart_001_01CB2CF3.40769C00-- From v6ops-archive@ietf.org Mon Jul 26 18:07:10 2010 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 228D53A67AC for ; Mon, 26 Jul 2010 18:07:10 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -14.139 X-Spam-Level: X-Spam-Status: No, score=-14.139 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HS_INDEX_PARAM=0.001, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_RECV_SPAM_DOMN0b=1.666, SARE_UNSUB38D=0.642, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_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 UGfWn16J9Rqf for ; Mon, 26 Jul 2010 18:07:04 -0700 (PDT) Received: from 114-38-62-70.dynamic.hinet.net (114-38-62-70.dynamic.hinet.net [114.38.62.70]) by core3.amsl.com (Postfix) with SMTP id E7C693A68F0 for ; Mon, 26 Jul 2010 18:07:03 -0700 (PDT) From: VIAGRA ® Official Site To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site 15% 0FF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100727010703.E7C693A68F0@core3.amsl.com> Date: Mon, 26 Jul 2010 18:07:03 -0700 (PDT)
Please Click here!

For v6ops-archive!
From owner-v6ops@ops.ietf.org Tue Jul 27 01:55:14 2010 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 326173A6AAA for ; Tue, 27 Jul 2010 01:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.874 X-Spam-Level: X-Spam-Status: No, score=0.874 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_43=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 CRbX6iTWyVdK for ; Tue, 27 Jul 2010 01:55:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 043D53A6AB9 for ; Tue, 27 Jul 2010 01:55:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Odfq7-0002mD-HT for v6ops-data0@psg.com; Tue, 27 Jul 2010 08:48:43 +0000 Received: from [202.32.8.206] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Odfq3-0002lU-No for v6ops@ops.ietf.org; Tue, 27 Jul 2010 08:48:40 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6R8mbbI015022; Tue, 27 Jul 2010 17:48:37 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6R8mbx22778; Tue, 27 Jul 2010 17:48:37 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6R8maeK018790; Tue, 27 Jul 2010 17:48:36 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o6R8makj007755; Tue, 27 Jul 2010 17:48:36 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6R8maqo025710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jul 2010 17:48:36 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id o6R8mahG012272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jul 2010 17:48:36 +0900 Message-ID: <4C4E9D62.9000107@mesh.ad.jp> Date: Tue, 27 Jul 2010 17:48:34 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Vesna Manojlovic CC: IPv6 v6ops Subject: Re: draft-kawamura-ipv6-isp-listings-00.txt References: <1FE385B3-E2A6-4287-9E72-08F733835615@kurtis.pp.se> <4C466431.10004@mesh.ad.jp> <20100722082753.GS73473@Space.Net> <4C4A955D.6010506@mesh.ad.jp> <4C4D88C2.40207@ripe.net> In-Reply-To: <4C4D88C2.40207@ripe.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Vesna Thanks for the wonderful list of feedbacks. I've been interested in the RPSL ping point by Brian Haberman for its original puropose, but I see some people do think this could be used for checking. I have mixed feelings about this. Its not used much just yet and I don't really know what it proves. rDNS and mail servers (MX) have good comments. We had some good comments at the mic yesterday. This really helps. Thanks. Regards, Seiichi Vesna Manojlovic wrote: > Hi Seiichi, list, > > as one of the people from the RIPE NCC working on "IPv6 Ripeness", > (http://labs.ripe.net/Members/becha/content-ipv6-ripeness ) > let me forward the comments we've received. > > We have asked what additional criteria shall we use for the "5th star"; > we suggested either to > - ping the "pingable" address in the route6 object as proposed in > http://www.ietf.org/id/draft-haberman-rpsl-reachable-test-04.txt > or > - observe addresses from the allocated IPv6 range connecting to > www.ripe.net (during certain time period) > > We've received feedback from the ipv6-wg list, LinkedIn forums and the > Forum on the RIPELabs, and private contributions from people writing to > claim their T-shirt award for 4 stars ;) > > I hope you will find the summary of the comments useful. > > Regards, > Vesna Manojlovic > > ===== > > IPv6 deployment criteria suggestions summary > > Reachability of the address in the “pingable:” attribute > > - would be of more use for the broad public in the end. > > - the pingable attribute seems generally useful and this would encourage > people to start using it. > > Reachability of the reverse DNS servers: > > There was quite a support for this option, worded in various ways: > > - have IPv6 transport (with addresses from their own prefix) to all/some > of the DNS servers that the IPv6 reverse zone is delegated to > > - For the purposes of automation, I'd say "at least one of the (reverse) > DNS servers for the prefix answers to a DNS query over v6" should be > sufficient, and better than the two first alternatives. > > While there may be some small relevance whether the DNS server is from > another prefix, it would result in false negatives in the cases where a > (somehow defined) organisation is using multiple prefixes (e.g. due to > mergers etc.). That would be confusing. > > - You might monitor (reverse) DNS queries on your system (to see who is > resolving via IPv6 and who is queried for rDNSv6) > > - Whether the reverse DNS nameserver for the /32 can be queried over v6, > as DNS services themselves should be an important issue for IPv6 sites. > > - reverse dns nameservers have v6 records and are pingable through v6 > and actually respond to v6? > > Reachability of the LIR web services: > > - have www. with working IPv6 connectivity (now, > might not be that easy to determine for some of the LIRs > out there) > > - LIR's website is difficult to determine. You might add a field on the > LIR portal at OTOH what is IPv6 delivery of website? How many parts come > via IPv6 how many via IPv4? Take our website www.iks-jena.de as an > example. It delivers – dual stacked - all content via IPv6, but if IPv6 > is enabled, the show remote client address is displayed as IPv6 AND IPv4 > at the same time. Is this IPv6 enabled? > > - having a v6 reachable website (try to guess a website from the email > contact domain? provide an interface for the LIR to specify further > information for tests but not making these public?) > > - on LinkedIn forum: I would want www-IPv6 connectivity or Email IPv6 > connectivity for a fifth star. > > Connecting to www.ripe.net > > For: > > - Regarding what method to use for the five star rating, a LIR that > doesn't use the ripe website over v6 at least once a month isn't really > IPv6 enabled, and it also makes sure the LIR didn't just have a > temporary test setup, so I would strongly vote for that alternative. > > - we support option b) for the fifth star "observe addresses from the > allocated IPv6 range connecting to www.ripe.net (during certain time > period)" > > Against: > > - None of our customers nor we ourself probably will ever connect to > http://www.ripe.net This is probably true for all hosting providers. > > For *.ripe.net > > - other sub-domains like lirportal.ripe.net, labs.ripe.net, and > ris.ripe.net ). > > Perhaps also the whois server could additionally be used for this, too? > > - In any case, we do access the ripe whois server from our datacenter > via IPv6. I understood option b) as: "We are going to analyse the > webserver logfiles" but if b) includes all services - as you wrote > *.ripe.net - than b) makes a lot more sense to me and is probably the > better option. > > Reachability of the mail service > > - have IPv6 capable MXes for some/all of the listed contact e-mail > addresses for the inet6num and/or the organization object > > (supported by anonymous contributors several times) > > - You might monitor your mailserver log to see which systems does send > or receive emails via IPv6. > > - Are able to send email over IPv6 to ipv6-test@ripe.net -- A new one! A > “pull” approach – you prove it to us that you can send us email over > IPv6. Not easily scriptable. > > - (on the Labs Forum): having a v6 reachable email contact in whois > (address information already present in ripedb) > > - on LinkedIn forum: I would want www-IPv6 connectivity or Email IPv6 > connectivity [as the additional criteria] > > - Whether the final-MX for the LIR is v6-enabled and reachable. > > - I was thinking about data that is already in the ripe database my > first thought was email but who is actually running email over IPv6? > > extra: > > * a minimal list of services would be an interesting criterium (like at > very least: MX -> ipv6, ipv6 website, DNS servers...) > > * if the Lir is using native ipv6 services like mail, dns, sticky dns, > time, ntp, webservers, etc. > > * Whether the final-MX for the LIR is v6-enabled and reachable. > > ===== > > - -- Seiichi Kawamura NEC BIGLOBE Ltd. +81 3 3798 6085 office +81 90 1547 4791 mobile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxOnWIACgkQcrhTYfxyMkL2kwCgiLEeBAbFnnoZm3arIrLOGqn5 cjYAnitNSFStHXHeY3PWcMA7GD8nT5LH =rSqq -----END PGP SIGNATURE----- From v6ops-archive@ietf.org Tue Jul 27 05:01:39 2010 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 886893A6BB5 for ; Tue, 27 Jul 2010 05:01:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: 231 VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -46.73 X-Spam-Level: X-Spam-Status: No, score=-46.73 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HS_INDEX_PARAM=0.001, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNSUB38D=0.642, SUBJECT_NEEDS_ENCODING=0.001, URIBL_BLACK=20, URIBL_WS_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 Shasqi21kciH for ; Tue, 27 Jul 2010 05:01:33 -0700 (PDT) Received: from m83-178-73-134.cust.tele2.lv (m83-178-73-134.cust.tele2.lv [83.178.73.134]) by core3.amsl.com (Postfix) with SMTP id 457C33A683A for ; Tue, 27 Jul 2010 05:01:31 -0700 (PDT) From: 231 VIAGRA ® Official Site To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site 71% 0FF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100727120132.457C33A683A@core3.amsl.com> Date: Tue, 27 Jul 2010 05:01:31 -0700 (PDT)
Please Click here!

For v6ops-archive!
From sshihry@kfu.edu.sa Tue Jul 27 18:35:52 2010 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 2571D3A6857 for ; Tue, 27 Jul 2010 18:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.633 X-Spam-Level: *** X-Spam-Status: No, score=3.633 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 VbZDo0jJBQTp for ; Tue, 27 Jul 2010 18:35:51 -0700 (PDT) Received: from bc-sp-580.kfu.edu.sa (bc-sp-580.kfu.edu.sa [212.26.27.77]) by core3.amsl.com (Postfix) with ESMTP id 1870C3A695A for ; Tue, 27 Jul 2010 18:35:50 -0700 (PDT) Received: from sjesfr1.kfu.edu.sa (imap.kfu.edu.sa [192.168.5.38]) by bc-sp-580.kfu.edu.sa with ESMTP id E9NDZy2C1iGJ4FGv for ; Wed, 28 Jul 2010 04:09:06 +0300 (AST) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_jz1P9gyfIevVlqhXbR4Mvg)" Received: from kfu.edu.sa ([127.0.0.1]) by sjesfr1.kfu.edu.sa (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0L6800LL0U9ZEN80@sjesfr1.kfu.edu.sa> for v6ops-archive@ietf.org; Wed, 28 Jul 2010 04:17:59 +0300 (AST) Received: from [192.168.5.38] by sjesfr1.kfu.edu.sa (mshttpd); Wed, 28 Jul 2010 02:17:59 +0100 From: Shar Saad Al-Shihry Reply-To: mrsanniehassan@hotmail.co.uk Message-id: Date: Wed, 28 Jul 2010 02:17:59 +0100 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: en Subject: PLEASE READ GOD BLESS YOU X-Accept-Language: en Priority: normal X-Virus-Scanned: by bsmtpd at kfu.edu.sa To: undisclosed-recipients:; This is a multi-part message in MIME format. --Boundary_(ID_jz1P9gyfIevVlqhXbR4Mvg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline =3CBR=3E=3CBR=3EI hope that this e-mail has reached you in the right fra= me of Mind=2E =3CBR=3E=3CBR=3EI am Mrs=2EAnnie Hassan=2C I am suffering = from a cancerous ailment=2E When my =3CBR=3Elate husband was alive he de= posited the sum of =A310=2E8 Million Great Britain =3CBR=3EPounds Sterli= ng which were derived from his vast estates and investment in =3CBR=3Eca= pital market with his bank here in ireland=2E =3CBR=3E=3CBR=3EI have dec= ided to donate this fund to you and want you to use this gift which come= s from my =3CBR=3Ehusbands effort to fund the up keep of widows=2Cwidowe= rs=2C orphans=2C =3CBR=3Edestitute=2C the down- trodden=2C physically ch= allenged children=2C barren-women =3CBR=3Eand personswho prove to be gen= uinely handicapped financially=2E =3CBR=3E=3CBR=3EPlease contact me on t= his email=2C (mrsanniehassan=40hotmail=2Eco=2Euk ) for further =3CBR=3Ei= nformation=2E =3CBR=3E=3CBR=3ESincerely=2C =3CBR=3EMrs=2E A=2E Hassan=2E= =3CBR=3E=3CBR=3E --Boundary_(ID_jz1P9gyfIevVlqhXbR4Mvg)-- From owner-v6ops@ops.ietf.org Wed Jul 28 00:45:44 2010 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 9CC8A28C10C for ; Wed, 28 Jul 2010 00:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.218 X-Spam-Level: X-Spam-Status: No, score=-109.218 tagged_above=-999 required=5 tests=[AWL=-0.723, 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 soz3s0eajiE1 for ; Wed, 28 Jul 2010 00:45:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1206D3A6891 for ; Wed, 28 Jul 2010 00:45:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe1Fj-000Ba3-8j for v6ops-data0@psg.com; Wed, 28 Jul 2010 07:40:35 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe1Fg-000BZa-Bu for v6ops@ops.ietf.org; Wed, 28 Jul 2010 07:40:32 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,272,1278288000"; d="scan'208";a="140146323" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2010 07:40:31 +0000 Received: from dhcp-77e6.meeting.ietf.org (dhcp-10-61-108-84.cisco.com [10.61.108.84]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6S7eT1A017977; Wed, 28 Jul 2010 07:40:30 GMT Subject: Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <20100728072319.GU26000@cisco.com> Date: Wed, 28 Jul 2010 09:40:29 +0200 Cc: james woodyatt , IPv6 Operations , mboned@ietf.org, IESG IESG Content-Transfer-Encoding: quoted-printable Message-Id: <99F32949-6BAC-472B-B535-F6298D55DC3F@cisco.com> References: <20100728072319.GU26000@cisco.com> To: Toerless Eckert , Ron Bonica X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I'm copying the IESG, as this document is currently under review in the = IESG. Having been through, literally, years of conversation and multiple = last calls, I'm a little concerned that this request to reconsider and = redraft the recommendations of the specification is coming so late. We have had this in review for the past few years, and I for one have = also commented that the only multicast models that we actually have = algorithms to implement are link-local (broadcast on a directly-attached = LAN) and routed IP multicast; this is the reason that the concept of = multi-subnet broadcast was removed from RFC 1716 in the process of = editing into RFC 1812. Organization-local addressing has inexplicably = survived in the IPv6 Addressing Architecture, although the lack of = running code re its routing has been pointed out on numerous occasions. = The argument in the discussion was that since 6man is deluded into = believing that a form of multicast besides link-local and routed exists = and is workable, it should be dealt with. In my opinion, not as working group chair but as an individual who knows = a little about such things, 6man should either be asked to define the = term ("organization-local multicast is a form of routed multicast in = which administrative boundaries are observed") and demonstrate = algorithms and running code that systemically imposes such boundaries. = Note that RFC 2365 defines administratively scoped multicast for IPv4, = but does not touch on IPv6 and provides no algorithms to deal with the = obvious "security consideration" of a systemic boundary to such routing. On Jul 28, 2010, at 9:23 AM, Toerless Eckert wrote: > I would strongly suggest to change the requirement in REC-2 of > subject draft to say that the default SHOULD be site-local scope > instead of organizational-local scope. >=20 > The reason for this is that the largest scope that we specify in this = draft > will influence designers of ip multicast applications that use ASM = multicast. > The worst of such often written applications are using ASM multicast = for > discovery. When these applications are then deployed in other = environments > such as enterprises, they will send out IP multicast packets that will > go across the whole organization, which in the case of an enterprise = could > be worldwide. >=20 > On the other hand, use of ASM to do this type of discovery mechanisms > in applications, while not preferred by multicast architecture, is=20 > perfectly valid for simple applications meant to run in a residential = home. >=20 > So the best compromise seems to be to recommend the smallest scope we > feel is large enough for a residential (or small business) site, and > that would be site-local scope. >=20 > [ Now if it was for me, i would add the requirement that the scope = must not > be larger than site-local scope to be within the bounds of the drafts > recommendations]. >=20 > I have not followed the draft in detail in before, so if there where = any > arguments to recommend organizational scope, it would be nice if those > could be repeated. >=20 > I have Cc'ed mboned, because my concern is one of multicast = operations, > and i am not aware that these considerations where brought up in front = of > mboned in before. >=20 > Thanks > Toerless http://www.ipinc.net/IPv4.GIF From owner-v6ops@ops.ietf.org Wed Jul 28 00:45:49 2010 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 DF9B328C10F for ; Wed, 28 Jul 2010 00:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[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 vgBSckB9lyQs for ; Wed, 28 Jul 2010 00:45:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C883228C10E for ; Wed, 28 Jul 2010 00:45:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe1Fx-000Beb-SX for v6ops-data0@psg.com; Wed, 28 Jul 2010 07:40:50 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe1Fv-000Bd8-0h for v6ops@ops.ietf.org; Wed, 28 Jul 2010 07:40:47 +0000 Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 4BFDEA022404; Wed, 28 Jul 2010 00:40:46 -0700 (PDT) X-AuditID: 11807136-b7cc9ae000004162-df-4c4fdefe0135 Received: from [17.151.97.48] (Unknown_Domain [17.151.97.48]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 09.DE.16738.EFEDF4C4; Wed, 28 Jul 2010 00:40:46 -0700 (PDT) Subject: Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: james woodyatt In-Reply-To: <20100728072319.GU26000@cisco.com> Date: Wed, 28 Jul 2010 00:40:45 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <430696D0-EA0E-438A-B46F-D6DCD00652E0@apple.com> References: <20100728072319.GU26000@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Jul 28, 2010, at 00:23 , Toerless Eckert wrote: > The reason for this is that the largest scope that we specify in this = draft > will influence designers of ip multicast applications that use ASM = multicast. > The worst of such often written applications are using ASM multicast = for > discovery. When these applications are then deployed in other = environments > such as enterprises, they will send out IP multicast packets that will > go across the whole organization, which in the case of an enterprise = could > be worldwide. I don't see the concern. If an enterprise expects their discovery = protocol to be routed over the global scope multicast routing domain, = then they should use global scope multicast addresses to be sure that = IPv6 CPE simple-security will forward it. Otherwise, the fact that CPE = routers enforce organizational scope multicast boundary means that CPE = routers will block those flows from extending into the service provider = routing domain and potentially into networks owned by other subscribers. = If we reduce the scope boundary to site-local, then organizational = scope discovery protocols will be blocked by the organizational boundary = somewhere north of the subscriber gateway. This doesn't strike me as a = desirable outcome. Why do you disagree? -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Wed Jul 28 06:11:14 2010 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 5495B28C17B for ; Wed, 28 Jul 2010 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 YkjKKBLMRepn for ; Wed, 28 Jul 2010 06:11:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 095F528C12F for ; Wed, 28 Jul 2010 06:11:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe6JU-0007pa-6u for v6ops-data0@psg.com; Wed, 28 Jul 2010 13:04:48 +0000 Received: from [2001:fa8:fffe:1000::25] (helo=mail.syce.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe6JR-0007lr-Mt for v6ops@ops.ietf.org; Wed, 28 Jul 2010 13:04:46 +0000 Received: from [130.129.117.183] (mail.syce.net [IPv6:2001:fa8:fffe:1000::25]) by mail.syce.net (8.14.4/8.14.4) with ESMTP/inet6 id o6SD4ePS053719 for ; Wed, 28 Jul 2010 22:04:42 +0900 (JST) (envelope-from kato@syce.net) Date: Wed, 28 Jul 2010 22:04:44 +0900 From: Jun-ya Kato To: v6ops@ops.ietf.org Subject: bar-bof Multihoming with multiple prefixes without NAT66 Message-Id: <20100728220441.4B39.2CE7EC31@syce.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.54 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (mail.syce.net [IPv6:2001:fa8:fffe:1000::25]); Wed, 28 Jul 2010 22:04:42 +0900 (JST) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello all, The place and time is fixed for the bar-bof. http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 We welcome everyone to drop by. 7/28 Wednesday 20:00-21:30 Multihoming with multiple prefixes without NAT66 : Implementation of http://tools.ietf.org/html/draft-troan-multihoming-without-nat66. Live demonstration with running codes related drafts: http://tools.ietf.org/html/draft-troan-multihoming-without-nat66 http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt http://tools.ietf.org/html/draft-dec-dhcpv6-route-option http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection location: 0.8 Rome Contact: Jun-ya Kato -- NTT Information Sharing Platform Laboratories Jun-ya Kato kato@syce.net tel: +81-422-59-2939 fax: +81-422-59-5637 From owner-v6ops@ops.ietf.org Wed Jul 28 06:33:51 2010 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 0BF8328C17C for ; Wed, 28 Jul 2010 06:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 aoZd5fkxCc9V for ; Wed, 28 Jul 2010 06:33:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D7883A6831 for ; Wed, 28 Jul 2010 06:33:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe6kC-000C22-MR for v6ops-data0@psg.com; Wed, 28 Jul 2010 13:32:24 +0000 Received: from [2001:630:d0:f102::25e] (helo=falcon.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oe6k8-000C0V-Va for v6ops@ops.ietf.org; Wed, 28 Jul 2010 13:32:21 +0000 Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6SDVQEb025845; Wed, 28 Jul 2010 14:31:26 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6SDVQEb025845 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1280323886; bh=3eruvqTJIIaUteg7R5YEFuT+vJA=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=oZihJMboNdLdzxW63pPwzroVykYmNFzOPD70MnHROgD8taaAz0P2bIAjo6q24hT57 0wA5D//lmH237fsJPO7P2ZTLNXPDsKwKosCQHQeSLwYFLPcTM2IpeRjDvfoTdpll97 pBhPKwYyGONTAgSvRDYq+yJg7Xw5yoFDmoO+j9KE= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m6REVP0540048226Q9 ret-id none; Wed, 28 Jul 2010 14:31:26 +0100 Received: from dhcp-152-78-61-95.ecs.soton.ac.uk (dhcp-152-78-61-95.ecs.soton.ac.uk [152.78.61.95]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6SDVF2I014256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Jul 2010 14:31:16 +0100 Subject: Re: [MBONED] draft-ietf-v6ops-cpe-simple-security-12.txt feedback Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Chown In-Reply-To: <20100728075127.GY26000@cisco.com> Date: Wed, 28 Jul 2010 14:31:15 +0100 Cc: Fred Baker , IPv6 Operations , mboned@ietf.org, IESG IESG , james woodyatt , Ron Bonica Content-Transfer-Encoding: quoted-printable Message-ID: References: <20100728072319.GU26000@cisco.com> <99F32949-6BAC-472B-B535-F6298D55DC3F@cisco.com> <20100728075127.GY26000@cisco.com> <6CCA639A-C23C-4942-BDBA-130E27BE04E0@ecs.soton.ac.uk> To: Toerless Eckert X-Mailer: Apple Mail (2.1081) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=m6REVP054004822600; tid=m6REVP0540048226Q9; client=relay,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: o6SDVQEb025845 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, I agree that 3.1 REC-2 should say site-local scope is the default for = the context of this draft (CPE devices in homes and small offices). = The provider would most likely use organisation-local to scope multicast = within its whole network. In our campus site-local multicast is constrained by configured router = boundaries within departments and organisation-local scope multicast is = constrained within our campus. But that's a very different, larger = scenario. The terminology is different for unicast where if we used 'site local' = unicast ULAs we would use one /48 ULA for our whole campus. As of yet = we have not felt a need to multi-address (any part of) our campus with = ULAs. Tim On 28 Jul 2010, at 08:51, Toerless Eckert wrote: > For once, the dfraft in question does not differentiate between > unicast site-local and multicast site-local addresses, and i do not > even know if there are unicast orginaizational-local addresses. >=20 > I am only referring to scoped IPv6 multicast group addresses as > defined in RFC4291 section 2.7. IPv6 site-local IP multicast addresses > are just a smaller scope than IPv6 Organizational-Local scope. There > is otherwise no semantic difference between them. >=20 > Routed IP multicast works and can be recommended and should be = included, > i did not contest that. I contested that we do recommend the correct = scope > size in this draft. Organizational-Local is too large, and i think i = explained > the risks. >=20 > Thanks > Toerless >=20 > On Wed, Jul 28, 2010 at 09:40:29AM +0200, Fred Baker wrote: >> I'm copying the IESG, as this document is currently under review in = the IESG. Having been through, literally, years of conversation and = multiple last calls, I'm a little concerned that this request to = reconsider and redraft the recommendations of the specification is = coming so late. >>=20 >> We have had this in review for the past few years, and I for one have = also commented that the only multicast models that we actually have = algorithms to implement are link-local (broadcast on a directly-attached = LAN) and routed IP multicast; this is the reason that the concept of = multi-subnet broadcast was removed from RFC 1716 in the process of = editing into RFC 1812. Organization-local addressing has inexplicably = survived in the IPv6 Addressing Architecture, although the lack of = running code re its routing has been pointed out on numerous occasions. = The argument in the discussion was that since 6man is deluded into = believing that a form of multicast besides link-local and routed exists = and is workable, it should be dealt with. >>=20 >> In my opinion, not as working group chair but as an individual who = knows a little about such things, 6man should either be asked to define = the term ("organization-local multicast is a form of routed multicast in = which administrative boundaries are observed") and demonstrate = algorithms and running code that systemically imposes such boundaries. = Note that RFC 2365 defines administratively scoped multicast for IPv4, = but does not touch on IPv6 and provides no algorithms to deal with the = obvious "security consideration" of a systemic boundary to such routing. >>=20 >> On Jul 28, 2010, at 9:23 AM, Toerless Eckert wrote: >>=20 >>> I would strongly suggest to change the requirement in REC-2 of >>> subject draft to say that the default SHOULD be site-local scope >>> instead of organizational-local scope. >>>=20 >>> The reason for this is that the largest scope that we specify in = this draft >>> will influence designers of ip multicast applications that use ASM = multicast. >>> The worst of such often written applications are using ASM multicast = for >>> discovery. When these applications are then deployed in other = environments >>> such as enterprises, they will send out IP multicast packets that = will >>> go across the whole organization, which in the case of an enterprise = could >>> be worldwide. >>>=20 >>> On the other hand, use of ASM to do this type of discovery = mechanisms >>> in applications, while not preferred by multicast architecture, is=20= >>> perfectly valid for simple applications meant to run in a = residential home. >>>=20 >>> So the best compromise seems to be to recommend the smallest scope = we >>> feel is large enough for a residential (or small business) site, and >>> that would be site-local scope. >>>=20 >>> [ Now if it was for me, i would add the requirement that the scope = must not >>> be larger than site-local scope to be within the bounds of the = drafts >>> recommendations]. >>>=20 >>> I have not followed the draft in detail in before, so if there where = any >>> arguments to recommend organizational scope, it would be nice if = those >>> could be repeated. >>>=20 >>> I have Cc'ed mboned, because my concern is one of multicast = operations, >>> and i am not aware that these considerations where brought up in = front of >>> mboned in before. >>>=20 >>> Thanks >>> Toerless >>=20 >> http://www.ipinc.net/IPv4.GIF >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > "The strategy is what you do, not what you write" - Wesley Clark > "Vision without ressources is hallucination" - James L. Jones >=20 > This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned From v6ops-archive@ietf.org Wed Jul 28 09:21:46 2010 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 154F03A6969 for ; Wed, 28 Jul 2010 09:21:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: 975 VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -32.335 X-Spam-Level: X-Spam-Status: No, score=-32.335 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HS_INDEX_PARAM=0.001, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNSUB38D=0.642, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_WS_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 RarlN74C2eaZ for ; Wed, 28 Jul 2010 09:21:38 -0700 (PDT) Received: from 81.30.221.144.dynamic.ufanet.ru (81.30.221.144.dynamic.ufanet.ru [81.30.221.144]) by core3.amsl.com (Postfix) with SMTP id 333243A68DD for ; Wed, 28 Jul 2010 09:21:37 -0700 (PDT) From: 975 VIAGRA ® Official Site To: v6ops-archive@ietf.org Subject: v6ops-archive@ietf.org VIAGRA ® Official Site 06% 0FF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100728162138.333243A68DD@core3.amsl.com> Date: Wed, 28 Jul 2010 09:21:37 -0700 (PDT)
Please Click here!

For v6ops-archive!
From owner-v6ops@ops.ietf.org Thu Jul 29 15:15:25 2010 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 D00483A6888 for ; Thu, 29 Jul 2010 15:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, 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 QAWi5uR6x0eo for ; Thu, 29 Jul 2010 15:15:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74DA13A67F4 for ; Thu, 29 Jul 2010 15:15:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OebHg-000LBg-Cu for v6ops-data0@psg.com; Thu, 29 Jul 2010 22:09:00 +0000 Received: from [2001:fa8:fffe:1000::25] (helo=mail.syce.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OebHd-000LBI-6E for v6ops@ops.ietf.org; Thu, 29 Jul 2010 22:08:57 +0000 Received: from [212.238.38.232] (mail.syce.net [IPv6:2001:fa8:fffe:1000::25]) by mail.syce.net (8.14.4/8.14.4) with ESMTP/inet6 id o6TM8rs5075178 for ; Fri, 30 Jul 2010 07:08:54 +0900 (JST) (envelope-from kato@syce.net) Date: Fri, 30 Jul 2010 07:08:58 +0900 From: Jun-ya Kato To: v6ops@ops.ietf.org Subject: Re: bar-bof Multihoming with multiple prefixes without NAT66 In-Reply-To: <20100728220441.4B39.2CE7EC31@syce.net> References: <20100728220441.4B39.2CE7EC31@syce.net> Message-Id: <20100730070856.2CF7.2CE7EC31@syce.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.54 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (mail.syce.net [IPv6:2001:fa8:fffe:1000::25]); Fri, 30 Jul 2010 07:08:55 +0900 (JST) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello all, I'm glad that many people had worth discussion at Wednesday demonstration regarding to multihoming with multiple prefixes. I'd like to thank all participants. Related drafts and other all matrials are available from http://wiki.github.com/otroan/IETF-Non-Congruent-Multi-homing/ Regards, -- NTT Information Sharing Platform Laboratories Jun-ya Kato kato@syce.net tel: +81-422-59-2939 fax: +81-422-59-5637 > Hello all, > > The place and time is fixed for the bar-bof. > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > We welcome everyone to drop by. > > 7/28 Wednesday 20:00-21:30 > Multihoming with multiple prefixes without NAT66 : Implementation of > http://tools.ietf.org/html/draft-troan-multihoming-without-nat66. Live > demonstration with running codes > related drafts: > http://tools.ietf.org/html/draft-troan-multihoming-without-nat66 > http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt > http://tools.ietf.org/html/draft-dec-dhcpv6-route-option > http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection > location: 0.8 Rome > Contact: Jun-ya Kato > > > -- > NTT Information Sharing Platform Laboratories > Jun-ya Kato > kato@syce.net > tel: +81-422-59-2939 > fax: +81-422-59-5637 > > From owner-v6ops@ops.ietf.org Fri Jul 30 23:01:09 2010 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 EA84C3A6937 for ; Fri, 30 Jul 2010 23:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.253 X-Spam-Level: X-Spam-Status: No, score=-109.253 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 lF+KdD5gK-u5 for ; Fri, 30 Jul 2010 23:01:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D71763A684C for ; Fri, 30 Jul 2010 23:01:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Of51m-000IAO-Ah for v6ops-data0@psg.com; Sat, 31 Jul 2010 05:54:34 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Of51i-000I9s-NH for v6ops@ops.ietf.org; Sat, 31 Jul 2010 05:54:31 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFACZXU0xAZnwN/2dsb2JhbACBRJ5icaRnmwuFOQSIfw X-IronPort-AV: E=Sophos;i="4.55,290,1278288000"; d="scan'208,217";a="141616379" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2010 05:54:29 +0000 Received: from [192.168.1.7] (dhcp-10-61-108-123.cisco.com [10.61.108.123]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6V5sRu8008661; Sat, 31 Jul 2010 05:54:28 GMT From: Fred Baker Content-Type: multipart/alternative; boundary=Apple-Mail-63--546726614 Subject: draft-gundavelli-v6ops-l2-unicast WGLC Date: Sat, 31 Jul 2010 07:54:27 +0200 Message-Id: <392017B9-C173-4A53-99E7-6FFF8BB24FEB@cisco.com> Cc: Kurt Erik Lindqvist , Ron Bonica To: IPv6 Operations , 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-63--546726614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week working group last call of = draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the combined lists. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= --Apple-Mail-63--546726614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a two week working = group last call of draft-gundavelli-v6ops-l2-unicast. Please read it = now. If you find nits (spelling errors, minor suggested wording changes, = etc), comment to the authors; if you find greater issues, such as = disagreeing with a statement or finding additional issues that need to = be addressed, please post your comments to the combined = lists.

We are looking specifically for comments on the = importance of the document as well as its content. If you have read the = document and believe it to be of operational utility, that is also an = important comment to make.
= --Apple-Mail-63--546726614-- From owner-v6ops@ops.ietf.org Sat Jul 31 18:15:08 2010 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 A983C3A6AB9 for ; Sat, 31 Jul 2010 18:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, 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 CmceL3Mlo3Dt for ; Sat, 31 Jul 2010 18:15:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 746573A6AB8 for ; Sat, 31 Jul 2010 18:15:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OfN3W-000Dtq-2k for v6ops-data0@psg.com; Sun, 01 Aug 2010 01:09:34 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OfN3T-000DtJ-5g for v6ops@ops.ietf.org; Sun, 01 Aug 2010 01:09:31 +0000 Received: from 114-30-99-20.ip.adam.com.au ([114.30.99.20] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1OfN35-0003Pt-Kk; Sun, 01 Aug 2010 10:39:07 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id EAD703B31E; Sun, 1 Aug 2010 10:40:25 +0930 (CST) Date: Sun, 1 Aug 2010 10:40:25 +0930 From: Mark Smith To: Fred Baker Cc: IPv6 Operations , 6man Mailing List , Kurt Erik Lindqvist , Ron Bonica Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC Message-ID: <20100801104025.7d43531e@opy.nosense.org> In-Reply-To: <392017B9-C173-4A53-99E7-6FFF8BB24FEB@cisco.com> References: <392017B9-C173-4A53-99E7-6FFF8BB24FEB@cisco.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Sat, 31 Jul 2010 07:54:27 +0200 Fred Baker wrote: > This is to initiate a two week working group last call of draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the combined lists. > > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. I think the Introduction is too long, as it also seems to be covering some of the use cases in a bit more detail than an Introduction normally would. I think the Introduction could probably just be the first paragraph with a bit of rewording. Conversely, I think the use cases detail is a bit lacking, possibly because they've been put in the Introduction. For example, I don't really understand this use case (part of the second paragraph of the Introduction) For example, an 802.11 wireless access point may be hosting multiple IPv6 subnets/VLAN's and it would need the ability to selectively advertise hosted IPv6 prefixes on a per-node basis. Such segregation can only be possible by ensuring the Router Advertisements received by any IPv6 node includes only those prefixes that are associated with their respective layer-3 subnet. This essentially requires the ability to transmit IPv6 multicast messages as unicast messages on the link-layer. It sounds to me that what is being attempted here is to, instead of dividing up nodes into groups via VLANs at layer 2, selective layer 2 unicast of multicast layer 3 is used instead. Is this the case? If it is the case, does this impact things like IPv6 redirect operation or neighbor discovery? Would an NBMA model of link layer operation be a more way of solving this problem? Is it somehow related to SAVI? Or maybe an attempt to achieve the goals of SeND without implementing cryto etc.? I'm also a bit confused by the ISATAP example, "Another such example where this semantic is needed is in ISATAP [RFC5214] for sending a unicast Router Advertisement message on ISTAP interfaces. " As RAs are allowed to have layer 3 unicast destination address, I'd have assumed that a corresponding layer 2 unicast destination address is also valid. The above text, in the context of this draft, seems to suggest to me that this isn't the case. As this draft is changing what has been a fundamental and fixed assumption for a very long time (i.e. layer 3 multicast always equals layer 2 multicast), I think it's important that use cases supporting it are very clear in what they're trying to achieve and why allowing multicast layer 3 addresses maps to layer 2 unicast is the best way to solve those problems. A bit more detail in these use cases would help. Regards, Mark.