From owner-v6ops@ops.ietf.org Thu Oct 1 04:30:46 2009 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 C4B503A67F3 for ; Thu, 1 Oct 2009 04:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYdykumaaBFg for ; Thu, 1 Oct 2009 04:30:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9B293A6800 for ; Thu, 1 Oct 2009 04:30:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJnk-000G6J-I4 for v6ops-data0@psg.com; Thu, 01 Oct 2009 11:26:24 +0000 Received: from [2001:610:140:2202:230:48ff:fe29:44a6] (helo=betonmix.noc.ams-ix.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJna-000G5K-Pz for v6ops@ops.ietf.org; Thu, 01 Oct 2009 11:26:22 +0000 Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 1DCF8FA868; Thu, 1 Oct 2009 13:26:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from betonmix.noc.ams-ix.net ([127.0.0.1]) by localhost (betonmix.noc.ams-ix.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iABV-dc9X-kX; Thu, 1 Oct 2009 13:26:12 +0200 (CEST) Received: from fizzix (miraculix.noc.ams-ix.net [IPv6:2001:7b8:200:120::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id DFDB6FA866; Thu, 1 Oct 2009 13:26:12 +0200 (CEST) Date: Thu, 1 Oct 2009 13:25:45 +0200 From: Martin Pels To: Roque Gagliano Cc: v6ops WG Subject: Re: comments on draft-ietf-v6ops-v6inixp-01.txt Message-ID: <20091001132545.25ceccc6@fizzix> In-Reply-To: References: <4A6EE42A.7020809@inex.ie> <4A702AFD.6040803@inex.ie> <20090730175043.14100900@fizzix> <4A81634A.2010301@inex.ie> <20090825135028.08f2b1a9@fizzix> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i486-pc-linux-gnu) 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: Hi Roque, On Fri, 28 Aug 2009 15:31:42 -0300 Roque Gagliano wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > martin, > > this is excellent material, not only for the IXP document but also > on how ND is handled in practice. > > referring to the next version of the document, I was thinking in add > the following comment when I talk about solicited-node multicast > addresses: > > solicited-node multicast groups. > > "Depending on the addressing plan selected by the IXP, each > solocited- node multicast group may be shared by a sub-set of > participants' caused by how the last three octects of the addresses > are selected. In example 1 in Section 3, only participants with ASNs > with the same two last digits are going to share the same > solocited-node multicast group." > > However, your test show that it may not make a difference in router > resources consumption, depending on implementations. > > what do you think? > The added text looks good to me, except for a small typo in the last sentence (you write solocited-node, instead of solicited-node). Kind regards, Martin From owner-v6ops@ops.ietf.org Thu Oct 1 04:54:23 2009 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 1EDF33A6A39 for ; Thu, 1 Oct 2009 04:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrc0ngyQXlgW for ; Thu, 1 Oct 2009 04:54:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EDD33A6A19 for ; Thu, 1 Oct 2009 04:54:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtKEV-000MgB-EQ for v6ops-data0@psg.com; Thu, 01 Oct 2009 11:54:03 +0000 Received: from [2001:610:140:2202:230:48ff:fe29:44a6] (helo=betonmix.noc.ams-ix.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtKEK-000MfD-I9 for v6ops@ops.ietf.org; Thu, 01 Oct 2009 11:54:00 +0000 Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 13426FA868; Thu, 1 Oct 2009 13:53:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from betonmix.noc.ams-ix.net ([127.0.0.1]) by localhost (betonmix.noc.ams-ix.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uQCq1plWQakS; Thu, 1 Oct 2009 13:53:50 +0200 (CEST) Received: from fizzix (miraculix.noc.ams-ix.net [IPv6:2001:610:140:120::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id D13B4FA863; Thu, 1 Oct 2009 13:53:50 +0200 (CEST) Date: Thu, 1 Oct 2009 13:53:23 +0200 From: Martin Pels To: Roque Gagliano Cc: v6ops WG Subject: Re: Fwd: New Version Notification for draft-ietf-v6ops-v6inixp-02 Message-ID: <20091001135323.0c574feb@fizzix> In-Reply-To: References: <20090909020014.0D00128C1DA@core3.amsl.com> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i486-pc-linux-gnu) 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: Hi, On Tue, 8 Sep 2009 23:25:37 -0300 Roque Gagliano wrote: > Hi, > > I issued a new ID of the draft with the changes that came up at the > Stockholm meeting. Changes were: > - I explained why ULA is not a good idea. > - I added that addressing can use two different /48, one for the > LANs and the second one for the internal services and not necessarily > one / 47, as comments at the meeting. In section 3 you added the following: "IPv6 prefixes for IXP LAN's are typically publicly well known.". I suggest changing this to something like: "IPv6 prefixes for IXP LANs are typically taken from dedicated IPv6 blocks for IXP assignments, reserved for this purpose by the different RIRs." Kind regards, Martin From owner-v6ops@ops.ietf.org Thu Oct 1 06:55:55 2009 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 41FAA3A696A for ; Thu, 1 Oct 2009 06:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opVnpfZeAFMw for ; Thu, 1 Oct 2009 06:55:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CAC223A6821 for ; Thu, 1 Oct 2009 06:55:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtM60-0004lN-N8 for v6ops-data0@psg.com; Thu, 01 Oct 2009 13:53:24 +0000 Received: from web45507.mail.sp1.yahoo.com ([68.180.197.107]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtM5o-0004e4-VB for v6ops@ops.ietf.org; Thu, 01 Oct 2009 13:53:21 +0000 Received: (qmail 31901 invoked by uid 60001); 1 Oct 2009 13:53:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254405190; bh=XA0JmI0Zhz0GvfK4AaTKkxbmXcwdRXktx9A3ETHrfV8=; 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=1fzHDN56annJ8fjRYAk2zqG9f2R69BNbs9g6lCjJFg96epoJoqhWUGKqZ6Jt+3ZmgbSsTDtYcHix/giVENXch3vjANxDUXcRBo7IlZBkHcpIyItT9Q0A83XTaV85rb/9S8LVsTZIod1WewStxFv/sujIILbOFAhQlS2mv65Zcqg= 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=0hTJMPxyLuUdourF7QA9mnwafjZv4yXoH/hIuiH8LAjHJJsYKMSqcmjNS2bSaqrzQr+VodkI70eHSmdbyM9ntfCccoJbsymDdp815Dz15nLYPv+4ynlXgfxxAMCiPBmplci4JnYoBuRb089K2J1zxYTweMpqnuSctF50Al9Wltw=; Message-ID: <841274.31511.qm@web45507.mail.sp1.yahoo.com> X-YMail-OSG: qjLyRQQVM1nj7S0SpYYmLFe1CTsbXt6xLWmB6iUzCsmwNkdHBqv6BCkIzN027OvQoBJYWO0Ey1aH6ztmtcJkbt9y84PoaBYUPbK.tFBpD2EcI0FhGijRDrwA8LfrS_KQ1jfg.Rv5xZsA.pYH5s9WEFpSRqtQZQz0Bey45fFbT0ziXvCx_8s6KD2sevX1KtxjTL6eliKKu8nvtwoqcV7kbIuma__OAQedyW_7kwwhvXiGs6YbHXB5MXgltUX4FWzlcL8_w9zFyvAmCsFY9QJiYZ8wzSdb Received: from [93.173.149.243] by web45507.mail.sp1.yahoo.com via HTTP; Thu, 01 Oct 2009 06:53:10 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> Date: Thu, 1 Oct 2009 06:53:10 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" Cc: v6ops In-Reply-To: <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.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: Removed the 6man and secdir=A0mailing lists from the Cc.=0A=0AFred, see com= ments below.=0A=0A----- Original Message ----=0A> From: "Templin, Fred L" <= Fred.L.Templin@boeing.com>=0A> To: Gabi Nakibly ; Chris= tian Huitema ; v6ops =0A> Cc: "i= pv6@ietf.org" ; "secdir@ietf.org" =0A> Sent= : Tuesday, September 29, 2009 6:00:55 PM=0A> Subject: RE: Routing loop atta= cks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> Welcome back from your vacat= ion. I trimmed quite a bit from=0A> the bottom of this message to eliminate= the clutter, but see=0A> below for responses to your current comments:=0A>= =0A> > -----Original Message-----=0A> > From: Gabi Nakibly [mailto:gnakibl= y@yahoo.com]=0A> > Sent: Tuesday, September 29, 2009 3:22 AM=0A> > To: Temp= lin, Fred L; Christian Huitema; v6ops=0A> > Cc: ipv6@ietf.org; secdir@ietf.= org=0A> > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > =0A> >= Hi Fred,=0A> > Back from vacation. See Comments inlines.=0A> > =0A> > Gabi= =0A> > =0A> > =0A> > =0A> > ----- Original Message ----=0A> > > From: "Temp= lin, Fred L" =0A> > > To: Gabi Nakibly ; Christian Huitema =0A> ; v6ops=0A>= > =0A> > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Sent: Friday, Septem= ber 11, 2009 11:13:44 PM=0A> > > Subject: RE: Routing loop attacks using IP= v6 tunnels=0A> > >=0A> > > Hi Gabi,=0A> > >=0A> > > > -----Original Message= -----=0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Se= nt: Friday, September 11, 2009 12:59 PM=0A> > > > To: Templin, Fred L; Chri= stian Huitema; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > >= Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > > > H= i Fred,=0A> > > > See below.=0A> > > >=0A> > > > Gabi=0A> > > >=0A> > > >= =0A> > > >=0A> > > > ----- Original Message ----=0A> > > > > From: "Templin= , Fred L"=0A> > > > > To: Gabi Nakibly ; Christian Huitema=0A> > > ; v6ops= =0A> > > >=0A> > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > Sent:= Tuesday, September 8, 2009 8:37:03 PM=0A> > > > > Subject: RE: Routing loo= p attacks using IPv6 tunnels=0A> > > > >=0A> > > > > Gabi and Christian,=0A= > > > > >=0A> > > > > Focusing only on attack #3 (i.e., leaving out attack = #1=0A> > > > > and #2 6to4 interactions for the moment), please check=0A> >= > > > the following summary of proposed mitigations:=0A> > > > >=0A> > > >= > 1) For ISATAP/VET routers that have assurance that their=0A> > > > > nei= ghbor cache is coherent, the router can make a simple=0A> > > > > check in = the neighbor cache to determine whether to=0A> > > > > forward or drop the = packet. In pseudo-code:=0A> > > > >=0A> > > > > =A0 isatap_rcv() {=0A> > > = > > =A0 =A0 ...=0A> > > > > =A0 =A0 if ((v6src is not a neighbor) && (v6dst= !=3D "fe80::*"))=0A> > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > =A0 =A0 .= ..=0A> > > > > =A0 }=0A> > > > >=0A> > > > > =A0 isatap_xmt() {=0A> > > > >= =A0 =A0 ...=0A> > > > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src != =3D "fe80::*"))=0A> > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > =A0 =A0 ...= =0A> > > > > =A0 }=0A> > > > >=0A> > > > > (Here, the link-local exception = is necessary to bootstrap=0A> > > > > neighbor discovery on the ISATAP link= .)=0A> > > > >=0A> > > > > Does anyone see a problem with this?=0A> > > > >= =0A> > > > Looks fine.=0A> > >=0A> > > OK.=0A> > >=0A> > =0A> > On second t= hought, a couple of comments:=0A> > 1) According to RFC 5214 Section 8.3.4:= =0A> > =A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY schedule periodic Router Sol= icitation events=0A> > =A0=A0 =A0=A0=A0 for certain PRL(i)s by setting the = corresponding TIMER(i)."=0A> > As I understand, this means that there is a = possibility for a host=A0not to=A0send =0A> RSs to all routers in=0A> > the= PRL. However, any router in the PRL may forward packets into the ISATAP = =0A> link. The isatap_xmt()=0A> > check will prevent forwarding packets by = routers which the destination=A0has not =0A> previously sent RS to.=0A> > I= f I am correct then this check=A0may break ISATAP connectivity.=0A> =0A> I = don't think this is a problem. If a host has not sent an RS to=0A> a PRL ro= uter, then it should not have configured a default route=0A> nor any prefix= information specific to that router. Therefore,=0A> the only packets the h= ost and router should expect to exchange=0A> in this state are link-local. = As such, the router can discard=0A> non-link-local packets if there is no n= eighbor cache entry. =0A> =0A=0AI was thinking=A0of a case of two routers i= n the PRL advertising the same prefix for the ISATAP link.=A0Either routers= obviously may forward packets _into_ the ISATAP link to any host. If a hos= t=A0will not send=A0a RS to one of those routers=A0then=A0it will drop pack= ets destined to that host.=0A=0A> > 2) I remind you a comment you made in t= he past: for the checks to work=A0the =0A> time between two=0A> > consequti= ve RSs from a host to a=A0router should be no greater than the the =0A> lif= etime of an entry for=0A> > that host in the router's neighbors cache.=A0Th= is is needed=A0to ensure that=A0the =0A> entry in the neighbors=0A> > cache= will not be erased. This raises two questions:=0A> > =A0=A0=A0 a) AFAIK th= ere is no minimum lifetime for an entry in a neighbors cache =0A> -=A0it is= an implementation=0A> > detail.=A0If this is true=A0how can we enforce the= above constraint?=0A> =0A> Correct that there is no minimum lifetime for n= eighbor cache=0A> entries specified by RFC4861. However, an ISATAP router t= hat=0A> uses the neighbor cache checking procedures I have described=0A> ca= n use its own discipline for managing its neighbor cache.=0A> Exactly such = a discipline is now specified in Section 5.4.1=0A> of 'draft-templin-intare= a-vet'. Please be aware that ISATAP=0A> and VET are simply "IPv6-over-(foo)= " specifications, and=0A> RFC4861 permits that operations of the neighbor d= iscovery=0A> protocol that are specific to (foo) links may be specified=0A>= in such documents.=0A> =0A=0AOK.=0A=0A> > =A0=A0=A0 b) A router's neighbor= s cache=A0must now=A0include at any given moment all the =0A> active ISATAP= nodes in=0A> > the ISATAP link. Is this a reasonable demand?=0A> =0A> Memo= ry should be cheap enough, and ISATAP links within private=0A> addressing r= ealms should be small enough, that I do not see this=0A> as an unreasonable= demand.=0A> =0A=0AOK.=0A=0A> > > > > 2) For ISATAP/VET routers that use pu= blic IPv4 addresses=0A> > > > > and that do not have assurance that their n= eighbor cache=0A> > > > > is coherent, the router can check for the interfa= ce ID=0A> > > > > "0200:5EFE:". In pseudo-code:=0A> > > > >=0A> > > > > =A0= isatap_rcv() {=0A> > > > > =A0 =A0 ...=0A> > > > > =A0 =A0 if (v6dst =3D= =3D "foreign_prefix::0200:5efe:")=0A> > > > > =A0 =A0 =A0 drop_pkt();=0A> >= > > > =A0 =A0 ...=0A> > > > > =A0 }=0A> > > > >=0A> > > > > =A0 isatap_xmt= () {=0A> > > > > =A0 =A0 ...=0A> > > > > =A0 =A0 if (v6src =3D=3D "foreign_= prefix::0200:5efe:")=0A> > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > =A0 = =A0 ...=0A> > > > > =A0 }=0A> > > > >=0A> > > > > Does anyone see a problem= with this?=0A> > > >=0A> > > > Looks fine.=0A> > >=0A> > > OK, but since I= sent this I began to wonder whether cases=0A> > > 1) and 2) should be reve= rsed (i.e., do the 0x00:5EFE check=0A> > > first). I came to believe that i= t almost doesn't matter=0A> > > from a performance standpoint, and perhaps = should be left=0A> > > up to the implementer. Do you have an opinion on thi= s?=0A> > >=0A> > > > > 3) For ISATAP/VET routers that use private IPv4 addr= esses=0A> > > > > and that do not have assurance that their neighbor cache= =0A> > > > > is coherent, the router can make the checks that Christian=0A>= > > > > has proposed. But, will we see any of these case 3)=0A> > > > > si= tuations in operational practice?=0A> > > > >=0A> > > >=0A> > > > I can not= tell for sure. Why this case seems to you less plausible than =0A> case=0A= > > > 2?=0A> > >=0A> > > Case 3) is the case in which source address spoofi= ng within=0A> > > a private IPv4 addressing range is possible. It seems to = me=0A> > > that it may correspond to either a poorly managed deployment,=0A= > > > or one in which there are multiple administrative authorities=0A> > >= with diverse policies and operational practices.=0A> > >=0A> > =0A> > I ag= ree. However, remember that the spoofed packet may also originate from =0A>= within the site, which is=0A> > very hard to defend against.=0A> =0A> Spoo= fing is not so hard to defend against if Secure Neighbor=0A> Discovery (SEN= D) is used to set up the neighbor relationships=0A> and if every packet car= ries a nonce that can be used to detect=0A> an off-path attack. =0A=0AI agr= ee again. I was referring to the case where SEND is not deployed.=0A=0A> Th= at is only the case for VET and SEAL,=0A> however, so if source address spo= ofing within the site is seen=0A> as a problem then VET and SEAL should be = used instead of ISATAP.=0A> =0A> Note that for the sake of consistency it m= ight be helpful to=0A> consider VET as simply "ISATAP version 2 (ISATAPv2)"= .=0A> =0A> Fred=0A> fred.l.templin@boeing.com=A0 =0A> =0A> > > The checks t= hat Christian proposed could be used for this=0A> > > scenario if possible.= Otherwise, the best solution IMHO=0A> > > would be to allow only routers (= and not hosts) on the=0A> > > virtual links. This final model would be best= addressed=0A> > > by VET and SEAL rather than ISATAP.=0A> > >=0A> > > Than= ks - Fred=0A> > > fred.l.templin@boeing.com=0A=0A__________________________= ________________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has= the best spam protection around =0Ahttp://mail.yahoo.com From owner-v6ops@ops.ietf.org Thu Oct 1 09:53:26 2009 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 EE90F28C184 for ; Thu, 1 Oct 2009 09:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyz7Y83vLnvB for ; Thu, 1 Oct 2009 09:53:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E8B93A6A7A for ; Thu, 1 Oct 2009 09:53:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtOqw-0009wz-A5 for v6ops-data0@psg.com; Thu, 01 Oct 2009 16:50:02 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtOqV-0009t6-I0 for v6ops@ops.ietf.org; Thu, 01 Oct 2009 16:49:48 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n91GnYDX029495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2009 09:49:34 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n91GnXKA027685; Thu, 1 Oct 2009 09:49:33 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n91GnXjX027668 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Oct 2009 09:49:33 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Thu, 1 Oct 2009 09:49:33 -0700 From: "Templin, Fred L" To: Gabi Nakibly CC: v6ops Date: Thu, 1 Oct 2009 09:49:31 -0700 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcpCnoSwo9uycJ3GTtabN/NYJI8ASAAFwglw Message-ID: <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> In-Reply-To: <841274.31511.qm@web45507.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: Hi Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Thursday, October 01, 2009 6:53 AM > To: Templin, Fred L > Cc: v6ops > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Removed the 6man and secdir=A0mailing lists from the Cc. >=20 > Fred, see comments below. >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; Christian Huitema ; v6ops > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" > > Sent: Tuesday, September 29, 2009 6:00:55 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > Welcome back from your vacation. I trimmed quite a bit from > > the bottom of this message to eliminate the clutter, but see > > below for responses to your current comments: > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Tuesday, September 29, 2009 3:22 AM > > > To: Templin, Fred L; Christian Huitema; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Hi Fred, > > > Back from vacation. See Comments inlines. > > > > > > Gabi > > > > > > > > > > > > ----- Original Message ---- > > > > From: "Templin, Fred L" > > > > To: Gabi Nakibly ; Christian Huitema > > ; v6ops > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > Sent: Friday, September 11, 2009 11:13:44 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Hi Gabi, > > > > > > > > > -----Original Message----- > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > Sent: Friday, September 11, 2009 12:59 PM > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > Hi Fred, > > > > > See below. > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > From: "Templin, Fred L" > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > ; v6ops > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > Sent: Tuesday, September 8, 2009 8:37:03 PM > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > Gabi and Christian, > > > > > > > > > > > > Focusing only on attack #3 (i.e., leaving out attack #1 > > > > > > and #2 6to4 interactions for the moment), please check > > > > > > the following summary of proposed mitigations: > > > > > > > > > > > > 1) For ISATAP/VET routers that have assurance that their > > > > > > neighbor cache is coherent, the router can make a simple > > > > > > check in the neighbor cache to determine whether to > > > > > > forward or drop the packet. In pseudo-code: > > > > > > > > > > > > =A0 isatap_rcv() { > > > > > > =A0 =A0 ... > > > > > > =A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*")= ) > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > =A0 =A0 ... > > > > > > =A0 } > > > > > > > > > > > > =A0 isatap_xmt() { > > > > > > =A0 =A0 ... > > > > > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src !=3D "fe80::*")= ) > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > =A0 =A0 ... > > > > > > =A0 } > > > > > > > > > > > > (Here, the link-local exception is necessary to bootstrap > > > > > > neighbor discovery on the ISATAP link.) > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > Looks fine. > > > > > > > > OK. > > > > > > > > > > On second thought, a couple of comments: > > > 1) According to RFC 5214 Section 8.3.4: > > > =A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY schedule periodic Router Soli= citation events > > > =A0=A0 =A0=A0=A0 for certain PRL(i)s by setting the corresponding TIM= ER(i)." > > > As I understand, this means that there is a possibility for a host=A0= not to=A0send > > RSs to all routers in > > > the PRL. However, any router in the PRL may forward packets into the = ISATAP > > link. The isatap_xmt() > > > check will prevent forwarding packets by routers which the destinatio= n=A0has not > > previously sent RS to. > > > If I am correct then this check=A0may break ISATAP connectivity. > > > > I don't think this is a problem. If a host has not sent an RS to > > a PRL router, then it should not have configured a default route > > nor any prefix information specific to that router. Therefore, > > the only packets the host and router should expect to exchange > > in this state are link-local. As such, the router can discard > > non-link-local packets if there is no neighbor cache entry. > > >=20 > I was thinking=A0of a case of two routers in the PRL advertising the same= prefix for the ISATAP > link.=A0Either routers obviously may forward packets _into_ the ISATAP li= nk to any host. If a host=A0will > not send=A0a RS to one of those routers=A0then=A0it will drop packets des= tined to that host. I'm actually OK with that. If two routers A and B advertise the same prefix P, and if B doesn't know about host H either through receiving RSs or through talking to A, then B should not forward packets to H. Thanks - Fred fred.l.templin@boeing.com=20 > > > 2) I remind you a comment you made in the past: for the checks to wor= k=A0the > > time between two > > > consequtive RSs from a host to a=A0router should be no greater than t= he the > > lifetime of an entry for > > > that host in the router's neighbors cache.=A0This is needed=A0to ensu= re that=A0the > > entry in the neighbors > > > cache will not be erased. This raises two questions: > > > =A0=A0=A0 a) AFAIK there is no minimum lifetime for an entry in a nei= ghbors cache > > -=A0it is an implementation > > > detail.=A0If this is true=A0how can we enforce the above constraint? > > > > Correct that there is no minimum lifetime for neighbor cache > > entries specified by RFC4861. However, an ISATAP router that > > uses the neighbor cache checking procedures I have described > > can use its own discipline for managing its neighbor cache. > > Exactly such a discipline is now specified in Section 5.4.1 > > of 'draft-templin-intarea-vet'. Please be aware that ISATAP > > and VET are simply "IPv6-over-(foo)" specifications, and > > RFC4861 permits that operations of the neighbor discovery > > protocol that are specific to (foo) links may be specified > > in such documents. > > >=20 > OK. >=20 > > > =A0=A0=A0 b) A router's neighbors cache=A0must now=A0include at any g= iven moment all the > > active ISATAP nodes in > > > the ISATAP link. Is this a reasonable demand? > > > > Memory should be cheap enough, and ISATAP links within private > > addressing realms should be small enough, that I do not see this > > as an unreasonable demand. > > >=20 > OK. >=20 > > > > > > 2) For ISATAP/VET routers that use public IPv4 addresses > > > > > > and that do not have assurance that their neighbor cache > > > > > > is coherent, the router can check for the interface ID > > > > > > "0200:5EFE:". In pseudo-code: > > > > > > > > > > > > =A0 isatap_rcv() { > > > > > > =A0 =A0 ... > > > > > > =A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:") > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > =A0 =A0 ... > > > > > > =A0 } > > > > > > > > > > > > =A0 isatap_xmt() { > > > > > > =A0 =A0 ... > > > > > > =A0 =A0 if (v6src =3D=3D "foreign_prefix::0200:5efe:") > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > =A0 =A0 ... > > > > > > =A0 } > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > Looks fine. > > > > > > > > OK, but since I sent this I began to wonder whether cases > > > > 1) and 2) should be reversed (i.e., do the 0x00:5EFE check > > > > first). I came to believe that it almost doesn't matter > > > > from a performance standpoint, and perhaps should be left > > > > up to the implementer. Do you have an opinion on this? > > > > > > > > > > 3) For ISATAP/VET routers that use private IPv4 addresses > > > > > > and that do not have assurance that their neighbor cache > > > > > > is coherent, the router can make the checks that Christian > > > > > > has proposed. But, will we see any of these case 3) > > > > > > situations in operational practice? > > > > > > > > > > > > > > > > I can not tell for sure. Why this case seems to you less plausibl= e than > > case > > > > 2? > > > > > > > > Case 3) is the case in which source address spoofing within > > > > a private IPv4 addressing range is possible. It seems to me > > > > that it may correspond to either a poorly managed deployment, > > > > or one in which there are multiple administrative authorities > > > > with diverse policies and operational practices. > > > > > > > > > > I agree. However, remember that the spoofed packet may also originate= from > > within the site, which is > > > very hard to defend against. > > > > Spoofing is not so hard to defend against if Secure Neighbor > > Discovery (SEND) is used to set up the neighbor relationships > > and if every packet carries a nonce that can be used to detect > > an off-path attack. >=20 > I agree again. I was referring to the case where SEND is not deployed. >=20 > > That is only the case for VET and SEAL, > > however, so if source address spoofing within the site is seen > > as a problem then VET and SEAL should be used instead of ISATAP. > > > > Note that for the sake of consistency it might be helpful to > > consider VET as simply "ISATAP version 2 (ISATAPv2)". > > > > Fred > > fred.l.templin@boeing.com > > > > > > The checks that Christian proposed could be used for this > > > > scenario if possible. Otherwise, the best solution IMHO > > > > would be to allow only routers (and not hosts) on the > > > > virtual links. This final model would be best addressed > > > > by VET and SEAL rather than ISATAP. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From owner-v6ops@ops.ietf.org Fri Oct 2 02:06:19 2009 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 559C53A6935 for ; Fri, 2 Oct 2009 02:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[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 H8PNbtV2-quO for ; Fri, 2 Oct 2009 02:06:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4781D3A68E9 for ; Fri, 2 Oct 2009 02:06:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mte2R-0006Ip-H8 for v6ops-data0@psg.com; Fri, 02 Oct 2009 09:02:55 +0000 Received: from [210.171.225.78] (helo=mx20.jpix.ad.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mte2I-0006Hu-0m for v6ops@ops.ietf.org; Fri, 02 Oct 2009 09:02:53 +0000 Received: from [10.10.31.173] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id C14A3FC012; Fri, 2 Oct 2009 18:02:44 +0900 (JST) Date: Fri, 02 Oct 2009 18:02:44 +0900 From: MAWATARI Masataka To: v6ops@ops.ietf.org Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Cc: martin.pels@ams-ix.net, roque@lacnic.net In-Reply-To: <20091001135323.0c574feb@fizzix> References: <20091001135323.0c574feb@fizzix> Message-Id: <20091002180244.E48A.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi all, * On Thu, 1 Oct 2009 13:53:23 +0200 * Martin Pels wrote: > Hi, > > On Tue, 8 Sep 2009 23:25:37 -0300 > Roque Gagliano wrote: > > > Hi, > > > > I issued a new ID of the draft with the changes that came up at the > > Stockholm meeting. Changes were: > > - I explained why ULA is not a good idea. > > - I added that addressing can use two different /48, one for the > > LANs and the second one for the internal services and not necessarily > > one / 47, as comments at the meeting. > > In section 3 you added the following: "IPv6 prefixes for IXP LAN's are > typically publicly well known.". > > I suggest changing this to something like: "IPv6 prefixes for IXP LANs > are typically taken from dedicated IPv6 blocks for IXP assignments, > reserved for this purpose by the different RIRs." Thanks for your effort about IPv6 IXP operation. If modifying as above, add notions that IXP can select PI address policy either routed or un-routed in the global table. (routed) pros - AS boundry monitoring IXP segment is possible. cons - Attacking IXP segment from non IXP participants is possible. (un-routed) pros - Attacking IXP segment from non IXP participants is impossible. cons - AS boundry monitoring IXP segment is impossible. Are there any other pros/cons? Regards, Masataka MAWATARI From mail@3wstudio.com Fri Oct 2 05:21:25 2009 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 1DEF928C0F9 for ; Fri, 2 Oct 2009 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.585 X-Spam-Level: X-Spam-Status: No, score=-26.585 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_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, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk90N0XNDU2S for ; Fri, 2 Oct 2009 05:21:24 -0700 (PDT) Received: from 84.123.171.20.dyn.user.ono.com (84.123.171.20.dyn.user.ono.com [84.123.171.20]) by core3.amsl.com (Postfix) with SMTP id 2720128C0D9 for ; Fri, 2 Oct 2009 05:21:18 -0700 (PDT) To: Subject: Hi From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091002122121.2720128C0D9@core3.amsl.com> Date: Fri, 2 Oct 2009 05:21:18 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.waitname.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://waitname.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 5, B889. 611 Clements Road. London. SE26 2DG

© 2009 AMAZON, Ltd. All Rights Reserved

From ncej@ama-assn.org Fri Oct 2 22:59:50 2009 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 3895B3A68EA for ; Fri, 2 Oct 2009 22:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.934 X-Spam-Level: X-Spam-Status: No, score=-10.934 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 bFr7ODrxOA6E for ; Fri, 2 Oct 2009 22:59:43 -0700 (PDT) Received: from andyhoffmann.de (unknown [187.15.77.249]) by core3.amsl.com (Postfix) with SMTP id 7B34C3A68A7 for ; Fri, 2 Oct 2009 22:59:37 -0700 (PDT) To: Subject: Invoice from itunes.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091003055939.7B34C3A68A7@core3.amsl.com> Date: Fri, 2 Oct 2009 22:59:37 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.coatfew.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://coatfew.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 8, B000. 852 Clements Road. London. SE97 0DG

© 2009 AMAZON, Ltd. All Rights Reserved

From larronar@amex.com Sat Oct 3 12:34:10 2009 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 054E03A67E4 for ; Sat, 3 Oct 2009 12:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 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_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_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_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 938TsoeVMhIG for ; Sat, 3 Oct 2009 12:34:09 -0700 (PDT) Received: from adsl-39-19-192-81.adsl.iam.net.ma (adsl-39-19-192-81.adsl.iam.net.ma [81.192.19.39]) by core3.amsl.com (Postfix) with SMTP id 7A8ED3A67A8 for ; Sat, 3 Oct 2009 12:34:00 -0700 (PDT) To: Subject: Sales Receipt from Amazon From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091003193403.7A8ED3A67A8@core3.amsl.com> Date: Sat, 3 Oct 2009 12:34:00 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.couldfloor.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://couldfloor.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 5, B969. 068 Clements Road. London. SE44 7DG

© 2009 AMAZON, Ltd. All Rights Reserved

From mkempton@amgen.com Sat Oct 3 13:44:03 2009 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 F26453A69F2 for ; Sat, 3 Oct 2009 13:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.179 X-Spam-Level: X-Spam-Status: No, score=-12.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 xDBpXIlnaQxI for ; Sat, 3 Oct 2009 13:44:02 -0700 (PDT) Received: from 33.you2q.com (unknown [79.164.124.105]) by core3.amsl.com (Postfix) with SMTP id 1865D3A67B5 for ; Sat, 3 Oct 2009 13:44:00 -0700 (PDT) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091003204401.1865D3A67B5@core3.amsl.com> Date: Sat, 3 Oct 2009 13:44:00 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.comfyrace.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://comfyrace.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 0, B508. 342 Clements Road. London. SE72 2DG

© 2009 AMAZON, Ltd. All Rights Reserved

From laire_wang@ama-assn.org Sun Oct 4 07:29:39 2009 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 DFA053A67FD for ; Sun, 4 Oct 2009 07:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 VLsKYA3T4f6a for ; Sun, 4 Oct 2009 07:29:38 -0700 (PDT) Received: from 89-160-137-136.du.xdsl.is (89-160-137-136.du.xdsl.is [89.160.137.136]) by core3.amsl.com (Postfix) with SMTP id DF89B3A67F3 for ; Sun, 4 Oct 2009 07:29:37 -0700 (PDT) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091004142937.DF89B3A67F3@core3.amsl.com> Date: Sun, 4 Oct 2009 07:29:37 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.awaredear.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://awaredear.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 7, B247. 761 Clements Road. London. SE30 6DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Sun Oct 4 16:29:02 2009 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 593093A6890 for ; Sun, 4 Oct 2009 16:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.929 X-Spam-Level: X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, 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 WJgcuh+GswZu for ; Sun, 4 Oct 2009 16:29:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 764813A6851 for ; Sun, 4 Oct 2009 16:29:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuaRA-0003eP-PW for v6ops-data0@psg.com; Sun, 04 Oct 2009 23:24:20 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuaR0-0003dt-OV for v6ops@ops.ietf.org; Sun, 04 Oct 2009 23:24:18 +0000 Received: from [172.25.89.236] (unknown [194.65.73.198]) by mail.lacnic.net.uy (Postfix) with ESMTP id 95D673084E2; Sun, 4 Oct 2009 21:24:01 -0200 (UYST) Cc: v6ops WG Message-Id: <0E737CC0-346E-4100-96A4-BF947FDC490F@lacnic.net> From: Roque Gagliano To: Martin Pels In-Reply-To: <20091001132545.25ceccc6@fizzix> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: comments on draft-ietf-v6ops-v6inixp-01.txt Date: Mon, 5 Oct 2009 00:23:56 +0100 References: <4A6EE42A.7020809@inex.ie> <4A702AFD.6040803@inex.ie> <20090730175043.14100900@fizzix> <4A81634A.2010301@inex.ie> <20090825135028.08f2b1a9@fizzix> <20091001132545.25ceccc6@fizzix> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin, >> >> > > The added text looks good to me, except for a small typo in the last > sentence (you write solocited-node, instead of solicited-node). > Will correct, Roque. > Kind regards, > Martin - ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkrJLowACgkQnk+WSgHpbO62CACfS/6LSxkPjoUh1RiKfWVmJCIw UVgAoJarJPRCPNJqX06b5qQtUpeHiMXE =3DzML7 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Oct 5 04:12:36 2009 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 D409D28C1AC for ; Mon, 5 Oct 2009 04:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.928 X-Spam-Level: X-Spam-Status: No, score=-99.928 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, 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 WtBi34ZdFMsc for ; Mon, 5 Oct 2009 04:12:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A97828C1A8 for ; Mon, 5 Oct 2009 04:12:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MulQI-000LyP-Qp for v6ops-data0@psg.com; Mon, 05 Oct 2009 11:08:10 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MulQ8-000LxW-2t for v6ops@ops.ietf.org; Mon, 05 Oct 2009 11:08:08 +0000 Received: from [172.25.89.216] (unknown [194.65.73.236]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7950F30850C; Mon, 5 Oct 2009 09:07:53 -0200 (UYST) Cc: v6ops@ops.ietf.org, martin.pels@ams-ix.net Message-Id: <8A3A255A-3786-4608-907B-5C1AD6B10A7A@lacnic.net> From: Roque Gagliano To: MAWATARI Masataka In-Reply-To: <20091002180244.E48A.8FE1F57E@jpix.ad.jp> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-54--591720256" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Date: Mon, 5 Oct 2009 12:07:50 +0100 References: <20091001135323.0c574feb@fizzix> <20091002180244.E48A.8FE1F57E@jpix.ad.jp> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-54--591720256 Content-Type: multipart/alternative; boundary=Apple-Mail-53--591720294 --Apple-Mail-53--591720294 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear Martin/ Masataka, I am proposing the following text for version 03. ---------------- IPv6 prefixes for IXP LANs are typically publicly well known and taken from dedicated IPv6 blocks for IXP assignments reserved for this purpose by the different RIRs.The current practice that applies to IPv4 about publishing IXP allocations to the DFZ (Default Free Zone) should also apply to the IPv6 allocation. When considering the routing of the IXP LANs two options are identified: o IXPs may decide that LANs should not to be globally routed in order to limit the possible origins of a Distributed Denial of Service (DDoS) attack to its particpant' AS boundries. In this configuration participants may route these prefixes inside their networks (e. g. using BGP no-export communities or routing the IXP LANs within the participants' IGP) to perform fault management. Using this configuration, the monitoring of the IXP LANs from outside of its participants' AS boundaries is not possible. o IXP may decide that LAN should be globally routed. In this case, IXP LANs monitoring from outside its participants' AS boundries is possible but the IXP LANs will be vulnerable to DDoS from outside of those boundaries. IXP external services (such as dns, web pages, ftp servers) need to be globally routed and due to strict prefix length filtering this could be the reason to request more than one /48 assignment from a RIR (i.e. requesting one /48 for the IXPs LANs that is not globally routed and a different /48 for the IXP external services that is globally routed). --------------------- What do you think? Roque On Oct 2, 2009, at 10:02 AM, MAWATARI Masataka wrote: > Hi all, > > > * On Thu, 1 Oct 2009 13:53:23 +0200 > * Martin Pels wrote: > >> Hi, >> >> On Tue, 8 Sep 2009 23:25:37 -0300 >> Roque Gagliano wrote: >> >>> Hi, >>> >>> I issued a new ID of the draft with the changes that came up at the >>> Stockholm meeting. Changes were: >>> - I explained why ULA is not a good idea. >>> - I added that addressing can use two different /48, one for the >>> LANs and the second one for the internal services and not >>> necessarily >>> one / 47, as comments at the meeting. >> >> In section 3 you added the following: "IPv6 prefixes for IXP LAN's >> are >> typically publicly well known.". >> >> I suggest changing this to something like: "IPv6 prefixes for IXP >> LANs >> are typically taken from dedicated IPv6 blocks for IXP assignments, >> reserved for this purpose by the different RIRs." > > > Thanks for your effort about IPv6 IXP operation. > > > If modifying as above, add notions that IXP can select PI address > policy > either routed or un-routed in the global table. > > (routed) > pros > - AS boundry monitoring IXP segment is possible. > cons > - Attacking IXP segment from non IXP participants is possible. > > (un-routed) > pros > - Attacking IXP segment from non IXP participants is impossible. > cons > - AS boundry monitoring IXP segment is impossible. > > > Are there any other pros/cons? > > > Regards, > Masataka MAWATARI > ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-53--591720294 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear Martin/ = Masataka,

I am proposing the following text for = version 03.

----------------
 =
  IPv6 prefixes for IXP LANs are typically publicly well known and
   taken from dedicated IPv6 blocks for IXP assignments reserved for
   this purpose by the different RIRs.The current practice that applies
   to IPv4 about publishing IXP allocations to the DFZ (Default Free
   Zone) should also apply to the IPv6 allocation.  When considering the
   routing of the IXP LANs two options are identified:

   o  IXPs may decide that LANs should not to be globally routed in
      order to limit the possible origins of a Distributed Denial of
      Service (DDoS) attack to its particpant' AS boundries.  In this
      configuration participants may route these prefixes inside their
      networks (e. g. using BGP no-export communities or routing the IXP
      LANs within the participants' IGP) to perform fault management.
      Using this configuration, the monitoring of the IXP LANs from
      outside of its participants' AS boundaries is not possible.

   o  IXP may decide that LAN should be globally routed.  In this case,
      IXP LANs monitoring from outside its participants' AS boundries is
      possible but the IXP LANs will be vulnerable to DDoS from outside =
of=20
      those boundaries.

   IXP external services (such as dns, web pages, ftp servers) need to
   be globally routed and due to strict prefix length filtering this
   could be the reason to request more than one /48 assignment from a
   RIR (i.e. requesting one /48 for the IXPs LANs that is not globally
   routed and a different /48 for the IXP external services that is
   globally =
routed).
---------------------

What do you = think?

Roque

On = Oct 2, 2009, at 10:02 AM, MAWATARI Masataka wrote:

Hi = all,


* On Thu, 1 Oct 2009 13:53:23 +0200
* Martin Pels = <martin.pels@ams-ix.net> = wrote:

Hi,

On Tue, 8 Sep = 2009 23:25:37 -0300
Roque = Gagliano <roque@lacnic.net> = wrote:

Hi,

I issued a new ID of the draft = with the changes that came up at the =  
Stockholm meeting. Changes = were:
- I explained why ULA is not a good = idea.
- I added that addressing can use two different /48, one = for the
LANs and the second one for the internal services and not = necessarily
one / 47, as comments at the = meeting.

In section 3 = you added the following: "IPv6 prefixes for IXP LAN's = are
typically publicly well = known.".

I suggest = changing this to something like: "IPv6 prefixes for IXP = LANs
are typically taken from = dedicated IPv6 blocks for IXP assignments,
reserved for this purpose by the different = RIRs."


Thanks for your effort about IPv6 IXP = operation.


If modifying as above, add notions that IXP can = select PI address policy
either routed or un-routed in the global = table.

(routed)
  pros
  - AS boundry = monitoring IXP segment is possible.
  cons
=   - Attacking IXP segment from non IXP participants is = possible.

(un-routed)
  pros
  - = Attacking IXP segment from non IXP participants is impossible.
=   cons
  - AS boundry monitoring IXP segment is = impossible.


Are there any other = pros/cons?


Regards,
Masataka = MAWATARI


-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =

= --Apple-Mail-53--591720294-- --Apple-Mail-54--591720256 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) iEYEARECAAYFAkrJ04YACgkQnk+WSgHpbO4PoACg3omvrZk5XQ5zpT+DEvCKged3 R8kAnjzC38YXj0sHYRRS51y0oMnZgsrP =WdF/ -----END PGP SIGNATURE----- --Apple-Mail-54--591720256-- From owner-v6ops@ops.ietf.org Mon Oct 5 04:12:44 2009 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 4961428C1A8 for ; Mon, 5 Oct 2009 04:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.927 X-Spam-Level: X-Spam-Status: No, score=-98.927 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RDNS_NONE=0.1, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ss8I8SAamHa for ; Mon, 5 Oct 2009 04:12:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC7943A6802 for ; Mon, 5 Oct 2009 04:12:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MulVH-000MV7-78 for v6ops-data0@psg.com; Mon, 05 Oct 2009 11:13:19 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MulV6-000MU1-FK for v6ops@ops.ietf.org; Mon, 05 Oct 2009 11:13:17 +0000 Received: from [172.25.89.216] (unknown [194.65.73.236]) by mail.lacnic.net.uy (Postfix) with ESMTP id DB58C30850A; Mon, 5 Oct 2009 09:12:57 -0200 (UYST) Cc: v6ops WG Message-Id: <232545B2-E0F8-44FC-AB32-AF0D042EB8C1@lacnic.net> From: Roque Gagliano To: tuy@renater.fr In-Reply-To: <4AC4CA4C.1060405@renater.fr> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-56--591417047" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Review of draft-ietf-v6ops-v6inixp-02.txt Date: Mon, 5 Oct 2009 12:12:53 +0100 References: <4AC20423.7080102@renater.fr> <6845F479-E3B8-4603-B144-D1F1A0733522@lacnic.net> <4AC4CA4C.1060405@renater.fr> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-56--591417047 Content-Type: multipart/alternative; boundary=Apple-Mail-55--591417099 --Apple-Mail-55--591417099 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Bernard, Thanks again for your review. I corrected all the typos for the 03 version and I have the following =20= comments: [BT1]I=D5d like to have a dedicated paragraph on =C7=CAMonitoring=CA=C8 = that =20 gathers information spread in the document ok, this is an important change I will take care of this before next =20 release. [BT2]Or 2^4=CA? 2^16 is correct. You get 4 HEX characters, each one of them represent =20= 4 bits 4x4=3D16. [BT3]Not sure to understand why =C9=CA;) I was just mentioning that when using the numbering as in example (1) =20= and considering how solicited-node multicast addresses are =20 constructed. This text came after AMS-IX paper on ND. Roque. On Oct 1, 2009, at 4:27 PM, Bernard Tuy wrote: > > =3D=3D=3D=3DBT: Hi again, > > I retrieved the paper where I wrote first all the modifs. > > Then I recreated the file and stored it as a PDF doc. > > It's attached to this email. > > Hope it'll help you, but no major changes have been done (I guess =20 > you can simply use the version I sent to you and just modifiy what =20 > you don't agree with.) > > Most important thing I propose is to make a separate paragraph for =20= > the Monitoring of IPv6 at IXes > > Cheers, > > +Bernard T. > --- > > Roque Gagliano wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Bernard, >> I tried in different computers to open the word file that you have =20= >> sent me but in every occasion the change tracks is not showing. =20 >> Could you please save it as Word 2003 or PDF? >> thanks, >> Roque. >> On Sep 29, 2009, at 9:57 AM, Bernard Tuy wrote: >>> >>> =3D=3D=3D=3DBT: Dear Chairmen, >>> >>> As proposed at the last IETF meeting in Stockholm, I reviewed =20 >>> the draft mentioned in the subject line. >>> >>> As said to the author (in Cc:), I find it useful and quite =20 >>> complete. >>> >>> Though, I suggest to gather information related to monitoring =20 >>> IPv6 traffic and switch resources, in a dedicated paragraph. >>> >>> Couple of typos and misspellings have been corrected as well. >>> >>> I attach to this email the modified version of this draft I =20 >>> sent back to the author. >>> >>> If I've something more to do for this review process, please =20 >>> just let me know. >>> >>> Thanx & cheers, >>> >>> +Bernard T. >>> >>> PJ: 1 >>> >> - ------------------------------------------------------------- >> Roque Gagliano >> LACNIC >> roque@lacnic.net >> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> iEYEARECAAYFAkrEuB8ACgkQnk+WSgHpbO4rKACfcMVtWnzjGdZ4WfqRr0BbbV7J >> GMcAn0Jh8vKfnHSfMYArop8ZLOHfrRr4 >> =3DjUMC >> -----END PGP SIGNATURE----- > ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-55--591417099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Bernard,

Thanks again for your = review.

I corrected all the typos for the 03 = version and I have the following comments:

[BT1]I=D5d like to have a = dedicated paragraph on =C7=CAMonitoring=CA=C8 that gathers information = spread in the document
ok, this is an important = change I will take care of this before next release.

[BT2]Or 2^4=CA?
2^16 is correct. You get 4 = HEX characters, each one of them represent 4 bits 4x4=3D16.

[BT3]Not sure to understand why =C9=CA;)
I was just mentioning that when using the numbering as in = example (1) and considering how solicited-node multicast addresses are = constructed. This text came after AMS-IX paper on ND.

Roque.

=3D=3D=3D=3DBT: Hi again,

I = retrieved the paper where I wrote first all the modifs.

Then I = recreated the file and stored it as a PDF doc.

It's = attached to this email.

 Hope it'll help you, but no major = changes have been done (I guess you can simply use the version I sent to = you and just modifiy what you don't agree with.)

 Most = important thing I propose is to make a separate paragraph for the = Monitoring of IPv6 at IXes

 Cheers,

 +Bernard = T.
---

Roque Gagliano wrote:
-----BEGIN PGP SIGNED = MESSAGE-----
Hash: = SHA1
Bernard,
I tried = in different computers to open the word file that you have sent me but = in every occasion the change tracks is not showing. Could you please = save it as Word 2003 or PDF?
thanks,
Roque.
On Sep = 29, 2009, at 9:57 AM, Bernard Tuy wrote:

=3D=3D=3D=3DBT: Dear = Chairmen,

   As proposed = at the last IETF meeting in Stockholm, I reviewed the draft mentioned in = the subject line.

   As said to = the author (in Cc:), I find it useful and quite = complete.

   Though, I = suggest to gather information related to monitoring IPv6 traffic and = switch resources, in a dedicated = paragraph.

   Couple of = typos and misspellings have been corrected as = well.

   I attach to = this email the modified version of this draft I sent back to the = author.

   If I've = something more to do for this review process, please just let me = know.

Thanx & = cheers,

+Bernard = T.

PJ: = 1
<BTreview_draft-ietf-v6ops-v6inixp-02.doc>
- = -------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 =  DB72 9E4F 964A 01E9 6CEE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkrEuB8ACgkQnk+WSgHpbO4rKACfcMVtWnzjGdZ4WfqRr0Bb= bV7J
GMcAn0Jh8vKfnHSfMYArop8ZLOHfrRr4
=3DjUMC
-----END = PGP = SIGNATURE-----
<BT2review_draft-ietf-v6ops-v6inix= p-02.pdf>

-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =

= --Apple-Mail-55--591417099-- --Apple-Mail-56--591417047 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) iEYEARECAAYFAkrJ1LUACgkQnk+WSgHpbO57FwCfRztjJjY8swX87Q9PC0UmGcA/ L+YAoJG1dlgAWBB9EPjVKvf6sBa9YBTy =OVdQ -----END PGP SIGNATURE----- --Apple-Mail-56--591417047-- From msulzend@abby-cheat.com Mon Oct 5 12:35:32 2009 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 E6A0028C201 for ; Mon, 5 Oct 2009 12:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.114 X-Spam-Level: X-Spam-Status: No, score=-17.114 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 u9ByEcM3mYSB for ; Mon, 5 Oct 2009 12:35:32 -0700 (PDT) Received: from alltel.net (unknown [92.60.16.139]) by core3.amsl.com (Postfix) with SMTP id 0B0CE3A686B for ; Mon, 5 Oct 2009 12:35:30 -0700 (PDT) To: Subject: Hi From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091005193531.0B0CE3A686B@core3.amsl.com> Date: Mon, 5 Oct 2009 12:35:30 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.comfyrace.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://comfyrace.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 5, B900. 059 Clements Road. London. SE46 9DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Mon Oct 5 13:36:46 2009 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 4CFB63A6A35 for ; Mon, 5 Oct 2009 13:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LurAldWgAgi8 for ; Mon, 5 Oct 2009 13:36:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 868763A67ED for ; Mon, 5 Oct 2009 13:36:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuuET-0004Qm-CX for v6ops-data0@psg.com; Mon, 05 Oct 2009 20:32:33 +0000 Received: from web45512.mail.sp1.yahoo.com ([68.180.197.152]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuuEI-0004Q6-Fe for v6ops@ops.ietf.org; Mon, 05 Oct 2009 20:32:30 +0000 Received: (qmail 94582 invoked by uid 60001); 5 Oct 2009 20:32:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254774741; bh=2RM7kH3VyX9fq7ZcT07Ia/7cWSn6j4It8RpHxF965dQ=; 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=N3bMdXVoM5syiD4xpy3e7nJVybeg1rJtLNsgegDIF9LmumAMqroE9qTM0sStvYiQluC6slY1BvUQ+9ZpgJAt4VeMXKsix80CoC2JVoO7A3RPitR5ro1UlbE/CVsAC/e9lDKNYYC5YfDuE67CeuJw/tvGvFdBsksu1zp4kDdp398= 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=5UanTpyxQovHehJG+l9xT/y/bOdGSHxJFwJrCJWnrMr2wJiZVoQy5ytyf8k/nSLJflCDyY7+VNBTUG+5TPlnz2BoNPgWugpuJktJ6qHNwx43VH0vd6BeXFTcNiTGI4j9qOAY72h+4SJeGN9gPChHIs6CuIZRmxDq1qJRlb+BVY0=; Message-ID: <339077.93936.qm@web45512.mail.sp1.yahoo.com> X-YMail-OSG: nyfw2PMVM1kTI7Ef.KIkz.TehZFk493KG2yFvEhZb9fCPzK0qZAyb1rX2AayAP4xZJV181ckG3pSLwFXQQZnG7vOjKu_SjwsJ6aRU.jdVS_03Lttcos7t5F2FDqGUpmAZsp70NJRWMT7XN_FN45NIdNsaeN.iSF6Xb7fKlC0qfj4kiwuw5NUl2d1r.CIxcDaZCDi8dqFFXTUEaN_xWrcY_OwVTULorfqc8EnfyKEEhwrjDQEM8yyG.jOIplhjdcNLRcKaM.zPpoO7LfmlOAPhqCeCZ1so4oqr14UxETRNh1Q86TdAdYKre8Q Received: from [89.138.46.188] by web45512.mail.sp1.yahoo.com via HTTP; Mon, 05 Oct 2009 13:32:21 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> Date: Mon, 5 Oct 2009 13:32:21 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" Cc: v6ops In-Reply-To: <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.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,=0AWith regrad to=A0your comment below: if=A0indeed an ISATAP=A0router= will not forward=A0packets to an ISATAP=A0host it has not recently=A0recei= ved RS from, then I think that the ISATAP specification should=A0at least r= equire=A0an ISATAP host (using a SHOULD) to regularly send RSs to _all_ rou= ters in the PRL, or else ISATAP connectivity=A0may be broken.=0A=0AGabi=0A= =0A----- Original Message ----=0A> From: "Templin, Fred L" =0A> To: Gabi Nakibly =0A> Cc: v6ops =0A> Sent: Thu, October 1, 2009 6:49:31 PM=0A> Subject: RE: Ro= uting loop attacks using IPv6 tunnels=0A> =0A> Hi Gabi,=0A> =0A> > -----Ori= ginal Message-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A>= > Sent: Thursday, October 01, 2009 6:53 AM=0A> > To: Templin, Fred L=0A> >= Cc: v6ops=0A> > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> >= =0A> > Removed the 6man and secdir=A0mailing lists from the Cc.=0A> > =0A>= > Fred, see comments below.=0A> > =0A> > ----- Original Message ----=0A> >= > From: "Templin, Fred L" =0A> > > To: Gabi Nakibly ; Christian Huitema = =0A> ; v6ops=0A> > =0A> > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" =0A> > = > Sent: Tuesday, September 29, 2009 6:00:55 PM=0A> > > Subject: RE: Routing= loop attacks using IPv6 tunnels=0A> > >=0A> > > Gabi,=0A> > >=0A> > > Welc= ome back from your vacation. I trimmed quite a bit from=0A> > > the bottom = of this message to eliminate the clutter, but see=0A> > > below for respons= es to your current comments:=0A> > >=0A> > > > -----Original Message-----= =0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Sent: T= uesday, September 29, 2009 3:22 AM=0A> > > > To: Templin, Fred L; Christian= Huitema; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Subj= ect: Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > > > Hi Fre= d,=0A> > > > Back from vacation. See Comments inlines.=0A> > > >=0A> > > > = Gabi=0A> > > >=0A> > > >=0A> > > >=0A> > > > ----- Original Message ----=0A= > > > > > From: "Templin, Fred L"=0A> > > > > To: Gabi Nakibly ; Christian = Huitema=0A> > > ; v6ops=0A> > > >=0A> > > > > Cc: ipv6@ietf.org; secdir@iet= f.org=0A> > > > > Sent: Friday, September 11, 2009 11:13:44 PM=0A> > > > > = Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > > >=0A> > > > = > Hi Gabi,=0A> > > > >=0A> > > > > > -----Original Message-----=0A> > > > >= > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > Sent: Frida= y, September 11, 2009 12:59 PM=0A> > > > > > To: Templin, Fred L; Christian= Huitema; v6ops=0A> > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > = > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > >=0A> = > > > > > Hi Fred,=0A> > > > > > See below.=0A> > > > > >=0A> > > > > > Gab= i=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > > ----- Original Me= ssage ----=0A> > > > > > > From: "Templin, Fred L"=0A> > > > > > > To: Gabi= Nakibly ; Christian Huitema=0A> > > > > ; v6ops=0A> > > > > >=0A> > > > > = > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > Sent: Tuesday, Septe= mber 8, 2009 8:37:03 PM=0A> > > > > > > Subject: RE: Routing loop attacks u= sing IPv6 tunnels=0A> > > > > > >=0A> > > > > > > Gabi and Christian,=0A> >= > > > > >=0A> > > > > > > Focusing only on attack #3 (i.e., leaving out at= tack #1=0A> > > > > > > and #2 6to4 interactions for the moment), please ch= eck=0A> > > > > > > the following summary of proposed mitigations:=0A> > > = > > > >=0A> > > > > > > 1) For ISATAP/VET routers that have assurance that = their=0A> > > > > > > neighbor cache is coherent, the router can make a sim= ple=0A> > > > > > > check in the neighbor cache to determine whether to=0A>= > > > > > > forward or drop the packet. In pseudo-code:=0A> > > > > > >=0A= > > > > > > > =A0 isatap_rcv() {=0A> > > > > > > =A0 =A0 ...=0A> > > > > > = > =A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*"))=0A> > > = > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > > > =A0 =A0 ...=0A> > > > > > >= =A0 }=0A> > > > > > >=0A> > > > > > > =A0 isatap_xmt() {=0A> > > > > > > = =A0 =A0 ...=0A> > > > > > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src= !=3D "fe80::*"))=0A> > > > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > > > = =A0 =A0 ...=0A> > > > > > > =A0 }=0A> > > > > > >=0A> > > > > > > (Here, th= e link-local exception is necessary to bootstrap=0A> > > > > > > neighbor d= iscovery on the ISATAP link.)=0A> > > > > > >=0A> > > > > > > Does anyone s= ee a problem with this?=0A> > > > > > >=0A> > > > > > Looks fine.=0A> > > >= >=0A> > > > > OK.=0A> > > > >=0A> > > >=0A> > > > On second thought, a cou= ple of comments:=0A> > > > 1) According to RFC 5214 Section 8.3.4:=0A> > > = > =A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY schedule periodic Router Solicita= tion events=0A> > > > =A0=A0 =A0=A0=A0 for certain PRL(i)s by setting the c= orresponding TIMER(i)."=0A> > > > As I understand, this means that there is= a possibility for a host=A0not =0A> to=A0send=0A> > > RSs to all routers i= n=0A> > > > the PRL. However, any router in the PRL may forward packets int= o the =0A> ISATAP=0A> > > link. The isatap_xmt()=0A> > > > check will preve= nt forwarding packets by routers which the destination=A0has =0A> not=0A> >= > previously sent RS to.=0A> > > > If I am correct then this check=A0may b= reak ISATAP connectivity.=0A> > >=0A> > > I don't think this is a problem. = If a host has not sent an RS to=0A> > > a PRL router, then it should not ha= ve configured a default route=0A> > > nor any prefix information specific t= o that router. Therefore,=0A> > > the only packets the host and router shou= ld expect to exchange=0A> > > in this state are link-local. As such, the ro= uter can discard=0A> > > non-link-local packets if there is no neighbor cac= he entry.=0A> > >=0A> > =0A> > I was thinking=A0of a case of two routers in= the PRL advertising the same prefix =0A> for the ISATAP=0A> > link.=A0Eith= er routers obviously may forward packets _into_ the ISATAP link to =0A> any= host. If a host=A0will=0A> > not send=A0a RS to one of those routers=A0the= n=A0it will drop packets destined to =0A> that host.=0A> =0A> I'm actually = OK with that. If two routers A and B advertise=0A> the same prefix P, and i= f B doesn't know about host H either=0A> through receiving RSs or through t= alking to A, then B should=0A> not forward packets to H.=0A> =0A> Thanks - = Fred=0A> fred.l.templin@boeing.com =0A> =0A> > > > 2) I remind you a commen= t you made in the past: for the checks to work=A0the=0A> > > time between t= wo=0A> > > > consequtive RSs from a host to a=A0router should be no greater= than the the=0A> > > lifetime of an entry for=0A> > > > that host in the r= outer's neighbors cache.=A0This is needed=A0to ensure =0A> that=A0the=0A> >= > entry in the neighbors=0A> > > > cache will not be erased. This raises t= wo questions:=0A> > > > =A0=A0=A0 a) AFAIK there is no minimum lifetime for= an entry in a neighbors =0A> cache=0A> > > -=A0it is an implementation=0A>= > > > detail.=A0If this is true=A0how can we enforce the above constraint?= =0A> > >=0A> > > Correct that there is no minimum lifetime for neighbor cac= he=0A> > > entries specified by RFC4861. However, an ISATAP router that=0A>= > > uses the neighbor cache checking procedures I have described=0A> > > c= an use its own discipline for managing its neighbor cache.=0A> > > Exactly = such a discipline is now specified in Section 5.4.1=0A> > > of 'draft-templ= in-intarea-vet'. Please be aware that ISATAP=0A> > > and VET are simply "IP= v6-over-(foo)" specifications, and=0A> > > RFC4861 permits that operations = of the neighbor discovery=0A> > > protocol that are specific to (foo) links= may be specified=0A> > > in such documents.=0A> > >=0A> > =0A> > OK.=0A> >= =0A> > > > =A0=A0=A0 b) A router's neighbors cache=A0must now=A0include at= any given moment all =0A> the=0A> > > active ISATAP nodes in=0A> > > > the= ISATAP link. Is this a reasonable demand?=0A> > >=0A> > > Memory should be= cheap enough, and ISATAP links within private=0A> > > addressing realms sh= ould be small enough, that I do not see this=0A> > > as an unreasonable dem= and.=0A> > >=0A> > =0A> > OK.=0A> > =0A> > > > > > > 2) For ISATAP/VET rout= ers that use public IPv4 addresses=0A> > > > > > > and that do not have ass= urance that their neighbor cache=0A> > > > > > > is coherent, the router ca= n check for the interface ID=0A> > > > > > > "0200:5EFE:". In pseudo-code:= =0A> > > > > > >=0A> > > > > > > =A0 isatap_rcv() {=0A> > > > > > > =A0 =A0= ...=0A> > > > > > > =A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:")= =0A> > > > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > > > =A0 =A0 ...=0A> > = > > > > > =A0 }=0A> > > > > > >=0A> > > > > > > =A0 isatap_xmt() {=0A> > > = > > > > =A0 =A0 ...=0A> > > > > > > =A0 =A0 if (v6src =3D=3D "foreign_prefi= x::0200:5efe:")=0A> > > > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > > > =A0= =A0 ...=0A> > > > > > > =A0 }=0A> > > > > > >=0A> > > > > > > Does anyone = see a problem with this?=0A> > > > > >=0A> > > > > > Looks fine.=0A> > > > = >=0A> > > > > OK, but since I sent this I began to wonder whether cases=0A>= > > > > 1) and 2) should be reversed (i.e., do the 0x00:5EFE check=0A> > >= > > first). I came to believe that it almost doesn't matter=0A> > > > > fr= om a performance standpoint, and perhaps should be left=0A> > > > > up to t= he implementer. Do you have an opinion on this?=0A> > > > >=0A> > > > > > >= 3) For ISATAP/VET routers that use private IPv4 addresses=0A> > > > > > > = and that do not have assurance that their neighbor cache=0A> > > > > > > is= coherent, the router can make the checks that Christian=0A> > > > > > > ha= s proposed. But, will we see any of these case 3)=0A> > > > > > > situation= s in operational practice?=0A> > > > > > >=0A> > > > > >=0A> > > > > > I ca= n not tell for sure. Why this case seems to you less plausible =0A> than=0A= > > > case=0A> > > > > 2?=0A> > > > >=0A> > > > > Case 3) is the case in wh= ich source address spoofing within=0A> > > > > a private IPv4 addressing ra= nge is possible. It seems to me=0A> > > > > that it may correspond to eithe= r a poorly managed deployment,=0A> > > > > or one in which there are multip= le administrative authorities=0A> > > > > with diverse policies and operati= onal practices.=0A> > > > >=0A> > > >=0A> > > > I agree. However, remember = that the spoofed packet may also originate from=0A> > > within the site, wh= ich is=0A> > > > very hard to defend against.=0A> > >=0A> > > Spoofing is n= ot so hard to defend against if Secure Neighbor=0A> > > Discovery (SEND) is= used to set up the neighbor relationships=0A> > > and if every packet carr= ies a nonce that can be used to detect=0A> > > an off-path attack.=0A> > = =0A> > I agree again. I was referring to the case where SEND is not deploye= d.=0A> > =0A> > > That is only the case for VET and SEAL,=0A> > > however, = so if source address spoofing within the site is seen=0A> > > as a problem = then VET and SEAL should be used instead of ISATAP.=0A> > >=0A> > > Note th= at for the sake of consistency it might be helpful to=0A> > > consider VET = as simply "ISATAP version 2 (ISATAPv2)".=0A> > >=0A> > > Fred=0A> > > fred.= l.templin@boeing.com=0A> > >=0A> > > > > The checks that Christian proposed= could be used for this=0A> > > > > scenario if possible. Otherwise, the be= st solution IMHO=0A> > > > > would be to allow only routers (and not hosts)= on the=0A> > > > > virtual links. This final model would be best addressed= =0A> > > > > by VET and SEAL rather than ISATAP.=0A> > > > >=0A> > > > > Th= anks - Fred=0A> > > > > fred.l.templin@boeing.com=0A> > =0A> > ____________= ______________________________________=0A> > Do You Yahoo!?=0A> > Tired of = spam?=A0 Yahoo! Mail has the best spam protection around=0A> > http://mail.= yahoo.com=0A=0A=0A=0A From owner-v6ops@ops.ietf.org Mon Oct 5 13:42:08 2009 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 DB5A23A6A3C for ; Mon, 5 Oct 2009 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=-1.996, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3, 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 UoqiqJCiJPqf for ; Mon, 5 Oct 2009 13:42:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F09423A6A34 for ; Mon, 5 Oct 2009 13:42:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuuN8-0005M4-SJ for v6ops-data0@psg.com; Mon, 05 Oct 2009 20:41:30 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuuMy-0005Ku-7U for v6ops@ops.ietf.org; Mon, 05 Oct 2009 20:41:28 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n95KfIRM002770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2009 15:41:18 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n95KfHkm028973; Mon, 5 Oct 2009 13:41:18 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n95KfHlE028970 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 5 Oct 2009 13:41:17 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 5 Oct 2009 13:41:17 -0700 From: "Templin, Fred L" To: Gabi Nakibly CC: v6ops Date: Mon, 5 Oct 2009 13:41:16 -0700 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcpF+vJhxdFepyg9Rq2oagkWNlDDcwAAFM5A Message-ID: <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> <339077.93936.qm@web45512.mail.sp1.yahoo.com> In-Reply-To: <339077.93936.qm@web45512.mail.sp1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.600.1016-16888.004 x-tm-as-result: No--69.167400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No 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: Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, October 05, 2009 1:32 PM > To: Templin, Fred L > Cc: v6ops > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > With regrad to=A0your comment below: if=A0indeed an ISATAP=A0router will = not forward=A0packets to an > ISATAP=A0host it has not recently=A0received RS from, then I think that t= he ISATAP specification > should=A0at least require=A0an ISATAP host (using a SHOULD) to regularly = send RSs to _all_ routers in the > PRL, or else ISATAP connectivity=A0may be broken. Yes, "ping them all" is certainly one way to ensure a nbr cache entry at each PRL router. I was also starting to think that another solution would be for PRL routers that advertise a shared IP prefx (e.g., 2001:DB8::/64) to somehow synchronize their neighbor caches. For that matter, it might be best to do both because you can never tell which subset of the PRLs is the correct subset to ping. Fred fred.l.templin@boeing.com > Gabi >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly > > Cc: v6ops > > Sent: Thu, October 1, 2009 6:49:31 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Hi Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Thursday, October 01, 2009 6:53 AM > > > To: Templin, Fred L > > > Cc: v6ops > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Removed the 6man and secdir=A0mailing lists from the Cc. > > > > > > Fred, see comments below. > > > > > > ----- Original Message ---- > > > > From: "Templin, Fred L" > > > > To: Gabi Nakibly ; Christian Huitema > > ; v6ops > > > > > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" > > > > Sent: Tuesday, September 29, 2009 6:00:55 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Gabi, > > > > > > > > Welcome back from your vacation. I trimmed quite a bit from > > > > the bottom of this message to eliminate the clutter, but see > > > > below for responses to your current comments: > > > > > > > > > -----Original Message----- > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > Sent: Tuesday, September 29, 2009 3:22 AM > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > Hi Fred, > > > > > Back from vacation. See Comments inlines. > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > From: "Templin, Fred L" > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > ; v6ops > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > Sent: Friday, September 11, 2009 11:13:44 PM > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > Hi Gabi, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > Sent: Friday, September 11, 2009 12:59 PM > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > Hi Fred, > > > > > > > See below. > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > > > From: "Templin, Fred L" > > > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > > > ; v6ops > > > > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > Sent: Tuesday, September 8, 2009 8:37:03 PM > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > Gabi and Christian, > > > > > > > > > > > > > > > > Focusing only on attack #3 (i.e., leaving out attack #1 > > > > > > > > and #2 6to4 interactions for the moment), please check > > > > > > > > the following summary of proposed mitigations: > > > > > > > > > > > > > > > > 1) For ISATAP/VET routers that have assurance that their > > > > > > > > neighbor cache is coherent, the router can make a simple > > > > > > > > check in the neighbor cache to determine whether to > > > > > > > > forward or drop the packet. In pseudo-code: > > > > > > > > > > > > > > > > =A0 isatap_rcv() { > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80:= :*")) > > > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 } > > > > > > > > > > > > > > > > =A0 isatap_xmt() { > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 =A0 if ((v6dst is not a neighbor) && (v6src !=3D "fe80:= :*")) > > > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 } > > > > > > > > > > > > > > > > (Here, the link-local exception is necessary to bootstrap > > > > > > > > neighbor discovery on the ISATAP link.) > > > > > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > > > > > Looks fine. > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > On second thought, a couple of comments: > > > > > 1) According to RFC 5214 Section 8.3.4: > > > > > =A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY schedule periodic Router = Solicitation events > > > > > =A0=A0 =A0=A0=A0 for certain PRL(i)s by setting the corresponding= TIMER(i)." > > > > > As I understand, this means that there is a possibility for a hos= t=A0not > > to=A0send > > > > RSs to all routers in > > > > > the PRL. However, any router in the PRL may forward packets into = the > > ISATAP > > > > link. The isatap_xmt() > > > > > check will prevent forwarding packets by routers which the destin= ation=A0has > > not > > > > previously sent RS to. > > > > > If I am correct then this check=A0may break ISATAP connectivity. > > > > > > > > I don't think this is a problem. If a host has not sent an RS to > > > > a PRL router, then it should not have configured a default route > > > > nor any prefix information specific to that router. Therefore, > > > > the only packets the host and router should expect to exchange > > > > in this state are link-local. As such, the router can discard > > > > non-link-local packets if there is no neighbor cache entry. > > > > > > > > > > I was thinking=A0of a case of two routers in the PRL advertising the = same prefix > > for the ISATAP > > > link.=A0Either routers obviously may forward packets _into_ the ISATA= P link to > > any host. If a host=A0will > > > not send=A0a RS to one of those routers=A0then=A0it will drop packets= destined to > > that host. > > > > I'm actually OK with that. If two routers A and B advertise > > the same prefix P, and if B doesn't know about host H either > > through receiving RSs or through talking to A, then B should > > not forward packets to H. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > 2) I remind you a comment you made in the past: for the checks to= work=A0the > > > > time between two > > > > > consequtive RSs from a host to a=A0router should be no greater th= an the the > > > > lifetime of an entry for > > > > > that host in the router's neighbors cache.=A0This is needed=A0to = ensure > > that=A0the > > > > entry in the neighbors > > > > > cache will not be erased. This raises two questions: > > > > > =A0=A0=A0 a) AFAIK there is no minimum lifetime for an entry in a= neighbors > > cache > > > > -=A0it is an implementation > > > > > detail.=A0If this is true=A0how can we enforce the above constrai= nt? > > > > > > > > Correct that there is no minimum lifetime for neighbor cache > > > > entries specified by RFC4861. However, an ISATAP router that > > > > uses the neighbor cache checking procedures I have described > > > > can use its own discipline for managing its neighbor cache. > > > > Exactly such a discipline is now specified in Section 5.4.1 > > > > of 'draft-templin-intarea-vet'. Please be aware that ISATAP > > > > and VET are simply "IPv6-over-(foo)" specifications, and > > > > RFC4861 permits that operations of the neighbor discovery > > > > protocol that are specific to (foo) links may be specified > > > > in such documents. > > > > > > > > > > OK. > > > > > > > > =A0=A0=A0 b) A router's neighbors cache=A0must now=A0include at a= ny given moment all > > the > > > > active ISATAP nodes in > > > > > the ISATAP link. Is this a reasonable demand? > > > > > > > > Memory should be cheap enough, and ISATAP links within private > > > > addressing realms should be small enough, that I do not see this > > > > as an unreasonable demand. > > > > > > > > > > OK. > > > > > > > > > > > 2) For ISATAP/VET routers that use public IPv4 addresses > > > > > > > > and that do not have assurance that their neighbor cache > > > > > > > > is coherent, the router can check for the interface ID > > > > > > > > "0200:5EFE:". In pseudo-code: > > > > > > > > > > > > > > > > =A0 isatap_rcv() { > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:") > > > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 } > > > > > > > > > > > > > > > > =A0 isatap_xmt() { > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 =A0 if (v6src =3D=3D "foreign_prefix::0200:5efe:") > > > > > > > > =A0 =A0 =A0 drop_pkt(); > > > > > > > > =A0 =A0 ... > > > > > > > > =A0 } > > > > > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > > > > Looks fine. > > > > > > > > > > > > OK, but since I sent this I began to wonder whether cases > > > > > > 1) and 2) should be reversed (i.e., do the 0x00:5EFE check > > > > > > first). I came to believe that it almost doesn't matter > > > > > > from a performance standpoint, and perhaps should be left > > > > > > up to the implementer. Do you have an opinion on this? > > > > > > > > > > > > > > 3) For ISATAP/VET routers that use private IPv4 addresses > > > > > > > > and that do not have assurance that their neighbor cache > > > > > > > > is coherent, the router can make the checks that Christian > > > > > > > > has proposed. But, will we see any of these case 3) > > > > > > > > situations in operational practice? > > > > > > > > > > > > > > > > > > > > > > I can not tell for sure. Why this case seems to you less plau= sible > > than > > > > case > > > > > > 2? > > > > > > > > > > > > Case 3) is the case in which source address spoofing within > > > > > > a private IPv4 addressing range is possible. It seems to me > > > > > > that it may correspond to either a poorly managed deployment, > > > > > > or one in which there are multiple administrative authorities > > > > > > with diverse policies and operational practices. > > > > > > > > > > > > > > > > I agree. However, remember that the spoofed packet may also origi= nate from > > > > within the site, which is > > > > > very hard to defend against. > > > > > > > > Spoofing is not so hard to defend against if Secure Neighbor > > > > Discovery (SEND) is used to set up the neighbor relationships > > > > and if every packet carries a nonce that can be used to detect > > > > an off-path attack. > > > > > > I agree again. I was referring to the case where SEND is not deployed= . > > > > > > > That is only the case for VET and SEAL, > > > > however, so if source address spoofing within the site is seen > > > > as a problem then VET and SEAL should be used instead of ISATAP. > > > > > > > > Note that for the sake of consistency it might be helpful to > > > > consider VET as simply "ISATAP version 2 (ISATAPv2)". > > > > > > > > Fred > > > > fred.l.templin@boeing.com > > > > > > > > > > The checks that Christian proposed could be used for this > > > > > > scenario if possible. Otherwise, the best solution IMHO > > > > > > would be to allow only routers (and not hosts) on the > > > > > > virtual links. This final model would be best addressed > > > > > > by VET and SEAL rather than ISATAP. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam?=A0 Yahoo! Mail has the best spam protection around > > > http://mail.yahoo.com >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Oct 5 14:25:02 2009 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 A70CE3A698B for ; Mon, 5 Oct 2009 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.361 X-Spam-Level: X-Spam-Status: No, score=0.361 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUVni-AVzcxl for ; Mon, 5 Oct 2009 14:25:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BBF83A68DB for ; Mon, 5 Oct 2009 14:25:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muv2f-000BgA-BG for v6ops-data0@psg.com; Mon, 05 Oct 2009 21:24:25 +0000 Received: from web45511.mail.sp1.yahoo.com ([68.180.197.143]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muv2T-000BdY-7Q for v6ops@ops.ietf.org; Mon, 05 Oct 2009 21:24:22 +0000 Received: (qmail 67655 invoked by uid 60001); 5 Oct 2009 21:24:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254777851; bh=RLOGaflY3gB83DypVV/ZKrpKtWN72lzpdOaoq2hxSAw=; 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=ATaySBfj7oFrlDs21GWM81q+Jbg5+ifeRl48EqwJXBCWhRLTsCqzxATfrGf1bAIfSQ/HsVVOoxIQCQrCtpPQKKaPX0zP2d0o67wSmKpyZGG+FRVQUp9gtOJ6NC0IfUmwOoDNuBNWhEvez2zHVyIWBVoKXwFwe+/9m1SSDI7Ih2w= 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=EyVTcFjf769CXd7mFLTIGn40M+JTDm3AaBZ6OH0Vego7kT4MXB4DHw/e2BKGEwpsyl6zLFrgzcSsTlTFn4iZBsnqJzBRcaAn05HX4dyZvRo1tMhr7ccAEBFiHUDnXKCh+we0ixym0jsqb14lMjtgKB/aoLsA9wZsiL9bO4Fl3bY=; Message-ID: <866685.67299.qm@web45511.mail.sp1.yahoo.com> X-YMail-OSG: Y5PT7ikVM1nmC8t7DNqktHbm8PDZtEUEN0XZhTOvMD8NN9vUb8HYXpJW3Xh9N20tfwLwgbRZIytMhXXC4DJHuzOVjGiVLU61S_tOHF8TIC1JOPSrwjrTVp19DBCMdDqHTpUgGIs65ShW5StONix.tn8y0IS.0BIHc4LXdWsK930cjechDAKr6ZxMs2.XD5djPbkxGoRGAxZMueA4GhR_uMqyfoqJERVqyHFbbmgUTf.ktZ_u0vQn1D2ToelQF6YiTb9O8_dbvOv8V18kXU6Re4EDz1mmoxmfmuT0wlPuS8GdhPUAS09GaIlFAA-- Received: from [89.138.46.188] by web45511.mail.sp1.yahoo.com via HTTP; Mon, 05 Oct 2009 14:24:11 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> <339077.93936.qm @web45512.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> Date: Mon, 5 Oct 2009 14:24:11 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" Cc: v6ops In-Reply-To: <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.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: On first thought, setting up a synchronization mechanism of the neighbor ca= ches at the routers=A0does not sound, IMHO,=A0like the best solution. It wi= ll probably add complexity and interdependence to=A0the routers' functional= ity. =0AMaybe=A0a good trade-off would be to first require=A0a host to send= an initial RS=A0to every router in the PRL. Then after the host learns the= advertised prefix of each router the host should continue sending RSs (or = stop sending) to=A0all routers=A0advertising the same prefix. =0A=0A=0A----= - Original Message ----=0A> From: "Templin, Fred L" =0A> To: Gabi Nakibly =0A> Cc: v6ops =0A> Sent: Mon, October 5, 2009 10:41:16 PM=0A> Subject: RE: Routing = loop attacks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> > -----Original Mes= sage-----=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: = Monday, October 05, 2009 1:32 PM=0A> > To: Templin, Fred L=0A> > Cc: v6ops= =0A> > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > =0A> > Fr= ed,=0A> > With regrad to=A0your comment below: if=A0indeed an ISATAP=A0rout= er will not =0A> forward=A0packets to an=0A> > ISATAP=A0host it has not rec= ently=A0received RS from, then I think that the ISATAP =0A> specification= =0A> > should=A0at least require=A0an ISATAP host (using a SHOULD) to regul= arly send RSs =0A> to _all_ routers in the=0A> > PRL, or else ISATAP connec= tivity=A0may be broken.=0A> =0A> Yes, "ping them all" is certainly one way = to ensure a nbr=0A> cache entry at each PRL router. I was also starting to= =0A> think that another solution would be for PRL routers that=0A> advertis= e a shared IP prefx (e.g., 2001:DB8::/64) to=0A> somehow synchronize their = neighbor caches. For that=0A> matter, it might be best to do both because y= ou can=0A> never tell which subset of the PRLs is the correct=0A> subset to= ping.=0A> =0A> Fred=0A> fred.l.templin@boeing.com=0A> =0A> > Gabi=0A> > = =0A> > ----- Original Message ----=0A> > > From: "Templin, Fred L" =0A> > >= To: Gabi Nakibly =0A> > > Cc: v6ops =0A> > > Sent: Thu, October 1, 2009 6:= 49:31 PM=0A> > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> >= >=0A> > > Hi Gabi,=0A> > >=0A> > > > -----Original Message-----=0A> > > > = From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Sent: Thursday, Oc= tober 01, 2009 6:53 AM=0A> > > > To: Templin, Fred L=0A> > > > Cc: v6ops=0A= > > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> = > > > Removed the 6man and secdir=A0mailing lists from the Cc.=0A> > > >=0A= > > > > Fred, see comments below.=0A> > > >=0A> > > > ----- Original Messag= e ----=0A> > > > > From: "Templin, Fred L"=0A> > > > > To: Gabi Nakibly ; C= hristian Huitema=0A> > > ; v6ops=0A> > > >=0A> > > > > Cc: "ipv6@ietf.org" = ; "secdir@ietf.org"=0A> > > > > Sent: Tuesday, September 29, 2009 6:00:55 P= M=0A> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > = > >=0A> > > > > Gabi,=0A> > > > >=0A> > > > > Welcome back from your vacati= on. I trimmed quite a bit from=0A> > > > > the bottom of this message to el= iminate the clutter, but see=0A> > > > > below for responses to your curren= t comments:=0A> > > > >=0A> > > > > > -----Original Message-----=0A> > > > = > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > Sent: Tues= day, September 29, 2009 3:22 AM=0A> > > > > > To: Templin, Fred L; Christia= n Huitema; v6ops=0A> > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > >= > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > >=0A>= > > > > > Hi Fred,=0A> > > > > > Back from vacation. See Comments inlines.= =0A> > > > > >=0A> > > > > > Gabi=0A> > > > > >=0A> > > > > >=0A> > > > > >= =0A> > > > > > ----- Original Message ----=0A> > > > > > > From: "Templin, = Fred L"=0A> > > > > > > To: Gabi Nakibly ; Christian Huitema=0A> > > > > ; = v6ops=0A> > > > > >=0A> > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> = > > > > > > Sent: Friday, September 11, 2009 11:13:44 PM=0A> > > > > > > Su= bject: RE: Routing loop attacks using IPv6 tunnels=0A> > > > > > >=0A> > > = > > > > Hi Gabi,=0A> > > > > > >=0A> > > > > > > > -----Original Message---= --=0A> > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > >= > > > > > Sent: Friday, September 11, 2009 12:59 PM=0A> > > > > > > > To: = Templin, Fred L; Christian Huitema; v6ops=0A> > > > > > > > Cc: ipv6@ietf.o= rg; secdir@ietf.org=0A> > > > > > > > Subject: Re: Routing loop attacks usi= ng IPv6 tunnels=0A> > > > > > > >=0A> > > > > > > > Hi Fred,=0A> > > > > > = > > See below.=0A> > > > > > > >=0A> > > > > > > > Gabi=0A> > > > > > > >= =0A> > > > > > > >=0A> > > > > > > >=0A> > > > > > > > ----- Original Messa= ge ----=0A> > > > > > > > > From: "Templin, Fred L"=0A> > > > > > > > > To:= Gabi Nakibly ; Christian Huitema=0A> > > > > > > ; v6ops=0A> > > > > > > >= =0A> > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > >= Sent: Tuesday, September 8, 2009 8:37:03 PM=0A> > > > > > > > > Subject: R= E: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > >=0A> > > > > = > > > > Gabi and Christian,=0A> > > > > > > > >=0A> > > > > > > > > Focusin= g only on attack #3 (i.e., leaving out attack #1=0A> > > > > > > > > and #2= 6to4 interactions for the moment), please check=0A> > > > > > > > > the fo= llowing summary of proposed mitigations:=0A> > > > > > > > >=0A> > > > > > = > > > 1) For ISATAP/VET routers that have assurance that their=0A> > > > > = > > > > neighbor cache is coherent, the router can make a simple=0A> > > > = > > > > > check in the neighbor cache to determine whether to=0A> > > > > >= > > > forward or drop the packet. In pseudo-code:=0A> > > > > > > > >=0A> = > > > > > > > > =A0 isatap_rcv() {=0A> > > > > > > > > =A0 =A0 ...=0A> > > = > > > > > > =A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*")= )=0A> > > > > > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > =A0 =A0 .= ..=0A> > > > > > > > > =A0 }=0A> > > > > > > > >=0A> > > > > > > > > =A0 is= atap_xmt() {=0A> > > > > > > > > =A0 =A0 ...=0A> > > > > > > > > =A0 =A0 if= ((v6dst is not a neighbor) && (v6src !=3D "fe80::*"))=0A> > > > > > > > > = =A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > =A0 =A0 ...=0A> > > > > > > > >= =A0 }=0A> > > > > > > > >=0A> > > > > > > > > (Here, the link-local except= ion is necessary to bootstrap=0A> > > > > > > > > neighbor discovery on the= ISATAP link.)=0A> > > > > > > > >=0A> > > > > > > > > Does anyone see a pr= oblem with this?=0A> > > > > > > > >=0A> > > > > > > > Looks fine.=0A> > > = > > > >=0A> > > > > > > OK.=0A> > > > > > >=0A> > > > > >=0A> > > > > > On = second thought, a couple of comments:=0A> > > > > > 1) According to RFC 521= 4 Section 8.3.4:=0A> > > > > > =A0=A0=A0=A0=A0=A0=A0" ISATAP nodes MAY sche= dule periodic Router Solicitation events=0A> > > > > > =A0=A0 =A0=A0=A0 for= certain PRL(i)s by setting the corresponding TIMER(i)."=0A> > > > > > As I= understand, this means that there is a possibility for a host=A0not=0A> > = > to=A0send=0A> > > > > RSs to all routers in=0A> > > > > > the PRL. Howeve= r, any router in the PRL may forward packets into the=0A> > > ISATAP=0A> > = > > > link. The isatap_xmt()=0A> > > > > > check will prevent forwarding pa= ckets by routers which the =0A> destination=A0has=0A> > > not=0A> > > > > p= reviously sent RS to.=0A> > > > > > If I am correct then this check=A0may b= reak ISATAP connectivity.=0A> > > > >=0A> > > > > I don't think this is a p= roblem. If a host has not sent an RS to=0A> > > > > a PRL router, then it s= hould not have configured a default route=0A> > > > > nor any prefix inform= ation specific to that router. Therefore,=0A> > > > > the only packets the = host and router should expect to exchange=0A> > > > > in this state are lin= k-local. As such, the router can discard=0A> > > > > non-link-local packets= if there is no neighbor cache entry.=0A> > > > >=0A> > > >=0A> > > > I was= thinking=A0of a case of two routers in the PRL advertising the same =0A> p= refix=0A> > > for the ISATAP=0A> > > > link.=A0Either routers obviously may= forward packets _into_ the ISATAP link =0A> to=0A> > > any host. If a host= =A0will=0A> > > > not send=A0a RS to one of those routers=A0then=A0it will = drop packets destined =0A> to=0A> > > that host.=0A> > >=0A> > > I'm actual= ly OK with that. If two routers A and B advertise=0A> > > the same prefix P= , and if B doesn't know about host H either=0A> > > through receiving RSs o= r through talking to A, then B should=0A> > > not forward packets to H.=0A>= > >=0A> > > Thanks - Fred=0A> > > fred.l.templin@boeing.com=0A> > >=0A> > = > > > > 2) I remind you a comment you made in the past: for the checks to = =0A> work=A0the=0A> > > > > time between two=0A> > > > > > consequtive RSs = from a host to a=A0router should be no greater than the =0A> the=0A> > > > = > lifetime of an entry for=0A> > > > > > that host in the router's neighbor= s cache.=A0This is needed=A0to ensure=0A> > > that=A0the=0A> > > > > entry = in the neighbors=0A> > > > > > cache will not be erased. This raises two qu= estions:=0A> > > > > > =A0=A0=A0 a) AFAIK there is no minimum lifetime for = an entry in a neighbors=0A> > > cache=0A> > > > > -=A0it is an implementati= on=0A> > > > > > detail.=A0If this is true=A0how can we enforce the above c= onstraint?=0A> > > > >=0A> > > > > Correct that there is no minimum lifetim= e for neighbor cache=0A> > > > > entries specified by RFC4861. However, an = ISATAP router that=0A> > > > > uses the neighbor cache checking procedures = I have described=0A> > > > > can use its own discipline for managing its ne= ighbor cache.=0A> > > > > Exactly such a discipline is now specified in Sec= tion 5.4.1=0A> > > > > of 'draft-templin-intarea-vet'. Please be aware that= ISATAP=0A> > > > > and VET are simply "IPv6-over-(foo)" specifications, an= d=0A> > > > > RFC4861 permits that operations of the neighbor discovery=0A>= > > > > protocol that are specific to (foo) links may be specified=0A> > >= > > in such documents.=0A> > > > >=0A> > > >=0A> > > > OK.=0A> > > >=0A> >= > > > > =A0=A0=A0 b) A router's neighbors cache=A0must now=A0include at an= y given moment =0A> all=0A> > > the=0A> > > > > active ISATAP nodes in=0A> = > > > > > the ISATAP link. Is this a reasonable demand?=0A> > > > >=0A> > >= > > Memory should be cheap enough, and ISATAP links within private=0A> > >= > > addressing realms should be small enough, that I do not see this=0A> >= > > > as an unreasonable demand.=0A> > > > >=0A> > > >=0A> > > > OK.=0A> >= > >=0A> > > > > > > > > 2) For ISATAP/VET routers that use public IPv4 add= resses=0A> > > > > > > > > and that do not have assurance that their neighb= or cache=0A> > > > > > > > > is coherent, the router can check for the inte= rface ID=0A> > > > > > > > > "0200:5EFE:". In pseudo-code:=0A> > > > > > > = > >=0A> > > > > > > > > =A0 isatap_rcv() {=0A> > > > > > > > > =A0 =A0 ...= =0A> > > > > > > > > =A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:")= =0A> > > > > > > > > =A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > =A0 =A0 ..= .=0A> > > > > > > > > =A0 }=0A> > > > > > > > >=0A> > > > > > > > > =A0 isa= tap_xmt() {=0A> > > > > > > > > =A0 =A0 ...=0A> > > > > > > > > =A0 =A0 if = (v6src =3D=3D "foreign_prefix::0200:5efe:")=0A> > > > > > > > > =A0 =A0 =A0= drop_pkt();=0A> > > > > > > > > =A0 =A0 ...=0A> > > > > > > > > =A0 }=0A> = > > > > > > > >=0A> > > > > > > > > Does anyone see a problem with this?=0A= > > > > > > > >=0A> > > > > > > > Looks fine.=0A> > > > > > >=0A> > > > > >= > OK, but since I sent this I began to wonder whether cases=0A> > > > > > = > 1) and 2) should be reversed (i.e., do the 0x00:5EFE check=0A> > > > > > = > first). I came to believe that it almost doesn't matter=0A> > > > > > > f= rom a performance standpoint, and perhaps should be left=0A> > > > > > > up= to the implementer. Do you have an opinion on this?=0A> > > > > > >=0A> > = > > > > > > > 3) For ISATAP/VET routers that use private IPv4 addresses=0A>= > > > > > > > > and that do not have assurance that their neighbor cache= =0A> > > > > > > > > is coherent, the router can make the checks that Chris= tian=0A> > > > > > > > > has proposed. But, will we see any of these case 3= )=0A> > > > > > > > > situations in operational practice?=0A> > > > > > > >= >=0A> > > > > > > >=0A> > > > > > > > I can not tell for sure. Why this ca= se seems to you less plausible=0A> > > than=0A> > > > > case=0A> > > > > > = > 2?=0A> > > > > > >=0A> > > > > > > Case 3) is the case in which source ad= dress spoofing within=0A> > > > > > > a private IPv4 addressing range is po= ssible. It seems to me=0A> > > > > > > that it may correspond to either a p= oorly managed deployment,=0A> > > > > > > or one in which there are multipl= e administrative authorities=0A> > > > > > > with diverse policies and oper= ational practices.=0A> > > > > > >=0A> > > > > >=0A> > > > > > I agree. How= ever, remember that the spoofed packet may also originate =0A> from=0A> > >= > > within the site, which is=0A> > > > > > very hard to defend against.= =0A> > > > >=0A> > > > > Spoofing is not so hard to defend against if Secur= e Neighbor=0A> > > > > Discovery (SEND) is used to set up the neighbor rela= tionships=0A> > > > > and if every packet carries a nonce that can be used = to detect=0A> > > > > an off-path attack.=0A> > > >=0A> > > > I agree again= . I was referring to the case where SEND is not deployed.=0A> > > >=0A> > >= > > That is only the case for VET and SEAL,=0A> > > > > however, so if sou= rce address spoofing within the site is seen=0A> > > > > as a problem then = VET and SEAL should be used instead of ISATAP.=0A> > > > >=0A> > > > > Note= that for the sake of consistency it might be helpful to=0A> > > > > consid= er VET as simply "ISATAP version 2 (ISATAPv2)".=0A> > > > >=0A> > > > > Fre= d=0A> > > > > fred.l.templin@boeing.com=0A> > > > >=0A> > > > > > > The che= cks that Christian proposed could be used for this=0A> > > > > > > scenario= if possible. Otherwise, the best solution IMHO=0A> > > > > > > would be to= allow only routers (and not hosts) on the=0A> > > > > > > virtual links. T= his final model would be best addressed=0A> > > > > > > by VET and SEAL rat= her than ISATAP.=0A> > > > > > >=0A> > > > > > > Thanks - Fred=0A> > > > > = > > fred.l.templin@boeing.com=0A> > > >=0A> > > > _________________________= _________________________=0A> > > > Do You Yahoo!?=0A> > > > Tired of spam?= =A0 Yahoo! Mail has the best spam protection around=0A> > > > http://mail.y= ahoo.com=0A> > =0A> > =0A> > =0A> > =0A=0A=0A=0A From owner-v6ops@ops.ietf.org Mon Oct 5 16:14:15 2009 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 7D0FB3A689D for ; Mon, 5 Oct 2009 16:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.169 X-Spam-Level: X-Spam-Status: No, score=-100.169 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, 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 Il1c0XBubiqi for ; Mon, 5 Oct 2009 16:14:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B6F83A6818 for ; Mon, 5 Oct 2009 16:14:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuwiZ-000Mhd-Ta for v6ops-data0@psg.com; Mon, 05 Oct 2009 23:11:47 +0000 Received: from [58.68.145.64] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuwiP-000MgZ-MZ for v6ops@ops.ietf.org; Mon, 05 Oct 2009 23:11:45 +0000 Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 4.0.0.0) with SMTP id jm94acac6b1; Tue, 06 Oct 2009 06:33:56 +0800 Received: from mail.ietf.org([127.0.0.1]) by people.com.cn(AIMC 4.0.0.0) with SMTP id jmc64aa7302a; Wed, 09 Sep 2009 09:29:13 +0800 Received: from mail.ietf.org([64.170.98.32]) by aisp.com(AIMC 3.2.0.0) with SMTP id AISP action; Wed, 09 Sep 2009 09:29:13 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9643A6A13; Tue, 8 Sep 2009 19:15:03 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A020F3A691A; Tue, 8 Sep 2009 19:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-v6ops-v6inixp-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090909021501.A020F3A691A@core3.amsl.com> Date: Tue, 8 Sep 2009 19:15:01 -0700 (PDT) Cc: v6ops@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: bXuzLlWB X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : IPv6 Deployment in Internet Exchange Points (IXPs) Author(s) : R. Gagliano Filename : draft-ietf-v6ops-v6inixp-02.txt Pages : 10 Date : 2009-09-08 This document provides a guide for IPv6 deployment in Internet Exchange Points (IXP). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks to be performed. IXPs are mainly a layer 2 infrastructure and in many case the best recommendations state that the IPv6 data, control and management plane should not be handled differently than in IPv4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6inixp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-v6inixp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-08190013.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 5 16:53:16 2009 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 659AD28C151 for ; Mon, 5 Oct 2009 16:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=-1.974, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3, 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 WlCR5jTBn9Uw for ; Mon, 5 Oct 2009 16:53:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 295453A68DD for ; Mon, 5 Oct 2009 16:53:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuxKI-000PvO-38 for v6ops-data0@psg.com; Mon, 05 Oct 2009 23:50:46 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuxK7-000Ptw-AM for v6ops@ops.ietf.org; Mon, 05 Oct 2009 23:50:43 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n95NoXZn004792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2009 18:50:34 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n95NoX94022534; Mon, 5 Oct 2009 16:50:33 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n95NoXhA022531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 5 Oct 2009 16:50:33 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Mon, 5 Oct 2009 16:50:33 -0700 From: "Templin, Fred L" To: Gabi Nakibly CC: v6ops Date: Mon, 5 Oct 2009 16:50:31 -0700 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcpGAmMloY/nTL9aTXeHUgaLgWldBgAEZ4/Q Message-ID: <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.com> References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> <339077.93936.q!m@web45512.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> <866685.67299.qm@web45511.mail.sp1.yahoo.com> In-Reply-To: <866685.67299.qm@web45511.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: Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, October 05, 2009 2:24 PM > To: Templin, Fred L > Cc: v6ops > Subject: Re: Routing loop attacks using IPv6 tunnels > > On first thought, setting up a synchronization mechanism of the neighbor = caches at the routers does > not sound, IMHO, like the best solution. It will probably add complexity = and interdependence to the > routers' functionality. > Maybe a good trade-off would be to first require a host to send an initia= l RS to every router in the > PRL. Then after the host learns the advertised prefix of each router the = host should continue sending > RSs (or stop sending) to all routers advertising the same prefix. I understand what you're saying, but here's the temptation. Lets say that ISATAP routers A and B both advertise prefix P::/64, then the ISATAP site partitions and the only way A and B can still talk to each other is via the provider network. The temptation part is that if A and B talk to each other over the provider network then they can keep track of the ISATAP hosts in each partition that configure an address from P::/64 and seemingly can "heal" the partition by forwarding misdirected packets to each other across the provider network. But then, we are guilty of "conspiracy to create a multilink subnet" (see RFC4903 for multi-link subnet issues). This suggests that, if multiple ISATAP routers are to advertise a shared prefix P::/64, then there either needs to be strong assurance that the site won't partition. If that condition cannot be met, then each ISATAP router must advertise a distinct prefix. Do you see any other way? Fred fred.l.templin@boeing.com > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly > > Cc: v6ops > > Sent: Mon, October 5, 2009 10:41:16 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, October 05, 2009 1:32 PM > > > To: Templin, Fred L > > > Cc: v6ops > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Fred, > > > With regrad to your comment below: if indeed an ISATAP router will no= t > > forward packets to an > > > ISATAP host it has not recently received RS from, then I think that t= he ISATAP > > specification > > > should at least require an ISATAP host (using a SHOULD) to regularly = send RSs > > to _all_ routers in the > > > PRL, or else ISATAP connectivity may be broken. > > > > Yes, "ping them all" is certainly one way to ensure a nbr > > cache entry at each PRL router. I was also starting to > > think that another solution would be for PRL routers that > > advertise a shared IP prefx (e.g., 2001:DB8::/64) to > > somehow synchronize their neighbor caches. For that > > matter, it might be best to do both because you can > > never tell which subset of the PRLs is the correct > > subset to ping. > > > > Fred > > fred.l.templin@boeing.com > > > > > Gabi > > > > > > ----- Original Message ---- > > > > From: "Templin, Fred L" > > > > To: Gabi Nakibly > > > > Cc: v6ops > > > > Sent: Thu, October 1, 2009 6:49:31 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Hi Gabi, > > > > > > > > > -----Original Message----- > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > Sent: Thursday, October 01, 2009 6:53 AM > > > > > To: Templin, Fred L > > > > > Cc: v6ops > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > Removed the 6man and secdir mailing lists from the Cc. > > > > > > > > > > Fred, see comments below. > > > > > > > > > > ----- Original Message ---- > > > > > > From: "Templin, Fred L" > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > ; v6ops > > > > > > > > > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" > > > > > > Sent: Tuesday, September 29, 2009 6:00:55 PM > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > Gabi, > > > > > > > > > > > > Welcome back from your vacation. I trimmed quite a bit from > > > > > > the bottom of this message to eliminate the clutter, but see > > > > > > below for responses to your current comments: > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > Sent: Tuesday, September 29, 2009 3:22 AM > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > Hi Fred, > > > > > > > Back from vacation. See Comments inlines. > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > > > From: "Templin, Fred L" > > > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > > > ; v6ops > > > > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > Sent: Friday, September 11, 2009 11:13:44 PM > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > Hi Gabi, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > > > Sent: Friday, September 11, 2009 12:59 PM > > > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > > > > > From: "Templin, Fred L" > > > > > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > > > > > ; v6ops > > > > > > > > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > > > Sent: Tuesday, September 8, 2009 8:37:03 PM > > > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > > > > > Gabi and Christian, > > > > > > > > > > > > > > > > > > > > Focusing only on attack #3 (i.e., leaving out attack #1 > > > > > > > > > > and #2 6to4 interactions for the moment), please check > > > > > > > > > > the following summary of proposed mitigations: > > > > > > > > > > > > > > > > > > > > 1) For ISATAP/VET routers that have assurance that thei= r > > > > > > > > > > neighbor cache is coherent, the router can make a simpl= e > > > > > > > > > > check in the neighbor cache to determine whether to > > > > > > > > > > forward or drop the packet. In pseudo-code: > > > > > > > > > > > > > > > > > > > > isatap_rcv() { > > > > > > > > > > ... > > > > > > > > > > if ((v6src is not a neighbor) && (v6dst !=3D "fe80:= :*")) > > > > > > > > > > drop_pkt(); > > > > > > > > > > ... > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > isatap_xmt() { > > > > > > > > > > ... > > > > > > > > > > if ((v6dst is not a neighbor) && (v6src !=3D "fe80:= :*")) > > > > > > > > > > drop_pkt(); > > > > > > > > > > ... > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > (Here, the link-local exception is necessary to bootstr= ap > > > > > > > > > > neighbor discovery on the ISATAP link.) > > > > > > > > > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > > > > > > > > > Looks fine. > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > > > > On second thought, a couple of comments: > > > > > > > 1) According to RFC 5214 Section 8.3.4: > > > > > > > " ISATAP nodes MAY schedule periodic Router Solicitati= on events > > > > > > > for certain PRL(i)s by setting the corresponding TIMER= (i)." > > > > > > > As I understand, this means that there is a possibility for a= host not > > > > to send > > > > > > RSs to all routers in > > > > > > > the PRL. However, any router in the PRL may forward packets i= nto the > > > > ISATAP > > > > > > link. The isatap_xmt() > > > > > > > check will prevent forwarding packets by routers which the > > destination has > > > > not > > > > > > previously sent RS to. > > > > > > > If I am correct then this check may break ISATAP connectivity= . > > > > > > > > > > > > I don't think this is a problem. If a host has not sent an RS t= o > > > > > > a PRL router, then it should not have configured a default rout= e > > > > > > nor any prefix information specific to that router. Therefore, > > > > > > the only packets the host and router should expect to exchange > > > > > > in this state are link-local. As such, the router can discard > > > > > > non-link-local packets if there is no neighbor cache entry. > > > > > > > > > > > > > > > > I was thinking of a case of two routers in the PRL advertising th= e same > > prefix > > > > for the ISATAP > > > > > link. Either routers obviously may forward packets _into_ the ISA= TAP link > > to > > > > any host. If a host will > > > > > not send a RS to one of those routers then it will drop packets d= estined > > to > > > > that host. > > > > > > > > I'm actually OK with that. If two routers A and B advertise > > > > the same prefix P, and if B doesn't know about host H either > > > > through receiving RSs or through talking to A, then B should > > > > not forward packets to H. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > > > 2) I remind you a comment you made in the past: for the check= s to > > work the > > > > > > time between two > > > > > > > consequtive RSs from a host to a router should be no greater = than the > > the > > > > > > lifetime of an entry for > > > > > > > that host in the router's neighbors cache. This is needed to = ensure > > > > that the > > > > > > entry in the neighbors > > > > > > > cache will not be erased. This raises two questions: > > > > > > > a) AFAIK there is no minimum lifetime for an entry in a n= eighbors > > > > cache > > > > > > - it is an implementation > > > > > > > detail. If this is true how can we enforce the above constrai= nt? > > > > > > > > > > > > Correct that there is no minimum lifetime for neighbor cache > > > > > > entries specified by RFC4861. However, an ISATAP router that > > > > > > uses the neighbor cache checking procedures I have described > > > > > > can use its own discipline for managing its neighbor cache. > > > > > > Exactly such a discipline is now specified in Section 5.4.1 > > > > > > of 'draft-templin-intarea-vet'. Please be aware that ISATAP > > > > > > and VET are simply "IPv6-over-(foo)" specifications, and > > > > > > RFC4861 permits that operations of the neighbor discovery > > > > > > protocol that are specific to (foo) links may be specified > > > > > > in such documents. > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > b) A router's neighbors cache must now include at any giv= en moment > > all > > > > the > > > > > > active ISATAP nodes in > > > > > > > the ISATAP link. Is this a reasonable demand? > > > > > > > > > > > > Memory should be cheap enough, and ISATAP links within private > > > > > > addressing realms should be small enough, that I do not see thi= s > > > > > > as an unreasonable demand. > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > 2) For ISATAP/VET routers that use public IPv4 addresse= s > > > > > > > > > > and that do not have assurance that their neighbor cach= e > > > > > > > > > > is coherent, the router can check for the interface ID > > > > > > > > > > "0200:5EFE:". In pseudo-code: > > > > > > > > > > > > > > > > > > > > isatap_rcv() { > > > > > > > > > > ... > > > > > > > > > > if (v6dst =3D=3D "foreign_prefix::0200:5efe:") > > > > > > > > > > drop_pkt(); > > > > > > > > > > ... > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > isatap_xmt() { > > > > > > > > > > ... > > > > > > > > > > if (v6src =3D=3D "foreign_prefix::0200:5efe:") > > > > > > > > > > drop_pkt(); > > > > > > > > > > ... > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > > > > > > > > Looks fine. > > > > > > > > > > > > > > > > OK, but since I sent this I began to wonder whether cases > > > > > > > > 1) and 2) should be reversed (i.e., do the 0x00:5EFE check > > > > > > > > first). I came to believe that it almost doesn't matter > > > > > > > > from a performance standpoint, and perhaps should be left > > > > > > > > up to the implementer. Do you have an opinion on this? > > > > > > > > > > > > > > > > > > 3) For ISATAP/VET routers that use private IPv4 address= es > > > > > > > > > > and that do not have assurance that their neighbor cach= e > > > > > > > > > > is coherent, the router can make the checks that Christ= ian > > > > > > > > > > has proposed. But, will we see any of these case 3) > > > > > > > > > > situations in operational practice? > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can not tell for sure. Why this case seems to you less = plausible > > > > than > > > > > > case > > > > > > > > 2? > > > > > > > > > > > > > > > > Case 3) is the case in which source address spoofing within > > > > > > > > a private IPv4 addressing range is possible. It seems to me > > > > > > > > that it may correspond to either a poorly managed deploymen= t, > > > > > > > > or one in which there are multiple administrative authoriti= es > > > > > > > > with diverse policies and operational practices. > > > > > > > > > > > > > > > > > > > > > > I agree. However, remember that the spoofed packet may also o= riginate > > from > > > > > > within the site, which is > > > > > > > very hard to defend against. > > > > > > > > > > > > Spoofing is not so hard to defend against if Secure Neighbor > > > > > > Discovery (SEND) is used to set up the neighbor relationships > > > > > > and if every packet carries a nonce that can be used to detect > > > > > > an off-path attack. > > > > > > > > > > I agree again. I was referring to the case where SEND is not depl= oyed. > > > > > > > > > > > That is only the case for VET and SEAL, > > > > > > however, so if source address spoofing within the site is seen > > > > > > as a problem then VET and SEAL should be used instead of ISATAP= . > > > > > > > > > > > > Note that for the sake of consistency it might be helpful to > > > > > > consider VET as simply "ISATAP version 2 (ISATAPv2)". > > > > > > > > > > > > Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > The checks that Christian proposed could be used for this > > > > > > > > scenario if possible. Otherwise, the best solution IMHO > > > > > > > > would be to allow only routers (and not hosts) on the > > > > > > > > virtual links. This final model would be best addressed > > > > > > > > by VET and SEAL rather than ISATAP. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon Oct 5 17:44:30 2009 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 DF3CE3A6782 for ; Mon, 5 Oct 2009 17:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 HFun85aGA81V for ; Mon, 5 Oct 2009 17:44:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E33523A67EC for ; Mon, 5 Oct 2009 17:44:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muy74-0004u9-3I for v6ops-data0@psg.com; Tue, 06 Oct 2009 00:41:10 +0000 Received: from [2001:4f8:0:1::23:2] (helo=afribone.trstech.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muy6r-0004tR-RF for v6ops@ops.ietf.org; Tue, 06 Oct 2009 00:41:07 +0000 Received: from [41.207.162.5] (helo=[192.168.1.12]) by afribone.trstech.net with esmtpa (Exim 4.69) (envelope-from ) id 1Muxnn-00062W-20; Tue, 06 Oct 2009 00:21:35 +0000 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-19--542968459 From: ALAIN AINA In-Reply-To: Date: Tue, 6 Oct 2009 00:40:21 +0000 Cc: v6ops WG Message-Id: <98E78CDB-C9DD-4DCD-8825-95668028969E@trstech.net> References: <20090909020014.0D00128C1DA@core3.amsl.com> To: Roque Gagliano X-Mailer: Apple Mail (2.1075.2) X-SA-Exim-Connect-IP: 41.207.162.5 X-SA-Exim-Mail-From: aalain@afribone.trstech.net Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 X-SA-Exim-Version: 4.2.1 (built Tue, 15 Jul 2008 18:57:52 +0000) X-SA-Exim-Scanned: Yes (on afribone.trstech.net) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-19--542968459 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 9, 2009, at 2:25 AM, Roque Gagliano wrote: > Hi, > > I issued a new ID of the draft with the changes that came up at the > Stockholm meeting. Changes were: > - I explained why ULA is not a good idea. > - I added that addressing can use two different /48, one for the > LANs and the second one for the internal services and not > necessarily one /47, as comments at the meeting. > - I included comments from Nick Hilliar about BGP sessions. > - I added text about having different participants in different > solocited-node multicast group. > - I mention of RA-Guard based on comments from Nick Hilliar. > > I will now request Alain and Bernard to review the doc as they are > the WG volunteers. attached is a .doc version with my comments hope this helps --alain > > Regards, > > Roque. > > > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: September 8, 2009 11:00:14 PM GMT-03:00 >> To: roque@lacnic.net >> Subject: New Version Notification for draft-ietf-v6ops-v6inixp-02 >> >> >> A new version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been >> successfuly submitted by Roque Gagliano and posted to the IETF >> repository. >> >> Filename: draft-ietf-v6ops-v6inixp >> Revision: 02 >> Title: IPv6 Deployment in Internet Exchange Points (IXPs) >> Creation_date: 2009-09-08 >> WG ID: v6ops >> Number_of_pages: 10 >> >> Abstract: >> This document provides a guide for IPv6 deployment in Internet >> Exchange Points (IXP). It includes information regarding the switch >> fabric configuration, the addressing plan and general organizational >> tasks to be performed. IXPs are mainly a layer 2 infrastructure and >> in many case the best recommendations state that the IPv6 data, >> control and management plane should not be handled differently than >> in IPv4. >> >> >> >> The IETF Secretariat. >> > > ------------------------------------------------------------- > Roque Gagliano > LACNIC > roque@lacnic.net > GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE > --Apple-Mail-19--542968459 Content-Type: multipart/mixed; boundary=Apple-Mail-20--542968458 --Apple-Mail-20--542968458 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

I = issued a new ID of the draft with the changes that came up at the = Stockholm meeting. Changes were:
- I explained why ULA is not = a good idea.
- I added that addressing can use two different = /48, one for the LANs and the second one for the internal services and = not necessarily one /47, as comments at the meeting.
- I = included comments from Nick Hilliar about BGP sessions.
- I = added text about having different participants in = different solocited-node multicast group.
- I mention of = RA-Guard based on comments from Nick Hilliar.

I = will now request Alain and Bernard to review the doc as they are the WG = volunteers.


attached= is a .doc version with my = comments


hope this = helps

--alain
= --Apple-Mail-20--542968458 Content-Disposition: attachment; filename=aina-review-of-draft-ietf-v6ops-v6inixp-02.doc Content-Type: application/msword; name="aina-review-of-draft-ietf-v6ops-v6inixp-02.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAfgAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 //////////7///8EAAAABQAAAAYAAAAHAAAACAAAAP7///8KAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABz AAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAP7///9/AAAA/v///1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAAQAA AP7////+////BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA/v///ykAAAAqAAAA/v///ywA AAD+//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8BAP7/ AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkLURva3VtZW50AAoAAABN U1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAASABUACgABAFsADwACAAAAAAAAAFgAABDx/wIAWAAAAAcARABlAGYA YQB1AGwAdAAAAAgAAAAxJAAqJAEvAEIqAE9KAwBRSgMAQ0oYAG1ICQBzSAkAUEoEAG5I/wBeSgUA YUoYAF9I/wB0SP8AAAAAAAAAAAAAAAAAAAAAAAAAAEIAQUDy/6EAQgAAABkAQQBiAHMAYQB0AHoA LQBTAHQAYQBuAGQAYQByAGQAcwBjAGgAcgBpAGYAdABhAHIAdAAAAAAAAAAAAAAAAABGAP4fAQAC AUYAAAAHAEgAZQBhAGQAaQBuAGcAAAANAA8AE6TwABSkeAAGJAEAGABPSgcAUUoHAENKHABQSgQA XkoFAGFKHAAuAEIQAQACAS4AAAAJAFQAZQB4AHQAIABiAG8AZAB5AAAACgAQABOkAAAUpHgAAAAg AC8QAQESASAAAAAEAEwAaQBzAHQAAAACABEABABeSggAQAD+HwEAIgFAAAAABwBDAGEAcAB0AGkA bwBuAAAADQASABOkeAAUpHgADCQBABIAQ0oYADYIAV5KCABhShgAXQgBJgD+HwEAMgEmAAAABQBJ AG4AZABlAHgAAAAFABMADCQBAAQAXkoIAFYA/h8BAEIBVgAAABEAUAByAGUAZgBvAHIAbQBhAHQA dABlAGQAIABUAGUAeAB0AAAACgAUABOkAAAUpAAAGABPSgkAUUoJAENKFABQSgkAXkoJAGFKFAAK AEEAbABhAGkAbgAgAEEASQBOAEEA4y3aJgAAAAAAAAAAAAAAAAAAGjDaRgAAAAAAAAAAAAAAAAAA SiYAACYqAABfUgAACQBBAGwAYQBpAG4AIABBAEkATgAAAAAAAAD/////CQBBAGwAYQBpAG4AIABB AEkATgAAAAAAAAD/////AAAAACEBAABwAQAAcQEAAAAAAADQUwAABAAA6AAAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAA+rwAAnq8A AFgAAABZAAAAAAgAAK4OAABqFQAA3hsAAM4iAAA8JAAA0CwAAMo3AAAqPgAAykgAAP5NAADuVAAA cF0AAG5mAAAIcgAAsHoAAJyCAAA+iQAACI8AAJSVAACUmwAA9KMAACCpAAD0qwAAJKwAAMiuAACg rwAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcA AABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAD//wIAAAAH AFUAbgBrAG4AbwB3AG4ACgBBAGwAYQBpAG4AIABBAEkATgBBAAAAAADQUwAAAAAAAAIQAAAAAAAA ANBTAABQAAAIAAAAAAoAAABHFpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA VABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAQQByAGkAYQBsAAAARxaQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAASQaQAYAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAA1 BpABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVABhAGgAbwBtAGEAAABDJJAB gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAB1AGMAaQBkAGEAIABHAHIAYQBu AGQAZQAAADMmkAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAHIAaQBhAGwA AAA1BJABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVABhAGgAbwBtAGEAAAA/ NZABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4A ZQB3AAAAQgAEAAGIjRgAAMUCAABoAQAAAAAAAAAAAAAAAAAAAAABAAAAAADzCwAAClAAAAsAWAEA AAQAg5BYAQAA8wsAAApQAAALAFgBAABYAQAAAAAAACcDACAAAAAAAAQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAASMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAA AAAgAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAEAAgAA AAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAfAAAAAYAAAABAAAAOAAAAAkA AABAAAAACgAAAEwAAAALAAAAWAAAAAwAAABkAAAADQAAAHAAAAACAAAA6f0AAB4AAAACAAAAMAAA AEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/v8AAAEAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rlwAAAAYAAAAAQAAAAEAAAAQAAAAAgAAAOn9AAAYAAAAAQAAAAEA AAAQAAAAAgAAAOn9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADspQEBTSAJBAAA ABK/AAAAAAAAMAAAAAAACAAAoK8AAA4AQ2FvbGFuODAAAAAAAAAAAAAAAAAAAAAAAAAJBBYAJOgA AAAAAAAAAAAAXlIAAAAAAAAAAAAAAAAAAHEBAAAAAAAAAAAAAAAAAAD//w8AWAAAAAIAAAD//w8A WgAAABoAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAACgCAAAAAAAAKAIAAAAAAAAAAAAAAAAA AAAAAABiAgAASAAAAKoCAAAQAAAAugIAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAM4CAAA0AAAAAgMAABQAAAAWAwAA1AAAAAAAAAAAAAAANwQAAGwCAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACjBgAAYgIA AAAAAAAAAAAAIgQAABUAAAAAAAAAAAAAAAAAAAAAAAAAKAIAABYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6gMAACwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgQAAAwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgDZAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA+AgAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAEBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0ADQANAEkAbgB0AGUA cgBuAGUAdAAgAEUAbgBnAGkAbgBlAGUAcgBpAG4AZwAgAFQAYQBzAGsAIABGAG8AcgBjAGUAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA UgAuACAARwBhAGcAbABpAGEAbgBvAA0ASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAATABBAEMATgBJAEMADQBJ AG4AdABlAG4AZABlAGQAIABzAHQAYQB0AHUAcwA6ACAASQBuAGYAbwByAG0AYQB0AGkAbwBuAGEA bAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABTAGUAcAB0 AGUAbQBiAGUAcgAgADAAOAAsACAAMgAwADAAOQANAEUAeABwAGkAcgBlAHMAOgAgAE0AYQByAGMA aAAgADEAMgAsACAAMgAwADEAMAANAA0ADQAgACAAIAAgACAAIAAgACAAIAAgACAASQBQAHYANgAg AEQAZQBwAGwAbwB5AG0AZQBuAHQAIABpAG4AIABJAG4AdABlAHIAbgBlAHQAIABFAHgAYwBoAGEA bgBnAGUAIABQAG8AaQBuAHQAcwAgACgASQBYAFAAcwApAA0AIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQB2ADYAbwBwAHMALQB2ADYA aQBuAGkAeABwAC0AMAAyAC4AdAB4AHQADQANAFMAdABhAHQAdQBzACAAbwBmACAAdABoAGkAcwAg AE0AZQBtAG8ADQANACAAIAAgAFQAaABpAHMAIABJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQA IABpAHMAIABzAHUAYgBtAGkAdAB0AGUAZAAgAHQAbwAgAEkARQBUAEYAIABpAG4AIABmAHUAbABs ACAAYwBvAG4AZgBvAHIAbQBhAG4AYwBlACAAdwBpAHQAaAAgAHQAaABlAA0AIAAgACAAcAByAG8A dgBpAHMAaQBvAG4AcwAgAG8AZgAgAEIAQwBQACAANwA4ACAAYQBuAGQAIABCAEMAUAAgADcAOQAu AA0ADQAgACAAIABJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAcwAgAGEAcgBlACAAdwBvAHIA awBpAG4AZwAgAGQAbwBjAHUAbQBlAG4AdABzACAAbwBmACAAdABoAGUAIABJAG4AdABlAHIAbgBl AHQAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcADQAgACAAIABUAGEAcwBrACAARgBvAHIAYwBlACAA KABJAEUAVABGACkALAAgAGkAdABzACAAYQByAGUAYQBzACwAIABhAG4AZAAgAGkAdABzACAAdwBv AHIAawBpAG4AZwAgAGcAcgBvAHUAcABzAC4AIAAgAE4AbwB0AGUAIAB0AGgAYQB0AA0AIAAgACAA bwB0AGgAZQByACAAZwByAG8AdQBwAHMAIABtAGEAeQAgAGEAbABzAG8AIABkAGkAcwB0AHIAaQBi AHUAdABlACAAdwBvAHIAawBpAG4AZwAgAGQAbwBjAHUAbQBlAG4AdABzACAAYQBzACAASQBuAHQA ZQByAG4AZQB0AC0ADQAgACAAIABEAHIAYQBmAHQAcwAuAA0ADQAgACAAIABJAG4AdABlAHIAbgBl AHQALQBEAHIAYQBmAHQAcwAgAGEAcgBlACAAZAByAGEAZgB0ACAAZABvAGMAdQBtAGUAbgB0AHMA IAB2AGEAbABpAGQAIABmAG8AcgAgAGEAIABtAGEAeABpAG0AdQBtACAAbwBmACAAcwBpAHgAIABt AG8AbgB0AGgAcwANACAAIAAgAGEAbgBkACAAbQBhAHkAIABiAGUAIAB1AHAAZABhAHQAZQBkACwA IAByAGUAcABsAGEAYwBlAGQALAAgAG8AcgAgAG8AYgBzAG8AbABlAHQAZQBkACAAYgB5ACAAbwB0 AGgAZQByACAAZABvAGMAdQBtAGUAbgB0AHMAIABhAHQAIABhAG4AeQANACAAIAAgAHQAaQBtAGUA LgAgACAASQB0ACAAaQBzACAAaQBuAGEAcABwAHIAbwBwAHIAaQBhAHQAZQAgAHQAbwAgAHUAcwBl ACAASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0AHMAIABhAHMAIAByAGUAZgBlAHIAZQBuAGMA ZQANACAAIAAgAG0AYQB0AGUAcgBpAGEAbAAgAG8AcgAgAHQAbwAgAGMAaQB0AGUAIAB0AGgAZQBt ACAAbwB0AGgAZQByACAAdABoAGEAbgAgAGEAcwAgACIAdwBvAHIAawAgAGkAbgAgAHAAcgBvAGcA cgBlAHMAcwAuACIADQANACAAIAAgAFQAaABlACAAbABpAHMAdAAgAG8AZgAgAGMAdQByAHIAZQBu AHQAIABJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAcwAgAGMAYQBuACAAYgBlACAAYQBjAGMA ZQBzAHMAZQBkACAAYQB0AA0AIAAgACAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBv AHIAZwAvAGkAZQB0AGYALwAxAGkAZAAtAGEAYgBzAHQAcgBhAGMAdABzAC4AdAB4AHQALgANAA0A IAAgACAAVABoAGUAIABsAGkAcwB0ACAAbwBmACAASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0 ACAAUwBoAGEAZABvAHcAIABEAGkAcgBlAGMAdABvAHIAaQBlAHMAIABjAGEAbgAgAGIAZQAgAGEA YwBjAGUAcwBzAGUAZAAgAGEAdAANACAAIAAgAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABm AC4AbwByAGcALwBzAGgAYQBkAG8AdwAuAGgAdABtAGwALgANAA0AIAAgACAAVABoAGkAcwAgAEkA bgB0AGUAcgBuAGUAdAAtAEQAcgBhAGYAdAAgAHcAaQBsAGwAIABlAHgAcABpAHIAZQAgAG8AbgAg AE0AYQByAGMAaAAgADEAMgAsACAAMgAwADEAMAAuAA0ADQBDAG8AcAB5AHIAaQBnAGgAdAAgAE4A bwB0AGkAYwBlAA0ADQAgACAAIABDAG8AcAB5AHIAaQBnAGgAdAAgACgAYwApACAAMgAwADAAOQAg AEkARQBUAEYAIABUAHIAdQBzAHQAIABhAG4AZAAgAHQAaABlACAAcABlAHIAcwBvAG4AcwAgAGkA ZABlAG4AdABpAGYAaQBlAGQAIABhAHMAIAB0AGgAZQANACAAIAAgAGQAbwBjAHUAbQBlAG4AdAAg AGEAdQB0AGgAbwByAHMALgAgACAAQQBsAGwAIAByAGkAZwBoAHQAcwAgAHIAZQBzAGUAcgB2AGUA ZAAuAA0ADQAgACAAIABUAGgAaQBzACAAZABvAGMAdQBtAGUAbgB0ACAAaQBzACAAcwB1AGIAagBl AGMAdAAgAHQAbwAgAEIAQwBQACAANwA4ACAAYQBuAGQAIAB0AGgAZQAgAEkARQBUAEYAIABUAHIA dQBzAHQAJwBzACAATABlAGcAYQBsAA0AIAAgACAAUAByAG8AdgBpAHMAaQBvAG4AcwAgAFIAZQBs AGEAdABpAG4AZwAgAHQAbwAgAEkARQBUAEYAIABEAG8AYwB1AG0AZQBuAHQAcwAgAGkAbgAgAGUA ZgBmAGUAYwB0ACAAbwBuACAAdABoAGUAIABkAGEAdABlACAAbwBmAA0AIAAgACAAcAB1AGIAbABp AGMAYQB0AGkAbwBuACAAbwBmACAAdABoAGkAcwAgAGQAbwBjAHUAbQBlAG4AdAAgACgAaAB0AHQA cAA6AC8ALwB0AHIAdQBzAHQAZQBlAC4AaQBlAHQAZgAuAG8AcgBnAC8AbABpAGMAZQBuAHMAZQAt AGkAbgBmAG8AKQAuAA0AIAAgACAAUABsAGUAYQBzAGUAIAByAGUAdgBpAGUAdwAgAHQAaABlAHMA ZQAgAGQAbwBjAHUAbQBlAG4AdABzACAAYwBhAHIAZQBmAHUAbABsAHkALAAgAGEAcwAgAHQAaABl AHkAIABkAGUAcwBjAHIAaQBiAGUAIAB5AG8AdQByACAAcgBpAGcAaAB0AHMADQAgACAAIABhAG4A ZAAgAHIAZQBzAHQAcgBpAGMAdABpAG8AbgBzACAAdwBpAHQAaAAgAHIAZQBzAHAAZQBjAHQAIAB0 AG8AIAB0AGgAaQBzACAAZABvAGMAdQBtAGUAbgB0AC4ADQANAEEAYgBzAHQAcgBhAGMAdAANAA0A IAAgACAAVABoAGkAcwAgAGQAbwBjAHUAbQBlAG4AdAAgAHAAcgBvAHYAaQBkAGUAcwAgAGEAIABn AHUAaQBkAGUAIABmAG8AcgAgAEkAUAB2ADYAIABkAGUAcABsAG8AeQBtAGUAbgB0ACAAaQBuACAA SQBuAHQAZQByAG4AZQB0AA0AIAAgACAARQB4AGMAaABhAG4AZwBlACAAUABvAGkAbgB0AHMAIAAo AEkAWABQACkALgAgACAASQB0ACAAaQBuAGMAbAB1AGQAZQBzACAAaQBuAGYAbwByAG0AYQB0AGkA bwBuACAAcgBlAGcAYQByAGQAaQBuAGcAIAB0AGgAZQAgAHMAdwBpAHQAYwBoAA0AIAAgACAAZgBh AGIAcgBpAGMAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACwAIAB0AGgAZQAgAGEAZABkAHIA ZQBzAHMAaQBuAGcAIABwAGwAYQBuACAAYQBuAGQAIABnAGUAbgBlAHIAYQBsACAAbwByAGcAYQBu AGkAegBhAHQAaQBvAG4AYQBsAA0ADQANAA0ARwBhAGcAbABpAGEAbgBvACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABFAHgAcABpAHIAZQBzACAATQBhAHIAYwBoACAAMQAyACwAIAAy ADAAMQAwACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABbAFAAYQBnAGUAIAAxAF0A DQANAA0ASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAASQBQAHYANgAgAGkAbgAgAEkAWABQAHMAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIABTAGUAcAB0AGUAbQBiAGUAcgAgADIAMAAwADkADQANAA0AIAAgACAAdABhAHMAawBz ACAAdABvACAAYgBlACAAcABlAHIAZgBvAHIAbQBlAGQALgAgACAASQBYAFAAcwAgAGEAcgBlACAA bQBhAGkAbgBsAHkAIABhACAAbABhAHkAZQByACAAMgAgAGkAbgBmAHIAYQBzAHQAcgB1AGMAdAB1 AHIAZQAgAGEAbgBkAA0AIAAgACAAaQBuACAAbQBhAG4AeQAgAGMAYQBzAGUAcwAgAHQAaABlACAA YgBlAHMAdAAgAHIAZQBjAG8AbQBtAGUAbgBkAGEAdABpAG8AbgBzACAAcwB0AGEAdABlACAAdABo AGEAdAAgAHQAaABlACAASQBQAHYANgAgAGQAYQB0AGEALAANACAAIAAgAGMAbwBuAHQAcgBvAGwA IABhAG4AZAAgAG0AYQBuAGEAZwBlAG0AZQBuAHQAIABwAGwAYQBuAGUAIABzAGgAbwB1AGwAZAAg AG4AbwB0ACAAYgBlACAAaABhAG4AZABsAGUAZAAgAGQAaQBmAGYAZQByAGUAbgB0AGwAeQAgAHQA aABhAG4ADQAgACAAIABpAG4AIABJAFAAdgA0AC4ADQANAA0AVABhAGIAbABlACAAbwBmACAAQwBv AG4AdABlAG4AdABzAA0ADQAgACAAIAAxAC4AIAAgAEkAbgB0AHIAbwBkAHUAYwB0AGkAbwBuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgACAAMwANACAAIAAgADIA LgAgACAAUwB3AGkAdABjAGgAIABGAGEAYgByAGkAYwAgAEMAbwBuAGYAaQBnAHUAcgBhAHQAaQBv AG4AIAAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAAIAAzAA0AIAAgACAAMwAuACAAIABBAGQAZAByAGUAcwBzAGkAbgBn ACAAUABsAGEAbgAgACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAgADQADQAg ACAAIAA0AC4AIAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAASQBQAHYANgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgACAANgANACAAIAAgADUALgAgACAAUgBlAHYAZQByAHMA ZQAgAEQATgBTACAAIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA IAA3AA0AIAAgACAANgAuACAAIABSAG8AdQB0AGUAIABTAGUAcgB2AGUAcgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAgADcADQAgACAAIAA3AC4AIAAgAEUAeAB0 AGUAcgBuAGEAbAAgAGEAbgBkACAASQBuAHQAZQByAG4AYQBsACAAcwB1AHAAcABvAHIAdAAgACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgACAANwANACAAIAAgADgALgAgACAASQBYAFAAIABQAG8AbABpAGMAaQBlAHMAIABhAG4A ZAAgAEkAUAB2ADYAIAAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAAIAA4AA0AIAAgACAAOQAuACAA IABJAEEATgBBACAAQwBvAG4AcwBpAGQAZQByAGEAdABpAG8AbgBzACAAIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAgADgADQAgACAAIAAxADAALgAgAFMAZQBjAHUAcgBpAHQAeQAgAEMAbwBu AHMAaQBkAGUAcgBhAHQAaQBvAG4AcwAgACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgACAAOAANACAAIAAg ADEAMQAuACAAQQBjAGsAbgBvAHcAbABlAGQAZwBlAG0AZQBuAHQAcwAgAC4AIAAuACAALgAgAC4A IAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAAIAA4AA0AIAAgACAAMQAyAC4AIABSAGUAZgBlAHIAZQBuAGMA ZQBzACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAg AC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAgADgA DQAgACAAIAAgACAAMQAyAC4AMQAuACAAIABOAG8AcgBtAGEAdABpAHYAZQAgAFIAZQBmAGUAcgBl AG4AYwBlAHMAIAAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgACAAOAANACAAIAAgACAAIAAxADIALgAyAC4AIAAg AEkAbgBmAG8AcgBtAGEAdABpAHYAZQAgAFIAZQBmAGUAcgBlAG4AYwBlAHMAIAAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAAMQAwAA0AIAAgACAAQQB1AHQAaABvAHIAJwBzACAAQQBkAGQAcgBlAHMAcwAgAC4AIAAuACAA LgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAu ACAALgAgAC4AIAAuACAALgAgAC4AIAAuACAALgAgAC4AIAAxADAADQANAA0ADQANAA0ADQANAA0A DQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAEcAYQBnAGwAaQBhAG4AbwAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAARQB4AHAAaQByAGUAcwAgAE0AYQByAGMA aAAgADEAMgAsACAAMgAwADEAMAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAWwBQ AGEAZwBlACAAMgBdAA0ADQANAEkAbgB0AGUAcgBuAGUAdAAtAEQAcgBhAGYAdAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEkAUAB2ADYAIABpAG4AIABJAFgAUABzACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAUwBlAHAAdABlAG0AYgBlAHIAIAAyADAAMAA5AA0ADQANADEA LgAgACAASQBuAHQAcgBvAGQAdQBjAHQAaQBvAG4ADQANACAAIAAgAE0AbwBzAHQAIABJAG4AdABl AHIAbgBlAHQAIABFAHgAYwBoAGEAbgBnAGUAIABQAG8AaQBuAHQAcwAgACgASQBYAFAAKQAgAHcA bwByAGsAIABvAG4AIAB0AGgAZQAgAEwAYQB5AGUAcgAgADIAIABsAGUAdgBlAGwALAAgAG0AYQBr AGkAbgBnAA0AIAAgACAAdABoAGUAIABhAGQAbwBwAHQAaQBvAG4AIABvAGYAIABJAFAAdgA2ACAA YQBuACAAZQBhAHMAeQAgAHQAYQBzAGsALgAgACAASABvAHcAZQB2AGUAcgAsACAASQBYAFAAcwAg AG4AbwByAG0AYQBsAGwAeQAgAGkAbQBwAGwAZQBtAGUAbgB0AA0AIAAgACAAYQBkAGQAaQB0AGkA bwBuAGEAbAAgAHMAZQByAHYAaQBjAGUAcwAgAHMAdQBjAGgAIABhAHMAIABzAHQAYQB0AGkAcwB0 AGkAYwBzACwAIAByAG8AdQB0AGUAIABzAGUAcgB2AGUAcgBzACwAIABsAG8AbwBrAGkAbgBnAA0A IAAgACAAZwBsAGEAcwBzAGUAcwAgAGEAbgBkACAAYgByAG8AYQBkAGMAYQBzAHQAIABjAG8AbgB0 AHIAbwBsACAAdABoAGEAdAAgAG0AYQB5ACAAYgBlACAAaQBtAHAAYQBjAHQAZQBkACAAYgB5ACAA dABoAGUADQAgACAAIABpAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AIABvAGYAIABJAFAAdgA2 AC4AIAAgAFQAaABpAHMAIABkAG8AYwB1AG0AZQBuAHQAIABjAGwAYQByAGkAZgBpAGUAcwAgAHQA aABlACAAaQBtAHAAYQBjAHQAIABvAGYAIABJAFAAdgA2AA0AIAAgACAAbwBuACAAYQAgAG4AZQB3 ACAAbwByACAAYQBuACAAZQB4AGkAcwB0AGkAbgBnACAASQBYAFAAIAB0AGgAYQB0ACAAbQBhAHkA IABvAHIAIABtAGEAeQAgAG4AbwB0ACAAZgBpAHQAIABhAG4AeQAgAHAAYQByAHQAaQBjAHUAbABh AHIADQAgACAAIABkAGUAcABsAG8AeQBtAGUAbgB0AC4AIAAgAFQAaABlACAAZABvAGMAdQBtAGUA bgB0ACAAYQBzAHMAdQBtAGUAcwAgAGEAbgAgAEUAdABoAGUAcgBuAGUAdAAgAHMAdwBpAHQAYwBo ACAAZgBhAGIAcgBpAGMALAAgAGEAbAB0AGgAbwB1AGcAaAANACAAIAAgAG8AdABoAGUAcgAgAGwA YQB5AGUAcgAgADIAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuAHMAIABjAGEAbgAgAGIAZQAg AGQAZQBwAGwAbwB5AGUAZAAuAA0ADQANADIALgAgACAAUwB3AGkAdABjAGgAIABGAGEAYgByAGkA YwAgAEMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4ADQANACAAIAAgAEEAbgAgAEUAdABoAGUAcgBu AGUAdAAgAGIAYQBzAGUAZAAgAEkAWABQACAAcwB3AGkAdABjAGgAIABmAGEAYgByAGkAYwAgAGkA bQBwAGwAZQBtAGUAbgB0AHMAIABJAFAAdgA2ACAAbwB2AGUAcgAgAEUAdABoAGUAcgBuAGUAdAAg AGEAcwANACAAIAAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAAWwBSAEYAQwAyADQANgA0AF0A LgAgACAAVABoAGUAcgBlAGYAbwByAGUALAAgAHQAaABlACAAcwB3AGkAdABjAGgAaQBuAGcAIABv AGYAIABJAFAAdgA2ACAAdAByAGEAZgBmAGkAYwANACAAIAAgAGgAYQBwAHAAZQBuAHMAIABpAG4A IAB0AGgAZQAgAHMAYQBtAGUAIAB3AGEAeQAgAGEAcwAgAGkAbgAgAEkAUAB2ADQALgAgACAASABv AHcAZQB2AGUAcgAsACAAcwBvAG0AZQAgAG0AYQBuAGEAZwBlAG0AZQBuAHQADQAgACAAIABmAHUA bgBjAHQAaQBvAG4AcwAgAHIAZQBxAHUAaQByAGUAIABlAHgAcABsAGkAYwBpAHQAIABJAFAAdgA2 ACAAcwB1AHAAcABvAHIAdAAgACgAcwB1AGMAaAAgAGEAcwAgAHMAdwBpAHQAYwBoACAAbQBhAG4A YQBnAGUAbQBlAG4AdAAsAA0AIAAgACAAUwBOAE0AUAAgAHMAdQBwAHAAbwByAHQAIABhAG4AZAAg AGYAbABvAHcAIABhAG4AYQBsAHkAcwBpAHMAIABlAHgAcABvAHIAdABhAHQAaQBvAG4AKQAgAGEA bgBkACAAdABoAGkAcwAgAHMAaABvAHUAbABkACAAYgBlAA0AIAAgACAAYQBzAHMAZQBzAHMAZQBk ACAAYgB5ACAAdABoAGUAIABJAFgAUAAgAG8AcABlAHIAYQB0AG8AcgAuAA0ADQAgACAAIABUAGgA ZQByAGUAIABhAHIAZQAgAHQAdwBvACAAYwBvAG0AbQBvAG4AIABjAG8AbgBmAGkAZwB1AHIAYQB0 AGkAbwBuAHMAIABvAGYAIABJAFgAUAAgAHMAdwBpAHQAYwBoACAAcABvAHIAdABzACAAdABvACAA cwB1AHAAcABvAHIAdAANACAAIAAgAEkAUAB2ADYAOgANAA0AIAAgACAAMQAuACAAIABkAHUAYQBs ACAAcwB0AGEAYwBrACAATABBAE4AOgAgAGIAbwB0AGgAIABJAFAAdgA0ACAAYQBuAGQAIABJAFAA dgA2ACAAdAByAGEAZgBmAGkAYwAgAHMAaABhAHIAZQAgAGEAIABjAG8AbQBtAG8AbgAgAEwAQQBO AC4ADQAgACAAIAAgACAAIAAgAE4AbwAgAGUAeAB0AHIAYQAgAGMAbwBuAGYAaQBnAHUAcgBhAHQA aQBvAG4AIABpAHMAIAByAGUAcQB1AGkAcgBlAGQAIABpAG4AIAB0AGgAZQAgAHMAdwBpAHQAYwBo AC4AIAAgAEkAbgAgAHQAaABpAHMADQAgACAAIAAgACAAIAAgAHMAYwBlAG4AYQByAGkAbwAsACAA cABhAHIAdABpAGMAaQBwAGEAbgB0AHMAIAB3AGkAbABsACAAdAB5AHAAaQBjAGEAbABsAHkAIABj AG8AbgBmAGkAZwB1AHIAZQAgAGQAdQBhAGwAIABzAHQAYQBjAGsADQAgACAAIAAgACAAIAAgAGkA bgB0AGUAcgBmAGEAYwBlAHMALAAgAGEAbAB0AGgAbwB1AGcAaAAgAGkAbgBkAGUAcABlAG4AZABl AG4AdAAgAHAAbwByAHQAIABjAGEAbgAgAGIAZQAgAGEAbgAgAG8AcAB0AGkAbwBuAC4ADQANACAA IAAgADIALgAgACAAaQBuAGQAZQBwAGUAbgBkAGUAbgB0ACAATABBAE4AOgAgAGEAbgAgAGUAeABj AGwAdQBzAGkAdgBlACAASQBQAHYANgAgAEwAQQBOACAAaQBzACAAYwByAGUAYQB0AGUAZAAgAGYA bwByACAASQBQAHYANgANACAAIAAgACAAIAAgACAAdAByAGEAZgBmAGkAYwAuACAAIABJAGYAIABJ AFgAUAAgAHAAYQByAHQAaQBjAGkAcABhAG4AdABzACAAYQByAGUAIABhAGwAcgBlAGEAZAB5ACAA dQBzAGkAbgBnACAAVgBpAHIAdAB1AGEAbAAgAEwAQQBOAA0AIAAgACAAIAAgACAAIAAoAFYATABB AE4AKQAgAHQAYQBnAGcAaQBuAGcAIABvAG4AIAB0AGgAZQBpAHIAIAByAG8AdQB0AGUAcgBzACAA aQBuAHQAZQByAGYAYQBjAGUAcwAgAHQAaABhAHQAIABhAHIAZQAgAGYAYQBjAGkAbgBnACAAdABo AGUADQAgACAAIAAgACAAIAAgAEkAWABQACAAcwB3AGkAdABjAGgALAAgAHQAaABpAHMAIABvAG4A bAB5ACAAcgBlAHEAdQBpAHIAZQBzACAAcABhAHMAcwBpAG4AZwAgAG8AbgBlACAAYQBkAGQAaQB0 AGkAbwBuAGEAbAAgAFYATABBAE4AIAB0AGEAZwANACAAIAAgACAAIAAgACAAYQBjAHIAbwBzAHMA IAB0AGgAZQAgAGkAbgB0AGUAcgBjAG8AbgBuAGUAYwB0AGkAbwBuAC4AIAAgAEkAZgAgAHAAYQBy AHQAaQBjAGkAcABhAG4AdABzACAAYQByAGUAIAB1AHMAaQBuAGcAIAB1AG4AdABhAGcAZwBlAGQA DQAgACAAIAAgACAAIAAgAGkAbgB0AGUAcgBjAG8AbgBuAGUAYwB0AGkAbwBuAHMAIAB3AGkAdABo ACAAdABoAGUAIABJAFgAUAAgAHMAdwBpAHQAYwBoACAAYQBuAGQAIAB3AGkAcwBoACAAdABvACAA YwBvAG4AdABpAG4AdQBlACAAZABvAGkAbgBnAA0AIAAgACAAIAAgACAAIABzAG8ALAAgAHQAaABl AHkAIAB3AGkAbABsACAAbgBlAGUAZAAgAHQAbwAgAGYAYQBjAGkAbABpAHQAYQB0AGUAIABhACAA cwBlAHAAYQByAGEAdABlACAAcABoAHkAcwBpAGMAYQBsACAAcABvAHIAdAAgAHQAbwANACAAIAAg ACAAIAAgACAAYQBjAGMAZQBzAHMAIAB0AGgAZQAgAEkAUAB2ADYALQBzAHAAZQBjAGkAZgBpAGMA IABMAEEATgAuAA0ADQAgACAAIABUAGgAZQAgACIAaQBuAGQAZQBwAGUAbgBkAGUAbgB0ACAATABB AE4AIgAgAGMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4AIABwAHIAbwB2AGkAZABlAHMAIABhACAA cABoAHkAcwBpAGMAYQBsACAAcwBlAHAAYQByAGEAdABpAG8AbgANACAAIAAgAGYAbwByACAASQBQ AHYANAAgAGEAbgBkACAASQBQAHYANgAgAHQAcgBhAGYAZgBpAGMAIABzAGkAbQBwAGwAaQBmAHkA aQBuAGcAIABzAGUAcABhAHIAYQB0AGUAIABhAG4AYQBsAHkAcwBpAHMAIABmAG8AcgAgAEkAUAB2 ADQAIABhAG4AZAANACAAIAAgAEkAUAB2ADYAIAB0AHIAYQBmAGYAaQBjAC4AIAAgAEgAbwB3AGUA dgBlAHIALAAgAGkAdAAgAGMAYQBuACAAYgBlACAAbQBvAHIAZQAgAGMAbwBzAHQAbAB5ACAAaQBu ACAAYgBvAHQAaAAgAGMAYQBwAGkAdABhAGwADQAgACAAIABlAHgAcABlAG4AcwBlAHMAIAAoAGkA ZgAgAG4AZQB3ACAAcABvAHIAdABzACAAYQByAGUAIABuAGUAZQBkAGUAZAApACAAYQBuAGQAIABv AHAAZQByAGEAdABpAG8AbgBhAGwAIABlAHgAcABlAG4AZABzAC4ADQAgACAAIABDAG8AbgB2AGUA cgBzAGUAbAB5ACwAIAB0AGgAZQAgAGQAdQBhAGwAIABzAHQAYQBjAGsAIABpAG0AcABsAGUAbQBl AG4AdABhAHQAaQBvAG4AIABhAGwAbABvAHcAcwAgAGEAIABxAHUAaQBjAGsAIABhAG4AZAAgAGMA YQBwAGkAdABhAGwADQAgACAAIABjAG8AcwB0AC0AZgByAGUAZQAgAHMAdABhAHIAdAAtAHUAcAAg AGYAbwByACAASQBQAHYANgAgAHMAdQBwAHAAbwByAHQAIABpAG4AIAB0AGgAZQAgAEkAWABQACwA IABhAGwAbABvAHcAaQBuAGcAIAB0AGgAZQAgAEkAWABQACAAdABvAA0AIAAgACAAYQB2AG8AaQBk ACAAdAByAGEAbgBzAGYAbwByAG0AaQBuAGcAIAB1AG4AdABhAGcAZwBlAGQAIABwAG8AcgB0AHMA IABpAG4AdABvACAAdABhAGcAZwBlAGQAIABwAG8AcgB0AHMALgAgACAASQBuACAAdABoAGkAcwAN ACAAIAAgAGkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgAsACAAdAByAGEAZgBmAGkAYwAtAHMA cABsAGkAdAAgAGYAbwByACAAcwB0AGEAdABpAHMAdABpAGMAYQBsACAAYQBuAGEAbAB5AHMAaQBz ACAAbQBhAHkAIABiAGUAIABkAG8AbgBlAA0AIAAgACAAdQBzAGkAbgBnACAAZgBsAG8AdwBzACAA dABlAGMAaABuAGkAcQB1AGUAcwAgAHMAdQBjAGgAIABhAHMAIABJAFAARgBJAFgAIABbAFIARgBD ADUAMQAwADEAXQAgAGMAbwBuAHMAaQBkAGUAcgBpAG4AZwAgAHQAaABlAA0AIAAgACAAZABpAGYA ZgBlAHIAZQBuAHQAIABlAHQAaABlAHIALQB0AHkAcABlAHMAIAAoADAAeAAwADgAMAAwACAAZgBv AHIAIABJAFAAdgA0ACwAIAAwAHgAMAA4ADAANgAgAGYAbwByACAAQQBSAFAAIABhAG4AZAAgADAA eAA4ADYARABEACAAZgBvAHIADQANAA0ADQBHAGEAZwBsAGkAYQBuAG8AIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMAIABNAGEAcgBjAGgAIAAxADIALAAgADIA MAAxADAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFsAUABhAGcAZQAgADMAXQAN AA0ADQBJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIABJAFAAdgA2ACAAaQBuACAASQBYAFAAcwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgAFMAZQBwAHQAZQBtAGIAZQByACAAMgAwADAAOQANAA0ADQAgACAAIABJAFAAdgA2ACkA LgANAA0AIAAgACAAVABoAGUAIABvAG4AbAB5ACAAdABlAGMAaABuAGkAYwBhAGwAIAByAGUAcQB1 AGkAcgBlAG0AZQBuAHQAIABmAG8AcgAgAEkAUAB2ADYAIAByAGUAZgBlAHIAcgBpAG4AZwAgAGwA aQBuAGsAIABNAFQAVQBzACAAaQBzACAAdABoAGEAdAANACAAIAAgAHQAaABlAHkAIABuAGUAZQBk ACAAdABvACAAYgBlACAAZwByAGUAYQB0AGUAcgAgAHQAaABhAG4AIABvAHIAIABlAHEAdQBhAGwA IAB0AG8AIAAxADIAOAAwACAAbwBjAHQAZQB0AHMAIABbAFIARgBDADIANAA2ADAAXQAuAA0AIAAg ACAAQwBvAG0AbQBvAG4AIABNAFQAVQAgAHMAaQB6AGUAcwAgAGkAbgAgAEkAWABQAHMAIABhAHIA ZQAgADEANQAwADAALAAgADQANAA3ADAALAAgAG8AcgAgADkAMgAxADYAIABiAHkAdABlAHMALgAN ACAAIAAgAEMAbwBuAHMAZQBxAHUAZQBuAHQAbAB5ACwAIABuAG8AIABNAFQAVQAgAGMAaABhAG4A ZwBlAHMAIABhAHIAZQAgAHQAeQBwAGkAYwBhAGwAbAB5ACAAcgBlAHEAdQBpAHIAZQBkAC4AIAAg AFQAaABlACAATQBUAFUAIABzAGkAegBlAA0AIAAgACAAZgBvAHIAIABlAHYAZQByAHkAIABMAEEA TgAgAGkAbgAgAGEAbgAgAEkAWABQACAAcwBoAG8AdQBsAGQAIABiAGUAIAB3AGUAbABsACAAawBu AG8AdwAgAGIAeQAgAGEAbABsACAAaQB0AHMAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAuAA0A DQANADMALgAgACAAQQBkAGQAcgBlAHMAcwBpAG4AZwAgAFAAbABhAG4ADQANACAAIAAgAFIAZQBn AGkAbwBuAGEAbAAgAEkAbgB0AGUAcgBuAGUAdAAgAFIAZQBnAGkAcwB0AHIAaQBlAHMAIAAoAFIA SQBSAHMAKQAgAGgAYQB2AGUAIABzAHAAZQBjAGkAZgBpAGMAIABhAGQAZAByAGUAcwBzACAAcABv AGwAaQBjAGkAZQBzACAAdABvAA0AIAAgACAAYQBzAHMAaQBnAG4AIABhAGwAbABvAGMAYQB0AGUA IABQAHIAbwB2AGkAZABlAHIAIABJAG4AZABlAHAAZQBuAGQAZQBuAHQAIAAoAFAASQApACAASQBQ AHYANgAgAGEAZABkAHIAZQBzAHMAIAB0AG8AIABJAFgAUABzAC4AIAAgAFQAaABvAHMAZQANACAA IAAgAGEAbABsAG8AYwBhAHQAaQBvAG4AcwAgAGEAcgBlACAAdQBzAHUAYQBsAGwAeQAgAC8ANAA4 ACAAbwByACAAcwBoAG8AcgB0AGUAcgAgAHAAcgBlAGYAaQB4AGUAcwAgAFsAUgBJAFIAXwBJAFgA UABfAFAATwBMAEkAQwBJAEUAUwBdAC4ADQAgACAAIABEAGUAcABlAG4AZABpAG4AZwAgAG8AbgAg AHQAaABlACAAYwBvAHUAbgB0AHIAeQAgAGEAbgBkACAAcgBlAGcAaQBvAG4AIABvAGYAIABvAHAA ZQByAGEAdABpAG8AbgAsACAAYQBkAGQAcgBlAHMAcwAgAGEAbABsAG8AYwBhAHQAaQBvAG4AcwAN ACAAIAAgAG0AYQB5ACAAYgBlACAAcAByAG8AdgBpAGQAZQBkACAAYgB5ACAATgBJAFIAcwAgACgA TgBhAHQAaQBvAG4AYQBsACAASQBuAHQAZQByAG4AZQB0ACAAUgBlAGcAaQBzAHQAcgBpAGUAcwAp AC4AIAAgAFUAbgBpAHEAdQBlACAATABvAGMAYQBsAA0AIAAgACAASQBQAHYANgAgAFUAbgBpAGMA YQBzAHQAIABBAGQAZAByAGUAcwBzAGUAcwAgACgAWwBSAEYAQwA0ADEAOQAzAF0AKQAgAGEAcgBl ACAAbgBvAHIAbQBhAGwAbAB5ACAAbgBvAHQAIAB1AHMAZQBkACAAaQBuACAAYQBuACAASQBYAFAA DQAgACAAIABMAEEATgAgAGEAcwAgAGcAbABvAGIAYQBsACAAcgBlAHYAZQByAHMAZQAgAEQATgBT ACAAcgBlAHMAbwBsAHUAdABpAG8AbgAgAGEAbgBkACAAdwBoAG8AaQBzACAAcwBlAHIAdgBpAGMA ZQBzACAAYQByAGUAIAByAGUAcQB1AGkAcgBlAGQALgANAA0AIAAgACAARgByAG8AbQAgAHQAaABl ACAAYQBsAGwAbwBjAGEAdABlAGQAIABwAHIAZQBmAGkAeAAsACAAZgBvAGwAbABvAHcAaQBuAGcA IAB0AGgAZQAgAHIAZQBjAG8AbQBtAGUAbgBkAGEAdABpAG8AbgBzACAAbwBmAA0AIAAgACAAWwBS AEYAQwA0ADIAOQAxAF0ALAAgAGEAIAAvADYANAAgAHAAcgBlAGYAaQB4ACAAcwBoAG8AdQBsAGQA IABiAGUAIABhAGwAbABvAGMAYQB0AGUAZAAgAGYAbwByACAAZQBhAGMAaAAgAG8AZgAgAHQAaABl ACAAZQB4AGMAaABhAG4AZwBlAA0AIAAgACAAcABvAGkAbgB0ACAASQBQAHYANgAgAGUAbgBhAGIA bABlAGQAIABMAEEATgBzAC4AIAAgAEEAIAAvADQAOAAgAHAAcgBlAGYAaQB4ACAAYQBsAGwAbwB3 AHMAIAB0AGgAZQAgAGEAZABkAHIAZQBzAHMAaQBuAGcAIABvAGYAIAA2ADUANQAzADYADQAgACAA IABMAEEATgBzAC4AIAAgAEEAcwAgAEkAWABQACAAdwBpAGwAbAAgAG4AbwByAG0AYQBsAGwAeQAg AHUAcwBlACAAbQBhAG4AdQBhAGwAIABhAGQAZAByAGUAcwBzACAAYwBvAG4AZgBpAGcAdQByAGEA dABpAG8AbgAsACAAbABvAG4AZwBlAHIADQAgACAAIABwAHIAZQBmAGkAeABlAHMAIAAoAC8ANgA1 AC0ALwAxADIANwApACwAIABhAHIAZQAgAHQAZQBjAGgAbgBpAGMAYQBsAGwAeQAgAGYAZQBhAHMA aQBiAGwAZQAgAGIAdQB0ACAAYQByAGUAIABuAG8AcgBtAGEAbABsAHkADQAgACAAIABkAGkAcwBj AG8AdQByAGEAZwBlAGQAIABiAGUAYwBhAHUAcwBlACAAbwBmACAAbwBwAGUAcgBhAHQAaQBvAG4A YQBsACAAcAByAGEAYwB0AGkAYwBlAHMALgAgACAAVABoAGUAIABtAGEAbgB1AGEAbAANACAAIAAg AGMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4AIABvAGYAIABJAFAAdgA2ACAAYQBkAGQAcgBlAHMA cwBlAHMAIABhAGwAbABvAHcAcwAgAEkAWABQACAAcABhAHIAdABpAGMAaQBwAGEAbgB0AHMAIAB0 AG8AIAByAGUAcABsAGEAYwBlAA0AIAAgACAAbgBlAHQAdwBvAHIAawAgAGkAbgB0AGUAcgBmAGEA YwBlAHMAIAB3AGkAdABoACAAbgBvACAAbgBlAGUAZAAgAHQAbwAgAHIAZQBjAG8AbgBmAGkAZwB1 AHIAZQAgAEIAbwByAGQAZQByACAARwBhAHQAZQB3AGEAeQANACAAIAAgAFAAcgBvAHQAbwBjAG8A bAAgACgAQgBHAFAAKQAgAHMAZQBzAHMAaQBvAG4AcwAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAg AGEAbgBkACAAaQB0ACAAYQBsAHMAbwAgAGYAYQBjAGkAbABpAHQAYQB0AGUAcwANACAAIAAgAG0A YQBuAGEAZwBlAG0AZQBuAHQAIAB0AGEAcwBrAHMALgANAA0AIAAgACAAVwBoAGUAbgAgAHMAZQBs AGUAYwB0AGkAbgBnACAAdABoAGUAIAB1AHMAZQAgAG8AZgAgAHMAdABhAHQAaQBjACAASQBuAHQA ZQByAGYAYQBjAGUAIABJAGQAZQBuAHQAaQBmAGkAZQByAHMAIAAoAEkASQBEAHMAKQAsACAAdABo AGUAcgBlAA0AIAAgACAAYQByAGUAIABkAGkAZgBmAGUAcgBlAG4AdAAgAG8AcAB0AGkAbwBuAHMA IABvAG4AIABoAG8AdwAgAHQAbwAgACIAaQBuAHQAZQBsAGwAaQBnAGUAbgB0AGwAeQAiACAAZgBp AGwAbAAgAGkAdABzACAANgA0ACAAYgBpAHQAcwAgACgAbwByAA0AIAAgACAAMQA2ACAAaABlAHgA YQBkAGUAYwBpAG0AYQBsACAAYwBoAGEAcgBhAGMAdABlAHIAcwApAC4AIAAgAEEAIABuAG8AbgAt AGUAeABoAGEAdQBzAHQAZQBkACAAbABpAHMAdAAgAG8AZgAgAHAAbwBzAHMAaQBiAGwAZQAgAEkA SQBEAA0AIAAgACAAcwBlAGwAZQBjAHQAaQBvAG4AIABtAGUAYwBoAGEAbgBpAHMAbQBzACAAaQBz ACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwA6AA0ADQAgACAAIAAxAC4AIAAgAFMAbwBtAGUA IABJAFgAUABzACAAbABpAGsAZQAgAHQAbwAgAGkAbgBjAGwAdQBkAGUAIAB0AGgAZQAgAHAAYQBy AHQAaQBjAGkAcABhAG4AdABzACcAIABBAFMATgAgAG4AdQBtAGIAZQByACAAZABlAGMAaQBtAGEA bAANACAAIAAgACAAIAAgACAAZQBuAGMAbwBkAGkAbgBnACAAaQBuAHMAaQBkAGUAIABlAGEAYwBo ACAASQBQAHYANgAgAGEAZABkAHIAZQBzAHMALgAgACAAVABoAGUAIABBAFMATgAgAGQAZQBjAGkA bQBhAGwAIABuAHUAbQBiAGUAcgAgAGkAcwANACAAIAAgACAAIAAgACAAdQBzAGUAZAAgAGEAcwAg AHQAaABlACAAQgBDAEQAIAAoAGIAaQBuAGEAcgB5ACAAYwBvAGQAZQAgAGQAZQBjAGkAbQBhAGwA KQAgAGUAbgBjAG8AZABpAG4AZwAgAG8AZgAgAHQAaABlACAAdQBwAHAAZQByACAAcABhAHIAdAAN ACAAIAAgACAAIAAgACAAbwBmACAAdABoAGUAIABJAEkARAAgAHMAdQBjAGgAIABhAHMAIABzAGgA bwB3AG4AIABpAG4AIAB0AGgAaQBzACAAZQB4AGEAbQBwAGwAZQA6AA0ADQAgACAAIAAgACAAIAAg ACoAIAAgAEkAWABQACAATABBAE4AIABwAHIAZQBmAGkAeAA6ACAAMgAwADAAMQA6AEQAQgA4ADoA OgAvADYANAANAA0AIAAgACAAIAAgACAAIAAqACAAIABBAFMATgA6ACAANgA0ADQAOQA2AA0ADQAg ACAAIAAgACAAIAAgACoAIAAgAEkAUAB2ADYAIABBAGQAZAByAGUAcwBzADoAIAAyADAAMAAxADoA RABCADgAOgA6ADAAMAAwADAAOgAwADAAMAA2ADoANAA0ADkANgA6ADAAMAAwADEALwA2ADQAIABv AHIAIABpAHQAcwANACAAIAAgACAAIAAgACAAIAAgACAAZQBxAHUAaQB2AGEAbABlAG4AdAAgAHIA ZQBwAHIAZQBzAGUAbgB0AGEAdABpAG8AbgAgADIAMAAwADEAOgBEAEIAOAA6ADoANgA6ADQANAA5 ADYAOgAxAC8ANgA0AA0ADQAgACAAIAAgACAAIAAgAEkAbgAgAHQAaABpAHMAIABlAHgAYQBtAHAA bABlACAAdwBlACAAYQByAGUAIAByAGkAZwBoAHQAIABqAHUAcwB0AGkAZgB5AGkAbgBnACAAdABo AGUAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAJwAgAEEAUwBOAA0ADQANAA0ARwBhAGcAbABpAGEA bgBvACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABFAHgAcABpAHIAZQBzACAATQBh AHIAYwBoACAAMQAyACwAIAAyADAAMQAwACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IABbAFAAYQBnAGUAIAA0AF0ADQANAA0ASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASQBQAHYANgAgAGkAbgAgAEkAWABQAHMAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIABTAGUAcAB0AGUAbQBiAGUAcgAgADIAMAAwADkADQAN AA0AIAAgACAAIAAgACAAIABuAHUAbQBiAGUAcgAgAGYAcgBvAG0AIAB0AGgAZQAgADEAMQAyAG4A ZAAgAGIAaQB0AC4AIAAgAFIAZQBtAGUAbQBiAGUAcgAgAHQAaABhAHQAIAAzADIAIABiAGkAdABz ACAAQQBTAE4AcwAgAHIAZQBxAHUAaQByAGUAIABhAA0AIAAgACAAIAAgACAAIABtAGEAeABpAG0A dQBtACAAbwBmACAAMQAwACAAYwBoAGEAcgBhAGMAdABlAHIAcwAuACAAIABXAGkAdABoACAAdABo AGkAcwAgAGUAeABhAG0AcABsAGUALAAgAHUAcAAgAHQAbwAgADIAXgAxADYAIABJAFAAdgA2AA0A IAAgACAAIAAgACAAIABhAGQAZAByAGUAcwBzAGUAcwAgAGMAYQBuACAAYgBlACAAYwBvAG4AZgBp AGcAdQByAGUAZAAgAHAAZQByACAAQQBTAE4ALgANAA0AIAAgACAAMgAuACAAIABBAGwAdABoAG8A dQBnAGgAIABCAEMARAAgAGUAbgBjAG8AZABpAG4AZwAgAGkAcwAgAG0AbwByAGUAIAAiAGgAdQBt AGEAbgAtAHIAZQBhAGQAYQBiAGwAZQAiACwAIABzAG8AbQBlACAASQBYAFAAcwAgAHAAcgBlAGYA ZQByAA0AIAAgACAAIAAgACAAIAB0AG8AIAB1AHMAZQAgAHQAaABlACAAaABlAHgAYQBkAGUAYwBp AG0AYQBsACAAZQBuAGMAbwBkAGkAbgBnACAAbwBmACAAdABoAGUAIABBAFMATgBzACAAbgB1AG0A YgBlAHIAIABhAHMAIAB0AGgAZQAgAHUAcABwAGUAcgANACAAIAAgACAAIAAgACAAcABhAHIAdAAg AG8AZgAgAHQAaABlACAASQBJAEQAIABhAHMAIABmAG8AbABsAG8AdwA6AA0ADQAgACAAIAAgACAA IAAgACoAIAAgAEkAWABQACAATABBAE4AIABwAHIAZQBmAGkAeAA6ACAAMgAwADAAMQA6AEQAQgA4 ADoAOgAvADYANAANAA0AIAAgACAAIAAgACAAIAAqACAAIABBAFMATgA6ACAANgA0ADQAOQA2ACAA KABEAEUAQwApACAAbwByACAARgBCAEYAMAAgACgASABFAFgAKQANAA0AIAAgACAAIAAgACAAIAAq ACAAIABJAFAAdgA2ACAAQQBkAGQAcgBlAHMAcwA6ACAAMgAwADAAMQA6AEQAQgA4ADoAOgAwADAA MAAwADoAMAAwADAAMAA6AEYAQgBGADAAOgAwADAAMAAxAC8ANgA0ACAAbwByACAAaQB0AHMADQAg ACAAIAAgACAAIAAgACAAIAAgAGUAcQB1AGkAdgBhAGwAZQBuAHQAIAByAGUAcAByAGUAcwBlAG4A dABhAHQAaQBvAG4AIAAyADAAMAAxADoARABCADgAOgA6AEYAQgBGADAAOgAxAC8ANgA0AA0ADQAg ACAAIAAzAC4AIAAgAEEAIAB0AGgAaQByAGQAIABzAGMAaABlAG0AZQAgAGYAbwByACAAcwB0AGEA dABpAGMAYQBsAGwAeQAgAGEAcwBzAGkAZwBuAGkAbgBnACAASQBQAHYANgAgAGEAZABkAHIAZQBz AHMAZQBzACAAbwBuACAAYQBuACAASQBYAFAADQAgACAAIAAgACAAIAAgAEwAQQBOACAAYwBvAHUA bABkACAAYgBlACAAdABvACAAcgBlAGwAYQB0AGUAIABzAG8AbQBlACAAcABvAHIAdABpAG8AbgBz ACAAbwBmACAAYQAgAHAAYQByAHQAaQBjAGkAcABhAG4AdAAnAHMAIABJAFAAdgA2AA0AIAAgACAA IAAgACAAIABhAGQAZAByAGUAcwBzACAAdABvACAAaQB0AHMAIABJAFAAdgA0ACAAYQBkAGQAcgBl AHMAcwAuACAAIABJAG4AIAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAZQB4AGEAbQBwAGwA ZQAsACAAdABoAGUAIABsAGEAcwB0AA0AIAAgACAAIAAgACAAIAB0AGgAcgBlAGUAIABkAGUAYwBp AG0AYQBsAHMAIABvAGYAIAB0AGgAZQAgAEkAUAB2ADQAIABhAGQAZAByAGUAcwBzACAAYQByAGUA IABjAG8AcABpAGUAZAAgAHQAbwAgAHQAaABlACAAbABhAHMAdAANACAAIAAgACAAIAAgACAAaABl AHgAYQBkAGUAYwBpAG0AYQBsAHMAIABvAGYAIAB0AGgAZQAgAEkAUAB2ADYAIABhAGQAZAByAGUA cwBzACwAIAB1AHMAaQBuAGcAIAB0AGgAZQAgAGQAZQBjAGkAbQBhAGwAIABuAHUAbQBiAGUAcgAg AGEAcwAgAHQAaABlAA0AIAAgACAAIAAgACAAIABCAEMARAAgAGUAbgBjAG8AZABpAG4AZwAgAGYA bwByACAAdABoAGUAIABsAGEAcwB0ACAAdABoAHIAZQBlACAAYwBoAGEAcgBhAGMAdABlAHIAcwAg AG8AZgAgAHQAaABlACAASQBJAEQAIABzAHUAYwBoACAAYQBzACAAaQBuAA0AIAAgACAAIAAgACAA IAB0AGgAZQAgAGYAbwBsAGwAbwB3AGkAbgBnACAAZQB4AGEAbQBwAGwAZQA6AA0ADQAgACAAIAAg ACAAIAAgACoAIAAgAEkAWABQACAATABBAE4AIABwAHIAZQBmAGkAeAA6ACAAMgAwADAAMQA6AEQA QgA4ADoAOgAvADYANAANAA0AIAAgACAAIAAgACAAIAAqACAAIABJAFAAdgA0ACAAQQBkAGQAcgBl AHMAcwA6ACAAMgA0ADAALgAwAC4AMgAwAC4AMQAzADIALwAyADMABQANAA0AIAAgACAAIAAgACAA IAAqACAAIABJAFAAdgA2ACAAQQBkAGQAcgBlAHMAcwA6ACAAMgAwADAAMQA6AEQAQgA4ADoAOgAx ADMAMgAvADYANAANAA0AIAAgACAANAAuACAAIABBACAAZgBvAHUAcgB0AGgAIABhAHAAcAByAG8A YQBjAGgAIABtAGkAZwBoAHQAIABiAGUAIABiAGEAcwBlAGQAIABvAG4AIAB0AGgAZQAgAEkAWABQ AHMAIABJAEQAIABmAG8AcgAgAHQAaABhAHQADQAgACAAIAAgACAAIAAgAHAAYQByAHQAaQBjAGkA cABhAG4AdAAuAA0ADQAgACAAIABUAGgAZQAgAGMAdQByAHIAZQBuAHQAIABwAHIAYQBjAHQAaQBj AGUAIAB0AGgAYQB0ACAAYQBwAHAAbABpAGUAcwAgAHQAbwAgAEkAUAB2ADQAIABhAGIAbwB1AHQA IABwAHUAYgBsAGkAcwBoAGkAbgBnACAASQBYAFAADQAgACAAIABhAGwAbABvAGMAYQB0AGkAbwBu AHMAIAB0AG8AIAB0AGgAZQAgAEQARgBaACAAKABEAGUAZgBhAHUAbAB0ACAARgByAGUAZQAgAFoA bwBuAGUAKQAgAHMAaABvAHUAbABkACAAYQBsAHMAbwAgAGEAcABwAGwAeQAgAHQAbwAgAHQAaABl AA0AIAAgACAASQBQAHYANgAgAGEAbABsAG8AYwBhAHQAaQBvAG4AIAAoAG4AbwByAG0AYQBsAGwA eQAgAGEAIAAvADQAOAAgAHAAcgBlAGYAaQB4ACkALgAgACAAVAB5AHAAaQBjAGEAbABsAHkAIABJ AFgAUABzACAATABBAE4AcwAgAGEAcgBlACAAbgBvAHQADQAgACAAIABnAGwAbwBiAGEAbABsAHkA IAByAGUAYQBjAGgAYQBiAGwAZQAgAGkAbgAgAG8AcgBkAGUAcgAgAHQAbwAgAGEAdgBvAGkAZAAg AGEAIABEAGkAcwB0AHIAaQBiAHUAdABlAGQAIABEAGUAbgBpAGEAbAAgAG8AZgAgAFMAZQByAHYA aQBjAGUADQAgACAAIAAoAEQARABvAFMAKQAgAGEAdAB0AGEAYwBrACAAYgB1AHQAIABwAGEAcgB0 AGkAYwBpAHAAYQBuAHQAIABtAGEAeQAgAHIAbwB1AHQAZQAgAHQAaABlAHMAZQAgAHAAcgBlAGYA aQB4AGUAcwAgAGkAbgBzAGkAZABlACAAdABoAGUAaQByAA0AIAAgACAAbgBlAHQAdwBvAHIAawBz ACAAKABlAC4AIABnAC4AIAB1AHMAaQBuAGcAIABCAEcAUAAgAG4AbwAtAGUAeABwAG8AcgB0ACAA YwBvAG0AbQB1AG4AaQB0AGkAZQBzACAAbwByACAAcgBvAHUAdABpAG4AZwAgAHQAaABlACAASQBY AFAADQAgACAAIABMAEEATgBzACAAdwBpAHQAaABpAG4AIAB0AGgAZQAgAHAAYQByAHQAaQBjAGkA cABhAG4AdABzACcAIABJAEcAUAApACAAdABvACAAcABlAHIAZgBvAHIAbQAgAGYAYQB1AGwAdAAg AG0AYQBuAGEAZwBlAG0AZQBuAHQALgAgACAASQBYAFAADQAgACAAIABlAHgAdABlAHIAbgBhAGwA IABzAGUAcgB2AGkAYwBlAHMAIAAoAHMAdQBjAGgAIABhAHMAIABkAG4AcwAsACAAdwBlAGIAIABw AGEAZwBlAHMALAAgAGYAdABwACAAcwBlAHIAdgBlAHIAcwApACAAbgBlAGUAZABzACAAdABvACAA YgBlAA0AIAAgACAAZwBsAG8AYgBhAGwAbAB5ACAAcgBvAHUAdABlAGQAIABhAG4AZAAgAGQAdQBl ACAAdABvACAAcwB0AHIAaQBjAHQAIABwAHIAZQBmAGkAeAAgAGwAZQBuAGcAdABoACAAZgBpAGwA dABlAHIAaQBuAGcAIABjAG8AdQBsAGQAIABiAGUADQAgACAAIAB0AGgAZQAgAHIAZQBhAHMAbwBu ACAAdABvACAAcgBlAHEAdQBlAHMAdAAgAG0AbwByAGUAIAB0AGgAYQBuACAAbwBuAGUAIAAvADQA OAAgAGEAcwBzAGkAZwBuAG0AZQBuAHQAIABmAHIAbwBtACAAYQAgAFIASQBSACAAKABpAC4AZQAu AA0AIAAgACAAcgBlAHEAdQBlAHMAdABpAG4AZwAgAG8AbgBlACAALwA0ADgAIABmAG8AcgAgAHQA aABlACAASQBYAFAAcwAgAEwAQQBOAHMAIAB0AGgAYQB0ACAAaQBzACAAbgBvAHQAIABnAGwAbwBi AGEAbABsAHkAIAByAG8AdQB0AGUAZAAgAGEAbgBkAA0AIAAgACAAYQAgAGQAaQBmAGYAZQByAGUA bgB0ACAALwA0ADgAIABmAG8AcgAgAHQAaABlACAASQBYAFAAIABlAHgAdABlAHIAbgBhAGwAIABz AGUAcgB2AGkAYwBlAHMAIAB0AGgAYQB0ACAAaQBzACAAZwBsAG8AYgBhAGwAbAB5AA0AIAAgACAA cgBvAHUAdABlAGQAKQAuACAAIAAFAEkAUAB2ADYAIABwAHIAZQBmAGkAeABlAHMAIABmAG8AcgAg AEkAWABQACAATABBAE4AJwBzACAAYQByAGUAIAB0AHkAcABpAGMAYQBsAGwAeQAgAHAAdQBiAGwA aQBjAGwAeQAgAHcAZQBsAGwADQAgACAAIABrAG4AbwB3AG4ALgANAA0ADQANAA0ADQBHAGEAZwBs AGkAYQBuAG8AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMA IABNAGEAcgBjAGgAIAAxADIALAAgADIAMAAxADAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgAFsAUABhAGcAZQAgADUAXQANAA0ADQBJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABJAFAAdgA2ACAAaQBuACAASQBYAFAAcwAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFMAZQBwAHQAZQBtAGIAZQByACAAMgAwADAA OQANAA0ADQA0AC4AIAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAASQBQAHYANgANAA0AIAAgACAAVABo AGUAcgBlACAAYQByAGUAIAB0AHcAbwAgAGUAbABlAG0AZQBuAHQAcwAgAHQAaABhAHQAIABuAGUA ZQBkACAAdABvACAAYgBlACAAZQB2AGEAbAB1AGEAdABlAGQAIAB3AGgAZQBuACAAcwB0AHUAZAB5 AGkAbgBnACAASQBQAHYANgANACAAIAAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAaQBuACAAYQBuACAA SQBYAFAAOgAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAcwB1AHAAcABvAHIAdAAgAGYAbwByACAAbgBl AGkAZwBoAGIAbwByACAAZABpAHMAYwBvAHYAZQByAHkAIABhAG4AZAANACAAIAAgAG0AdQBsAHQA aQBjAGEAcwB0ACAAcABlAGUAcgBpAG4AZwAuAA0ADQAgACAAIABJAFgAUABzACAAdAB5AHAAaQBj AGEAbABsAHkAIABjAG8AbgB0AHIAbwBsACAAYgByAG8AYQBkAGMAYQBzAHQAIAB0AHIAYQBmAGYA aQBjACAAYQBjAHIAbwBzAHMAIAB0AGgAZQAgAHMAdwBpAHQAYwBoAGkAbgBnACAAZgBhAGIAcgBp AGMADQAgACAAIABpAG4AIABvAHIAZABlAHIAIAB0AG8AIABhAHYAbwBpAGQAIABiAHIAbwBhAGQA YwBhAHMAdAAgAHMAdABvAHIAbQBzACAAYgB5ACAAbwBuAGwAeQAgAGEAbABsAG8AdwBpAG4AZwAg AGwAaQBtAGkAdABlAGQAIABBAFIAUAANACAAIAAgAFsAUgBGAEMAMAA4ADIANgBdACAAdAByAGEA ZgBmAGkAYwAgAGYAbwByACAAYQBkAGQAcgBlAHMAcwAgAHIAZQBzAG8AbAB1AHQAaQBvAG4ALgAg ACAASQBuACAASQBQAHYANgAgAHQAaABlAHIAZQAgAGkAcwAgAG4AbwB0AA0AIAAgACAAYgByAG8A YQBkAGMAYQBzAHQAIABzAHUAcABwAG8AcgB0ACAAYgB1AHQAIABJAFgAUAAgAG0AYQB5ACAAaQBu AHQAZQBuAGQAIAB0AG8AIABjAG8AbgB0AHIAbwBsACAAbQB1AGwAdABpAGMAYQBzAHQAIAB0AHIA YQBmAGYAaQBjACAAaQBuAA0AIAAgACAAZQBhAGMAaAAgAEwAQQBOACAAaQBuAHMAdABlAGEAZAAu ACAAIABJAEMATQBQAHYANgAgAE4AZQBpAGcAaABiAG8AcgAgAEQAaQBzAGMAbwB2AGUAcgB5ACAA WwBSAEYAQwA0ADgANgAxAF0AIABpAG0AcABsAGUAbQBlAG4AdABzACAAdABoAGUADQAgACAAIABm AG8AbABsAG8AdwBpAG4AZwAgAG4AZQBjAGUAcwBzAGEAcgB5ACAAZgB1AG4AYwB0AGkAbwBuAHMA IABpAG4AIABhAG4AIABJAFgAUAAgAHMAdwBpAHQAYwBoAGkAbgBnACAAZgBhAGIAcgBpAGMAOgAg AEEAZABkAHIAZQBzAHMADQAgACAAIABSAGUAcwBvAGwAdQB0AGkAbwBuACwAIABOAGUAaQBnAGgA YgBvAHIAIABVAG4AcgBlAGEAYwBoAGEAYgBpAGwAaQB0AHkAIABEAGUAdABlAGMAdABpAG8AbgAg AGEAbgBkACAARAB1AHAAbABpAGMAYQB0AGUAIABBAGQAZAByAGUAcwBzAA0AIAAgACAARABlAHQA ZQBjAHQAaQBvAG4ALgAgACAASQBuACAAbwByAGQAZQByACAAdABvACAAcABlAHIAZgBvAHIAbQAg AHQAaABlAHMAZQAgAGYAdQBuAGMAdABpAG8AbgBzACwAIABOAGUAaQBnAGgAYgBvAHIADQAgACAA IABTAG8AbABpAGMAaQB0AGEAdABpAG8AbgAgAGEAbgBkACAATgBlAGkAZwBoAGIAbwByACAAQQBk AHYAZQByAHQAaQBzAGUAbQBlAG4AdAAgAHAAYQBjAGsAZQB0AHMAIABhAHIAZQAgAGUAeABjAGgA YQBuAGcAZQAgAHUAcwBpAG4AZwANACAAIAAgAHQAaABlACAAbABpAG4AawAtAGwAbwBjAGEAbAAg AGEAbABsAC0AbgBvAGQAZQBzACAAbQB1AGwAdABpAGMAYQBzAHQAIABhAGQAZAByAGUAcwBzACAA KABGAEYAMAAyADoAOgAxACkAIABhAG4AZAAvAG8AcgANACAAIAAgAHMAbwBsAGkAYwBpAHQAZQBk AC0AbgBvAGQAZQAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAYQBkAGQAcgBlAHMAcwBlAHMAIAAoAEYA RgAwADIAOgAwADoAMAA6ADAAOgAwADoAMQA6AEYARgAwADAAOgAwADAAMAAwACAAdABvACAARgBG ADAAMgA6AA0AIAAgACAAMAA6ADAAOgAwADoAMAA6ADEAOgBGAEYARgBGADoARgBGAEYARgApAC4A IAAgAEEAcwAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAAWwBSAEYAQwA0ADgANgAxAF0AIABy AG8AdQB0AGUAcgBzACAAdwBpAGwAbAANACAAIAAgAGkAbgBpAHQAaQBhAGwAaQB6AGUAIABpAHQA cwAgAGkAbgB0AGUAcgBmAGEAYwBlAHMAIABiAHkAIABqAG8AaQBuAGkAbgBnACAAaQB0AHMAIABz AG8AbABpAGMAaQB0AGUAZAAtAG4AbwBkAGUAIABtAHUAbAB0AGkAYwBhAHMAdAANACAAIAAgAGEA ZABkAHIAZQBzAHMAZQBzACAAdQBzAGkAbgBnACAAZQBpAHQAaABlAHIAIABNAHUAbAB0AGkAYwBh AHMAdAAgAEwAaQBzAHQAZQBuAGUAcgAgAEQAaQBzAGMAbwB2AGUAcgB5ACAAKABNAEwARAApACAA WwBSAEYAQwAyADcAMQAwAF0ADQAgACAAIABvAHIAIABNAEwARAB2ADIAIABbAFIARgBDADMAOAAx ADAAXQAuACAAIABNAEwARAAgAG0AZQBzAHMAYQBnAGUAcwAgAG0AYQB5ACAAYgBlACAAcwBlAG4A dAAgAHQAbwAgAHQAaABlACAAYwBvAHIAcgBlAHMAcABvAG4AZABpAG4AZwANACAAIAAgAGcAcgBv AHUAcAAgAGEAZABkAHIAZQBzAHMAOgBGAEYAMAAyADoAOgAyACAAKABNAEwARAApACAAbwByACAA RgBGADAAMgA6ADoAMQA2ACAAKABNAEwARAB2ADIAKQAuACAAIABEAGUAcABlAG4AZABpAG4AZwAg AG8AbgAgAHQAaABlAA0AIAAgACAAYQBkAGQAcgBlAHMAcwBpAG4AZwAgAHAAbABhAG4AIABzAGUA bABlAGMAdABlAGQAIABiAHkAIAB0AGgAZQAgAEkAWABQACwAIABlAGEAYwBoACAAcwBvAGwAaQBj AGkAdABlAGQALQBuAG8AZABlACAAbQB1AGwAdABpAGMAYQBzAHQADQAgACAAIABnAHIAbwB1AHAA IABtAGEAeQAgAGIAZQAgAHMAaABhAHIAZQBkACAAYgB5ACAAYQAgAHMAdQBiAC0AcwBlAHQAIABv AGYAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAnACAAYwBvAG4AZABpAHQAaQBvAG4AZQBkACAA YgB5ACAAaABvAHcADQAgACAAIAB0AGgAZQAgAGwAYQBzAHQAIAB0AGgAcgBlAGUAIABvAGMAdABl AGMAdABzACAAbwBmACAAdABoAGUAIABhAGQAZAByAGUAcwBzAGUAcwAgAGEAcgBlACAAcwBlAGwA ZQBjAHQAZQBkAC4AIAAgAEkAbgAgAFMAZQBjAHQAaQBvAG4AIAAzAA0AIAAgACAAZQB4AGEAbQBw AGwAZQAgADEALAAgAG8AbgBsAHkAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAgAHcAaQB0AGgA IABBAFMATgBzACAAdwBpAHQAaAAgAHQAaABlACAAcwBhAG0AZQAgAHQAdwBvACAAbABhAHMAdAAg AGQAaQBnAGkAdABzAA0AIAAgACAAYQByAGUAIABnAG8AaQBuAGcAIAB0AG8AIABzAGgAYQByAGUA IAB0AGgAZQAgAHMAYQBtAGUAIABzAG8AbABpAG8AYwBpAHQAZQBkAC0AbgBvAGQAZQAgAG0AdQBs AHQAaQBjAGEAcwB0ACAAZwByAG8AdQBwAC4ADQANACAAIAAgAFMAaQBtAGkAbABhAHIAbAB5ACAA dABvACAAdABoAGUAIABBAFIAUAAgAHAAbwBsAGkAYwB5ACAAYQBuACAASQBYAFAAIABtAGEAeQAg AGwAaQBtAGkAdAAgAG0AdQBsAHQAaQBjAGEAcwB0ACAAdAByAGEAZgBmAGkAYwANACAAIAAgAGEA YwBjAHIAbwBzAHMAcwAgAHQAaABlACAAcwB3AGkAdABjAGgAaQBuAGcAIABmAGEAYgByAGkAYwAg AGkAbgAgAG8AcgBkAGUAcgAgAHQAbwAgAG8AbgBsAHkAIABhAGwAbABvAHcAIABJAEMATQBQAHYA NgAgAE4AZQBpAGcAaABiAG8AcgANACAAIAAgAFMAbwBsAGkAYwBpAHQAYQB0AGkAbwBuACwAIABO AGUAaQBnAGgAYgBvAHIAIABBAGQAdgBlAHIAdABpAHMAZQBtAGUAbgB0ACAAYQBuAGQAIABNAEwA RAAgAG0AZQBzAHMAYQBnAGUAcwAuACAAIABDAG8AbgBmAGkAZwB1AHIAaQBuAGcADQAgACAAIABk AGUAZgBhAHUAbAB0ACAAcgBvAHUAdABlAHMAIABpAG4AIABhAG4AIABJAFgAUAAgAEwAQQBOACAA dwBpAHQAaABvAHUAdAAgAGEAbgAgAGEAZwByAGUAZQBtAGUAbgB0ACAAdwBpAHQAaABpAG4AIAB0 AGgAZQAgAHAAYQByAHQAaQBlAHMADQAgACAAIABpAHMAIABuAG8AcgBtAGEAbABsAHkAIABhAGcA YQBpAG4AcwB0ACAASQBYAFAAIABwAG8AbABpAGMAaQBlAHMALgAgACAASQBDAE0AUAB2ADYAIABS AG8AdQB0AGUAcgAgAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQADQAgACAAIABwAGEAYwBrAGUA dABzACAAcwBoAG8AdQBsAGQAIABuAGUAaQB0AGgAZQByACAAYgBlACAAaQBzAHMAdQBlAGQAIABu AG8AcgAgAGEAYwBjAGUAcAB0AGUAZAAgAGIAeQAgAHIAbwB1AHQAZQByAHMAIABjAG8AbgBuAGUA YwB0AGUAZAAgAHQAbwANACAAIAAgAHQAaABlACAASQBYAFAALgAgACAAVwBoAGUAcgBlACAAcABv AHMAcwBpAGIAbABlACwAIAB0AGgAZQAgAEkAWABQACAAbwBwAGUAcgBhAHQAbwByACAAcwBoAG8A dQBsAGQAIABiAGwAbwBjAGsAIABsAGkAbgBrAC0AbABvAGMAYQBsACAAUgBBAA0AIAAgACAAcABh AGMAawBlAHQAcwAgAHUAcwBpAG4AZwAgAEkAUAB2ADYAIABSAEEALQBHAHUAYQByAGQALgAgACAA SQBmACAAdABoAGkAcwAgAGkAcwAgAG4AbwB0ACAAcABvAHMAcwBpAGIAbABlACwAIAB0AGgAZQAg AEkAWABQAA0AIAAgACAAbwBwAGUAcgBhAHQAbwByACAAcwBoAG8AdQBsAGQAIABtAG8AbgBpAHQA bwByACAAdABoAGUAIABlAHgAYwBoAGEAbgBnAGUAIABmAG8AcgAgAHIAbwBnAHUAZQAgAFIAbwB1 AHQAZQByACAAQQBkAHYAZQByAHQAaQBzAGUAbQBlAG4AdAANACAAIAAgAHAAYQBjAGsAZQB0AHMA LgANAA0AIAAgACAARgBvAHIAIABJAFAAdgA2ACAATQB1AGwAdABpAGMAYQBzAHQAIAB0AHIAYQBm AGYAaQBjACAAZQB4AGMAaABhAG4AZwBlACwAIABhAG4AIABJAFgAUAAgAG0AYQB5ACAAZABlAGMA aQBkAGUAIAB0AG8AIAB1AHMAZQAgAGUAaQB0AGgAZQByAA0AIAAgACAAdABoAGUAIABzAGEAbQBl ACAATABBAE4AIABiAGUAaQBuAGcAIAB1AHMAZQBkACAAZgBvAHIAIAB1AG4AaQBjAGEAcwB0ACAA SQBQAHYANgAgAHQAcgBhAGYAZgBpAGMAIABlAHgAYwBoAGEAbgBnAGUALAAgAHQAaABlACAAcwBh AG0AZQANACAAIAAgAEwAQQBOACAAYgBlAGkAbgBnACAAdQBzAGUAZAAgAGYAbwByACAASQBQAHYA NAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAAdAByAGEAZgBmAGkAYwAgAGUAeABjAGgAYQBuAGcAZQAg AG8AcgAgAGEAIABkAGUAZABpAGMAYQB0AGUAZAAgAEwAQQBOAA0AIAAgACAAZgBvAHIAIABJAFAA dgA2ACAATQB1AGwAdABpAGMAYQBzAHQAIAB0AHIAYQBmAGYAaQBjACAAZQB4AGMAaABhAG4AZwBl AC4AIAAgAFQAaABlACAAcgBlAGEAcwBvAG4AIABmAG8AcgAgAGgAYQB2AGkAbgBnACAAYQANACAA IAAgAGQAZQBkAGkAYwBhAHQAZQBkACAATABBAE4AIABmAG8AcgAgAG0AdQBsAHQAaQBjAGEAcwB0 ACAAaQBzACAAdABvACAAcAByAGUAdgBlAG4AdAAgAHUAbgB3AGEAbgB0AGUAZAAgAG0AdQBsAHQA aQBjAGEAcwB0ACAAdAByAGEAZgBmAGkAYwANACAAIAAgAHQAbwAgAHIAZQBhAGMAaAAgAHAAYQBy AHQAaQBjAGkAcABhAG4AdABzACAAdABoAGEAdAAgAGQAbwAgAG4AbwB0ACAAaABhAHYAZQAgAG0A dQBsAHQAaQBjAGEAcwB0ACAAcwB1AHAAcABvAHIAdAAuACAAIABQAHIAbwB0AG8AYwBvAGwADQAg ACAAIABJAG4AZABlAHAAZQBuAGQAZQBuAHQAIABNAHUAbAB0AGkAYwBhAHMAdAAgAFsAUgBGAEMA NAA2ADAAMQBdACAAbQBlAHMAcwBhAGcAZQBzACAAdwBpAGwAbAAgAGIAZQAgAHMAZQBuAHQAIAB0 AG8AIAB0AGgAZQAgAHQAaABlAA0AIAAgACAAbABpAG4AawAtAGwAbwBjAGEAbAAgAEkAUAB2ADYA IAAnAEEATABMAC0AUABJAE0ALQBSAE8AVQBUAEUAUgBTACcAIABtAHUAbAB0AGkAYwBhAHMAdAAg AGcAcgBvAHUAcAAgAGYAZgAwADIAOgA6AGQAIABpAG4AIAB0AGgAZQANACAAIAAgAHMAZQBsAGUA YwB0AGUAZAAgAEwAQQBOACAAYQBuAGQAIABzAGgAbwB1AGwAZAAgAGIAZQAgAGEAbABsAG8AdwBl AGQALgAgACAASQBtAHAAbABlAG0AZQBuAHQAaQBuAGcAIABJAFAAdgA2ACAAUABJAE0AIABzAG4A bwBvAHAAaQBuAGcADQANAA0ADQBHAGEAZwBsAGkAYQBuAG8AIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgAEUAeABwAGkAcgBlAHMAIABNAGEAcgBjAGgAIAAxADIALAAgADIAMAAxADAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFsAUABhAGcAZQAgADYAXQANAA0ADQBJ AG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IABJAFAAdgA2ACAAaQBuACAASQBYAFAAcwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg AFMAZQBwAHQAZQBtAGIAZQByACAAMgAwADAAOQANAA0ADQAgACAAIAB3AGkAbABsACAAYQBsAGwA bwB3ACAAbwBuAGwAeQAgAHQAaABlACAAcABhAHIAdABpAGMAaQBwAGEAbgB0AHMAIABhAHMAcwBv AGMAaQBhAHQAZQBkACAAdABvACAAYQAgAHAAYQByAHQAaQBjAHUAbABhAHIAIABnAHIAbwB1AHAA IAB0AG8ADQAgACAAIAByAGUAYwBlAGkAdgBlACAAaQB0AHMAIABtAHUAbAB0AGkAYwBhAHMAdAAg AHQAcgBhAGYAZgBpAGMALgAgACAAQgBHAFAAIAByAGUAYQBjAGgAYQBiAGkAbABpAHQAeQAgAGkA bgBmAG8AcgBtAGEAdABpAG8AbgAgAGYAbwByACAASQBQAHYANgANACAAIAAgAG0AdQBsAHQAaQBj AGEAcwB0ACAAYQBkAGQAcgBlAHMAcwAtAGYAYQBtAGkAbAB5ACAAKABTAEEARgBJAD0AMgApACAA aQBzACAAbgBvAHIAbQBhAGwAbAB5ACAAZQB4AGMAaABhAG4AZwBlAGQAIAB1AHMAaQBuAGcAIABN AFAALQBCAEcAUAANACAAIAAgAFsAUgBGAEMANAA3ADYAMABdACAAYQBuAGQAIABpAHMAIAB1AHMA ZQBkACAAZgBvAHIAIABSAGUAdgBlAHIAcwBlACAAUABhAHQAaAAgAEYAbwByAHcAYQByAGQAaQBu AGcAIAAoAFIAUABGACkAIABsAG8AbwBrAHUAcABzAA0AIAAgACAAcABlAHIAZgBvAHIAbQBlAGQA IABiAHkAIAB0AGgAZQAgAEkAUAB2ADYAIABQAEkATQAuACAAIABJAGYAIABhACAAZABlAGQAaQBj AGEAdABlAGQAIABMAEEATgAgAGkAcwAgAGMAbwBuAGYAaQBnAHUAcgBlAGQAIABmAG8AcgANACAA IAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAASQBQAHYANgAgAHQAcgBhAGYAZgBpAGMAIABlAHgAYwBo AGEAbgBnAGUALAAgAHIAZQBhAGMAaABhAGIAaQBsAGkAdAB5ACAAaQBuAGYAbwByAG0AYQB0AGkA bwBuACAAZgBvAHIAIABJAFAAdgA2AA0AIAAgACAATQB1AGwAdABpAGMAYQBzAHQAIABhAGQAZABy AGUAcwBzACAAZgBhAG0AaQBsAHkAIABzAGgAbwB1AGwAZAAgAGIAZQAgAGMAYQByAHIAaQBlAGQA IABpAG4AIABuAGUAdwAgAEIARwBQACAAcwBlAHMAcwBpAG8AbgBzAC4ADQAgACAAIABJAEMATQBQ AHYANgAgAE4AZQBpAGcAaABiAG8AcgAgAEQAaQBzAGMAbwB2AGUAcgB5ACAAcwBoAG8AdQBsAGQA IABiAGUAIABhAGwAbABvAHcAZQBkACAAaQBuACAAdABoAGUAIABNAHUAbAB0AGkAYwBhAHMAdAAg AEkAUAB2ADYAIABMAEEATgANACAAIAAgAGEAcwAgAGQAZQBzAGMAcgBpAGIAZQBkACAAaQBuACAA dABoAGUAIABwAHIAZQB2AGkAbwB1AHMAIABwAGEAcgBhAGcAcgBhAHAAaAAuAA0ADQANADUALgAg ACAAUgBlAHYAZQByAHMAZQAgAEQATgBTAA0ADQAgACAAIABQAFQAUgAgAHIAZQBjAG8AcgBkAHMA IABmAG8AcgAgAGEAbABsACAAYQBkAGQAcgBlAHMAcwBlAHMAIABhAHMAcwBpAGcAbgBlAGQAIAB0 AG8AIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAgAHMAaABvAHUAbABkACAAYgBlAA0AIAAgACAA aQBuAGMAbAB1AGQAZQBkACAAaQBuACAAdABoAGUAIABJAFgAUAAgAHIAZQB2AGUAcgBzAGUAIAB6 AG8AbgBlACAAdQBuAGQAZQByACAAIgBpAHAANgAuAGEAcgBwAGEAIgAgAGYAbwByACAAdAByAG8A dQBiAGwAZQBzAGgAbwBvAHQAaQBuAGcADQAgACAAIABwAHUAcgBwAG8AcwBlAHMALgAgACAARABO AFMAIABzAGUAcgB2AGUAcgBzACAAcwBoAG8AdQBsAGQAIABiAGUAIAByAGUAYQBjAGgAYQBiAGwA ZQAgAG8AdgBlAHIAIABJAFAAdgA2ACAAdAByAGEAbgBzAHAAbwByAHQAIABmAG8AcgANACAAIAAg AGMAbwBtAHAAbABlAHQAZQAgAEkAUAB2ADYAIABzAHUAcABwAG8AcgB0AC4ADQANAA0ANgAuACAA IABSAG8AdQB0AGUAIABTAGUAcgB2AGUAcgANAA0AIAAgACAASQBYAFAAcwAgAG0AYQB5ACAAbwBm AGYAZQByACAAYQAgAFIAbwB1AHQAZQAgAFMAZQByAHYAZQByACAAcwBlAHIAdgBpAGMAZQAsACAA ZQBpAHQAaABlAHIAIABmAG8AcgAgAE0AdQBsAHQAaQAtAEwAYQB0AGUAcgBhAGwADQAgACAAIABQ AGUAZQByAGkAbgBnACAAQQBnAHIAZQBlAG0AZQBuAHQAcwAgACgATQBMAFAAQQApACAAcwBlAHIA dgBpAGMAZQAsACAAbABvAG8AawBpAG4AZwAgAGcAbABhAHMAcwAgAHMAZQByAHYAaQBjAGUAIABv AHIAIAByAG8AdQB0AGUALQANACAAIAAgAGMAbwBsAGwAZQBjAHQAaQBvAG4AIABzAGUAcgB2AGkA YwBlAC4AIAAgAEkAUAB2ADYAIABzAHUAcABwAG8AcgB0ACAAbgBlAGUAZABzACAAdABvACAAYgBl ACAAYQBkAGQAZQBkACAAdABvACAAdABoAGUAIABCAEcAUAANACAAIAAgAHMAcABlAGEAawBpAG4A ZwAgAHIAbwB1AHQAZQByAC4AIAAgAFQAaABlACAAZQBxAHUAaQBwAG0AZQBuAHQAIABzAGgAbwB1 AGwAZAAgAGIAZQAgAGEAYgBsAGUAIAB0AG8AIAB0AHIAYQBuAHMAcABvAHIAdAAgAEkAUAB2ADYA DQAgACAAIAB0AHIAYQBmAGYAaQBjACAAYQBuAGQAIAB0AG8AIABzAHUAcABwAG8AcgB0ACAATQB1 AGwAdABpAC0AcAByAG8AdABvAGMAbwBsACAAQgBHAFAAIAAoAE0AUAAtAEIARwBQACkAIABlAHgA dABlAG4AcwBpAG8AbgBzACAAZgBvAHIADQAgACAAIABJAFAAdgA2ACAAYQBkAGQAcgBlAHMAcwAg AGYAYQBtAGkAbAB5ACAAKABbAFIARgBDADIANQA0ADUAXQAgAGEAbgBkACAAWwBSAEYAQwA0ADcA NgAwAF0AKQAuAA0ADQAgACAAIABBACAAZwBvAG8AZAAgAHAAcgBhAGMAdABpAGMAZQAgAGkAcwAg AHQAaABhAHQAIABhAGwAbAAgAEIARwBQACAAcwBlAHMAcwBpAG8AbgBzACAAdQBzAGUAZAAgAHQA bwAgAGUAeABjAGgAYQBuAGcAZQAgAEkAUAB2ADYADQAgACAAIABuAGUAdAB3AG8AcgBrACAAaQBu AGYAbwByAG0AYQB0AGkAbwBuACAAYQByAGUAIABjAG8AbgBmAGkAZwB1AHIAZQBkACAAdQBzAGkA bgBnACAASQBQAHYANgAgAGQAYQB0AGEAIAB0AHIAYQBuAHMAcABvAHIAdAAuACAAIABUAGgAaQBz AA0AIAAgACAAYwBvAG4AZgBpAGcAdQByAGEAdABpAG8AbgAgAHMAdAB5AGwAZQAgAGUAbgBzAHUA cgBlAHMAIAB0AGgAYQB0ACAAYQBzACAAYgBvAHQAaAAgAG4AZQB0AHcAbwByAGsAIAByAGUAYQBj AGgAYQBiAGkAbABpAHQAeQANACAAIAAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAGEAbgBkACAA ZwBlAG4AZQByAGkAYwAgAHAAYQBjAGsAZQB0ACAAZABhAHQAYQAgAHQAcgBhAG4AcwBwAG8AcgB0 ACAAdQBzAGUAIAB0AGgAZQAgAHMAYQBtAGUAIAB0AHIAYQBuAHMAcABvAHIAdAANACAAIAAgAHAA bABhAG4AZQAsACAAaQBuACAAdABoAGUAIABlAHYAZQBuAHQAIABvAGYAIABJAFAAdgA2ACAAcgBl AGEAYwBoAGEAYgBpAGwAaQB0AHkAIABwAHIAbwBiAGwAZQBtAHMAIABiAGUAdAB3AGUAZQBuACAA SQBQAHYANgAgAHAAZQBlAHIAcwAsAA0AIAAgACAAdABoAGUAIABJAFAAdgA2ACAAQgBHAFAAIABz AGUAcwBzAGkAbwBuACAAbQBhAHkAIABiAGUAIAB0AGUAcgBtAGkAbgBhAHQAZQBkACAAaQBuAGQA ZQBwAGUAbgBkAGUAbgB0AGwAeQAgAG8AZgAgAGEAbgB5ACAASQBQAHYANAANACAAIAAgAHMAZQBz AHMAaQBvAG4AcwAuACAAIABUAGgAZQAgAHUAcwBlACAAbwBmACAATQBEADUAIABbAFIARgBDADIA MwA4ADUAXQAgAG8AcgAgAEkAUABTAEUAQwAgAFsAUgBGAEMANAAzADAAMQBdACAAdABvAA0AIAAg ACAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGUAIAB0AGgAZQAgAEIARwBQACAAcwBlAHMAcwBpAG8A bgBzACAAYQBuAGQAIAB0AGgAZQAgAHUAcwBlACAAbwBmACAARwBUAFMATQAgACgAVABoAGUAIABH AGUAbgBlAHIAYQBsAGkAegBlAGQADQAgACAAIABUAFQATAAgAFMAZQBjAHUAcgBpAHQAeQAgAE0A ZQBjAGgAYQBuAGkAcwBtACkAIABbAFIARgBDADMANgA4ADIAXQAgAHMAaABvAHUAbABkACAAYgBl ACAAYwBvAG4AcwBpAGQAZQByAGUAZAAuAA0ADQAgACAAIABUAGgAZQAgAHIAbwB1AHQAZQAgAGMA bwBsAGwAZQBjAHQAaQBvAG4AUgBvAHUAdABlAHIALQBTAGUAcgB2AGUAcgAgAG8AcgAgAEwAbwBv AGsAaQBuAGcAIABHAGwAYQBzAHMAIABlAHgAdABlAHIAbgBhAGwAIABzAGUAcgB2AGkAYwBlACAA cwBoAG8AdQBsAGQAIABiAGUADQAgACAAIABhAHYAYQBpAGwAYQBiAGwAZQAgAGYAbwByACAAZQB4 AHQAZQByAG4AYQBsACAASQBQAHYANgAgAGEAYwBjAGUAcwBzACwAIABlAGkAdABoAGUAcgAgAGIA eQAgAGEAbgAgAEkAUAB2ADYAIABlAG4AYQBiAGwAZQBkACAAdwBlAGIADQAgACAAIABwAGEAZwBl ACAAbwByACAAYQBuACAASQBQAHYANgAgAGUAbgBhAGIAbABlAGQAIABjAG8AbgBzAG8AbABlACAA aQBuAHQAZQByAGYAYQBjAGUALgANAA0ADQA3AC4AIAAgAEUAeAB0AGUAcgBuAGEAbAAgAGEAbgBk ACAASQBuAHQAZQByAG4AYQBsACAAcwB1AHAAcABvAHIAdAANAA0AIAAgACAAUwBvAG0AZQAgAGUA eAB0AGUAcgBuAGEAbAAgAHMAZQByAHYAaQBjAGUAcwAgAHQAaABhAHQAIABuAGUAZQBkACAAdABv ACAAaABhAHYAZQAgAEkAUAB2ADYAIABzAHUAcABwAG8AcgB0ACAAYQByAGUAIABUAHIAYQBmAGYA aQBjAA0AIAAgACAARwByAGEAcABoAGkAYwBzACwAIABEAE4AUwAsACAARgBUAFAALAAgAFcAZQBi ACwAIABSAG8AdQB0AGUAIABTAGUAcgB2AGUAcgAgAGEAbgBkACAATABvAG8AawBpAG4AZwAgAEcA bABhAHMAcwAuACAAIABPAHQAaABlAHIADQAgACAAIABlAHgAdABlAHIAbgBhAGwAIABzAGUAcgB2 AGkAYwBlAHMAIABzAHUAYwBoACAAYQBzACAATgBUAFAAIABzAGUAcgB2AGUAcgBzACwAIABvAHIA IABTAEkAUAAgAEcAYQB0AGUAdwBhAHkAcwAgAG4AZQBlAGQAIAB0AG8AIABiAGUADQANAA0ADQBH AGEAZwBsAGkAYQBuAG8AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEUAeABwAGkA cgBlAHMAIABNAGEAcgBjAGgAIAAxADIALAAgADIAMAAxADAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgAFsAUABhAGcAZQAgADcAXQANAA0ADQBJAG4AdABlAHIAbgBlAHQALQBEAHIA YQBmAHQAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABJAFAAdgA2ACAAaQBuACAASQBY AFAAcwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFMAZQBwAHQAZQBtAGIAZQByACAA MgAwADAAOQANAA0ADQAgACAAIABlAHYAYQBsAHUAYQB0AGUAZAAgAGEAcwAgAHcAZQBsAGwALgAg ACAASQBuACAAZwBlAG4AZQByAGEAbAAsACAAZQBhAGMAaAAgAHMAZQByAHYAaQBjAGUAIAB0AGgA YQB0ACAAaQBzACAAYwB1AHIAcgBlAG4AdABsAHkADQAgACAAIABhAGMAYwBlAHMAcwBlAGQAIAB0 AGgAcgBvAHUAZwBoACAASQBQAHYANAAgAG8AcgAgAHQAaABhAHQAIABoAGEAbgBkAGwAZQAgAEkA UAB2ADQAIABhAGQAZAByAGUAcwBzAGUAcwAgAHMAaABvAHUAbABkACAAYgBlAA0AIAAgACAAZQB2 AGEAbAB1AGEAdABlAGQAIABmAG8AcgAgAEkAUAB2ADYAIABzAHUAcABwAG8AcgB0AC4ADQANACAA IAAgAEkAbgB0AGUAcgBuAGEAbAAgAHMAZQByAHYAaQBjAGUAcwAgAGEAcgBlACAAYQBsAHMAbwAg AGkAbQBwAG8AcgB0AGEAbgB0ACAAdwBoAGUAbgAgAGMAbwBuAHMAaQBkAGUAcgBpAG4AZwAgAEkA UAB2ADYAIABhAGQAbwBwAHQAaQBvAG4ADQAgACAAIABhAHQAIABhAG4AIABJAFgAUAAuACAAIABT AHUAYwBoACAAcwBlAHIAdgBpAGMAZQBzACAAbQBhAHkAIABuAG8AdAAgAGQAZQBhAGwAIAB3AGkA dABoACAASQBQAHYANgAgAHQAcgBhAGYAZgBpAGMAIABiAHUAdAAgAG0AYQB5AA0AIAAgACAAaABh AG4AZABsAGUAIABJAFAAdgA2ACAAYQBkAGQAcgBlAHMAcwBlAHMAOwAgAHQAaABhAHQAIABpAHMA IAB0AGgAZQAgAGMAYQBzAGUAIABvAGYAIABwAHIAbwB2AGkAcwBpAG8AbgBpAG4AZwAgAHMAeQBz AHQAZQBtAHMALAANACAAIAAgAGwAbwBnAGcAaQBuAGcAIAB0AG8AbwBsAHMAIABhAG4AZAAgAHMA dABhAHQAaQBzAHQAaQBjAHMAIABhAG4AYQBsAHkAcwBpAHMAIAB0AG8AbwBsAHMALgAgACAARABh AHQAYQBiAGEAcwBlAHMAIABhAG4AZAAgAHQAbwBvAGwAcwANACAAIAAgAHMAaABvAHUAbABkACAA YgBlACAAZQB2AGEAbAB1AGEAdABlAGQAIABmAG8AcgAgAEkAUAB2ADYAIABzAHUAcABwAG8AcgB0 AC4ADQANAA0AOAAuACAAIABJAFgAUAAgAFAAbwBsAGkAYwBpAGUAcwAgAGEAbgBkACAASQBQAHYA NgANAA0AIAAgACAASQBYAFAAIABQAG8AbABpAGMAaQBlAHMAIABhAG4AZAAgAGMAbwBuAHQAcgBh AGMAdABzACAAcwBoAG8AdQBsAGQAIABiAGUAIABiAGUAIAByAGUAdgBpAHMAZQBkACAAYQBzACAA YQBuAHkAIABtAGUAbgB0AGkAbwBuACAAbwBmACAASQBQAA0AIAAgACAAcwBoAG8AdQBsAGQAIABi AGUAIABjAGwAYQByAGkAZgBpAGUAZAAgAGkAZgAgAGkAdAAgAHIAZQBmAGUAcgBzACAAdABvACAA SQBQAHYANAAsACAASQBQAHYANgAgAG8AcgAgAGIAbwB0AGgALgANAA0ADQA5AC4AIAAgAEkAQQBO AEEAIABDAG8AbgBzAGkAZABlAHIAYQB0AGkAbwBuAHMADQANACAAIAAgAFQAaABpAHMAIABtAGUA bQBvACAAaQBuAGMAbAB1AGQAZQBzACAAbgBvACAAcgBlAHEAdQBlAHMAdAAgAHQAbwAgAEkAQQBO AEEALgANAA0ADQAxADAALgAgACAAUwBlAGMAdQByAGkAdAB5ACAAQwBvAG4AcwBpAGQAZQByAGEA dABpAG8AbgBzAA0ADQAgACAAIABUAGgAaQBzACAAbQBlAG0AbwAgAGkAbgBjAGwAdQBkAGUAcwAg AGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAG8AbgAgAHAAcgBhAGMAdABpAGMAZQBzACAAYQB0ACAA SQBYAFAAcwAgAGYAbwByACAAbQBvAG4AaQB0AG8AcgBpAG4AZwANACAAIAAgAGEAbgBkAC8AbwBy ACAAYQB2AG8AaQBkAGkAbgBnACAAYgByAG8AYQBkAGMAYQBzAHQAIABzAHQAbwByAG0AcwAgAGkA bgAgAEkAWABQACAATABBAE4AcwAgAGMAYQB1AHMAZQBkACAAYgB5ACAASQBQAHYANgAgAG0AdQBs AHQAaQBjAGEAcwB0AA0AIAAgACAAdAByAGEAZgBmAGkAYwAuACAAIABJAHQAIABhAGwAcwBvACAA bQBlAG4AdABpAG8AbgBzACAAYQB2AG8AaQBkAGkAbgBnACAASQBQAHYANgAgAEQARABvAFMAIABh AHQAdABhAGMAawBzACAAdABvACAAdABoAGUAIABJAFgAUAANACAAIAAgAHMAdwBpAHQAYwBoAGkA bgBnACAAZgBhAGIAcgBpAGMAIABiAHkAIABuAG8AdAAgAGcAbABvAGIAYQBsAGwAeQAgAGEAbgBu AG8AdQBuAGMAZQAgAHQAaABlACAASQBYAFAAIABMAEEATgBzACAAcAByAGUAZgBpAHgALgANAA0A DQAxADEALgAgACAAQQBjAGsAbgBvAHcAbABlAGQAZwBlAG0AZQBuAHQAcwANAA0AIAAgACAAVABo AGUAIABhAHUAdABoAG8AcgAgAHcAbwB1AGwAZAAgAGwAaQBrAGUAIAB0AG8AIAB0AGgAYQBuAGsA IAB0AGgAZQAgAGMAbwBuAHQAcgBpAGIAdQB0AGkAbwBuAHMAIABmAHIAbwBtACAAUwB0AGkAZwAg AFYAZQBuAGEAYQBzACwADQAgACAAIABNAGEAcgB0AGkAbgAgAEwAZQB2AHkALAAgAE4AaQBjAGsA IABIAGkAbABsAGkAYQByAGQALAAgAE0AYQByAHQAaQBuACAAUABlAGwAcwAsACAAQgBpAGwAbAAg AFcAbwBvAGQAYwBvAGMAawAsACAAQwBhAHIAbABvAHMAIABGAHIAaQBhAHMALAANACAAIAAgAEEA cgBpAGUAbgAgAFYAaQBqAG4AIABhAG4AZAAgAEwAbwB1AGkAcwAgAEwAZQBlAC4ADQANAA0AMQAy AC4AIAAgAFIAZQBmAGUAcgBlAG4AYwBlAHMADQANADEAMgAuADEALgAgACAATgBvAHIAbQBhAHQA aQB2AGUAIABSAGUAZgBlAHIAZQBuAGMAZQBzAA0ADQAgACAAIABbAFIARgBDADAAOAAyADYAXQAg ACAAUABsAHUAbQBtAGUAcgAsACAARAAuACwAIAAiAEUAdABoAGUAcgBuAGUAdAAgAEEAZABkAHIA ZQBzAHMAIABSAGUAcwBvAGwAdQB0AGkAbwBuACAAUAByAG8AdABvAGMAbwBsADoAIABPAHIADQAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAYwBvAG4AdgBlAHIAdABpAG4AZwAgAG4AZQB0AHcA bwByAGsAIABwAHIAbwB0AG8AYwBvAGwAIABhAGQAZAByAGUAcwBzAGUAcwAgAHQAbwAgADQAOAAu AGIAaQB0ACAARQB0AGgAZQByAG4AZQB0AA0AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAGEA ZABkAHIAZQBzAHMAIABmAG8AcgAgAHQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuACAAbwBuACAARQB0 AGgAZQByAG4AZQB0ACAAaABhAHIAZAB3AGEAcgBlACIALAAgAFMAVABEACAAMwA3ACwADQAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAUgBGAEMAIAA4ADIANgAsACAATgBvAHYAZQBtAGIAZQBy ACAAMQA5ADgAMgAuAA0ADQAgACAAIABbAFIARgBDADIAMQAxADkAXQAgACAAQgByAGEAZABuAGUA cgAsACAAUwAuACwAIAAiAEsAZQB5ACAAdwBvAHIAZABzACAAZgBvAHIAIAB1AHMAZQAgAGkAbgAg AFIARgBDAHMAIAB0AG8AIABJAG4AZABpAGMAYQB0AGUADQAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAUgBlAHEAdQBpAHIAZQBtAGUAbgB0ACAATABlAHYAZQBsAHMAIgAsACAAQgBDAFAAIAAx ADQALAAgAFIARgBDACAAMgAxADEAOQAsACAATQBhAHIAYwBoACAAMQA5ADkANwAuAA0ADQANAA0A RwBhAGcAbABpAGEAbgBvACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABFAHgAcABp AHIAZQBzACAATQBhAHIAYwBoACAAMQAyACwAIAAyADAAMQAwACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIABbAFAAYQBnAGUAIAA4AF0ADQANAA0ASQBuAHQAZQByAG4AZQB0AC0ARABy AGEAZgB0ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASQBQAHYANgAgAGkAbgAgAEkA WABQAHMAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABTAGUAcAB0AGUAbQBiAGUAcgAg ADIAMAAwADkADQANAA0AIAAgACAAWwBSAEYAQwAyADMAOAA1AF0AIAAgAEgAZQBmAGYAZQByAG4A YQBuACwAIABBAC4ALAAgACIAUAByAG8AdABlAGMAdABpAG8AbgAgAG8AZgAgAEIARwBQACAAUwBl AHMAcwBpAG8AbgBzACAAdgBpAGEAIAB0AGgAZQAgAFQAQwBQACAATQBEADUADQAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAUwBpAGcAbgBhAHQAdQByAGUAIABPAHAAdABpAG8AbgAiACwAIABS AEYAQwAgADIAMwA4ADUALAAgAEEAdQBnAHUAcwB0ACAAMQA5ADkAOAAuAA0ADQAgACAAIABbAFIA RgBDADIANAA2ADAAXQAgACAARABlAGUAcgBpAG4AZwAsACAAUwAuACAAYQBuAGQAIABSAC4AIABI AGkAbgBkAGUAbgAsACAAIgBJAG4AdABlAHIAbgBlAHQAIABQAHIAbwB0AG8AYwBvAGwALAAgAFYA ZQByAHMAaQBvAG4AIAA2AA0AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACgASQBQAHYANgAp ACAAUwBwAGUAYwBpAGYAaQBjAGEAdABpAG8AbgAiACwAIABSAEYAQwAgADIANAA2ADAALAAgAEQA ZQBjAGUAbQBiAGUAcgAgADEAOQA5ADgALgANAA0AIAAgACAAWwBSAEYAQwAyADQANgA0AF0AIAAg AEMAcgBhAHcAZgBvAHIAZAAsACAATQAuACwAIAAiAFQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuACAA bwBmACAASQBQAHYANgAgAFAAYQBjAGsAZQB0AHMAIABvAHYAZQByACAARQB0AGgAZQByAG4AZQB0 AA0AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAE4AZQB0AHcAbwByAGsAcwAiACwAIABSAEYA QwAgADIANAA2ADQALAAgAEQAZQBjAGUAbQBiAGUAcgAgADEAOQA5ADgALgANAA0AIAAgACAAWwBS AEYAQwAyADUANAA1AF0AIAAgAE0AYQByAHEAdQBlAHMALAAgAFAALgAgAGEAbgBkACAARgAuACAA RAB1AHAAbwBuAHQALAAgACIAVQBzAGUAIABvAGYAIABCAEcAUAAtADQAIABNAHUAbAB0AGkAcABy AG8AdABvAGMAbwBsAA0AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEUAeAB0AGUAbgBzAGkA bwBuAHMAIABmAG8AcgAgAEkAUAB2ADYAIABJAG4AdABlAHIALQBEAG8AbQBhAGkAbgAgAFIAbwB1 AHQAaQBuAGcAIgAsACAAUgBGAEMAIAAyADUANAA1ACwADQAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAATQBhAHIAYwBoACAAMQA5ADkAOQAuAA0ADQAgACAAIABbAFIARgBDADIANwAxADAAXQAg ACAARABlAGUAcgBpAG4AZwAsACAAUwAuACwAIABGAGUAbgBuAGUAcgAsACAAVwAuACwAIABhAG4A ZAAgAEIALgAgAEgAYQBiAGUAcgBtAGEAbgAsACAAIgBNAHUAbAB0AGkAYwBhAHMAdAANACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIABMAGkAcwB0AGUAbgBlAHIAIABEAGkAcwBjAG8AdgBlAHIA eQAgACgATQBMAEQAKQAgAGYAbwByACAASQBQAHYANgAiACwAIABSAEYAQwAgADIANwAxADAALAAN ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABPAGMAdABvAGIAZQByACAAMQA5ADkAOQAuAA0A DQAgACAAIABbAFIARgBDADMANgA4ADIAXQAgACAARwBpAGwAbAAsACAAVgAuACwAIABIAGUAYQBz AGwAZQB5ACwAIABKAC4ALAAgAGEAbgBkACAARAAuACAATQBlAHkAZQByACwAIAAiAFQAaABlACAA RwBlAG4AZQByAGEAbABpAHoAZQBkACAAVABUAEwADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAUwBlAGMAdQByAGkAdAB5ACAATQBlAGMAaABhAG4AaQBzAG0AIAAoAEcAVABTAE0AKQAiACwA IABSAEYAQwAgADMANgA4ADIALAAgAEYAZQBiAHIAdQBhAHIAeQAgADIAMAAwADQALgANAA0AIAAg ACAAWwBSAEYAQwAzADgAMQAwAF0AIAAgAFYAaQBkAGEALAAgAFIALgAgAGEAbgBkACAATAAuACAA QwBvAHMAdABhACwAIAAiAE0AdQBsAHQAaQBjAGEAcwB0ACAATABpAHMAdABlAG4AZQByACAARABp AHMAYwBvAHYAZQByAHkADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAVgBlAHIAcwBpAG8A bgAgADIAIAAoAE0ATABEAHYAMgApACAAZgBvAHIAIABJAFAAdgA2ACIALAAgAFIARgBDACAAMwA4 ADEAMAAsACAASgB1AG4AZQAgADIAMAAwADQALgANAA0AIAAgACAAWwBSAEYAQwA0ADEAOQAzAF0A IAAgAEgAaQBuAGQAZQBuACwAIABSAC4AIABhAG4AZAAgAEIALgAgAEgAYQBiAGUAcgBtAGEAbgAs ACAAIgBVAG4AaQBxAHUAZQAgAEwAbwBjAGEAbAAgAEkAUAB2ADYAIABVAG4AaQBjAGEAcwB0AA0A IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEEAZABkAHIAZQBzAHMAZQBzACIALAAgAFIARgBD ACAANAAxADkAMwAsACAATwBjAHQAbwBiAGUAcgAgADIAMAAwADUALgANAA0AIAAgACAAWwBSAEYA QwA0ADIAOQAxAF0AIAAgAEgAaQBuAGQAZQBuACwAIABSAC4AIABhAG4AZAAgAFMALgAgAEQAZQBl AHIAaQBuAGcALAAgACIASQBQACAAVgBlAHIAcwBpAG8AbgAgADYAIABBAGQAZAByAGUAcwBzAGkA bgBnAA0AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEEAcgBjAGgAaQB0AGUAYwB0AHUAcgBl ACIALAAgAFIARgBDACAANAAyADkAMQAsACAARgBlAGIAcgB1AGEAcgB5ACAAMgAwADAANgAuAA0A DQAgACAAIABbAFIARgBDADQAMwAwADEAXQAgACAASwBlAG4AdAAsACAAUwAuACAAYQBuAGQAIABL AC4AIABTAGUAbwAsACAAIgBTAGUAYwB1AHIAaQB0AHkAIABBAHIAYwBoAGkAdABlAGMAdAB1AHIA ZQAgAGYAbwByACAAdABoAGUADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASQBuAHQAZQBy AG4AZQB0ACAAUAByAG8AdABvAGMAbwBsACIALAAgAFIARgBDACAANAAzADAAMQAsACAARABlAGMA ZQBtAGIAZQByACAAMgAwADAANQAuAA0ADQAgACAAIABbAFIARgBDADQANgAwADEAXQAgACAARgBl AG4AbgBlAHIALAAgAEIALgAsACAASABhAG4AZABsAGUAeQAsACAATQAuACwAIABIAG8AbABiAHIA bwBvAGsALAAgAEgALgAsACAAYQBuAGQAIABJAC4AIABLAG8AdQB2AGUAbABhAHMALAANACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAiAFAAcgBvAHQAbwBjAG8AbAAgAEkAbgBkAGUAcABlAG4A ZABlAG4AdAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAALQAgAFMAcABhAHIAcwBlACAATQBvAGQAZQAg ACgAUABJAE0ALQBTAE0AKQA6AA0AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFAAcgBvAHQA bwBjAG8AbAAgAFMAcABlAGMAaQBmAGkAYwBhAHQAaQBvAG4AIAAoAFIAZQB2AGkAcwBlAGQAKQAi ACwAIABSAEYAQwAgADQANgAwADEALAAgAEEAdQBnAHUAcwB0ACAAMgAwADAANgAuAA0ADQAgACAA IABbAFIARgBDADQANwA2ADAAXQAgACAAQgBhAHQAZQBzACwAIABUAC4ALAAgAEMAaABhAG4AZABy AGEALAAgAFIALgAsACAASwBhAHQAegAsACAARAAuACwAIABhAG4AZAAgAFkALgAgAFIAZQBrAGgA dABlAHIALAANACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAiAE0AdQBsAHQAaQBwAHIAbwB0 AG8AYwBvAGwAIABFAHgAdABlAG4AcwBpAG8AbgBzACAAZgBvAHIAIABCAEcAUAAtADQAIgAsACAA UgBGAEMAIAA0ADcANgAwACwADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASgBhAG4AdQBh AHIAeQAgADIAMAAwADcALgANAA0AIAAgACAAWwBSAEYAQwA0ADgANgAxAF0AIAAgAE4AYQByAHQA ZQBuACwAIABUAC4ALAAgAE4AbwByAGQAbQBhAHIAawAsACAARQAuACwAIABTAGkAbQBwAHMAbwBu ACwAIABXAC4ALAAgAGEAbgBkACAASAAuACAAUwBvAGwAaQBtAGEAbgAsAA0AIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACIATgBlAGkAZwBoAGIAbwByACAARABpAHMAYwBvAHYAZQByAHkAIABm AG8AcgAgAEkAUAAgAHYAZQByAHMAaQBvAG4AIAA2ACAAKABJAFAAdgA2ACkAIgAsACAAUgBGAEMA IAA0ADgANgAxACwADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAUwBlAHAAdABlAG0AYgBl AHIAIAAyADAAMAA3AC4ADQANACAAIAAgAFsAUgBGAEMANQAxADAAMQBdACAAIABDAGwAYQBpAHMA ZQAsACAAQgAuACwAIAAiAFMAcABlAGMAaQBmAGkAYwBhAHQAaQBvAG4AIABvAGYAIAB0AGgAZQAg AEkAUAAgAEYAbABvAHcAIABJAG4AZgBvAHIAbQBhAHQAaQBvAG4ADQAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAARQB4AHAAbwByAHQAIAAoAEkAUABGAEkAWAApACAAUAByAG8AdABvAGMAbwBs ACAAZgBvAHIAIAB0AGgAZQAgAEUAeABjAGgAYQBuAGcAZQAgAG8AZgAgAEkAUAAgAFQAcgBhAGYA ZgBpAGMADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAARgBsAG8AdwAgAEkAbgBmAG8AcgBt AGEAdABpAG8AbgAiACwAIABSAEYAQwAgADUAMQAwADEALAAgAEoAYQBuAHUAYQByAHkAIAAyADAA MAA4AC4ADQANAA0ADQANAEcAYQBnAGwAaQBhAG4AbwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAARQB4AHAAaQByAGUAcwAgAE0AYQByAGMAaAAgADEAMgAsACAAMgAwADEAMAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAWwBQAGEAZwBlACAAOQBdAA0ADQANAEkAbgB0 AGUAcgBuAGUAdAAtAEQAcgBhAGYAdAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEkA UAB2ADYAIABpAG4AIABJAFgAUABzACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAUwBl AHAAdABlAG0AYgBlAHIAIAAyADAAMAA5AA0ADQANADEAMgAuADIALgAgACAASQBuAGYAbwByAG0A YQB0AGkAdgBlACAAUgBlAGYAZQByAGUAbgBjAGUAcwANAA0AIAAgACAAWwBSAEkAUgBfAEkAWABQ AF8AUABPAEwASQBDAEkARQBTAF0ADQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAATgB1AG0A YgBlAHIAcwAgAFMAdQBwAHAAbwByAHQAIABPAHIAZwBhAG4AaQB6AGEAdABpAG8AbgAgACgATgBS AE8AKQAuACwAIAAiAFIASQBSAHMAIABBAGwAbABvAGMAYQB0AGkAbwBuAHMADQAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAUABvAGwAaQBjAGkAZQBzACAAZgBvAHIAIABJAFgAUAAuACAATgBS AE8AIABDAG8AbQBwAGEAcgBpAHMAbwBuACAAbQBhAHQAcgBpAHgAIgAsACAAMgAwADAAOAAsAA0A IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgADwAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG4AcgBv AC4AbgBlAHQALwBkAG8AYwB1AG0AZQBuAHQAcwAvAGMAbwBtAHAALQBwAG8AbAAuAGgAdABtAGwA IwAzAC0ANAAtADIAPgAuAA0ADQANAEEAdQB0AGgAbwByACcAcwAgAEEAZABkAHIAZQBzAHMADQAN ACAAIAAgAFIAbwBxAHUAZQAgAEcAYQBnAGwAaQBhAG4AbwANACAAIAAgAEwAQQBDAE4ASQBDAA0A IAAgACAAUgBhAG0AYgBsAGEAIABSAGUAcAAgAE0AZQB4AGkAYwBvACAANgAxADIANQANACAAIAAg AE0AbwBuAHQAZQB2AGkAZABlAG8ALAAgACAAIAAxADEANAAwADAADQAgACAAIABVAFkADQANACAA IAAgAFAAaABvAG4AZQA6ACAAKwA1ADkAOAAgADIAIAA0ADAAMAA1ADYAMwAzAA0AIAAgACAARQBt AGEAaQBsADoAIAByAG8AcQB1AGUAQABsAGEAYwBuAGkAYwAuAG4AZQB0AA0ADQANAA0ADQANAA0A DQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ADQANAA0ARwBh AGcAbABpAGEAbgBvACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABFAHgAcABpAHIA ZQBzACAATQBhAHIAYwBoACAAMQAyACwAIAAyADAAMQAwACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAWwBQAGEAZwBlACAAMQAwAF0ADQANAA0ADQAFADIAIABwAHIAbwBiAGwAZQBtAHMA IAB3AGkAdABoACAAdABoAGkAcwAgAHYANAAgAGEAZABkAHIAZQBzAHMAOgANAA0AMQAtACAAdQBz AGkAbgBnACAAdABoAGUAIAAzACAAbABhAHMAdAAgAGQAZQBjAGkAbQBhAGwAcwAgAG8AZgAgAHQA aABpAHMAIAAvADIAMwAgAGMAYQBuACAAbABlAGEAZAAgAHQAbwAgAGMAbwBuAGYAbABpAGMAdAAg AGEAcwAgAHQAaABlACAAcABhAHIAdABpAGMAaQBwAGEAbgB0ACAAdwBpAHQAaAAgAEkAcAB2ADQA IAAyADQAMAAuADAALgAyADAALgAxADMAMgAvADIAMwAgAGEAbgBkACAAdABoAGUAIABvAG4AZQAg AHcAaQB0AGgAIAAyADQAMAAuADAALgAyADEALgAxADMAMgAvADIAMwAgAHcAaQBsAGwAIABoAGEA dgBlACAAdABoAGUAIABzAGEAbQBlACAASQBwAHYANgAgAGEAZABkAHIAZQBzAHMAIAAyADAAMAAx ADoAZABiADgAOgA6ADEAMwAyAC8ANgA0AA0ADQAyAC0AIAB1AHMAaQBuAGcAIABzAHAAYQBjAGUA IABmAHIAbwBtACAAMgA0ADAAIABhAHMAIABlAHgAYQBtAHAAbABlAC4ADQANAEkAIABzAHUAZwBn AGUAcwB0ACAAOgANADEAOQAyAC4AMAAuADIALgAxADMAMgAvADIANAANAAUAVwBoAGEAdAAgAGQA bwAgAHkAbwB1ACAAdwBhAG4AdAAgAHQAbwAgAHMAYQB5ACAAaABlAHIAZQAgAD8ADQANAFQAaABh AHQAIABJAFgAUAAgAEwAQQBOACAAcAByAGUAZgBpAHgAZQBzACAAYQByAGUAIABmAHIAbwBtACAA awBuAG8AdwBuACAAYgBsAG8AYwBrAHMAIAA/AA0ADQANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAIAADuGAAA8BgAAHw8AACKPAAAmjwAAE5RAABQUQAAlFQAAJZUAABM XAAATlwAAFxpAABeaQAAkmoAAJRqAACWagAAXmsAAGBrAABmawAAaGsAAGprAACwhAAAvIQAANCE AADqhAAAvKwAAL6sAAAArQAAAq0AAHyuAAB+rgAAxq4AAMiuAADgrgAA/q4AAACvAAA+rwAAAPgA 8eoA4wDaANEAygDDygC8ALWuAKegmQCXYQBhAGEAYWGXYQAAAAAAakIqAFJIZAA1CAA+KgBTKgA3 CAA2CAA4CAA5CABIKgBFSAAAQ0oUAEtIAABAiAAAbUgJAHNICQBuSP8AX0j/AHRI/wBQSgQAXkoF AGFKGABcCABdCAA0KgBYCABUCABPSgYAUUoGAENKFAAAA1UIAQ0ACAFjSAEAZGj2LdomDQEIAQRI AQAFaPct2iYNAQgBBEgBAAVo9i3aJg0ACAFjSAEAZGiSLdomDQEIAQRIAQAFaOkt2iYNAAgBY0gB AGRo6S3aJg0BCAEESAEABWiRLdomDQAIAWNIAQBkaJEt2iYQVQgBAQgBBEgBAAVoGjDaRgAQVQgB AQgBBEgBAAVo4y3aJgANAQgBBEgBAAVo0C3aJg0ACAFjSAEAZGjLLdomDQEIAQRIAQAFaMst2iYN AQgBBEgBAAVojS3aJgAlPq8AAECvAACcrwAAnq8AAADKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABqQioAUkhkADUIAD4qAFMqADcIADYIADgIADkIAEgqAEVIAABD ShQAS0gAAECIAABtSAkAc0gJAG5I/wBfSP8AdEj/AFBKBABeSgUAYUoYAFwIAF0IADQqAFgIAFQI AE9KBgBRSgYAQ0oUAAMACAAAAggAAAQIAAAGCAAAmAgAACoJAAC8CQAA7AkAAO4JAADwCQAAbAoA ANQKAADWCgAA/goAAAALAACSCwAA2gsAANwLAABmDAAA7gwAAHQNAACKDQAAjA0AAB4OAACuDgAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAA AAAA6wAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOMA AAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADbAAAAAAAA AAAAAAAA2QAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAGK4OAAAyDwAArg8AALAPAAAkEAAAghAAAIQQAAAMEQAAVBEAAFYRAADCEQAA xBEAAOYRAADoEQAAbhIAAMQSAADGEgAASBMAAMwTAABcFAAA7hQAAFQVAABWFQAAaBUAAGoVAAD9 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAA AAAAAAAAAAAAAOEAAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANsAAAAAAAAA AAAAAADZAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAAAEUAAAYahUAAO4VAAB+FgAADhcAABAXAAASFwAAFBcAAKYXAACoFwAAqhcAADwYAAA+ GAAAQBgAANAYAABYGQAA5hkAAP4ZAAAAGgAAAhoAACYaAAAoGgAAuhoAAEwbAADeGwAA/QAAAAAA AAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA6gAA AAAAAAAAAAAAAOgAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOIAAAAAAAAA AAAAAADgAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA 2AAAAAAAAAAAAAAAANYAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAMUAAckAQABFAAAARQAAAEUAAABFAAAARQAAAEU AAABFAAAARQAABfeGwAAcBwAAAIdAACUHQAAJh4AALgeAABKHwAA3B8AAG4gAAAAIQAAkiEAACQi AAC2IgAAuCIAALoiAAC8IgAAviIAAMAiAADCIgAAxCIAAMYiAADIIgAAyiIAAMwiAADOIgAA/QAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA 6wAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOMAAAAA AAAAAAAAAADhAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADbAAAAAAAAAAAA AAAA2QAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEU AAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAAAGM4iAADQIgAA0iIAANQiAADWIgAA2CIAANoiAADcIgAA3iIAAOAiAADiIgAA5CIA AOYiAADoIgAA6iIAAOwiAADuIgAAgCMAAIIjAACEIwAAFiQAABgkAAAaJAAAPCQAAP0AAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADpAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAA AAAA4QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANgA AAAAAAAAAAAAAADWAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADQAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAMUAAckAQABFAAAARQA AAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAAXPCQAAD4kAADQJAAAYCUAAOQlAABeJgAA7CYAAHgnAAAKKAAAbCgAAG4oAABwKAAA sCgAALIoAABCKQAAzCkAAE4qAADcKgAAYCsAAKIrAACkKwAAMCwAAEIsAABELAAA0CwAAP0AAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAA AAAAAAAA4QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAA ANkAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAAzwAAAAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAABjQLAAAVC0AANgtAABWLgAAWC4AANwuAABiLwAA7i8AAHowAAAIMQAAljEAAB4yAABo MgAAajIAAPYyAACGMwAACDQAAIY0AAAWNQAApDUAACY2AACyNgAANjcAAMg3AADKNwAA/QAAAAAA AAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6wAA AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOMAAAAAAAAA AAAAAADhAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA 2QAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADPAAAAAAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEU AAABFAAAGMo3AADMNwAAzjcAAGA4AABiOAAAZDgAAPY4AAD4OAAA+jgAAA45AAAQOQAAnjkAACQ6 AACaOgAAJjsAALY7AAC4OwAAujsAAOI7AADkOwAAdjwAAAo9AACYPQAAKj4AAP0AAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOoAAAAAAAAA AAAAAADoAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA 4AAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANgAAAAA AAAAAAAAAADWAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADQAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAxQAByQBAAEUAAABFAAAARQA AAEUAAAXKj4AALw+AABIPwAA2j8AANw/AABaQAAA6kAAAHxBAAAMQgAAkEIAAApDAACWQwAAGEQA AJZEAADARAAAwkQAAFJFAADiRQAAbEYAAMBGAADCRgAATkcAANhHAABoSAAAykgAAP0AAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADpAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAA AAAA4QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkA AAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAAzwAAAAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAABjKSAAAzEgAABxJAAAeSQAASEkAAEpJAADKSQAAPkoAAEBKAADISgAAykoAAMxKAADOSgAA YEsAAGJLAABkSwAA9ksAAPhLAAD6SwAAikwAABRNAABsTQAAbk0AAP5NAAD9AAAAAAAAAAAAAAAA +wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA6QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOAA AAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADYAAAAAAAA AAAAAAAA1gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAxQA ByQBAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAF/5NAACMTgAA0E4AANJOAAAiTwAAJE8AAHZPAAB4TwAA+E8AAGhQAABqUAAA+lAAAIJRAAAS UgAAlFIAACZTAAC2UwAA8lMAAPRTAABEVAAARlQAAJhUAACaVAAA7FQAAO5UAAD9AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAA AAAAAAAA6QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAA AOEAAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADZAAAA AAAAAAAAAAAA1wAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAAM8AAAAAAAAAAAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEU AAAY7lQAAG5VAACWVQAAmFUAABxWAACqVgAAPFcAAMxXAABaWAAA5lgAAHZZAAAEWgAAkFoAAB5b AACuWwAAMlwAAL5cAADSXAAA1FwAANZcAADYXAAA2lwAANxcAABuXQAAcF0AAP0AAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAAAAAA AAAAAADpAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA 4QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAA AAAAAAAAAADXAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAAzwAAAAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEU AAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA ABhwXQAAcl0AAAReAAAGXgAACF4AAC5eAAAwXgAAvl4AAEhfAAB0XwAAdl8AAAZgAACMYAAAEmEA AKJhAAA0YgAAvmIAAExjAADGYwAAUmQAANBkAABiZQAA5GUAAG5mAAD8AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADwAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA 6AAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOAAAAAA AAAAAAAAAADeAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADYAAAAAAAAAAAA AAAA1gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAADFAAHJAEA F25mAAD8ZgAAiGcAABRoAACgaAAAMGkAAL5pAABOagAAzmoAANBqAABUawAA5GsAAHJsAAACbQAA hm0AABhuAACqbgAALm8AALxvAADUbwAA1m8AAGZwAAD0cAAAhnEAAAhyAAD9AAAAAAAAAAAAAAAA +wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA6QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOEA AAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADZAAAAAAAA AAAAAAAA1wAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA AM8AAAAAAAAAAAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAY CHIAAJhyAAAmcwAArnMAADZ0AADEdAAAxnQAAMh0AADKdAAAXHUAAF51AABgdQAA8nUAAPR1AAD2 dQAAhnYAABh3AACodwAALngAALZ4AABCeQAAyHkAAFp6AACwegAA/QAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOgA AAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADgAAAAAAAA AAAAAAAA3gAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAA ANYAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAADFAAHJAEAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAABew egAAsnoAALR6AADUegAA1noAAF57AADwewAAfHwAALB8AACyfAAAtHwAANZ8AADYfAAAXn0AAOp9 AABufgAA9n4AAIB/AADkfwAA5n8AAGqAAAD4gAAAeoEAAAqCAACcggAA/QAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADzAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAA AOkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADhAAAA AAAAAAAAAAAA3wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2QAAAAAAAAAA AAAAANcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADP AAAAAAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEU AAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAGJyC AAAkgwAAnoMAACqEAACghAAAooQAAESFAADOhQAAKoYAACyGAAAuhgAAcoYAAHSGAAD+hgAAhIcA AA6IAAAQiAAAEogAABSIAACmiAAAqIgAAKqIAAA8iQAAPokAAP0AAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAA AAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4QAAAAAAAAAA AAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADX AAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEUAAABFAADFAAHJAEAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAXPokA AECJAADEiQAARooAAISKAACGigAAFIsAAJyLAAAkjAAArowAAACNAAACjQAABI0AADiNAAA6jQAA yo0AAECOAABCjgAARI4AAHSOAAB2jgAAyo4AAMyOAADOjgAACI8AAP0AAAAAAAAAAAAAAAD7AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADp AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4QAAAAAA AAAAAAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAAAAAAAAAA AADXAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAzwAA AAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAABgIjwAA Co8AAJaPAAAokAAAsJAAADSRAAA2kQAAOJEAAGSRAABmkQAA8pEAAISSAAC+kgAAwJIAAMKSAADi kgAA5JIAAByTAAAekwAAqJMAADaUAADClAAADpUAABCVAACUlQAA/QAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOkA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADhAAAAAAAA AAAAAAAA3wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAA ANcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADPAAAA AAAAAAAAAAAAAAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAGJSVAAAW lgAAGJYAABqWAAAclgAArpYAALCWAACylgAARJcAAEaXAABIlwAA2pcAAEqYAABMmAAA2pgAAFaZ AABYmQAA6JkAAEyaAABOmgAA2JoAAF6bAACSmwAAlJsAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPAA AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADoAAAAAAAA AAAAAAAA5gAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAA AN4AAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAADWAAAA AAAAAAAAAAAA1AAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAMUAAckAQABFAAAARQAAAEUAAABFAAAARQAAAEUAAAXlJsAABqc AACSnAAAypwAAMycAABcnQAA4p0AAOSdAABqngAA6p4AAOyeAAB2nwAA2p8AANyfAABgoAAAzKAA AM6gAABSoQAAyKEAAMqhAABWogAA4qIAAHKjAAB0owAA9KMAAP0AAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAA AAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4QAAAAAAAAAA AAAAAN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADX AAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAzwAAAAAA AAAAAAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQA AAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAABj0owAAcKQA AKikAACqpAAANKUAAMClAAD8pQAA/qUAAIamAAAQpwAAgqcAAISnAACGpwAAiKcAAIqnAAAcqAAA HqgAACCoAACyqAAAtKgAALaoAADyqAAA9KgAACCpAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6QAAAAAAAAAA AAAAAOcAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADf AAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA1gAAAAAA AAAAAAAAANQAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAMUAAckAQABFAAAARQAAAEUAAABFAAA ARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAFyCpAACqqQAA JqoAAKqqAACsqgAArqoAANCqAADSqgAA9qoAAAqrAAA+qwAAbKsAAHirAAB6qwAArKsAAOKrAADk qwAA5qsAAOirAADqqwAA7KsAAO6rAADwqwAA8qsAAPSrAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAOcAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOEAAAAAAAAAAAAA AADfAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA1wAA AAAAAAAAAAAAANUAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAM8AAAAAAAAA AAAAAAAAAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAB FAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAAY9KsAAParAAD4 qwAA+qsAAPyrAAD+qwAAAKwAAAKsAAAErAAABqwAAAisAAAKrAAADKwAAA6sAAAQrAAAEqwAABSs AAAWrAAAGKwAABqsAAAcrAAAHqwAACCsAAAirAAAJKwAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAAAAAA AAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAA AN8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADXAAAA AAAAAAAAAAAA1QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAzwAAAAAAAAAA AAAAAAAAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEU AAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAAAEUAAABFAAAARQAABgkrAAAtqwAALis AAC6rAAAvKwAAACtAAACrQAAfK4AAH6uAADGrgAAyK4AAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAAAK4A AAAAAAAAAAAAAACWAAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFwAAQSQANSQAMyQBNyQBXoQAAF2EAABghAAAE6QAABSk AAASZAAAAAADJABhJAAAFwAAQSQANSQAMyQBNyQBXoQAAF2EAABghAAAE6QAABSkAAASZAAAAAAD JABhJAAAFwAAQSQANSQAMyQBNyQBXoQAAF2EAABghAAAE6QAABSkAAASZAAAAAADJABhJAAAFwAA QSQANSQAMyQBNyQBXoQAAF2EAABghAAAE6QAABSkAAASZAAAAAADJABhJAAAFwAAQSQANSQAMyQB NyQBXoQAAF2EAABghAAAE6QAABSkAAASZAAAAAADJABhJAAAFwAAQSQANSQAMyQBNyQBXoQAAF2E AABghAAAE6QAABSkAAASZAAAAAADJABhJAAAARQAAxQAByQBAAEUAAABFAAACsiuAADgrgAA/q4A AD6vAABArwAAnK8AAJ6vAACgrwAA5wAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAAC3AAAAAAAAAAAA AAAAnwAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAgwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQAAAEAAAAXAABBJAA1JAAzJAE3JAFehAAAXYQAAGCE AAATpAAAFKQAABJkAAAAAAMkAGEkAAAXAABBJAA1JAAzJAE3JAFehAAAXYQAAGCEAAATpAAAFKQA ABJkAAAAAAMkAGEkAAAXAABBJAA1JAAzJAE3JAFehAAAXYQAAGCEAAATpAAAFKQAABJkAAAAAAMk AGEkAAAXAABBJAA1JAAzJAE3JAFehAAAXYQAAGCEAAATpAAAFKQAABJkAAAAAAMkAGEkAAAXAABB JAA1JAAzJAE3JAFehAAAXYQAAGCEAAATpAAAFKQAABJkAAAAAAMkAGEkAAAHIgAfsIEuILDFQSGw bgQisG4EI5BuBCSQbgQzUAAAKDIADjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBu AHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAP// ////////AQAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAABACwAAAAAA AAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASAAIAAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGoAAAAAAAAAAQBPAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgD/////AwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAFAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAFCQAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIABQAA AAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAKwAAAAAAAAA VwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAJAAAAJOgAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACsAAAB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAA --Apple-Mail-20--542968458 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Regards,

Roque. 
=




Begin = forwarded message:

From: = IETF I-D Submission Tool <idsubmission@ietf.org>=
Date: September 8, 2009 11:00:14 PM = GMT-03:00
Subject: = New Version Notification for = draft-ietf-v6ops-v6inixp-02 


A new = version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been successfuly = submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-ietf-v6ops-v6inixp
Revision: 02
Title: IPv6 = Deployment in Internet Exchange Points (IXPs)
Creation_date: = 2009-09-08
WG ID: v6ops
Number_of_pages: = 10

Abstract:
This document provides a guide for IPv6 = deployment in Internet
Exchange Points (IXP).  It includes = information regarding the switch
fabric configuration, the addressing = plan and general organizational
tasks to be performed.  IXPs are = mainly a layer 2 infrastructure and
in many case the best = recommendations state that the IPv6 data,
control and management = plane should not be handled differently than
in = IPv4.



The IETF = Secretariat.


-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =


= --Apple-Mail-20--542968458-- --Apple-Mail-19--542968459-- From owner-v6ops@ops.ietf.org Tue Oct 6 02:17:36 2009 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 1FC8528C153 for ; Tue, 6 Oct 2009 02:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.368 X-Spam-Level: * X-Spam-Status: No, score=1.368 tagged_above=-999 required=5 tests=[AWL=-2.993, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyd4cmFNPgux for ; Tue, 6 Oct 2009 02:17:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BA713A6774 for ; Tue, 6 Oct 2009 02:17:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv67N-0002cg-ME for v6ops-data0@psg.com; Tue, 06 Oct 2009 09:14:01 +0000 Received: from [212.27.42.6] (helo=smtp6-g21.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv67B-0002aQ-Us for v6ops@ops.ietf.org; Tue, 06 Oct 2009 09:13:59 +0000 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id AB9BAE08127; Tue, 6 Oct 2009 11:13:44 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id EE035E08189; Tue, 6 Oct 2009 11:13:40 +0200 (CEST) In-Reply-To: <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.com> References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> <339077.93936.q!m@web45512.mail.sp1.yahoo.com> <12F 4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> <866685.67299.qm@web45511.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1D70211C-A03B-441E-977C-55B858AD753E@free.fr> Cc: Gabi Nakibly , v6ops Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Routing loop attacks using IPv6 tunnels Date: Tue, 6 Oct 2009 11:13:29 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.753.1) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Fred, Gabi, I didn't follow all details of this discussion, but it seems to me =20 that the much simpler checks below are sufficient to prevent routing-=20 loop attacks in ISATAP routers. ISATAP router checks: - In an IPv6 packet received natively, the SOURCE address MUST NOT =20 have the IPv4 address of the router itself embedded in it (neither in =20= ISATAP nor in 6to4). - In an IPv6 packets received encapsulated in an IPv4 packet, the =20 DESTINATION address MUST NOT have the IPv4 address of the router =20 itself embedded in it (neither in ISATAP nor in 6to4). Did I miss anything? Regards, RD Le 6 oct. 09 =E0 01:50, Templin, Fred L a =E9crit : > Gabi, > >> -----Original Message----- >> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] >> Sent: Monday, October 05, 2009 2:24 PM >> To: Templin, Fred L >> Cc: v6ops >> Subject: Re: Routing loop attacks using IPv6 tunnels >> >> On first thought, setting up a synchronization mechanism of the =20 >> neighbor caches at the routers does >> not sound, IMHO, like the best solution. It will probably add =20 >> complexity and interdependence to the >> routers' functionality. >> Maybe a good trade-off would be to first require a host to send an =20= >> initial RS to every router in the >> PRL. Then after the host learns the advertised prefix of each =20 >> router the host should continue sending >> RSs (or stop sending) to all routers advertising the same prefix. > > I understand what you're saying, but here's the temptation. > Lets say that ISATAP routers A and B both advertise prefix > P::/64, then the ISATAP site partitions and the only way > A and B can still talk to each other is via the provider > network. The temptation part is that if A and B talk to > each other over the provider network then they can keep > track of the ISATAP hosts in each partition that configure > an address from P::/64 and seemingly can "heal" the > partition by forwarding misdirected packets to each other > across the provider network. But then, we are guilty of > "conspiracy to create a multilink subnet" (see RFC4903 > for multi-link subnet issues). > > This suggests that, if multiple ISATAP routers are to > advertise a shared prefix P::/64, then there either needs > to be strong assurance that the site won't partition. If > that condition cannot be met, then each ISATAP router must > advertise a distinct prefix. Do you see any other way? > > Fred > fred.l.templin@boeing.com > >> ----- Original Message ---- >>> From: "Templin, Fred L" >>> To: Gabi Nakibly >>> Cc: v6ops >>> Sent: Mon, October 5, 2009 10:41:16 PM >>> Subject: RE: Routing loop attacks using IPv6 tunnels >>> >>> Gabi, >>> >>>> -----Original Message----- >>>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] >>>> Sent: Monday, October 05, 2009 1:32 PM >>>> To: Templin, Fred L >>>> Cc: v6ops >>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>> >>>> Fred, >>>> With regrad to your comment below: if indeed an ISATAP router =20 >>>> will not >>> forward packets to an >>>> ISATAP host it has not recently received RS from, then I think =20 >>>> that the ISATAP >>> specification >>>> should at least require an ISATAP host (using a SHOULD) to =20 >>>> regularly send RSs >>> to _all_ routers in the >>>> PRL, or else ISATAP connectivity may be broken. >>> >>> Yes, "ping them all" is certainly one way to ensure a nbr >>> cache entry at each PRL router. I was also starting to >>> think that another solution would be for PRL routers that >>> advertise a shared IP prefx (e.g., 2001:DB8::/64) to >>> somehow synchronize their neighbor caches. For that >>> matter, it might be best to do both because you can >>> never tell which subset of the PRLs is the correct >>> subset to ping. >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>>> Gabi >>>> >>>> ----- Original Message ---- >>>>> From: "Templin, Fred L" >>>>> To: Gabi Nakibly >>>>> Cc: v6ops >>>>> Sent: Thu, October 1, 2009 6:49:31 PM >>>>> Subject: RE: Routing loop attacks using IPv6 tunnels >>>>> >>>>> Hi Gabi, >>>>> >>>>>> -----Original Message----- >>>>>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] >>>>>> Sent: Thursday, October 01, 2009 6:53 AM >>>>>> To: Templin, Fred L >>>>>> Cc: v6ops >>>>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>>>> >>>>>> Removed the 6man and secdir mailing lists from the Cc. >>>>>> >>>>>> Fred, see comments below. >>>>>> >>>>>> ----- Original Message ---- >>>>>>> From: "Templin, Fred L" >>>>>>> To: Gabi Nakibly ; Christian Huitema >>>>> ; v6ops >>>>>> >>>>>>> Cc: "ipv6@ietf.org" ; "secdir@ietf.org" >>>>>>> Sent: Tuesday, September 29, 2009 6:00:55 PM >>>>>>> Subject: RE: Routing loop attacks using IPv6 tunnels >>>>>>> >>>>>>> Gabi, >>>>>>> >>>>>>> Welcome back from your vacation. I trimmed quite a bit from >>>>>>> the bottom of this message to eliminate the clutter, but see >>>>>>> below for responses to your current comments: >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] >>>>>>>> Sent: Tuesday, September 29, 2009 3:22 AM >>>>>>>> To: Templin, Fred L; Christian Huitema; v6ops >>>>>>>> Cc: ipv6@ietf.org; secdir@ietf.org >>>>>>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>>>>>> >>>>>>>> Hi Fred, >>>>>>>> Back from vacation. See Comments inlines. >>>>>>>> >>>>>>>> Gabi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ---- >>>>>>>>> From: "Templin, Fred L" >>>>>>>>> To: Gabi Nakibly ; Christian Huitema >>>>>>> ; v6ops >>>>>>>> >>>>>>>>> Cc: ipv6@ietf.org; secdir@ietf.org >>>>>>>>> Sent: Friday, September 11, 2009 11:13:44 PM >>>>>>>>> Subject: RE: Routing loop attacks using IPv6 tunnels >>>>>>>>> >>>>>>>>> Hi Gabi, >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com] >>>>>>>>>> Sent: Friday, September 11, 2009 12:59 PM >>>>>>>>>> To: Templin, Fred L; Christian Huitema; v6ops >>>>>>>>>> Cc: ipv6@ietf.org; secdir@ietf.org >>>>>>>>>> Subject: Re: Routing loop attacks using IPv6 tunnels >>>>>>>>>> >>>>>>>>>> Hi Fred, >>>>>>>>>> See below. >>>>>>>>>> >>>>>>>>>> Gabi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ---- >>>>>>>>>>> From: "Templin, Fred L" >>>>>>>>>>> To: Gabi Nakibly ; Christian Huitema >>>>>>>>> ; v6ops >>>>>>>>>> >>>>>>>>>>> Cc: ipv6@ietf.org; secdir@ietf.org >>>>>>>>>>> Sent: Tuesday, September 8, 2009 8:37:03 PM >>>>>>>>>>> Subject: RE: Routing loop attacks using IPv6 tunnels >>>>>>>>>>> >>>>>>>>>>> Gabi and Christian, >>>>>>>>>>> >>>>>>>>>>> Focusing only on attack #3 (i.e., leaving out attack #1 >>>>>>>>>>> and #2 6to4 interactions for the moment), please check >>>>>>>>>>> the following summary of proposed mitigations: >>>>>>>>>>> >>>>>>>>>>> 1) For ISATAP/VET routers that have assurance that their >>>>>>>>>>> neighbor cache is coherent, the router can make a simple >>>>>>>>>>> check in the neighbor cache to determine whether to >>>>>>>>>>> forward or drop the packet. In pseudo-code: >>>>>>>>>>> >>>>>>>>>>> isatap_rcv() { >>>>>>>>>>> ... >>>>>>>>>>> if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*")) >>>>>>>>>>> drop_pkt(); >>>>>>>>>>> ... >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> isatap_xmt() { >>>>>>>>>>> ... >>>>>>>>>>> if ((v6dst is not a neighbor) && (v6src !=3D "fe80::*")) >>>>>>>>>>> drop_pkt(); >>>>>>>>>>> ... >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> (Here, the link-local exception is necessary to bootstrap >>>>>>>>>>> neighbor discovery on the ISATAP link.) >>>>>>>>>>> >>>>>>>>>>> Does anyone see a problem with this? >>>>>>>>>>> >>>>>>>>>> Looks fine. >>>>>>>>> >>>>>>>>> OK. >>>>>>>>> >>>>>>>> >>>>>>>> On second thought, a couple of comments: >>>>>>>> 1) According to RFC 5214 Section 8.3.4: >>>>>>>> " ISATAP nodes MAY schedule periodic Router =20 >>>>>>>> Solicitation events >>>>>>>> for certain PRL(i)s by setting the corresponding TIMER=20= >>>>>>>> (i)." >>>>>>>> As I understand, this means that there is a possibility for =20 >>>>>>>> a host not >>>>> to send >>>>>>> RSs to all routers in >>>>>>>> the PRL. However, any router in the PRL may forward packets =20 >>>>>>>> into the >>>>> ISATAP >>>>>>> link. The isatap_xmt() >>>>>>>> check will prevent forwarding packets by routers which the >>> destination has >>>>> not >>>>>>> previously sent RS to. >>>>>>>> If I am correct then this check may break ISATAP connectivity. >>>>>>> >>>>>>> I don't think this is a problem. If a host has not sent an RS to >>>>>>> a PRL router, then it should not have configured a default route >>>>>>> nor any prefix information specific to that router. Therefore, >>>>>>> the only packets the host and router should expect to exchange >>>>>>> in this state are link-local. As such, the router can discard >>>>>>> non-link-local packets if there is no neighbor cache entry. >>>>>>> >>>>>> >>>>>> I was thinking of a case of two routers in the PRL advertising =20= >>>>>> the same >>> prefix >>>>> for the ISATAP >>>>>> link. Either routers obviously may forward packets _into_ the =20 >>>>>> ISATAP link >>> to >>>>> any host. If a host will >>>>>> not send a RS to one of those routers then it will drop =20 >>>>>> packets destined >>> to >>>>> that host. >>>>> >>>>> I'm actually OK with that. If two routers A and B advertise >>>>> the same prefix P, and if B doesn't know about host H either >>>>> through receiving RSs or through talking to A, then B should >>>>> not forward packets to H. >>>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> >>>>>>>> 2) I remind you a comment you made in the past: for the =20 >>>>>>>> checks to >>> work the >>>>>>> time between two >>>>>>>> consequtive RSs from a host to a router should be no greater =20= >>>>>>>> than the >>> the >>>>>>> lifetime of an entry for >>>>>>>> that host in the router's neighbors cache. This is needed to =20= >>>>>>>> ensure >>>>> that the >>>>>>> entry in the neighbors >>>>>>>> cache will not be erased. This raises two questions: >>>>>>>> a) AFAIK there is no minimum lifetime for an entry in a =20 >>>>>>>> neighbors >>>>> cache >>>>>>> - it is an implementation >>>>>>>> detail. If this is true how can we enforce the above =20 >>>>>>>> constraint? >>>>>>> >>>>>>> Correct that there is no minimum lifetime for neighbor cache >>>>>>> entries specified by RFC4861. However, an ISATAP router that >>>>>>> uses the neighbor cache checking procedures I have described >>>>>>> can use its own discipline for managing its neighbor cache. >>>>>>> Exactly such a discipline is now specified in Section 5.4.1 >>>>>>> of 'draft-templin-intarea-vet'. Please be aware that ISATAP >>>>>>> and VET are simply "IPv6-over-(foo)" specifications, and >>>>>>> RFC4861 permits that operations of the neighbor discovery >>>>>>> protocol that are specific to (foo) links may be specified >>>>>>> in such documents. >>>>>>> >>>>>> >>>>>> OK. >>>>>> >>>>>>>> b) A router's neighbors cache must now include at any =20 >>>>>>>> given moment >>> all >>>>> the >>>>>>> active ISATAP nodes in >>>>>>>> the ISATAP link. Is this a reasonable demand? >>>>>>> >>>>>>> Memory should be cheap enough, and ISATAP links within private >>>>>>> addressing realms should be small enough, that I do not see this >>>>>>> as an unreasonable demand. >>>>>>> >>>>>> >>>>>> OK. >>>>>> >>>>>>>>>>> 2) For ISATAP/VET routers that use public IPv4 addresses >>>>>>>>>>> and that do not have assurance that their neighbor cache >>>>>>>>>>> is coherent, the router can check for the interface ID >>>>>>>>>>> "0200:5EFE:". In pseudo-code: >>>>>>>>>>> >>>>>>>>>>> isatap_rcv() { >>>>>>>>>>> ... >>>>>>>>>>> if (v6dst =3D=3D "foreign_prefix::0200:5efe:") >>>>>>>>>>> drop_pkt(); >>>>>>>>>>> ... >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> isatap_xmt() { >>>>>>>>>>> ... >>>>>>>>>>> if (v6src =3D=3D "foreign_prefix::0200:5efe:") >>>>>>>>>>> drop_pkt(); >>>>>>>>>>> ... >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Does anyone see a problem with this? >>>>>>>>>> >>>>>>>>>> Looks fine. >>>>>>>>> >>>>>>>>> OK, but since I sent this I began to wonder whether cases >>>>>>>>> 1) and 2) should be reversed (i.e., do the 0x00:5EFE check >>>>>>>>> first). I came to believe that it almost doesn't matter >>>>>>>>> from a performance standpoint, and perhaps should be left >>>>>>>>> up to the implementer. Do you have an opinion on this? >>>>>>>>> >>>>>>>>>>> 3) For ISATAP/VET routers that use private IPv4 addresses >>>>>>>>>>> and that do not have assurance that their neighbor cache >>>>>>>>>>> is coherent, the router can make the checks that Christian >>>>>>>>>>> has proposed. But, will we see any of these case 3) >>>>>>>>>>> situations in operational practice? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can not tell for sure. Why this case seems to you less =20 >>>>>>>>>> plausible >>>>> than >>>>>>> case >>>>>>>>> 2? >>>>>>>>> >>>>>>>>> Case 3) is the case in which source address spoofing within >>>>>>>>> a private IPv4 addressing range is possible. It seems to me >>>>>>>>> that it may correspond to either a poorly managed deployment, >>>>>>>>> or one in which there are multiple administrative authorities >>>>>>>>> with diverse policies and operational practices. >>>>>>>>> >>>>>>>> >>>>>>>> I agree. However, remember that the spoofed packet may also =20 >>>>>>>> originate >>> from >>>>>>> within the site, which is >>>>>>>> very hard to defend against. >>>>>>> >>>>>>> Spoofing is not so hard to defend against if Secure Neighbor >>>>>>> Discovery (SEND) is used to set up the neighbor relationships >>>>>>> and if every packet carries a nonce that can be used to detect >>>>>>> an off-path attack. >>>>>> >>>>>> I agree again. I was referring to the case where SEND is not =20 >>>>>> deployed. >>>>>> >>>>>>> That is only the case for VET and SEAL, >>>>>>> however, so if source address spoofing within the site is seen >>>>>>> as a problem then VET and SEAL should be used instead of ISATAP. >>>>>>> >>>>>>> Note that for the sake of consistency it might be helpful to >>>>>>> consider VET as simply "ISATAP version 2 (ISATAPv2)". >>>>>>> >>>>>>> Fred >>>>>>> fred.l.templin@boeing.com >>>>>>> >>>>>>>>> The checks that Christian proposed could be used for this >>>>>>>>> scenario if possible. Otherwise, the best solution IMHO >>>>>>>>> would be to allow only routers (and not hosts) on the >>>>>>>>> virtual links. This final model would be best addressed >>>>>>>>> by VET and SEAL rather than ISATAP. >>>>>>>>> >>>>>>>>> Thanks - Fred >>>>>>>>> fred.l.templin@boeing.com >>>>>> >>>>>> __________________________________________________ >>>>>> Do You Yahoo!? >>>>>> Tired of spam? Yahoo! Mail has the best spam protection around >>>>>> http://mail.yahoo.com >>>> >>>> >>>> >>>> >> >> >> >> > From owner-v6ops@ops.ietf.org Tue Oct 6 02:20:47 2009 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 F220928C10C for ; Tue, 6 Oct 2009 02:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[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 TFUGir3ecXGp for ; Tue, 6 Oct 2009 02:20:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DF3D3A6774 for ; Tue, 6 Oct 2009 02:20:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv6Ev-0003St-Le for v6ops-data0@psg.com; Tue, 06 Oct 2009 09:21:49 +0000 Received: from [210.171.225.78] (helo=mx20.jpix.ad.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv6El-0003RL-Vq for v6ops@ops.ietf.org; Tue, 06 Oct 2009 09:21:47 +0000 Received: from [10.10.31.135] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id B5EC6FC012; Tue, 6 Oct 2009 18:21:38 +0900 (JST) Date: Tue, 06 Oct 2009 18:21:38 +0900 From: MAWATARI Masataka To: roque@lacnic.net Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Cc: martin.pels@ams-ix.net, v6ops@ops.ietf.org In-Reply-To: <8A3A255A-3786-4608-907B-5C1AD6B10A7A@lacnic.net> References: <20091002180244.E48A.8FE1F57E@jpix.ad.jp> <8A3A255A-3786-4608-907B-5C1AD6B10A7A@lacnic.net> Message-Id: <20091006182138.A0D6.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Roque, Thank you very much. Please excuse the brevity. Just a few standardizing words. * On Mon, 5 Oct 2009 12:07:50 +0100 * Roque Gagliano wrote: > Dear Martin/ Masataka, > > I am proposing the following text for version 03. > > ---------------- > IPv6 prefixes for IXP LANs are typically publicly well known and > taken from dedicated IPv6 blocks for IXP assignments reserved for > this purpose by the different RIRs.The current practice that applies > to IPv4 about publishing IXP allocations to the DFZ (Default Free > Zone) should also apply to the IPv6 allocation. When considering > the > routing of the IXP LANs two options are identified: > > o IXPs may decide that LANs should not to be globally routed in ^^^^ IXP > order to limit the possible origins of a Distributed Denial of > Service (DDoS) attack to its particpant' AS boundries. In this > configuration participants may route these prefixes inside their > networks (e. g. using BGP no-export communities or routing the > IXP > LANs within the participants' IGP) to perform fault management. > Using this configuration, the monitoring of the IXP LANs from > outside of its participants' AS boundaries is not possible. > > o IXP may decide that LAN should be globally routed. In this case, ^^^ LANs > IXP LANs monitoring from outside its participants' AS boundries > is > possible but the IXP LANs will be vulnerable to DDoS from > outside of > those boundaries. > > IXP external services (such as dns, web pages, ftp servers) need to > be globally routed and due to strict prefix length filtering this > could be the reason to request more than one /48 assignment from a ^^^^^^^^^^^^^^ allocation > RIR (i.e. requesting one /48 for the IXPs LANs that is not globally ^^^^^^^^^ IXP LANs > routed and a different /48 for the IXP external services that is ^^^ allocation e.g. sometimes, /48 (for IXP LANs) and /48 (for external services). sometimes, /48 (for IXP LANs) and /32 (for external services). sometimes, something else. > globally routed). > --------------------- > > What do you think? > > Roque Regards, Masataka MAWATARI From kibijoaln@advanced-connect.net Tue Oct 6 07:14:24 2009 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 BDF033A693E for ; Tue, 6 Oct 2009 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.179 X-Spam-Level: X-Spam-Status: No, score=-12.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 TJJb8odDTc1L for ; Tue, 6 Oct 2009 07:14:23 -0700 (PDT) Received: from ambergrissolutions.com (unknown [189.24.144.232]) by core3.amsl.com (Postfix) with SMTP id D714B3A68E8 for ; Tue, 6 Oct 2009 07:14:17 -0700 (PDT) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091006141419.D714B3A68E8@core3.amsl.com> Date: Tue, 6 Oct 2009 07:14:17 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.comfyrace.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://comfyrace.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 8, B613. 333 Clements Road. London. SE81 3DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Tue Oct 6 08:27:23 2009 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 D7EE93A69B9 for ; Tue, 6 Oct 2009 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.857 X-Spam-Level: X-Spam-Status: No, score=-104.857 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q562DCzm9Ijs for ; Tue, 6 Oct 2009 08:27:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6E063A697A for ; Tue, 6 Oct 2009 08:27:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBtj-000N0D-H9 for v6ops-data0@psg.com; Tue, 06 Oct 2009 15:24: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.69 (FreeBSD)) (envelope-from ) id 1MvBtT-000Mz2-Cf for v6ops@ops.ietf.org; Tue, 06 Oct 2009 15:24:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1433; q=dns/txt; s=sjiport06001; t=1254842643; x=1256052243; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20|Subject:=20Fwd: =20V6OPS=20-=20Requested=20sessions=20have=20been=20sched uled=20for=20IETF=2076=20|Date:=20Tue,=206=20Oct=202009 =2007:37:05=20-0700|Message-Id:=20<0FC1CE5D-DE73-4B8D-8AC 5-CF84DD32590A@cisco.com>|To:=20IPv6=20Operations=20|Mime-Version:=201.0=20(Apple=20Message=20 framework=20v936)|Content-Transfer-Encoding:=207bit |References:=20<20091006012033.BF01F3A6915@core3.amsl.com >; bh=cSsd8rpfLmGf2GYRCiCHcnDy506TzovsU0kZyVgqyz8=; b=J6ZxkR45qdljZMaw+RT3dsEEc7eQKHT87kEec7GCBZ61AjRPp/hZRicY tKaH+cFCsmxTkaMuotr+3/4fxnhq3jDzkD0qIvUysP4tlz1F4CKAhg6At +zCsSutmuR6eltfwcbbSPjwUhWnUEHamqcAVsUdWiMwPMNnK9ZFnAGjVE o=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=fred@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGf+ykqrR7PE/2dsb2JhbAC7OYhjAY8aBoQqgVc X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208";a="403042221" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2009 15:24:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n96FO2Io031618 for ; Tue, 6 Oct 2009 08:24:02 -0700 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n96FO1I6001782 for ; Tue, 6 Oct 2009 15:24:02 GMT Message-Id: <0FC1CE5D-DE73-4B8D-8AC5-CF84DD32590A@cisco.com> From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Fwd: V6OPS - Requested sessions have been scheduled for IETF 76 Date: Tue, 6 Oct 2009 07:37:05 -0700 References: <20091006012033.BF01F3A6915@core3.amsl.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1433; t=1254842642; x=1255706642; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20V6OPS=20-=20Requested=20sessions=20hav e=20been=20scheduled=20for=20IETF=2076=20 |Sender:=20; bh=cSsd8rpfLmGf2GYRCiCHcnDy506TzovsU0kZyVgqyz8=; b=FjTlFsB4miJyGA8U4kLLDWN4+j60mkG0HqmucZ687X4e1fndVNrSOVyC6r H3UjV0aveRTWHE1dQWmI3OkrnM7WqCBeKuH8zcDU+jWA/U5+HEd6ztChUaZm Xsc4I62VCW; Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Begin forwarded message: > From: IETF Secretariat > Date: October 5, 2009 6:20:33 PM PDT > To: fred.baker@cisco.com > Cc: kurtis@kurtis.pp.se, dromasca@avaya.com, rbonica@juniper.net, session-request@ietf.org > Subject: V6OPS - Requested sessions have been scheduled for IETF 76 > > Dear Fred Baker, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > V6OPS Session 1 (2 hours) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Orchid 1 > ---------------------------------------------- > V6OPS Session 2 (2 hours) > Thursday, Afternoon Session I 1300-1500 > Room Name: Acacia 1 > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: v6ops > Area Name: Operations and Management Area > Session Requester: Fred Baker > > Number of Sessions: 2 > Length of Session(s): 2 hours > 2 hours > > Number of Attendees: 100 > Conflicts to Avoid: > First Priority: > shim6,6man > ,intarea > ,opsarea,opsawg,pcn,rtgarea,rtgwg,savi,tcpm,tsvarea,tsvwg,rrg,behave > BOF or IRTF Session: AI, IPR (whatever it is called) > > Special Requests: > > --------------------------------------------------------- > > From owner-v6ops@ops.ietf.org Wed Oct 7 02:21:05 2009 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 DA04728C13C for ; Wed, 7 Oct 2009 02:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bnxjWr2M9Ghr for ; Wed, 7 Oct 2009 02:21:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C344D28C0EE for ; Wed, 7 Oct 2009 02:21:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvSeE-0001uC-IH for v6ops-data0@psg.com; Wed, 07 Oct 2009 09:17:26 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvSe3-0001t0-S0 for v6ops@ops.ietf.org; Wed, 07 Oct 2009 09:17:23 +0000 Received: from [IPv6:2001:67c:64:42:225:ff:fe4b:94a8] (unknown [IPv6:2001:67c:64:42:225:ff:fe4b:94a8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1D8243084EC for ; Wed, 7 Oct 2009 07:17:05 -0200 (UYST) Message-Id: From: Roque Gagliano To: v6ops WG In-Reply-To: <20091006182138.A0D6.8FE1F57E@jpix.ad.jp> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-23--425581079" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Date: Wed, 7 Oct 2009 10:16:49 +0100 References: <20091002180244.E48A.8FE1F57E@jpix.ad.jp> <8A3A255A-3786-4608-907B-5C1AD6B10A7A@lacnic.net> <20091006182138.A0D6.8FE1F57E@jpix.ad.jp> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-23--425581079 Content-Type: multipart/alternative; boundary=Apple-Mail-22--425581081 --Apple-Mail-22--425581081 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Dear Masataka, Thank you for the comments. > > > e.g. > sometimes, /48 (for IXP LANs) and /48 (for external services). > sometimes, /48 (for IXP LANs) and /32 (for external services). > sometimes, something else. > exactly, that is why I was mentioning one example. Roque. > >> globally routed). >> --------------------- >> >> What do you think? >> >> Roque > > > Regards, > Masataka MAWATARI > ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-22--425581081 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = Masataka,

Thank you for the = comments.



e.g.
sometimes, /48 (for IXP LANs) = and /48 (for external services).
sometimes, /48 (for IXP LANs) and = /32 (for external services).
sometimes, something else.


exactly, that is why I was mentioning one = example.

Roque.



=    globally routed).
---------------------

What do you = think?

Roque


Regards,
Masataka = MAWATARI


-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =

= --Apple-Mail-22--425581081-- --Apple-Mail-23--425581079 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) iEYEARECAAYFAkrMXIEACgkQnk+WSgHpbO6LswCfRLBIsA+d1DuSQv0CI+0nn1Hn l2wAn0rDZDDIJuI7Av9UoIreHpJ3QQqT =JKh6 -----END PGP SIGNATURE----- --Apple-Mail-23--425581079-- From owner-v6ops@ops.ietf.org Wed Oct 7 03:10:29 2009 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 004053A6A7B for ; Wed, 7 Oct 2009 03:10:29 -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 TapDqAyIx8qc for ; Wed, 7 Oct 2009 03:10:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A3AE3A6A79 for ; Wed, 7 Oct 2009 03:10:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvTTA-00080U-14 for v6ops-data0@psg.com; Wed, 07 Oct 2009 10:10:04 +0000 Received: from [2001:610:140:2202:230:48ff:fe29:44a6] (helo=betonmix.noc.ams-ix.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvTSy-0007zG-Of for v6ops@ops.ietf.org; Wed, 07 Oct 2009 10:10:00 +0000 Received: from localhost (localhost [127.0.0.1]) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id F2A87FA86D; Wed, 7 Oct 2009 12:09:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from betonmix.noc.ams-ix.net ([127.0.0.1]) by localhost (betonmix.noc.ams-ix.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uMoiCarxi4pq; Wed, 7 Oct 2009 12:09:50 +0200 (CEST) Received: from fizzix (miraculix.noc.ams-ix.net [IPv6:2001:7b8:200:120::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by betonmix.noc.ams-ix.net (Postfix) with ESMTP id 885E4FA872; Wed, 7 Oct 2009 12:09:42 +0200 (CEST) Date: Wed, 7 Oct 2009 11:09:02 +0100 From: Martin Pels To: Roque Gagliano Cc: MAWATARI Masataka , v6ops@ops.ietf.org Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Message-ID: <20091007110902.6c0b329a@fizzix> In-Reply-To: <8A3A255A-3786-4608-907B-5C1AD6B10A7A@lacnic.net> References: <20091001135323.0c574feb@fizzix> <20091002180244.E48A.8FE1F57E@jpix.ad.jp> <8A3A255A-3786-4608-907B-5C1AD6B10A7A@lacnic.net> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i486-pc-linux-gnu) 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: Hi, On Mon, 5 Oct 2009 12:07:50 +0100 Roque Gagliano wrote: > [...] When considering the > routing of the IXP LANs two options are identified: > > o IXPs may decide that LANs should not to be globally routed in > order to limit the possible origins of a Distributed Denial of > Service (DDoS) attack to its particpant' AS boundries. In this > configuration participants may route these prefixes inside > their networks (e. g. using BGP no-export communities or routing the > IXP > LANs within the participants' IGP) to perform fault management. > Using this configuration, the monitoring of the IXP LANs from > outside of its participants' AS boundaries is not possible. > > o IXP may decide that LAN should be globally routed. In this > case, IXP LANs monitoring from outside its participants' AS > boundries is > possible but the IXP LANs will be vulnerable to DDoS from > outside of > those boundaries. > Although I have no problems with the content of this text, we should be careful to limit this document to options and recommendations for IPv6 deployment in specific. Since the above options are no different than those for IPv4 I believe this piece of text does not need to be added. Kind regards, Martin From owner-v6ops@ops.ietf.org Wed Oct 7 08:58:07 2009 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 EE6EB28C1C1 for ; Wed, 7 Oct 2009 08:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.143 X-Spam-Level: X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=-0.648, 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 pWxfQdjGABeE for ; Wed, 7 Oct 2009 08:58:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32ACB28C1BD for ; Wed, 7 Oct 2009 08:58:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvYqm-000Knm-K1 for v6ops-data0@psg.com; Wed, 07 Oct 2009 15:54:48 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvYqZ-000Kmp-6k for v6ops@ops.ietf.org; Wed, 07 Oct 2009 15:54:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=106; q=dns/txt; s=sjiport01001; t=1254930875; x=1256140475; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20|Subject:=20Agend a=20call|Date:=20Wed,=207=20Oct=202009=2008:54:28=20-0700 |Message-Id:=20|To:=20IPv6=20Operations=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit; bh=Mz2APqcCYH7rdTf7HeQqhOGyDEKgUnVxsmefM4Qmgag=; b=fBCl2S+QrIUqGQ1+Eudag/E+qxt/ay2tqJ0iliRdKqRdjBAyRs4CgjCD M3ETFeCX5hQmnzUoRTW5IxLVnmi1iWR5Q/4LpzzAIq/2b24kg14AweinG 3XquTa0ybvDjnp84KWRnU6lrSb7zbadA/xz+o8h7xekruW/ySkTiBF+ev I=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=fred@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHdWzEqrR7PE/2dsb2JhbAC/PYhjAY9DBoQq X-IronPort-AV: E=Sophos;i="4.44,519,1249257600"; d="scan'208";a="252230710" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 07 Oct 2009 15:54:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n97FsTe7002239 for ; Wed, 7 Oct 2009 08:54:29 -0700 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n97FsSFL000970 for ; Wed, 7 Oct 2009 15:54:29 GMT Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Agenda call Date: Wed, 7 Oct 2009 08:54:28 -0700 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=106; t=1254930869; x=1255794869; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Agenda=20call |Sender:=20; bh=Mz2APqcCYH7rdTf7HeQqhOGyDEKgUnVxsmefM4Qmgag=; b=YJqxuWLAAnv/RdyjkK5zVgNIKMrtOk56wXhtIAm/y3EfKsg2+Mm0QU0qYM MkRlqL1qPzKiFZmEpF14XTXOvIiUzRko0MLHP/ae2PmpI8VhHFoTl29Rdkdi zoRRZ9PS54; Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: We have two sessions scheduled in Hiroshima. This is a call for agenda items. Who wants time to talk? From owner-v6ops@ops.ietf.org Wed Oct 7 10:19:16 2009 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 65A3C3A687B for ; Wed, 7 Oct 2009 10:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MArUehdM-sV7 for ; Wed, 7 Oct 2009 10:19:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0561D28C0D7 for ; Wed, 7 Oct 2009 10:19:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mva76-0005B4-MH for v6ops-data0@psg.com; Wed, 07 Oct 2009 17:15:44 +0000 Received: from web45509.mail.sp1.yahoo.com ([68.180.197.125]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mva6u-00059o-Sb for v6ops@ops.ietf.org; Wed, 07 Oct 2009 17:15:41 +0000 Received: (qmail 41296 invoked by uid 60001); 7 Oct 2009 17:15:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254935730; bh=1xAWMtbm7UD9Y5jPtrn5TXwQV4Y4eD+kITCJy90R41w=; 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=JKK814HpHQI4AbZY4PojQ439LsenA3taabtMCpnDj3x1Sd/4MsMKLnDdaFT3MljY3MyPIP6uEXp/HXJjL3T2XXHuuFaznlyomPdnZIoC2wskR/k0cmvk3Se+46b0yPPCYIEdxuzFxQR/DKeuZJQcrj59AkR6YpW+5fxFHu32wRs= 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=l9UUeBZLvgdfvylTh2yc9j5JBRW8zA/cDsi+M6sSZJ3gG3l3fYLZTHiH45j+Zho63FTdgKBaAkNqe9eoWoVKviVMVNtCHkuNwednD3eLuaQaQH/W38JZcQN8QUODu77NPOyCXvkzlBoIM4BaRVVK/RbK3813+GtE6vPMoxFzNU8=; Message-ID: <908783.41273.qm@web45509.mail.sp1.yahoo.com> X-YMail-OSG: Hk5el5cVM1khwdp_a1QcYntcibemdDtUp1I2sxw4NU57UMn.DF8dvHb3p8ZkNlRgPbcq52Uh6nSYDKXCABBVztid4_Wdxx3pNqt32SksCmus4JHePwDemTHZIi8cdgZypqGt7Aw0PjPETu3MhUn_PFr9k1Zm49EtAe8aBXo3H8Zs410mQY2qgiySuKYdCPADXbMSJOBW5.K3oLzQbaNqpxn0aFW3eHicZzeaM1IVT4Nb2JR5vGCyKjRH6yDvx8STKLA5AYGJGRth2pQWOxXL4b0_xKgw Received: from [93.173.96.115] by web45509.mail.sp1.yahoo.com via HTTP; Wed, 07 Oct 2009 10:15:30 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> < 339077.93936.q!m@web45512.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> <866685.67299.qm@web45511.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.com> Date: Wed, 7 Oct 2009 10:15:30 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" Cc: v6ops In-Reply-To: <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.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 believe the problem you=A0are trying to address (link partitionin= g with=A0two or more=A0same-prefix routers) is not specific to ISATAP links= .=A0Any link may suffer from this problem (with smaller probability, perhap= s).=A0As I see it, if this issue was not addressed up until now for IPv6 in= general, then we should not=A0try to cope with it specifically=A0in ISATAP= using special mechanisms or restrictions.=A0=0A=0AI think the best way to = move forward is to go ahead with the three types of checks you described a = few weeks ago.=0A=0AGabi=0A=0A----- Original Message ----=0A> From: "Templi= n, Fred L" =0A> To: Gabi Nakibly =0A> Cc: v6ops =0A> Sent: Mon, October 5, 2009 4:5= 0:31 PM=0A> Subject: RE: Routing loop attacks using IPv6 tunnels=0A> =0A> G= abi,=0A> =0A> > -----Original Message-----=0A> > From: Gabi Nakibly [mailto= :gnakibly@yahoo.com]=0A> > Sent: Monday, October 05, 2009 2:24 PM=0A> > To:= Templin, Fred L=0A> > Cc: v6ops=0A> > Subject: Re: Routing loop attacks us= ing IPv6 tunnels=0A> >=0A> > On first thought, setting up a synchronization= mechanism of the neighbor =0A> caches at the routers does=0A> > not sound,= IMHO, like the best solution. It will probably add complexity and =0A> int= erdependence to the=0A> > routers' functionality.=0A> > Maybe a good trade-= off would be to first require a host to send an initial RS =0A> to every ro= uter in the=0A> > PRL. Then after the host learns the advertised prefix of = each router the host =0A> should continue sending=0A> > RSs (or stop sendin= g) to all routers advertising the same prefix.=0A> =0A> I understand what y= ou're saying, but here's the temptation.=0A> Lets say that ISATAP routers A= and B both advertise prefix=0A> P::/64, then the ISATAP site partitions an= d the only way=0A> A and B can still talk to each other is via the provider= =0A> network. The temptation part is that if A and B talk to=0A> each other= over the provider network then they can keep=0A> track of the ISATAP hosts= in each partition that configure=0A> an address from P::/64 and seemingly = can "heal" the=0A> partition by forwarding misdirected packets to each othe= r=0A> across the provider network. But then, we are guilty of=0A> "conspira= cy to create a multilink subnet" (see RFC4903=0A> for multi-link subnet iss= ues).=0A> =0A> This suggests that, if multiple ISATAP routers are to=0A> ad= vertise a shared prefix P::/64, then there either needs=0A> to be strong as= surance that the site won't partition. If=0A> that condition cannot be met,= then each ISATAP router must=0A> advertise a distinct prefix. Do you see a= ny other way?=0A> =0A> Fred=0A> fred.l.templin@boeing.com=0A> =0A> > ----- = Original Message ----=0A> > > From: "Templin, Fred L" =0A> > > To: Gabi Nak= ibly =0A> > > Cc: v6ops =0A> > > Sent: Mon, October 5, 2009 10:41:16 PM=0A>= > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > >=0A> > > G= abi,=0A> > >=0A> > > > -----Original Message-----=0A> > > > From: Gabi Naki= bly [mailto:gnakibly@yahoo.com]=0A> > > > Sent: Monday, October 05, 2009 1:= 32 PM=0A> > > > To: Templin, Fred L=0A> > > > Cc: v6ops=0A> > > > Subject: = Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > > > Fred,=0A> >= > > With regrad to your comment below: if indeed an ISATAP router will not= =0A> > > forward packets to an=0A> > > > ISATAP host it has not recently re= ceived RS from, then I think that the =0A> ISATAP=0A> > > specification=0A>= > > > should at least require an ISATAP host (using a SHOULD) to regularly= send =0A> RSs=0A> > > to _all_ routers in the=0A> > > > PRL, or else ISATA= P connectivity may be broken.=0A> > >=0A> > > Yes, "ping them all" is certa= inly one way to ensure a nbr=0A> > > cache entry at each PRL router. I was = also starting to=0A> > > think that another solution would be for PRL route= rs that=0A> > > advertise a shared IP prefx (e.g., 2001:DB8::/64) to=0A> > = > somehow synchronize their neighbor caches. For that=0A> > > matter, it mi= ght be best to do both because you can=0A> > > never tell which subset of t= he PRLs is the correct=0A> > > subset to ping.=0A> > >=0A> > > Fred=0A> > >= fred.l.templin@boeing.com=0A> > >=0A> > > > Gabi=0A> > > >=0A> > > > -----= Original Message ----=0A> > > > > From: "Templin, Fred L"=0A> > > > > To: = Gabi Nakibly=0A> > > > > Cc: v6ops=0A> > > > > Sent: Thu, October 1, 2009 6= :49:31 PM=0A> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels= =0A> > > > >=0A> > > > > Hi Gabi,=0A> > > > >=0A> > > > > > -----Original M= essage-----=0A> > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A= > > > > > > Sent: Thursday, October 01, 2009 6:53 AM=0A> > > > > > To: Temp= lin, Fred L=0A> > > > > > Cc: v6ops=0A> > > > > > Subject: Re: Routing loop= attacks using IPv6 tunnels=0A> > > > > >=0A> > > > > > Removed the 6man an= d secdir mailing lists from the Cc.=0A> > > > > >=0A> > > > > > Fred, see c= omments below.=0A> > > > > >=0A> > > > > > ----- Original Message ----=0A> = > > > > > > From: "Templin, Fred L"=0A> > > > > > > To: Gabi Nakibly ; Chri= stian Huitema=0A> > > > > ; v6ops=0A> > > > > >=0A> > > > > > > Cc: "ipv6@i= etf.org" ; "secdir@ietf.org"=0A> > > > > > > Sent: Tuesday, September 29, 2= 009 6:00:55 PM=0A> > > > > > > Subject: RE: Routing loop attacks using IPv6= tunnels=0A> > > > > > >=0A> > > > > > > Gabi,=0A> > > > > > >=0A> > > > > = > > Welcome back from your vacation. I trimmed quite a bit from=0A> > > > >= > > the bottom of this message to eliminate the clutter, but see=0A> > > >= > > > below for responses to your current comments:=0A> > > > > > >=0A> > = > > > > > > -----Original Message-----=0A> > > > > > > > From: Gabi Nakibly= [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: Tuesday, September 29,= 2009 3:22 AM=0A> > > > > > > > To: Templin, Fred L; Christian Huitema; v6o= ps=0A> > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > S= ubject: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > > > >=0A> >= > > > > > > Hi Fred,=0A> > > > > > > > Back from vacation. See Comments in= lines.=0A> > > > > > > >=0A> > > > > > > > Gabi=0A> > > > > > > >=0A> > > >= > > > >=0A> > > > > > > >=0A> > > > > > > > ----- Original Message ----=0A= > > > > > > > > > From: "Templin, Fred L"=0A> > > > > > > > > To: Gabi Naki= bly ; Christian Huitema=0A> > > > > > > ; v6ops=0A> > > > > > > >=0A> > > >= > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > > Sent: Fri= day, September 11, 2009 11:13:44 PM=0A> > > > > > > > > Subject: RE: Routin= g loop attacks using IPv6 tunnels=0A> > > > > > > > >=0A> > > > > > > > > H= i Gabi,=0A> > > > > > > > >=0A> > > > > > > > > > -----Original Message----= -=0A> > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> = > > > > > > > > > Sent: Friday, September 11, 2009 12:59 PM=0A> > > > > > >= > > > To: Templin, Fred L; Christian Huitema; v6ops=0A> > > > > > > > > > = Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > > > Subject: Re: Routi= ng loop attacks using IPv6 tunnels=0A> > > > > > > > > >=0A> > > > > > > > = > > Hi Fred,=0A> > > > > > > > > > See below.=0A> > > > > > > > > >=0A> > >= > > > > > > > Gabi=0A> > > > > > > > > >=0A> > > > > > > > > >=0A> > > > >= > > > > >=0A> > > > > > > > > > ----- Original Message ----=0A> > > > > > = > > > > > From: "Templin, Fred L"=0A> > > > > > > > > > > To: Gabi Nakibly = ; Christian Huitema=0A> > > > > > > > > ; v6ops=0A> > > > > > > > > >=0A> >= > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > > >= > Sent: Tuesday, September 8, 2009 8:37:03 PM=0A> > > > > > > > > > > Subj= ect: RE: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > > > >=0A= > > > > > > > > > > > Gabi and Christian,=0A> > > > > > > > > > >=0A> > > >= > > > > > > > Focusing only on attack #3 (i.e., leaving out attack #1=0A> = > > > > > > > > > > and #2 6to4 interactions for the moment), please check= =0A> > > > > > > > > > > the following summary of proposed mitigations:=0A>= > > > > > > > > > >=0A> > > > > > > > > > > 1) For ISATAP/VET routers that= have assurance that their=0A> > > > > > > > > > > neighbor cache is cohere= nt, the router can make a simple=0A> > > > > > > > > > > check in the neigh= bor cache to determine whether to=0A> > > > > > > > > > > forward or drop t= he packet. In pseudo-code:=0A> > > > > > > > > > >=0A> > > > > > > > > > >= =A0 isatap_rcv() {=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > >= >=A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D "fe80::*"))=0A> > > = > > > > > > > >=A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > > >=A0 =A0 ...= =0A> > > > > > > > > > >=A0 }=0A> > > > > > > > > > >=0A> > > > > > > > > >= >=A0 isatap_xmt() {=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > >= > >=A0 =A0 if ((v6dst is not a neighbor) && (v6src !=3D "fe80::*"))=0A> > = > > > > > > > > >=A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > > >=A0 =A0 ...= =0A> > > > > > > > > > >=A0 }=0A> > > > > > > > > > >=0A> > > > > > > > > >= > (Here, the link-local exception is necessary to bootstrap=0A> > > > > > = > > > > > neighbor discovery on the ISATAP link.)=0A> > > > > > > > > > >= =0A> > > > > > > > > > > Does anyone see a problem with this?=0A> > > > > >= > > > > >=0A> > > > > > > > > > Looks fine.=0A> > > > > > > > >=0A> > > > = > > > > > OK.=0A> > > > > > > > >=0A> > > > > > > >=0A> > > > > > > > On se= cond thought, a couple of comments:=0A> > > > > > > > 1) According to RFC 5= 214 Section 8.3.4:=0A> > > > > > > >=A0 =A0 =A0 =A0 " ISATAP nodes MAY sche= dule periodic Router Solicitation =0A> events=0A> > > > > > > >=A0 =A0 =A0 = =A0 for certain PRL(i)s by setting the corresponding TIMER(i)."=0A> > > > >= > > > As I understand, this means that there is a possibility for a host = =0A> not=0A> > > > > to send=0A> > > > > > > RSs to all routers in=0A> > > = > > > > > the PRL. However, any router in the PRL may forward packets into = =0A> the=0A> > > > > ISATAP=0A> > > > > > > link. The isatap_xmt()=0A> > > = > > > > > check will prevent forwarding packets by routers which the=0A> > = > destination has=0A> > > > > not=0A> > > > > > > previously sent RS to.=0A= > > > > > > > > If I am correct then this check may break ISATAP connectivi= ty.=0A> > > > > > >=0A> > > > > > > I don't think this is a problem. If a h= ost has not sent an RS to=0A> > > > > > > a PRL router, then it should not = have configured a default route=0A> > > > > > > nor any prefix information = specific to that router. Therefore,=0A> > > > > > > the only packets the ho= st and router should expect to exchange=0A> > > > > > > in this state are l= ink-local. As such, the router can discard=0A> > > > > > > non-link-local p= ackets if there is no neighbor cache entry.=0A> > > > > > >=0A> > > > > >= =0A> > > > > > I was thinking of a case of two routers in the PRL advertisi= ng the =0A> same=0A> > > prefix=0A> > > > > for the ISATAP=0A> > > > > > li= nk. Either routers obviously may forward packets _into_ the ISATAP =0A> lin= k=0A> > > to=0A> > > > > any host. If a host will=0A> > > > > > not send a = RS to one of those routers then it will drop packets =0A> destined=0A> > > = to=0A> > > > > that host.=0A> > > > >=0A> > > > > I'm actually OK with that= . If two routers A and B advertise=0A> > > > > the same prefix P, and if B = doesn't know about host H either=0A> > > > > through receiving RSs or throu= gh talking to A, then B should=0A> > > > > not forward packets to H.=0A> > = > > >=0A> > > > > Thanks - Fred=0A> > > > > fred.l.templin@boeing.com=0A> >= > > >=0A> > > > > > > > 2) I remind you a comment you made in the past: fo= r the checks to=0A> > > work the=0A> > > > > > > time between two=0A> > > >= > > > > consequtive RSs from a host to a router should be no greater than = =0A> the=0A> > > the=0A> > > > > > > lifetime of an entry for=0A> > > > > >= > > that host in the router's neighbors cache. This is needed to =0A> ensu= re=0A> > > > > that the=0A> > > > > > > entry in the neighbors=0A> > > > > = > > > cache will not be erased. This raises two questions:=0A> > > > > > > = >=A0 =A0 a) AFAIK there is no minimum lifetime for an entry in a =0A> neigh= bors=0A> > > > > cache=0A> > > > > > > - it is an implementation=0A> > > > = > > > > detail. If this is true how can we enforce the above constraint?=0A= > > > > > > >=0A> > > > > > > Correct that there is no minimum lifetime for= neighbor cache=0A> > > > > > > entries specified by RFC4861. However, an I= SATAP router that=0A> > > > > > > uses the neighbor cache checking procedur= es I have described=0A> > > > > > > can use its own discipline for managing= its neighbor cache.=0A> > > > > > > Exactly such a discipline is now speci= fied in Section 5.4.1=0A> > > > > > > of 'draft-templin-intarea-vet'. Pleas= e be aware that ISATAP=0A> > > > > > > and VET are simply "IPv6-over-(foo)"= specifications, and=0A> > > > > > > RFC4861 permits that operations of the= neighbor discovery=0A> > > > > > > protocol that are specific to (foo) lin= ks may be specified=0A> > > > > > > in such documents.=0A> > > > > > >=0A> = > > > > >=0A> > > > > > OK.=0A> > > > > >=0A> > > > > > > >=A0 =A0 b) A rou= ter's neighbors cache must now include at any given =0A> moment=0A> > > all= =0A> > > > > the=0A> > > > > > > active ISATAP nodes in=0A> > > > > > > > t= he ISATAP link. Is this a reasonable demand?=0A> > > > > > >=0A> > > > > > = > Memory should be cheap enough, and ISATAP links within private=0A> > > > = > > > addressing realms should be small enough, that I do not see this=0A> = > > > > > > as an unreasonable demand.=0A> > > > > > >=0A> > > > > >=0A> > = > > > > OK.=0A> > > > > >=0A> > > > > > > > > > > 2) For ISATAP/VET routers= that use public IPv4 addresses=0A> > > > > > > > > > > and that do not hav= e assurance that their neighbor cache=0A> > > > > > > > > > > is coherent, = the router can check for the interface ID=0A> > > > > > > > > > > "0200:5EF= E:". In pseudo-code:=0A> > > > > > > > > > >=0A> > > > > > > > > > >=A0 isa= tap_rcv() {=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > >=A0 = =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:")=0A> > > > > > > > > > >= =A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > = > > > >=A0 }=0A> > > > > > > > > > >=0A> > > > > > > > > > >=A0 isatap_xmt(= ) {=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > >=A0 =A0 if (v= 6src =3D=3D "foreign_prefix::0200:5efe:")=0A> > > > > > > > > > >=A0 =A0 = =A0 drop_pkt();=0A> > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > >= =A0 }=0A> > > > > > > > > > >=0A> > > > > > > > > > > Does anyone see a pro= blem with this?=0A> > > > > > > > > >=0A> > > > > > > > > > Looks fine.=0A>= > > > > > > > >=0A> > > > > > > > > OK, but since I sent this I began to w= onder whether cases=0A> > > > > > > > > 1) and 2) should be reversed (i.e.,= do the 0x00:5EFE check=0A> > > > > > > > > first). I came to believe that = it almost doesn't matter=0A> > > > > > > > > from a performance standpoint,= and perhaps should be left=0A> > > > > > > > > up to the implementer. Do y= ou have an opinion on this?=0A> > > > > > > > >=0A> > > > > > > > > > > 3) = For ISATAP/VET routers that use private IPv4 addresses=0A> > > > > > > > > = > > and that do not have assurance that their neighbor cache=0A> > > > > > = > > > > > is coherent, the router can make the checks that Christian=0A> > = > > > > > > > > > has proposed. But, will we see any of these case 3)=0A> >= > > > > > > > > > situations in operational practice?=0A> > > > > > > > > = > >=0A> > > > > > > > > >=0A> > > > > > > > > > I can not tell for sure. Wh= y this case seems to you less =0A> plausible=0A> > > > > than=0A> > > > > >= > case=0A> > > > > > > > > 2?=0A> > > > > > > > >=0A> > > > > > > > > Case= 3) is the case in which source address spoofing within=0A> > > > > > > > >= a private IPv4 addressing range is possible. It seems to me=0A> > > > > > = > > > that it may correspond to either a poorly managed deployment,=0A> > >= > > > > > > or one in which there are multiple administrative authorities= =0A> > > > > > > > > with diverse policies and operational practices.=0A> >= > > > > > > >=0A> > > > > > > >=0A> > > > > > > > I agree. However, rememb= er that the spoofed packet may also =0A> originate=0A> > > from=0A> > > > >= > > within the site, which is=0A> > > > > > > > very hard to defend agains= t.=0A> > > > > > >=0A> > > > > > > Spoofing is not so hard to defend agains= t if Secure Neighbor=0A> > > > > > > Discovery (SEND) is used to set up the= neighbor relationships=0A> > > > > > > and if every packet carries a nonce= that can be used to detect=0A> > > > > > > an off-path attack.=0A> > > > >= >=0A> > > > > > I agree again. I was referring to the case where SEND is n= ot deployed.=0A> > > > > >=0A> > > > > > > That is only the case for VET an= d SEAL,=0A> > > > > > > however, so if source address spoofing within the s= ite is seen=0A> > > > > > > as a problem then VET and SEAL should be used i= nstead of ISATAP.=0A> > > > > > >=0A> > > > > > > Note that for the sake of= consistency it might be helpful to=0A> > > > > > > consider VET as simply = "ISATAP version 2 (ISATAPv2)".=0A> > > > > > >=0A> > > > > > > Fred=0A> > >= > > > > fred.l.templin@boeing.com=0A> > > > > > >=0A> > > > > > > > > The = checks that Christian proposed could be used for this=0A> > > > > > > > > s= cenario if possible. Otherwise, the best solution IMHO=0A> > > > > > > > > = would be to allow only routers (and not hosts) on the=0A> > > > > > > > > v= irtual links. This final model would be best addressed=0A> > > > > > > > > = by VET and SEAL rather than ISATAP.=0A> > > > > > > > >=0A> > > > > > > > >= Thanks - Fred=0A> > > > > > > > > fred.l.templin@boeing.com=0A> > > > > >= =0A> > > > > > __________________________________________________=0A> > > >= > > Do You Yahoo!?=0A> > > > > > Tired of spam?=A0 Yahoo! Mail has the bes= t spam protection around=0A> > > > > > http://mail.yahoo.com=0A> > > >=0A> = > > >=0A> > > >=0A> > > >=0A> >=0A> >=0A> >=0A> >=0A=0A=0A=0A From owner-v6ops@ops.ietf.org Wed Oct 7 10:42:44 2009 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 7DC373A697D for ; Wed, 7 Oct 2009 10:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=-2.697, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3, 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 DZrfkPxqL0B4 for ; Wed, 7 Oct 2009 10:42:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 583783A696B for ; Wed, 7 Oct 2009 10:42:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvaX3-0007eJ-7u for v6ops-data0@psg.com; Wed, 07 Oct 2009 17:42:33 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvaWs-0007cs-9G for v6ops@ops.ietf.org; Wed, 07 Oct 2009 17:42:30 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n97HgBb4009611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Oct 2009 12:42:11 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n97HgAtT001957; Wed, 7 Oct 2009 10:42:10 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n97HgAxr001954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 7 Oct 2009 10:42:10 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 7 Oct 2009 10:42:10 -0700 From: "Templin, Fred L" To: Gabi Nakibly CC: v6ops Date: Wed, 7 Oct 2009 10:42:07 -0700 Subject: RE: Routing loop attacks using IPv6 tunnels Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcpHc5PrgdOjN2WtRem5LS8FndiI3gAAS5rg Message-ID: <12F4112206976147A34FEC0277597CCF27A410A0A9@XCH-NW-15V.nw.nos.boeing.com> References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeplo y .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos.boeing.com> !<339077.93936.q!m@web45512.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> <866685.67299.qm@web45511.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.com> <908783.41273.qm@web45509.mail.sp1.yahoo.com> In-Reply-To: <908783.41273.qm@web45509.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: Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Wednesday, October 07, 2009 10:16 AM > To: Templin, Fred L > Cc: v6ops > Subject: Re: Routing loop attacks using IPv6 tunnels > > Fred, > I believe the problem you are trying to address (link partitioning with t= wo or more same-prefix > routers) is not specific to ISATAP links. Any link may suffer from this p= roblem (with smaller > probability, perhaps). Right. At any time, an operator might unplug a cable, a backhoe might dig up a wiring conduit, a piece of networking gear might fail, etc., etc. > As I see it, if this issue was not addressed up until now for IPv6 in gen= eral, > then we should not try to cope with it specifically in ISATAP using speci= al mechanisms or > restrictions. In general I agree, but as ISATAP may be applied to a wide variety of use cases perhaps there would be a separate study to be investigated in a specific use case analysis. But I can agree that that would be out of scope wrt what we are discussing here. > I think the best way to move forward is to go ahead with the three types = of checks you described a > few weeks ago. How shall we document this? Thanks - Fred fred.l.templin@boeing.com > Gabi > > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly > > Cc: v6ops > > Sent: Mon, October 5, 2009 4:50:31 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, October 05, 2009 2:24 PM > > > To: Templin, Fred L > > > Cc: v6ops > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > On first thought, setting up a synchronization mechanism of the neigh= bor > > caches at the routers does > > > not sound, IMHO, like the best solution. It will probably add complex= ity and > > interdependence to the > > > routers' functionality. > > > Maybe a good trade-off would be to first require a host to send an in= itial RS > > to every router in the > > > PRL. Then after the host learns the advertised prefix of each router = the host > > should continue sending > > > RSs (or stop sending) to all routers advertising the same prefix. > > > > I understand what you're saying, but here's the temptation. > > Lets say that ISATAP routers A and B both advertise prefix > > P::/64, then the ISATAP site partitions and the only way > > A and B can still talk to each other is via the provider > > network. The temptation part is that if A and B talk to > > each other over the provider network then they can keep > > track of the ISATAP hosts in each partition that configure > > an address from P::/64 and seemingly can "heal" the > > partition by forwarding misdirected packets to each other > > across the provider network. But then, we are guilty of > > "conspiracy to create a multilink subnet" (see RFC4903 > > for multi-link subnet issues). > > > > This suggests that, if multiple ISATAP routers are to > > advertise a shared prefix P::/64, then there either needs > > to be strong assurance that the site won't partition. If > > that condition cannot be met, then each ISATAP router must > > advertise a distinct prefix. Do you see any other way? > > > > Fred > > fred.l.templin@boeing.com > > > > > ----- Original Message ---- > > > > From: "Templin, Fred L" > > > > To: Gabi Nakibly > > > > Cc: v6ops > > > > Sent: Mon, October 5, 2009 10:41:16 PM > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > Gabi, > > > > > > > > > -----Original Message----- > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > Sent: Monday, October 05, 2009 1:32 PM > > > > > To: Templin, Fred L > > > > > Cc: v6ops > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > Fred, > > > > > With regrad to your comment below: if indeed an ISATAP router wil= l not > > > > forward packets to an > > > > > ISATAP host it has not recently received RS from, then I think th= at the > > ISATAP > > > > specification > > > > > should at least require an ISATAP host (using a SHOULD) to regula= rly send > > RSs > > > > to _all_ routers in the > > > > > PRL, or else ISATAP connectivity may be broken. > > > > > > > > Yes, "ping them all" is certainly one way to ensure a nbr > > > > cache entry at each PRL router. I was also starting to > > > > think that another solution would be for PRL routers that > > > > advertise a shared IP prefx (e.g., 2001:DB8::/64) to > > > > somehow synchronize their neighbor caches. For that > > > > matter, it might be best to do both because you can > > > > never tell which subset of the PRLs is the correct > > > > subset to ping. > > > > > > > > Fred > > > > fred.l.templin@boeing.com > > > > > > > > > Gabi > > > > > > > > > > ----- Original Message ---- > > > > > > From: "Templin, Fred L" > > > > > > To: Gabi Nakibly > > > > > > Cc: v6ops > > > > > > Sent: Thu, October 1, 2009 6:49:31 PM > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > Hi Gabi, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > Sent: Thursday, October 01, 2009 6:53 AM > > > > > > > To: Templin, Fred L > > > > > > > Cc: v6ops > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > Removed the 6man and secdir mailing lists from the Cc. > > > > > > > > > > > > > > Fred, see comments below. > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > > > From: "Templin, Fred L" > > > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > > > ; v6ops > > > > > > > > > > > > > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org" > > > > > > > > Sent: Tuesday, September 29, 2009 6:00:55 PM > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > Gabi, > > > > > > > > > > > > > > > > Welcome back from your vacation. I trimmed quite a bit from > > > > > > > > the bottom of this message to eliminate the clutter, but se= e > > > > > > > > below for responses to your current comments: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > > > Sent: Tuesday, September 29, 2009 3:22 AM > > > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > Back from vacation. See Comments inlines. > > > > > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > > > > > From: "Templin, Fred L" > > > > > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > > > > > ; v6ops > > > > > > > > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > > > Sent: Friday, September 11, 2009 11:13:44 PM > > > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > > > > > Hi Gabi, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > > > > > > > > > Sent: Friday, September 11, 2009 12:59 PM > > > > > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > > Gabi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > > > > > > > > > From: "Templin, Fred L" > > > > > > > > > > > > To: Gabi Nakibly ; Christian Huitema > > > > > > > > > > ; v6ops > > > > > > > > > > > > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > > > > > > > > > Sent: Tuesday, September 8, 2009 8:37:03 PM > > > > > > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnel= s > > > > > > > > > > > > > > > > > > > > > > > > Gabi and Christian, > > > > > > > > > > > > > > > > > > > > > > > > Focusing only on attack #3 (i.e., leaving out attac= k #1 > > > > > > > > > > > > and #2 6to4 interactions for the moment), please ch= eck > > > > > > > > > > > > the following summary of proposed mitigations: > > > > > > > > > > > > > > > > > > > > > > > > 1) For ISATAP/VET routers that have assurance that = their > > > > > > > > > > > > neighbor cache is coherent, the router can make a s= imple > > > > > > > > > > > > check in the neighbor cache to determine whether to > > > > > > > > > > > > forward or drop the packet. In pseudo-code: > > > > > > > > > > > > > > > > > > > > > > > > isatap_rcv() { > > > > > > > > > > > > ... > > > > > > > > > > > > if ((v6src is not a neighbor) && (v6dst !=3D "fe= 80::*")) > > > > > > > > > > > > drop_pkt(); > > > > > > > > > > > > ... > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > isatap_xmt() { > > > > > > > > > > > > ... > > > > > > > > > > > > if ((v6dst is not a neighbor) && (v6src !=3D "fe= 80::*")) > > > > > > > > > > > > drop_pkt(); > > > > > > > > > > > > ... > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > (Here, the link-local exception is necessary to boo= tstrap > > > > > > > > > > > > neighbor discovery on the ISATAP link.) > > > > > > > > > > > > > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > > > > > > > > > > > > > Looks fine. > > > > > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On second thought, a couple of comments: > > > > > > > > > 1) According to RFC 5214 Section 8.3.4: > > > > > > > > > " ISATAP nodes MAY schedule periodic Router Solici= tation > > events > > > > > > > > > for certain PRL(i)s by setting the corresponding T= IMER(i)." > > > > > > > > > As I understand, this means that there is a possibility f= or a host > > not > > > > > > to send > > > > > > > > RSs to all routers in > > > > > > > > > the PRL. However, any router in the PRL may forward packe= ts into > > the > > > > > > ISATAP > > > > > > > > link. The isatap_xmt() > > > > > > > > > check will prevent forwarding packets by routers which th= e > > > > destination has > > > > > > not > > > > > > > > previously sent RS to. > > > > > > > > > If I am correct then this check may break ISATAP connecti= vity. > > > > > > > > > > > > > > > > I don't think this is a problem. If a host has not sent an = RS to > > > > > > > > a PRL router, then it should not have configured a default = route > > > > > > > > nor any prefix information specific to that router. Therefo= re, > > > > > > > > the only packets the host and router should expect to excha= nge > > > > > > > > in this state are link-local. As such, the router can disca= rd > > > > > > > > non-link-local packets if there is no neighbor cache entry. > > > > > > > > > > > > > > > > > > > > > > I was thinking of a case of two routers in the PRL advertisin= g the > > same > > > > prefix > > > > > > for the ISATAP > > > > > > > link. Either routers obviously may forward packets _into_ the= ISATAP > > link > > > > to > > > > > > any host. If a host will > > > > > > > not send a RS to one of those routers then it will drop packe= ts > > destined > > > > to > > > > > > that host. > > > > > > > > > > > > I'm actually OK with that. If two routers A and B advertise > > > > > > the same prefix P, and if B doesn't know about host H either > > > > > > through receiving RSs or through talking to A, then B should > > > > > > not forward packets to H. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > 2) I remind you a comment you made in the past: for the c= hecks to > > > > work the > > > > > > > > time between two > > > > > > > > > consequtive RSs from a host to a router should be no grea= ter than > > the > > > > the > > > > > > > > lifetime of an entry for > > > > > > > > > that host in the router's neighbors cache. This is needed= to > > ensure > > > > > > that the > > > > > > > > entry in the neighbors > > > > > > > > > cache will not be erased. This raises two questions: > > > > > > > > > a) AFAIK there is no minimum lifetime for an entry in = a > > neighbors > > > > > > cache > > > > > > > > - it is an implementation > > > > > > > > > detail. If this is true how can we enforce the above cons= traint? > > > > > > > > > > > > > > > > Correct that there is no minimum lifetime for neighbor cach= e > > > > > > > > entries specified by RFC4861. However, an ISATAP router tha= t > > > > > > > > uses the neighbor cache checking procedures I have describe= d > > > > > > > > can use its own discipline for managing its neighbor cache. > > > > > > > > Exactly such a discipline is now specified in Section 5.4.1 > > > > > > > > of 'draft-templin-intarea-vet'. Please be aware that ISATAP > > > > > > > > and VET are simply "IPv6-over-(foo)" specifications, and > > > > > > > > RFC4861 permits that operations of the neighbor discovery > > > > > > > > protocol that are specific to (foo) links may be specified > > > > > > > > in such documents. > > > > > > > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > b) A router's neighbors cache must now include at any = given > > moment > > > > all > > > > > > the > > > > > > > > active ISATAP nodes in > > > > > > > > > the ISATAP link. Is this a reasonable demand? > > > > > > > > > > > > > > > > Memory should be cheap enough, and ISATAP links within priv= ate > > > > > > > > addressing realms should be small enough, that I do not see= this > > > > > > > > as an unreasonable demand. > > > > > > > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > 2) For ISATAP/VET routers that use public IPv4 addr= esses > > > > > > > > > > > > and that do not have assurance that their neighbor = cache > > > > > > > > > > > > is coherent, the router can check for the interface= ID > > > > > > > > > > > > "0200:5EFE:". In pseudo-code: > > > > > > > > > > > > > > > > > > > > > > > > isatap_rcv() { > > > > > > > > > > > > ... > > > > > > > > > > > > if (v6dst =3D=3D "foreign_prefix::0200:5efe:") > > > > > > > > > > > > drop_pkt(); > > > > > > > > > > > > ... > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > isatap_xmt() { > > > > > > > > > > > > ... > > > > > > > > > > > > if (v6src =3D=3D "foreign_prefix::0200:5efe:") > > > > > > > > > > > > drop_pkt(); > > > > > > > > > > > > ... > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > Does anyone see a problem with this? > > > > > > > > > > > > > > > > > > > > > > Looks fine. > > > > > > > > > > > > > > > > > > > > OK, but since I sent this I began to wonder whether cas= es > > > > > > > > > > 1) and 2) should be reversed (i.e., do the 0x00:5EFE ch= eck > > > > > > > > > > first). I came to believe that it almost doesn't matter > > > > > > > > > > from a performance standpoint, and perhaps should be le= ft > > > > > > > > > > up to the implementer. Do you have an opinion on this? > > > > > > > > > > > > > > > > > > > > > > 3) For ISATAP/VET routers that use private IPv4 add= resses > > > > > > > > > > > > and that do not have assurance that their neighbor = cache > > > > > > > > > > > > is coherent, the router can make the checks that Ch= ristian > > > > > > > > > > > > has proposed. But, will we see any of these case 3) > > > > > > > > > > > > situations in operational practice? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can not tell for sure. Why this case seems to you l= ess > > plausible > > > > > > than > > > > > > > > case > > > > > > > > > > 2? > > > > > > > > > > > > > > > > > > > > Case 3) is the case in which source address spoofing wi= thin > > > > > > > > > > a private IPv4 addressing range is possible. It seems t= o me > > > > > > > > > > that it may correspond to either a poorly managed deplo= yment, > > > > > > > > > > or one in which there are multiple administrative autho= rities > > > > > > > > > > with diverse policies and operational practices. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree. However, remember that the spoofed packet may al= so > > originate > > > > from > > > > > > > > within the site, which is > > > > > > > > > very hard to defend against. > > > > > > > > > > > > > > > > Spoofing is not so hard to defend against if Secure Neighbo= r > > > > > > > > Discovery (SEND) is used to set up the neighbor relationshi= ps > > > > > > > > and if every packet carries a nonce that can be used to det= ect > > > > > > > > an off-path attack. > > > > > > > > > > > > > > I agree again. I was referring to the case where SEND is not = deployed. > > > > > > > > > > > > > > > That is only the case for VET and SEAL, > > > > > > > > however, so if source address spoofing within the site is s= een > > > > > > > > as a problem then VET and SEAL should be used instead of IS= ATAP. > > > > > > > > > > > > > > > > Note that for the sake of consistency it might be helpful t= o > > > > > > > > consider VET as simply "ISATAP version 2 (ISATAPv2)". > > > > > > > > > > > > > > > > Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > The checks that Christian proposed could be used for th= is > > > > > > > > > > scenario if possible. Otherwise, the best solution IMHO > > > > > > > > > > would be to allow only routers (and not hosts) on the > > > > > > > > > > virtual links. This final model would be best addressed > > > > > > > > > > by VET and SEAL rather than ISATAP. > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > __________________________________________________ > > > > > > > Do You Yahoo!? > > > > > > > Tired of spam? Yahoo! Mail has the best spam protection arou= nd > > > > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Wed Oct 7 14:48:42 2009 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 3504D3A697C for ; Wed, 7 Oct 2009 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.893, 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 fkRbO0DFhB0w for ; Wed, 7 Oct 2009 14:48:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57EB03A697B for ; Wed, 7 Oct 2009 14:48:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MveJl-0003SP-3K for v6ops-data0@psg.com; Wed, 07 Oct 2009 21:45:05 +0000 Received: from [209.85.222.198] (helo=mail-pz0-f198.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MveJb-0003Rg-MQ for v6ops@ops.ietf.org; Wed, 07 Oct 2009 21:45:03 +0000 Received: by pzk36 with SMTP id 36so2529462pzk.5 for ; Wed, 07 Oct 2009 14:44:55 -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=/X9s77q41IqwhWjd3lgYZJqerN1cDxKfa59ahKXhnQk=; b=MmRCoPsZUcrRKvVe87rFK5mOyk9F2hDollH9bIURmzMF9IW18904Y5cwQuEl6evQOi 7R/W1U83/cDgd8ECQB8+8GG9MUDWSWb8JPNAg2BcFrYIZUqVhvo6Lfd7kw8F7+Mv9lo5 Y8OIKqr5qdfyQqxITE8JBj7y2x2jbNlYNP/nY= 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=ncogLE2bzU1U1z6Vs8uihXlg3DDbM3veufMVDxC+j/kwwirL7W5ew1Nlio4xFnIVy2 iB4OTOxaR5SeIP0V/d/ptlbqjCZ3BQEGAMvGtNjDdk4qp8pjFh22PLGAOawAXhaacRvf 2x+01vk3ugtZ+SEW2M056OVxKcp7hteJWlhqk= Received: by 10.114.164.5 with SMTP id m5mr659594wae.195.1254951894967; Wed, 07 Oct 2009 14:44:54 -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 23sm369007pzk.4.2009.10.07.14.44.53 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 14:44:54 -0700 (PDT) Message-ID: <4ACD0BD3.4080705@gmail.com> Date: Thu, 08 Oct 2009 10:44:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations Subject: Re: Agenda call 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: I'm not sure if Sheng is back on line, so let me say that we want to propose WG adoption of draft-jiang-v6ops-incremental-cgn-03.txt It's been updated according to comments received by September 25. We could describe those updates in a short agenda slot. Brian On 2009-10-08 04:54, Fred Baker wrote: > We have two sessions scheduled in Hiroshima. This is a call for agenda > items. Who wants time to talk? > > From owner-v6ops@ops.ietf.org Wed Oct 7 18:39:56 2009 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 ED7893A687A for ; Wed, 7 Oct 2009 18:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.133 X-Spam-Level: X-Spam-Status: No, score=-105.133 tagged_above=-999 required=5 tests=[AWL=-0.638, 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 9jq4EFukP7he for ; Wed, 7 Oct 2009 18:39:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D86BA3A67F1 for ; Wed, 7 Oct 2009 18:39:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mvhuk-000MAy-Ti for v6ops-data0@psg.com; Thu, 08 Oct 2009 01:35:30 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mvhub-000M9n-65 for v6ops@ops.ietf.org; Thu, 08 Oct 2009 01:35:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=790; q=dns/txt; s=sjiport06001; t=1254965721; x=1256175321; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20|Subject:=20Re: =20Agenda=20call|Date:=20Wed,=207=20Oct=202009=2018:20:33 =20-0700|Message-Id:=20<27A1609E-5988-41DB-A930-2ABB2EE26 1FB@cisco.com>|To:=20IPv6=20Operations=20|Mime-Version:=201.0=20(Apple=20Message=20framework =20v936)|Content-Transfer-Encoding:=207bit|In-Reply-To: =20<4ACD0BD3.4080705@gmail.com>|References:=20=20<4ACD0BD3.4080705 @gmail.com>; bh=/bpi2MhubSODXpmrdfXeqr4zkLjjAcm/t5BUBbT4Im0=; b=LnKGmOUGy35pH6Oa4n4b1nplUvbkW6NjCjI/0ru+E0p3OI5Hbf8cs7GC ugsNJRvbvhixoUT1VqeYlO3KbyRMfKsT1xjZ51qT7uLUcTbCSbq3iQ4Fr xzR8ZwKmTtVi29hMISVKYxi/ayj03OAdaK+Bt3DWH5Ivi4p/kxOYSdxXP 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=fred@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOnezEqrR7MV/2dsb2JhbADAEIhjAY83BoQq X-IronPort-AV: E=Sophos;i="4.44,522,1249257600"; d="scan'208";a="404214763" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Oct 2009 01:20:36 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n981Ka4j018915 for ; Wed, 7 Oct 2009 18:20:36 -0700 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n981KaXH012755 for ; Thu, 8 Oct 2009 01:20:36 GMT Message-Id: <27A1609E-5988-41DB-A930-2ABB2EE261FB@cisco.com> From: Fred Baker To: IPv6 Operations In-Reply-To: <4ACD0BD3.4080705@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Agenda call Date: Wed, 7 Oct 2009 18:20:33 -0700 References: <4ACD0BD3.4080705@gmail.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=790; t=1254964836; x=1255828836; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Agenda=20call |Sender:=20; bh=/bpi2MhubSODXpmrdfXeqr4zkLjjAcm/t5BUBbT4Im0=; b=DaqRLi8977oBSqBVovYfyHeQa1yx6mwQnUAe+Al4c7DhjSMES3rS7AE5sr o7VzZjsBwYiIyY2eLfi52EV1INHJ1fVcKHFWOVJznV/Ozk/z4JlqFsUTB1vP QFwaZS0lPVEMqJwCIqNA3gzY8LHLSvEHW631cY6V/aDBTZS+EjCE4=; Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: The authors wanted to ask about this at the last IETF meeting, and the discussion around the document told me that it wasn't ready for working group status. Opinions at this point? Does this document represent something the working group wants to take on? On Oct 7, 2009, at 2:44 PM, Brian E Carpenter wrote: > I'm not sure if Sheng is back on line, so let me say > that we want to propose WG adoption of > draft-jiang-v6ops-incremental-cgn-03.txt > > It's been updated according to comments received by > September 25. We could describe those updates in a short > agenda slot. > > Brian > > On 2009-10-08 04:54, Fred Baker wrote: >> We have two sessions scheduled in Hiroshima. This is a call for >> agenda >> items. Who wants time to talk? >> >> From owner-v6ops@ops.ietf.org Wed Oct 7 18:41:46 2009 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 B73C83A687A for ; Wed, 7 Oct 2009 18:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.124 X-Spam-Level: X-Spam-Status: No, score=-105.124 tagged_above=-999 required=5 tests=[AWL=-0.629, 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 2B2xc2sIQ+JV for ; Wed, 7 Oct 2009 18:41:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F9AE3A684E for ; Wed, 7 Oct 2009 18:41:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mvi1i-000MnT-FT for v6ops-data0@psg.com; Thu, 08 Oct 2009 01:42:42 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mvi1Z-000MmX-3Y for v6ops@ops.ietf.org; Thu, 08 Oct 2009 01:42:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=493; q=dns/txt; s=sjiport06001; t=1254966153; x=1256175753; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20|Subject:=20Re: =20Agenda=20call|Date:=20Wed,=207=20Oct=202009=2018:24:03 =20-0700|Message-Id:=20<0F5D3145-AB54-40E2-A3CE-4990B03EE 17C@cisco.com>|To:=20IPv6=20Operations=20|Mime-Version:=201.0=20(Apple=20Message=20framework =20v936)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20; bh=qhh4izTID2WG2YmuSwz5RxMviox54K7ma4fgDceopvE=; b=UITzlBaGTvUN0dtc92wxOUzHPyFhReu9x420XluImyNr057F7Z9h7D73 bpVmUkk7syrfRb9JpmVDC0QihSMaaBV4paasybvip/0jGDyhniwjaT3Xy VM4Kjx3fc6d7t80Sa2ezTwvProkpOjzfG1n43dm44lg1iioGegRYBDwFw c=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=fred@cisco.com Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Oct 2009 01:24:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n981O3Jg009135 for ; Wed, 7 Oct 2009 18:24:03 -0700 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n981O3jT010048 for ; Thu, 8 Oct 2009 01:24:03 GMT Message-Id: <0F5D3145-AB54-40E2-A3CE-4990B03EE17C@cisco.com> From: Fred Baker To: IPv6 Operations In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Agenda call Date: Wed, 7 Oct 2009 18:24:03 -0700 References: X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=493; t=1254965043; x=1255829043; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Agenda=20call |Sender:=20; bh=qhh4izTID2WG2YmuSwz5RxMviox54K7ma4fgDceopvE=; b=lgjVQTS0mCoko+iCYichEKEQ+tZT8Wa+Re19AVPp9p0I3X5ByM3RvEDSei j7lyh2c27QfNs3yUt/mhC+fQmk1rX6yT+EXYk/eY7s+5QyLeyXAXpk7ZLYI7 riGO/DO/5+; Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Oct 7, 2009, at 8:54 AM, Fred Baker wrote: > We have two sessions scheduled in Hiroshima. This is a call for =20 > agenda items. Who wants time to talk? BTW: =95 2009-10-19 (Monday): Internet Draft Cut-off for initial = document =20 (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using the IETF =20 ID Submission Tool. =95 2009-10-26 (Monday): Internet Draft final submission cut-off = by =20 17:00 PDT (24:00 UTC/GMT), upload using the IETF ID Submission Tool. From l.gondloch@aluform-kowary.pl Wed Oct 7 19:33:12 2009 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 2210B3A67B5 for ; Wed, 7 Oct 2009 19:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 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_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 xXPOhTqUUhbk for ; Wed, 7 Oct 2009 19:33:11 -0700 (PDT) Received: from r190-133-133-219.dialup.adsl.anteldata.net.uy (r190-133-132-90.dialup.adsl.anteldata.net.uy [190.133.132.90]) by core3.amsl.com (Postfix) with SMTP id BE9003A6838 for ; Wed, 7 Oct 2009 19:33:02 -0700 (PDT) To: Subject: Order Shipped -- Order #91347 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091008023304.BE9003A6838@core3.amsl.com> Date: Wed, 7 Oct 2009 19:33:02 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.coatfew.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://coatfew.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 3, B745. 262 Clements Road. London. SE84 2DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Thu Oct 8 08:29:16 2009 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 47A573A693E for ; Thu, 8 Oct 2009 08:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=-0.479, 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 5b8hOcJkaexh for ; Thu, 8 Oct 2009 08:29:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A493528C1B7 for ; Thu, 8 Oct 2009 08:29:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mvuqe-000M9x-E3 for v6ops-data0@psg.com; Thu, 08 Oct 2009 15:24:08 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvuqU-000M95-0p for v6ops@ops.ietf.org; Thu, 08 Oct 2009 15:24:05 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n98FNavk013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2009 08:23:36 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n98FNaLt014644; Thu, 8 Oct 2009 08:23:36 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n98FNZkK014640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 8 Oct 2009 08:23:35 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 8 Oct 2009 08:23:35 -0700 From: "Templin, Fred L" To: Fred Baker , IPv6 Operations Date: Thu, 8 Oct 2009 08:23:34 -0700 Subject: RE: Agenda call Thread-Topic: Agenda call Thread-Index: AcpHuWoE+AcniIT0Tf+Blb47v680oAAcXsGg Message-ID: <12F4112206976147A34FEC0277597CCF27A410A337@XCH-NW-15V.nw.nos.boeing.com> References: <4ACD0BD3.4080705@gmail.com> <27A1609E-5988-41DB-A930-2ABB2EE261FB@cisco.com> In-Reply-To: <27A1609E-5988-41DB-A930-2ABB2EE261FB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.600.1016-16888.004 x-tm-as-result: No--65.632000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No 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: > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behal= f Of Fred Baker > Sent: Wednesday, October 07, 2009 6:21 PM > To: IPv6 Operations > Subject: Re: Agenda call >=20 > The authors wanted to ask about this at the last IETF meeting, and the > discussion around the document told me that it wasn't ready for > working group status. >=20 > Opinions at this point? Does this document represent something the > working group wants to take on? I reviewed the document, and IMHO it is stable enough and relevant enough to take on as a wg item. Fred fred.l.templin@boeing.com =20 > On Oct 7, 2009, at 2:44 PM, Brian E Carpenter wrote: >=20 > > I'm not sure if Sheng is back on line, so let me say > > that we want to propose WG adoption of > > draft-jiang-v6ops-incremental-cgn-03.txt > > > > It's been updated according to comments received by > > September 25. We could describe those updates in a short > > agenda slot. > > > > Brian > > > > On 2009-10-08 04:54, Fred Baker wrote: > >> We have two sessions scheduled in Hiroshima. This is a call for > >> agenda > >> items. Who wants time to talk? > >> > >> >=20 From owner-v6ops@ops.ietf.org Thu Oct 8 22:19:14 2009 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 BC5C328C14E for ; Thu, 8 Oct 2009 22:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 wvEOsWqlJe+p for ; Thu, 8 Oct 2009 22:19:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D702F28C0FB for ; Thu, 8 Oct 2009 22:19:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mw7oU-000A1v-QZ for v6ops-data0@psg.com; Fri, 09 Oct 2009 05:14:46 +0000 Received: from [211.151.89.50] (helo=mail.jzland.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mw7oJ-0009xl-O5 for v6ops@ops.ietf.org; Fri, 09 Oct 2009 05:14:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 33DD130B0972; Fri, 9 Oct 2009 13:13:58 +0800 (CST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Oct 9 13:13:58 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4acec69656071273433962 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Eixu1wds-zJ; Fri, 9 Oct 2009 13:13:57 +0800 (CST) Received: from LENOVO (th024190.ip.tsinghua.edu.cn [59.66.24.190]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 1EC9830B096C; Fri, 9 Oct 2009 13:13:57 +0800 (CST) Date: Fri, 9 Oct 2009 13:13:58 +0800 From: "Yong" To: "Templin, Fred L" , "Fred Baker" , "IPv6 Operations" Subject: Re: RE: Agenda call X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20091009051358.33DD130B0972@mail.jzland.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I also agree to accept this I-D as WG document bacause I believe dual-stack or IPv6-only ISP networks should be important parts during the IPv4/IPv6 coexistence. -Yong yong@csnet1.cs.tsinghua.edu.cn ======= 2009-10-08 23:23:34 You wrote ======= >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker >> Sent: Wednesday, October 07, 2009 6:21 PM >> To: IPv6 Operations >> Subject: Re: Agenda call >> >> The authors wanted to ask about this at the last IETF meeting, and the >> discussion around the document told me that it wasn't ready for >> working group status. >> >> Opinions at this point? Does this document represent something the >> working group wants to take on? > >I reviewed the document, and IMHO it is stable enough >and relevant enough to take on as a wg item. > >Fred >fred.l.templin@boeing.com > >> On Oct 7, 2009, at 2:44 PM, Brian E Carpenter wrote: >> >> > I'm not sure if Sheng is back on line, so let me say >> > that we want to propose WG adoption of >> > draft-jiang-v6ops-incremental-cgn-03.txt >> > >> > It's been updated according to comments received by >> > September 25. We could describe those updates in a short >> > agenda slot. >> > >> > Brian >> > >> > On 2009-10-08 04:54, Fred Baker wrote: >> >> We have two sessions scheduled in Hiroshima. This is a call for >> >> agenda >> >> items. Who wants time to talk? >> >> >> >> >> ======================================= Best regards, 13:12:00 2009-10-09 ******************************************************** * Yong Cui * * Ph.D, Department of Computer Science & Technology * * Tsinghua University, Beijing, P.R.China(100084) * * Tel: (8610)-62603059 * * Email: yong@csnet1.cs.tsinghua.edu.cn * ******************************************************** From owner-v6ops@ops.ietf.org Fri Oct 9 11:15:58 2009 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 0C1FF28C1AA for ; Fri, 9 Oct 2009 11:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-1.223, 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 dI1BfOGeI4Mk for ; Fri, 9 Oct 2009 11:15:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05A843A67FC for ; Fri, 9 Oct 2009 11:15:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwJw9-0008rR-Ho for v6ops-data0@psg.com; Fri, 09 Oct 2009 18:11:29 +0000 Received: from [209.85.219.160] (helo=mail-ew0-f160.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwJvy-0008qS-Fk for v6ops@ops.ietf.org; Fri, 09 Oct 2009 18:11:26 +0000 Received: by ewy4 with SMTP id 4so123799ewy.17 for ; Fri, 09 Oct 2009 11:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=33Og7M1/RGaeHuTGrRyD7No+FXt6ByFdawZsQeaotqA=; b=ws5uT1jSgIkpKqgs6GgsY3UtCJMhpZD3xrVs+ZZU+jxLMfvPELlIe7Itw1hwyPXA7l GNY1zIX7qQRbT8Rb74EQBGO8U5hxBGAFGvnL97qG7ZmfNmazozqVg3ofdpzQ8ogQi3Yl 7MWUXEvT+Y7zq3plTDVuy1kqJvD9yX+QzViJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=r7/ZaZVCZIzyud1aTMe5U0TAV+mtmDYOt3vqtaCSnavaS2NRAUI0HGa20PrTMxJKZk UunOW+9AUatPd7uv+Gzl31Ne7qzIzz2gSvfRJyK5zNsPIb1nBVxa3Vr0FpCyw3q7LUN7 yIdY0u4RHAFQaty/aMcFiHZyzz3xYyK25CTD0= Received: by 10.216.88.65 with SMTP id z43mr1010047wee.5.1255111876773; Fri, 09 Oct 2009 11:11:16 -0700 (PDT) Received: from ?192.168.0.174? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id p37sm5612343gvf.24.2009.10.09.11.11.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Oct 2009 11:11:15 -0700 (PDT) Message-ID: <4ACF7CBE.9070200@gont.com.ar> Date: Fri, 09 Oct 2009 15:11:10 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Roque Gagliano Subject: Some comments on draft-ietf-v6ops-v6inixp-03.txt X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hello, Roque, Here's some feedback on the aforementioned I-D. * Editorial * Abstract: > This document provides a guide for IPv6 deployment in Internet s/a guide for/guidance on/ > Exchange Points (IXP). It includes information regarding the switch s/information/advice/ > fabric configuration, the addressing plan and general organizational > tasks to be performed. IXPs are mainly a layer 2 infrastructure and s/to be/that need to be/ > in many case the best recommendations state that the IPv6 data, s/case/cases/ s/state/suggest/ Introduction: > Most Internet Exchange Points (IXP) work on the Layer 2 level, making > the adoption of IPv6 an easy task. s/work on/work at/ I found it hard to parse this sentence: > This document clarifies the impact of IPv6 > on a new or an existing IXP that may or may not fit any particular > deployment. Section 2: > However, some management > functions require explicit IPv6 support (such as switch management, > SNMP support and flow analysis exportation) and this should be > assessed by the IXP operator. Include a (Informative) reference to the SNMP spec. > scenario, participants will typically configure dual stack s/dual stack/dual-stack/ BTW, in this text: > scenario, participants will typically configure dual stack > interfaces, although independent port can be an option. You meant something like "...will typically configure interfaces as dual-stack, although independent interfaces could be possibly used for each version of IP"? > traffic. If IXP participants are already using Virtual LAN > (VLAN) tagging on their routers interfaces that are facing the > IXP switch, Rephrase as "If IXP participants are already using Virtual LAN (VLAN) tagging on those interfaces of their routers that are facing the IXP switch...." > Conversely, the dual stack implementation allows a quick and capital > cost-free start-up for IPv6 support in the IXP, allowing the IXP to s/dual stack/dual-stack/ Maybe s/capital cost-free/inexpensive/ ? P.S.: More in the pipeline! Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-v6ops@ops.ietf.org Fri Oct 9 18:58:26 2009 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 E59773A67A5 for ; Fri, 9 Oct 2009 18:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 x5DRaP-tiurR for ; Fri, 9 Oct 2009 18:58:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A408F3A672E for ; Fri, 9 Oct 2009 18:58:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwRA5-000K4a-MU for v6ops-data0@psg.com; Sat, 10 Oct 2009 01:54:21 +0000 Received: from [209.85.222.198] (helo=mail-pz0-f198.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwR9v-000K3s-EC for v6ops@ops.ietf.org; Sat, 10 Oct 2009 01:54:19 +0000 Received: by pzk36 with SMTP id 36so4598676pzk.5 for ; Fri, 09 Oct 2009 18:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dNQdDowumbfztn5ZooyZjRG/9kyc+w5SCDmG8HuIvJ8=; b=tERvTZhnNt4ad4MkxZTvh7dsOjvthg7m0o2GYUJk9hrmAAmsoWg0R1Gg7AjMDAWyVE qpzrxY5na2qMe0KkVW8bWFHZv5/KLPohOqzKdpEUyfpNxcGfaLCcrrnToytDOHEwzbme rcLGOUS5eSxU6LXesp/+FM+2AemntJsWabGaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BJBwCFZiyFfQ6buvhsWg0b43UzuQmUDOpVzFNYOAiebGo8lJ443+Ir0N8lJusUNb2X nhOxbkSww7xoDVa4QpLFPfli1CY+vs6/3xvtEoaGX04frq0n+6K8UOd5dp8NmswtP7JF kq/XrHd1BwM18aeKivRm8asr6UmrniizpvscU= MIME-Version: 1.0 Received: by 10.142.152.26 with SMTP id z26mr275338wfd.324.1255139650867; Fri, 09 Oct 2009 18:54:10 -0700 (PDT) In-Reply-To: <20091009051358.33DD130B0972@mail.jzland.com> References: <20091009051358.33DD130B0972@mail.jzland.com> Date: Sat, 10 Oct 2009 09:54:10 +0800 Message-ID: <36ba02b00910091854ia395f26v99f47ad4b067691c@mail.gmail.com> Subject: Re: RE: Agenda call From: Chen Gang To: Yong Cc: "Templin, Fred L" , Fred Baker , IPv6 Operations Content-Type: multipart/alternative; boundary=000e0cd2de1208910804758af95f Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --000e0cd2de1208910804758af95f Content-Type: text/plain; charset=ISO-8859-1 CGN is a important approach for IPv6 transition and has numerous use cases in current network deployment. I also think it should be approved as a wg item. Gang chengang@chinamobile.com 2009/10/9 Yong > I also agree to accept this I-D as WG document bacause I believe > dual-stack or IPv6-only ISP networks should be important parts > during the IPv4/IPv6 coexistence. > > > -Yong > yong@csnet1.cs.tsinghua.edu.cn > > > ======= 2009-10-08 23:23:34 You wrote ======= > > >> -----Original Message----- > >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Fred Baker > >> Sent: Wednesday, October 07, 2009 6:21 PM > >> To: IPv6 Operations > >> Subject: Re: Agenda call > >> > >> The authors wanted to ask about this at the last IETF meeting, and the > >> discussion around the document told me that it wasn't ready for > >> working group status. > >> > >> Opinions at this point? Does this document represent something the > >> working group wants to take on? > > > >I reviewed the document, and IMHO it is stable enough > >and relevant enough to take on as a wg item. > > > >Fred > >fred.l.templin@boeing.com > > > >> On Oct 7, 2009, at 2:44 PM, Brian E Carpenter wrote: > >> > >> > I'm not sure if Sheng is back on line, so let me say > >> > that we want to propose WG adoption of > >> > draft-jiang-v6ops-incremental-cgn-03.txt > >> > > >> > It's been updated according to comments received by > >> > September 25. We could describe those updates in a short > >> > agenda slot. > >> > > >> > Brian > >> > > >> > On 2009-10-08 04:54, Fred Baker wrote: > >> >> We have two sessions scheduled in Hiroshima. This is a call for > >> >> agenda > >> >> items. Who wants time to talk? > >> >> > >> >> > >> > > ======================================= > > Best regards, > 13:12:00 2009-10-09 > ******************************************************** > * Yong Cui * > * Ph.D, Department of Computer Science & Technology * > * Tsinghua University, Beijing, P.R.China(100084) * > * Tel: (8610)-62603059 * > * Email: yong@csnet1.cs.tsinghua.edu.cn * > ******************************************************** > > > --000e0cd2de1208910804758af95f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
CGN is a important approach for IPv6 transition=A0and has=A0numerous= =A0use cases in current network deployment. I also think it should be appro= ved as a wg item.=A0
=A0
Gang


=A0
2009/10/9 Yong <yong@csnet1.cs.tsinghua.edu.cn&g= t;
I also agree to accept this I-D = as WG document bacause I believe
dual-stack or IPv6-only ISP networks sh= ould be important parts
during the IPv4/IPv6 coexistence.


-Yong
yong@csnet1.cs.tsinghua.edu.cn


= =3D=3D=3D=3D=3D=3D=3D 2009-10-08 23:23:34 You wrote =3D=3D=3D=3D=3D=3D=3D

>> -----Original Message-----
>> From:= owner-v6ops@ops.ietf.org [= mailto:owner-v6ops@ops.ietf.org= ] On Behalf Of Fred Baker
>> Sent: Wednesday, October 07, 2009 6:21 PM
>> To: IPv6 Ope= rations
>> Subject: Re: Agenda call
>>
>> The au= thors wanted to ask about this at the last IETF meeting, and the
>>= ; discussion around the document told me that it wasn't ready for
>> working group status.
>>
>> Opinions at this poi= nt? Does this document represent something the
>> working group wa= nts to take on?
>
>I reviewed the document, and IMHO it is stab= le enough
>and relevant enough to take on as a wg item.
>
>Fred
>= ;fred.l.templin@boeing.com=
>
>> On Oct 7, 2009, at 2:44 PM, Brian E Carpenter wrote: >>
>> > I'm not sure if Sheng is back on line, so let= me say
>> > that we want to propose WG adoption of
>>= > draft-jiang-v6ops-incremental-cgn-03.txt
>> >
>>= > It's been updated according to comments received by
>> > September 25. We could describe those updates in a short
&= gt;> > agenda slot.
>> >
>> > =A0 Brian
&g= t;> >
>> > On 2009-10-08 04:54, Fred Baker wrote:
>= > >> We have two sessions scheduled in Hiroshima. This is a call f= or
>> >> agenda
>> >> items. Who wants time to talk= ?
>> >>
>> >>
>>

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Best regards,
13:12:00= 2009-10-09
********************************************************
* =A0 =A0Yong Cui =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
* =A0 =A0Ph.D, Department of Comput= er Science & Technology *
* =A0 =A0Tsinghua University, Beijing, P.R= .China(100084) =A0 *
* =A0 =A0Tel: (8610)-62603059 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0*
* =A0 =A0Email: yong@csnet1.cs.tsinghua.edu.cn =A0 =A0 =A0 =A0 =A0 =A0 *
= ********************************************************



--000e0cd2de1208910804758af95f-- From owner-v6ops@ops.ietf.org Fri Oct 9 19:19:50 2009 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 539053A6407 for ; Fri, 9 Oct 2009 19:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjPA33neM7vW for ; Fri, 9 Oct 2009 19:19:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5943A3A679C for ; Fri, 9 Oct 2009 19:19:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwRYM-000LuP-Nz for v6ops-data0@psg.com; Sat, 10 Oct 2009 02:19:26 +0000 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwRYB-000Ltr-Jg for v6ops@ops.ietf.org; Sat, 10 Oct 2009 02:19:23 +0000 Received: from localhost (m4b0536d0.tmodns.net [208.54.5.75]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n9A2J0xO058935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Oct 2009 02:19:04 GMT (envelope-from joelja@bogus.com) Subject: Re: RE: Agenda call From: joel jaeggli Date: Fri, 09 Oct 2009 19:18:44 -0700 To: Chen Gang , Yong CC: "Templin, Fred L" , Fred Baker , IPv6 Operations Message-ID: <36ba02b00910091854ia395f26v99f47ad4b067691c@mail.gmail.com> Content-Type: multipart/mixed; boundary="----1IM20VLBO7GPRRQ43OH87KYYPTO09N" MIME-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sat, 10 Oct 2009 02:19:07 +0000 (UTC) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: ------1IM20VLBO7GPRRQ43OH87KYYPTO09N Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Q0dOIGlzIGxpa2VseSB0byBiZSB1c2VkIHdoZXRoZXIgaXQncyBzdGFuZGFyZGl6ZWQgb3Igbm90 LiBPbmUgbWlnaHQgaW4gZmFjdCBhcmd1ZSB0aGF0IGl0J3MgbW9yZSBsaWtlbHkgdG8gYmUgdXNl ZCBpZiBpdCBpc24ndCBzdGFuZGFyZGl6ZWQuCgpKb2VsCgpDaGVuIEdhbmcgPHBoZGdhbmdAZ21h aWwuY29tPiB3cm90ZToKCj5DR04gaXMgYSBpbXBvcnRhbnQgYXBwcm9hY2ggZm9yIElQdjYgdHJh bnNpdGlvbiBhbmQgaGFzIG51bWVyb3VzIHVzZSBjYXNlcw0KPmluIGN1cnJlbnQgbmV0d29yayBk ZXBsb3ltZW50LiBJIGFsc28gdGhpbmsgaXQgc2hvdWxkIGJlIGFwcHJvdmVkIGFzIGEgd2cNCj5p dGVtLg0KPg0KPkdhbmcNCj5jaGVuZ2FuZ0BjaGluYW1vYmlsZS5jb20NCj4NCj4NCj4NCj4yMDA5 LzEwLzkgWW9uZyA8eW9uZ0Bjc25ldDEuY3MudHNpbmdodWEuZWR1LmNuPg0KPg0KPj4gSSBhbHNv IGFncmVlIHRvIGFjY2VwdCB0aGlzIEktRCBhcyBXRyBkb2N1bWVudCBiYWNhdXNlIEkgYmVsaWV2 ZQ0KPj4gZHVhbC1zdGFjayBvciBJUHY2LW9ubHkgSVNQIG5ldHdvcmtzIHNob3VsZCBiZSBpbXBv cnRhbnQgcGFydHMNCj4+IGR1cmluZyB0aGUgSVB2NC9JUHY2IGNvZXhpc3RlbmNlLg0KPj4NCj4+ DQo+PiAtWW9uZw0KPj4geW9uZ0Bjc25ldDEuY3MudHNpbmdodWEuZWR1LmNuDQo+Pg0KPj4NCj4+ ID09PT09PT0gMjAwOS0xMC0wOCAyMzoyMzozNCBZb3Ugd3JvdGUgPT09PT09PQ0KPj4NCj4+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBvd25lci12Nm9wc0BvcHMu aWV0Zi5vcmcgW21haWx0bzpvd25lci12Nm9wc0BvcHMuaWV0Zi5vcmddIE9uDQo+PiBCZWhhbGYg T2YgRnJlZCBCYWtlcg0KPj4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3LCAyMDA5IDY6 MjEgUE0NCj4+ID4+IFRvOiBJUHY2IE9wZXJhdGlvbnMNCj4+ID4+IFN1YmplY3Q6IFJlOiBBZ2Vu ZGEgY2FsbA0KPj4gPj4NCj4+ID4+IFRoZSBhdXRob3JzIHdhbnRlZCB0byBhc2sgYWJvdXQgdGhp cyBhdCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcsIGFuZCB0aGUNCj4+ID4+IGRpc2N1c3Npb24gYXJv dW5kIHRoZSBkb2N1bWVudCB0b2xkIG1lIHRoYXQgaXQgd2Fzbid0IHJlYWR5IGZvcg0KPj4gPj4g d29ya2luZyBncm91cCBzdGF0dXMuDQo+PiA+Pg0KPj4gPj4gT3BpbmlvbnMgYXQgdGhpcyBwb2lu dD8gRG9lcyB0aGlzIGRvY3VtZW50IHJlcHJlc2VudCBzb21ldGhpbmcgdGhlDQo+PiA+PiB3b3Jr aW5nIGdyb3VwIHdhbnRzIHRvIHRha2Ugb24/DQo+PiA+DQo+PiA+SSByZXZpZXdlZCB0aGUgZG9j dW1lbnQsIGFuZCBJTUhPIGl0IGlzIHN0YWJsZSBlbm91Z2gNCj4+ID5hbmQgcmVsZXZhbnQgZW5v dWdoIHRvIHRha2Ugb24gYXMgYSB3ZyBpdGVtLg0KPj4gPg0KPj4gPkZyZWQNCj4+ID5mcmVkLmwu dGVtcGxpbkBib2VpbmcuY29tDQo+PiA+DQo+PiA+PiBPbiBPY3QgNywgMjAwOSwgYXQgMjo0NCBQ TSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+PiA+Pg0KPj4gPj4gPiBJJ20gbm90IHN1cmUg aWYgU2hlbmcgaXMgYmFjayBvbiBsaW5lLCBzbyBsZXQgbWUgc2F5DQo+PiA+PiA+IHRoYXQgd2Ug d2FudCB0byBwcm9wb3NlIFdHIGFkb3B0aW9uIG9mDQo+PiA+PiA+IGRyYWZ0LWppYW5nLXY2b3Bz LWluY3JlbWVudGFsLWNnbi0wMy50eHQNCj4+ID4+ID4NCj4+ID4+ID4gSXQncyBiZWVuIHVwZGF0 ZWQgYWNjb3JkaW5nIHRvIGNvbW1lbnRzIHJlY2VpdmVkIGJ5DQo+PiA+PiA+IFNlcHRlbWJlciAy NS4gV2UgY291bGQgZGVzY3JpYmUgdGhvc2UgdXBkYXRlcyBpbiBhIHNob3J0DQo+PiA+PiA+IGFn ZW5kYSBzbG90Lg0KPj4gPj4gPg0KPj4gPj4gPiAgIEJyaWFuDQo+PiA+PiA+DQo+PiA+PiA+IE9u IDIwMDktMTAtMDggMDQ6NTQsIEZyZWQgQmFrZXIgd3JvdGU6DQo+PiA+PiA+PiBXZSBoYXZlIHR3 byBzZXNzaW9ucyBzY2hlZHVsZWQgaW4gSGlyb3NoaW1hLiBUaGlzIGlzIGEgY2FsbCBmb3INCj4+ ID4+ID4+IGFnZW5kYQ0KPj4gPj4gPj4gaXRlbXMuIFdobyB3YW50cyB0aW1lIHRvIHRhbGs/DQo+ PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+DQo+Pg0KPj4gPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gMTM6MTI6MDAgMjAwOS0x MC0wOQ0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+ICogICAgWW9uZyBDdWkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAqDQo+PiAqICAgIFBoLkQsIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5j ZSAmIFRlY2hub2xvZ3kgKg0KPj4gKiAgICBUc2luZ2h1YSBVbml2ZXJzaXR5LCBCZWlqaW5nLCBQ LlIuQ2hpbmEoMTAwMDg0KSAgICoNCj4+ICogICAgVGVsOiAoODYxMCktNjI2MDMwNTkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAqDQo+PiAqICAgIEVtYWlsOiB5b25nQGNzbmV0MS5jcy50 c2luZ2h1YS5lZHUuY24gICAgICAgICAgICAgKg0KPj4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+DQo+Pg0KPj4NCg== ------1IM20VLBO7GPRRQ43OH87KYYPTO09N-- From owner-v6ops@ops.ietf.org Fri Oct 9 19:28:08 2009 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 02C7E3A68D6 for ; Fri, 9 Oct 2009 19:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 kjWl9PeT9cmM for ; Fri, 9 Oct 2009 19:28:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEE8D3A6862 for ; Fri, 9 Oct 2009 19:28:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwRhL-000Mcf-1k for v6ops-data0@psg.com; Sat, 10 Oct 2009 02:28:43 +0000 Received: from [209.85.223.178] (helo=mail-iw0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwRh9-000Mbk-TJ for v6ops@ops.ietf.org; Sat, 10 Oct 2009 02:28:39 +0000 Received: by iwn8 with SMTP id 8so4270118iwn.33 for ; Fri, 09 Oct 2009 19:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZUGaWrwEgBL9YesbfTdG0JYDuNDerAa5KbThPIpzHL4=; b=efft3m+sZ9Z+dyUaRwYG/THLWXhPNX+fvaom5a/fshZyF6JPZJtqdQwgbjS1WBM74K 1cGkPpEH4n7VI8ZAs53BLjKmObWJg3LUdZ1CLbuBRDwctUreXtfpe+YlsgjSBJqMMV3N mW6te6wNt968gJehD5OEJcsBqxqfcmmz5TzKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YvV1BxOSZK3dupmDBlNsCZ7BD59Yz5olUON5YIcZm7Ecbp1/A6wtYQrv2RL1XpQseL 373gnWCdKrAqF1jrKuHOJnlXocKJsvBQ/40LQROT//3pmqeEMCcbpMB5LRqTGR9zKU+Q p61DZB7LrxP7CQSOaaoO30hiEcYKqW5D+23XA= MIME-Version: 1.0 Received: by 10.231.122.103 with SMTP id k39mr6740031ibr.10.1255141711060; Fri, 09 Oct 2009 19:28:31 -0700 (PDT) In-Reply-To: <36ba02b00910091854ia395f26v99f47ad4b067691c@mail.gmail.com> References: <20091009051358.33DD130B0972@mail.jzland.com> <36ba02b00910091854ia395f26v99f47ad4b067691c@mail.gmail.com> Date: Sat, 10 Oct 2009 10:28:31 +0800 Message-ID: <36a593230910091928ybd2fd98ke8c329a48a5a9960@mail.gmail.com> Subject: Re: RE: Agenda call From: bo zhou To: Chen Gang Cc: Yong , "Templin, Fred L" , Fred Baker , IPv6 Operations Content-Type: multipart/alternative; boundary=0016e6460848d4aac704758b7374 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0016e6460848d4aac704758b7374 Content-Type: text/plain; charset=ISO-8859-1 I read through the draft, believe the issues that the draft try to sort out are important and relevant enough to be a WG item at moment. Regards, Bo Zhou On Sat, Oct 10, 2009 at 9:54 AM, Chen Gang wrote: > CGN is a important approach for IPv6 transition and has numerous use cases > in current network deployment. I also think it should be approved as a wg > item. > > Gang > chengang@chinamobile.com > > > > 2009/10/9 Yong > > I also agree to accept this I-D as WG document bacause I believe >> dual-stack or IPv6-only ISP networks should be important parts >> during the IPv4/IPv6 coexistence. >> >> >> -Yong >> yong@csnet1.cs.tsinghua.edu.cn >> >> >> ======= 2009-10-08 23:23:34 You wrote ======= >> >> >> -----Original Message----- >> >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >> Behalf Of Fred Baker >> >> Sent: Wednesday, October 07, 2009 6:21 PM >> >> To: IPv6 Operations >> >> Subject: Re: Agenda call >> >> >> >> The authors wanted to ask about this at the last IETF meeting, and the >> >> discussion around the document told me that it wasn't ready for >> >> working group status. >> >> >> >> Opinions at this point? Does this document represent something the >> >> working group wants to take on? >> > >> >I reviewed the document, and IMHO it is stable enough >> >and relevant enough to take on as a wg item. >> > >> >Fred >> >fred.l.templin@boeing.com >> > >> >> On Oct 7, 2009, at 2:44 PM, Brian E Carpenter wrote: >> >> >> >> > I'm not sure if Sheng is back on line, so let me say >> >> > that we want to propose WG adoption of >> >> > draft-jiang-v6ops-incremental-cgn-03.txt >> >> > >> >> > It's been updated according to comments received by >> >> > September 25. We could describe those updates in a short >> >> > agenda slot. >> >> > >> >> > Brian >> >> > >> >> > On 2009-10-08 04:54, Fred Baker wrote: >> >> >> We have two sessions scheduled in Hiroshima. This is a call for >> >> >> agenda >> >> >> items. Who wants time to talk? >> >> >> >> >> >> >> >> >> >> ======================================= >> >> Best regards, >> 13:12:00 2009-10-09 >> ******************************************************** >> * Yong Cui * >> * Ph.D, Department of Computer Science & Technology * >> * Tsinghua University, Beijing, P.R.China(100084) * >> * Tel: (8610)-62603059 * >> * Email: yong@csnet1.cs.tsinghua.edu.cn * >> ******************************************************** >> >> >> > -- Regards, Bo Zhou China Mobile --0016e6460848d4aac704758b7374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I read through the draft, believe the issues that the draft try to sor= t out are important and relevant enough to be a WG item at moment.
=A0
Regards,
=A0
Bo Zhou

On Sat, Oct 10, 2009 at 9:54 AM, Chen Gang <phdgang@gmail.com= > wrote:
CGN is a important approach for IPv6 transition=A0and has=A0numerous= =A0use cases in current network deployment. I also think it should be appro= ved as a wg item.=A0
=A0
Gang


=A0
2009/10/9 Yong <yong@csnet1.cs.tsi= nghua.edu.cn>=20

I also agree to accept this I-D = as WG document bacause I believe
dual-stack or IPv6-only ISP networks sh= ould be important parts
during the IPv4/IPv6 coexistence.


-Yong
yong@csnet1.cs.tsinghua.edu.= cn


=3D=3D=3D=3D=3D=3D=3D 2009-10-08 23:23:34 You wrote =3D= =3D=3D=3D=3D=3D=3D

>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org<= /a> [mailto:o= wner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
>> Sent: Wednesday, October 07, 2009 6:21 PM
>> To: IPv6 Ope= rations
>> Subject: Re: Agenda call
>>
>> The au= thors wanted to ask about this at the last IETF meeting, and the
>>= ; discussion around the document told me that it wasn't ready for
>> working group status.
>>
>> Opinions at this poi= nt? Does this document represent something the
>> working group wa= nts to take on?
>
>I reviewed the document, and IMHO it is stab= le enough
>and relevant enough to take on as a wg item.
>
>Fred
>= ;fred.l.temp= lin@boeing.com
>
>> On Oct 7, 2009, at 2:44 PM, Brian E = Carpenter wrote:
>>
>> > I'm not sure if Sheng is back on line, so let= me say
>> > that we want to propose WG adoption of
>>= > draft-jiang-v6ops-incremental-cgn-03.txt
>> >
>>= > It's been updated according to comments received by
>> > September 25. We could describe those updates in a short
&= gt;> > agenda slot.
>> >
>> > =A0 Brian
&g= t;> >
>> > On 2009-10-08 04:54, Fred Baker wrote:
>= > >> We have two sessions scheduled in Hiroshima. This is a call f= or
>> >> agenda
>> >> items. Who wants time to talk= ?
>> >>
>> >>
>>

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Best regards,
13:12:00= 2009-10-09
********************************************************
* =A0 =A0Yong Cui =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
* =A0 =A0Ph.D, Department of Comput= er Science & Technology *
* =A0 =A0Tsinghua University, Beijing, P.R= .China(100084) =A0 *
* =A0 =A0Tel: (8610)-62603059 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0*
* =A0 =A0Email: yong@csnet1.cs.tsinghua.edu.cn =A0 =A0 =A0= =A0 =A0 =A0 *
********************************************************<= br>




--
Regards,

Bo Zhou
China Mobile
--0016e6460848d4aac704758b7374-- From owner-v6ops@ops.ietf.org Sat Oct 10 02:20:16 2009 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 CC38628C0E4 for ; Sat, 10 Oct 2009 02:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.716 X-Spam-Level: ** X-Spam-Status: No, score=2.716 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_40=-0.185, 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 LMLTC9GjgMFW for ; Sat, 10 Oct 2009 02:20:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6C2B28C0E8 for ; Sat, 10 Oct 2009 02:20:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwY3J-000Pse-Cf for v6ops-data0@psg.com; Sat, 10 Oct 2009 09:15:49 +0000 Received: from [211.151.89.50] (helo=mail.jzland.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwY39-000Prn-1L for v6ops@ops.ietf.org; Sat, 10 Oct 2009 09:15:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 2460F30B0973; Sat, 10 Oct 2009 17:15:32 +0800 (CST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Oct 10 17:15:31 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4ad050b356071739215297 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go8+27XWj48A; Sat, 10 Oct 2009 17:15:30 +0800 (CST) Received: from LENOVO (th024190.ip.tsinghua.edu.cn [59.66.24.190]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 4F8AC30B096C; Sat, 10 Oct 2009 17:15:30 +0800 (CST) Date: Sat, 10 Oct 2009 17:15:32 +0800 From: "Yong" To: "Fred Baker" , "IPv6 Operations" Cc: "xing" , "jianping" , "slwang" , "xmw" Subject: Re: Agenda call X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20091010091532.2460F30B0973@mail.jzland.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, Fred, We need a slot of 15min to present the I-D: draft-cui-softwire-pet-00. Although this I-D currently is in Softwire WG, we analyze the combination of tunnels and translations in this document, e.g. how or where to use them. The suggestion or comment from v6ops are very important to improve this I-D. By the way, we are also deploying the PET boxes. So we hope to share some basic ideas in v6ops. Thanks, -Yong yong@csnet1.cs.tsinghua.edu.cn ======= 2009-10-07 23:54:28 You wrote ======= >We have two sessions scheduled in Hiroshima. This is a call for agenda >items. Who wants time to talk? > ======================================= Best regards, 13:14:13 2009-10-09 ******************************************************** * Yong Cui * * Ph.D, Department of Computer Science & Technology * * Tsinghua University, Beijing, P.R.China(100084) * * Tel: (8610)-62603059 * * Email: yong@csnet1.cs.tsinghua.edu.cn * ******************************************************** From nielsen@aegislimited.com Sat Oct 10 04:37:12 2009 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 A48863A68AB for ; Sat, 10 Oct 2009 04:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, GB_I_LETTER=-2, HELO_DYNAMIC_SPLIT_IP=3.493, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_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_RHS_DOB=1.083, 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 DQZEMlbKIgWP for ; Sat, 10 Oct 2009 04:37:11 -0700 (PDT) Received: from 119.Red-217-126-69.staticIP.rima-tde.net (119.Red-217-126-69.staticIP.rima-tde.net [217.126.69.119]) by core3.amsl.com (Postfix) with SMTP id EBBD03A67D7 for ; Sat, 10 Oct 2009 04:37:06 -0700 (PDT) To: Subject: Email Handling Opinion Needed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091010113707.EBBD03A67D7@core3.amsl.com> Date: Sat, 10 Oct 2009 04:37:06 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.heatthank.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://heatthank.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 0, B452. 960 Clements Road. London. SE92 8DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Sat Oct 10 10:12:42 2009 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 8F1873A6988 for ; Sat, 10 Oct 2009 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTpmcMuKZ7mA for ; Sat, 10 Oct 2009 10:12:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 558C73A6993 for ; Sat, 10 Oct 2009 10:12:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwfRL-000K9x-Dg for v6ops-data0@psg.com; Sat, 10 Oct 2009 17:09:07 +0000 Received: from web45503.mail.sp1.yahoo.com ([68.180.197.71]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwfR8-000K8p-Ta for v6ops@ops.ietf.org; Sat, 10 Oct 2009 17:09:04 +0000 Received: (qmail 59492 invoked by uid 60001); 10 Oct 2009 17:08:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1255194533; bh=K3MbOiGmx9tO9l1mdjmPpXyPV+jDrlWS1oQTccqlyAM=; 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=bxQ6Bdum9FIW1hXOB/oH47Kx2tvDhZt4RPQfBZlpqnyP8LdZvczd5zzBXOCOH9x8LHtmQI1A119VGLoQPPxqUP8e2NE6323Hd/6BKcYkoaZPjY89HeWUfGrCQ1jUOrmK/S/7y+ZIR1I07GSd6cBQrIZvRHX1NzjTNk2poHSh3HI= 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=Qs5gCAVObwAjDdAyvKZfK5QVuORi/CMw+2rw12ttU74fhCUzG5SyahiCyuabDahJbKTVjaefcbZuTWxkYEngfLnWPqsQCN0jRRCf4d+0ixMSXvmN8u9q6R2cM+FtW/mQzGBQ9QbEPdB/nZemmmmQvwvLThZe+p5a9OxMrahdHyo=; Message-ID: <560047.58497.qm@web45503.mail.sp1.yahoo.com> X-YMail-OSG: VJ3w8_kVM1nVoZ8u.moM7IEhI_A.es7Rzuiwef0hcgu6l78iVRCmPqny3crLmcBmRAkcSstO5zwLb6KpPjxwlYZThfp27dJZryweWdAHjxyciVVqNR7KhmvHop0iTYC4xSPOG5KW2bKGSawTVfWOpk_Xrl9las1jJzvRyvmE5mlETURQKT0CrtWQPtlmSutX3f9dFGIhSdCt9HSXeti6XeGyyVSBQ3xnHU19fHwFUwDwpxJE4UrhL_r_izyLDFW0Ms_91ytxd7Ib50Xi8AcP_wHcql4t Received: from [89.138.46.188] by web45503.mail.sp1.yahoo.com via HTTP; Sat, 10 Oct 2009 10:08:53 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeplo y .ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com> <309242.20809.qm@web45513.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com> <841274.31511.qm@web45507.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A41094D6@XCH-NW-15V.nw.nos. boeing.com> !<339077.93936.q!m@web45512.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109B14@XCH-NW-15V.nw.nos.boeing.com> <866685.67299.qm@web45511.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A4109BA8@XCH-NW-15V.nw.nos.boeing.com> <908783.41273.qm@web45509.mail.sp1.yahoo.com> <12F4112206976147A34FEC0277597CCF27A410A0A9@XCH-NW-15V.nw.nos.boeing.com> Date: Sat, 10 Oct 2009 10:08:53 -0700 (PDT) From: Gabi Nakibly Subject: Re: Routing loop attacks using IPv6 tunnels To: "Templin, Fred L" Cc: v6ops In-Reply-To: <12F4112206976147A34FEC0277597CCF27A410A0A9@XCH-NW-15V.nw.nos.boeing.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=A0guess the best way to document those checks is by an I-D that m= ay eventually update RFC 5214. =0A=0AGabi=0A=0A=0A=A0=0A----- Original Mess= age ----=0A> From: "Templin, Fred L" =0A> To: Ga= bi Nakibly =0A> Cc: v6ops =0A> Sent= : Wed, October 7, 2009 7:42:07 PM=0A> Subject: RE: Routing loop attacks usi= ng IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> > -----Original Message-----=0A> > = From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Wednesday, Octob= er 07, 2009 10:16 AM=0A> > To: Templin, Fred L=0A> > Cc: v6ops=0A> > Subjec= t: Re: Routing loop attacks using IPv6 tunnels=0A> >=0A> > Fred,=0A> > I be= lieve the problem you are trying to address (link partitioning with two or = =0A> more same-prefix=0A> > routers) is not specific to ISATAP links. Any l= ink may suffer from this =0A> problem (with smaller=0A> > probability, perh= aps).=0A> =0A> Right. At any time, an operator might unplug a cable, a back= hoe=0A> might dig up a wiring conduit, a piece of networking gear might=0A>= fail, etc., etc.=0A> =0A> > As I see it, if this issue was not addressed u= p until now for IPv6 in general,=0A> > then we should not try to cope with = it specifically in ISATAP using special =0A> mechanisms or=0A> > restrictio= ns.=0A> =0A> In general I agree, but as ISATAP may be applied to a wide=0A>= variety of use cases perhaps there would be a separate=0A> study to be inv= estigated in a specific use case analysis.=0A> But I can agree that that wo= uld be out of scope wrt what=0A> we are discussing here.=0A> =0A> > I think= the best way to move forward is to go ahead with the three types of =0A> c= hecks you described a=0A> > few weeks ago.=0A> =0A> How shall we document t= his?=0A> =0A> Thanks - Fred=0A> fred.l.templin@boeing.com=0A> =0A> > Gabi= =0A> >=0A> > ----- Original Message ----=0A> > > From: "Templin, Fred L" = =0A> > > To: Gabi Nakibly =0A> > > Cc: v6ops =0A> > > Sent: Mon, October 5,= 2009 4:50:31 PM=0A> > > Subject: RE: Routing loop attacks using IPv6 tunne= ls=0A> > >=0A> > > Gabi,=0A> > >=0A> > > > -----Original Message-----=0A> >= > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Sent: Monday,= October 05, 2009 2:24 PM=0A> > > > To: Templin, Fred L=0A> > > > Cc: v6ops= =0A> > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > >= =0A> > > > On first thought, setting up a synchronization mechanism of the = neighbor=0A> > > caches at the routers does=0A> > > > not sound, IMHO, like= the best solution. It will probably add complexity =0A> and=0A> > > interd= ependence to the=0A> > > > routers' functionality.=0A> > > > Maybe a good t= rade-off would be to first require a host to send an initial =0A> RS=0A> > = > to every router in the=0A> > > > PRL. Then after the host learns the adve= rtised prefix of each router the =0A> host=0A> > > should continue sending= =0A> > > > RSs (or stop sending) to all routers advertising the same prefix= .=0A> > >=0A> > > I understand what you're saying, but here's the temptatio= n.=0A> > > Lets say that ISATAP routers A and B both advertise prefix=0A> >= > P::/64, then the ISATAP site partitions and the only way=0A> > > A and B= can still talk to each other is via the provider=0A> > > network. The temp= tation part is that if A and B talk to=0A> > > each other over the provider= network then they can keep=0A> > > track of the ISATAP hosts in each parti= tion that configure=0A> > > an address from P::/64 and seemingly can "heal"= the=0A> > > partition by forwarding misdirected packets to each other=0A> = > > across the provider network. But then, we are guilty of=0A> > > "conspi= racy to create a multilink subnet" (see RFC4903=0A> > > for multi-link subn= et issues).=0A> > >=0A> > > This suggests that, if multiple ISATAP routers = are to=0A> > > advertise a shared prefix P::/64, then there either needs=0A= > > > to be strong assurance that the site won't partition. If=0A> > > that= condition cannot be met, then each ISATAP router must=0A> > > advertise a = distinct prefix. Do you see any other way?=0A> > >=0A> > > Fred=0A> > > fre= d.l.templin@boeing.com=0A> > >=0A> > > > ----- Original Message ----=0A> > = > > > From: "Templin, Fred L"=0A> > > > > To: Gabi Nakibly=0A> > > > > Cc: = v6ops=0A> > > > > Sent: Mon, October 5, 2009 10:41:16 PM=0A> > > > > Subjec= t: RE: Routing loop attacks using IPv6 tunnels=0A> > > > >=0A> > > > > Gabi= ,=0A> > > > >=0A> > > > > > -----Original Message-----=0A> > > > > > From: = Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > > > Sent: Monday, Octobe= r 05, 2009 1:32 PM=0A> > > > > > To: Templin, Fred L=0A> > > > > > Cc: v6op= s=0A> > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > = > > > >=0A> > > > > > Fred,=0A> > > > > > With regrad to your comment below= : if indeed an ISATAP router will not=0A> > > > > forward packets to an=0A>= > > > > > ISATAP host it has not recently received RS from, then I think t= hat =0A> the=0A> > > ISATAP=0A> > > > > specification=0A> > > > > > should = at least require an ISATAP host (using a SHOULD) to regularly =0A> send=0A>= > > RSs=0A> > > > > to _all_ routers in the=0A> > > > > > PRL, or else ISA= TAP connectivity may be broken.=0A> > > > >=0A> > > > > Yes, "ping them all= " is certainly one way to ensure a nbr=0A> > > > > cache entry at each PRL = router. I was also starting to=0A> > > > > think that another solution woul= d be for PRL routers that=0A> > > > > advertise a shared IP prefx (e.g., 20= 01:DB8::/64) to=0A> > > > > somehow synchronize their neighbor caches. For = that=0A> > > > > matter, it might be best to do both because you can=0A> > = > > > never tell which subset of the PRLs is the correct=0A> > > > > subset= to ping.=0A> > > > >=0A> > > > > Fred=0A> > > > > fred.l.templin@boeing.co= m=0A> > > > >=0A> > > > > > Gabi=0A> > > > > >=0A> > > > > > ----- Original= Message ----=0A> > > > > > > From: "Templin, Fred L"=0A> > > > > > > To: G= abi Nakibly=0A> > > > > > > Cc: v6ops=0A> > > > > > > Sent: Thu, October 1,= 2009 6:49:31 PM=0A> > > > > > > Subject: RE: Routing loop attacks using IP= v6 tunnels=0A> > > > > > >=0A> > > > > > > Hi Gabi,=0A> > > > > > >=0A> > >= > > > > > -----Original Message-----=0A> > > > > > > > From: Gabi Nakibly = [mailto:gnakibly@yahoo.com]=0A> > > > > > > > Sent: Thursday, October 01, 2= 009 6:53 AM=0A> > > > > > > > To: Templin, Fred L=0A> > > > > > > > Cc: v6o= ps=0A> > > > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels= =0A> > > > > > > >=0A> > > > > > > > Removed the 6man and secdir mailing li= sts from the Cc.=0A> > > > > > > >=0A> > > > > > > > Fred, see comments bel= ow.=0A> > > > > > > >=0A> > > > > > > > ----- Original Message ----=0A> > >= > > > > > > From: "Templin, Fred L"=0A> > > > > > > > > To: Gabi Nakibly ;= Christian Huitema=0A> > > > > > > ; v6ops=0A> > > > > > > >=0A> > > > > > = > > > Cc: "ipv6@ietf.org" ; "secdir@ietf.org"=0A> > > > > > > > > Sent: Tue= sday, September 29, 2009 6:00:55 PM=0A> > > > > > > > > Subject: RE: Routin= g loop attacks using IPv6 tunnels=0A> > > > > > > > >=0A> > > > > > > > > G= abi,=0A> > > > > > > > >=0A> > > > > > > > > Welcome back from your vacatio= n. I trimmed quite a bit from=0A> > > > > > > > > the bottom of this messag= e to eliminate the clutter, but see=0A> > > > > > > > > below for responses= to your current comments:=0A> > > > > > > > >=0A> > > > > > > > > > -----O= riginal Message-----=0A> > > > > > > > > > From: Gabi Nakibly [mailto:gnaki= bly@yahoo.com]=0A> > > > > > > > > > Sent: Tuesday, September 29, 2009 3:22= AM=0A> > > > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops=0A>= > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > > > >= Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > > > > > >= =0A> > > > > > > > > > Hi Fred,=0A> > > > > > > > > > Back from vacation. S= ee Comments inlines.=0A> > > > > > > > > >=0A> > > > > > > > > > Gabi=0A> >= > > > > > > > >=0A> > > > > > > > > >=0A> > > > > > > > > >=0A> > > > > > = > > > > ----- Original Message ----=0A> > > > > > > > > > > From: "Templin,= Fred L"=0A> > > > > > > > > > > To: Gabi Nakibly ; Christian Huitema=0A> >= > > > > > > > ; v6ops=0A> > > > > > > > > >=0A> > > > > > > > > > > Cc: ip= v6@ietf.org; secdir@ietf.org=0A> > > > > > > > > > > Sent: Friday, Septembe= r 11, 2009 11:13:44 PM=0A> > > > > > > > > > > Subject: RE: Routing loop at= tacks using IPv6 tunnels=0A> > > > > > > > > > >=0A> > > > > > > > > > > Hi= Gabi,=0A> > > > > > > > > > >=0A> > > > > > > > > > > > -----Original Mess= age-----=0A> > > > > > > > > > > > From: Gabi Nakibly [mailto:gnakibly@yaho= o.com]=0A> > > > > > > > > > > > Sent: Friday, September 11, 2009 12:59 PM= =0A> > > > > > > > > > > > To: Templin, Fred L; Christian Huitema; v6ops=0A= > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > > > > = > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> > > > > = > > > > > > >=0A> > > > > > > > > > > > Hi Fred,=0A> > > > > > > > > > > > = See below.=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > Gabi=0A> > >= > > > > > > > > >=0A> > > > > > > > > > > >=0A> > > > > > > > > > > >=0A> = > > > > > > > > > > > ----- Original Message ----=0A> > > > > > > > > > > >= > From: "Templin, Fred L"=0A> > > > > > > > > > > > > To: Gabi Nakibly ; C= hristian Huitema=0A> > > > > > > > > > > ; v6ops=0A> > > > > > > > > > > >= =0A> > > > > > > > > > > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > >= > > > > > > > > Sent: Tuesday, September 8, 2009 8:37:03 PM=0A> > > > > > = > > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > = > > > > > > > > > >=0A> > > > > > > > > > > > > Gabi and Christian,=0A> > >= > > > > > > > > > >=0A> > > > > > > > > > > > > Focusing only on attack #3= (i.e., leaving out attack #1=0A> > > > > > > > > > > > > and #2 6to4 inter= actions for the moment), please check=0A> > > > > > > > > > > > > the follo= wing summary of proposed mitigations:=0A> > > > > > > > > > > > >=0A> > > >= > > > > > > > > > 1) For ISATAP/VET routers that have assurance that their= =0A> > > > > > > > > > > > > neighbor cache is coherent, the router can mak= e a simple=0A> > > > > > > > > > > > > check in the neighbor cache to deter= mine whether to=0A> > > > > > > > > > > > > forward or drop the packet. In = pseudo-code:=0A> > > > > > > > > > > > >=0A> > > > > > > > > > > > >=A0 isa= tap_rcv() {=0A> > > > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > > = > >=A0 =A0 if ((v6src is not a neighbor) && (v6dst !=3D =0A> "fe80::*"))=0A= > > > > > > > > > > > > >=A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > > > > = >=A0 =A0 ...=0A> > > > > > > > > > > > >=A0 }=0A> > > > > > > > > > > > >= =0A> > > > > > > > > > > > >=A0 isatap_xmt() {=0A> > > > > > > > > > > > >= =A0 =A0 ...=0A> > > > > > > > > > > > >=A0 =A0 if ((v6dst is not a neighbor= ) && (v6src !=3D =0A> "fe80::*"))=0A> > > > > > > > > > > > >=A0 =A0 =A0 dr= op_pkt();=0A> > > > > > > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > > > = >=A0 }=0A> > > > > > > > > > > > >=0A> > > > > > > > > > > > > (Here, the l= ink-local exception is necessary to =0A> bootstrap=0A> > > > > > > > > > > = > > neighbor discovery on the ISATAP link.)=0A> > > > > > > > > > > > >=0A>= > > > > > > > > > > > > Does anyone see a problem with this?=0A> > > > > >= > > > > > > >=0A> > > > > > > > > > > > Looks fine.=0A> > > > > > > > > > = >=0A> > > > > > > > > > > OK.=0A> > > > > > > > > > >=0A> > > > > > > > > >= =0A> > > > > > > > > > On second thought, a couple of comments:=0A> > > > >= > > > > > 1) According to RFC 5214 Section 8.3.4:=0A> > > > > > > > > >=A0= =A0 =A0 =A0 " ISATAP nodes MAY schedule periodic Router =0A> Solicitation= =0A> > > events=0A> > > > > > > > > >=A0 =A0 =A0 =A0 for certain PRL(i)s by= setting the corresponding =0A> TIMER(i)."=0A> > > > > > > > > > As I under= stand, this means that there is a possibility for a =0A> host=0A> > > not= =0A> > > > > > > to send=0A> > > > > > > > > RSs to all routers in=0A> > > = > > > > > > > the PRL. However, any router in the PRL may forward packets = =0A> into=0A> > > the=0A> > > > > > > ISATAP=0A> > > > > > > > > link. The = isatap_xmt()=0A> > > > > > > > > > check will prevent forwarding packets by= routers which the=0A> > > > > destination has=0A> > > > > > > not=0A> > > = > > > > > > previously sent RS to.=0A> > > > > > > > > > If I am correct th= en this check may break ISATAP connectivity.=0A> > > > > > > > >=0A> > > > = > > > > > I don't think this is a problem. If a host has not sent an RS to= =0A> > > > > > > > > a PRL router, then it should not have configured a def= ault route=0A> > > > > > > > > nor any prefix information specific to that = router. Therefore,=0A> > > > > > > > > the only packets the host and router= should expect to exchange=0A> > > > > > > > > in this state are link-local= . As such, the router can discard=0A> > > > > > > > > non-link-local packet= s if there is no neighbor cache entry.=0A> > > > > > > > >=0A> > > > > > > = >=0A> > > > > > > > I was thinking of a case of two routers in the PRL adve= rtising the=0A> > > same=0A> > > > > prefix=0A> > > > > > > for the ISATAP= =0A> > > > > > > > link. Either routers obviously may forward packets _into= _ the =0A> ISATAP=0A> > > link=0A> > > > > to=0A> > > > > > > any host. If = a host will=0A> > > > > > > > not send a RS to one of those routers then it= will drop packets=0A> > > destined=0A> > > > > to=0A> > > > > > > that hos= t.=0A> > > > > > >=0A> > > > > > > I'm actually OK with that. If two router= s A and B advertise=0A> > > > > > > the same prefix P, and if B doesn't kno= w about host H either=0A> > > > > > > through receiving RSs or through talk= ing to A, then B should=0A> > > > > > > not forward packets to H.=0A> > > >= > > >=0A> > > > > > > Thanks - Fred=0A> > > > > > > fred.l.templin@boeing.= com=0A> > > > > > >=0A> > > > > > > > > > 2) I remind you a comment you mad= e in the past: for the checks =0A> to=0A> > > > > work the=0A> > > > > > > = > > time between two=0A> > > > > > > > > > consequtive RSs from a host to a= router should be no greater =0A> than=0A> > > the=0A> > > > > the=0A> > > = > > > > > > lifetime of an entry for=0A> > > > > > > > > > that host in the= router's neighbors cache. This is needed to=0A> > > ensure=0A> > > > > > >= that the=0A> > > > > > > > > entry in the neighbors=0A> > > > > > > > > > = cache will not be erased. This raises two questions:=0A> > > > > > > > > >= =A0 =A0 a) AFAIK there is no minimum lifetime for an entry in a=0A> > > nei= ghbors=0A> > > > > > > cache=0A> > > > > > > > > - it is an implementation= =0A> > > > > > > > > > detail. If this is true how can we enforce the above= =0A> constraint?=0A> > > > > > > > >=0A> > > > > > > > > Correct that ther= e is no minimum lifetime for neighbor cache=0A> > > > > > > > > entries spe= cified by RFC4861. However, an ISATAP router that=0A> > > > > > > > > uses = the neighbor cache checking procedures I have described=0A> > > > > > > > >= can use its own discipline for managing its neighbor cache.=0A> > > > > > = > > > Exactly such a discipline is now specified in Section 5.4.1=0A> > > >= > > > > > of 'draft-templin-intarea-vet'. Please be aware that ISATAP=0A> = > > > > > > > > and VET are simply "IPv6-over-(foo)" specifications, and=0A= > > > > > > > > > RFC4861 permits that operations of the neighbor discovery= =0A> > > > > > > > > protocol that are specific to (foo) links may be speci= fied=0A> > > > > > > > > in such documents.=0A> > > > > > > > >=0A> > > > >= > > >=0A> > > > > > > > OK.=0A> > > > > > > >=0A> > > > > > > > > >=A0 =A0= b) A router's neighbors cache must now include at any given=0A> > > moment= =0A> > > > > all=0A> > > > > > > the=0A> > > > > > > > > active ISATAP node= s in=0A> > > > > > > > > > the ISATAP link. Is this a reasonable demand?=0A= > > > > > > > > >=0A> > > > > > > > > Memory should be cheap enough, and IS= ATAP links within private=0A> > > > > > > > > addressing realms should be s= mall enough, that I do not see this=0A> > > > > > > > > as an unreasonable = demand.=0A> > > > > > > > >=0A> > > > > > > >=0A> > > > > > > > OK.=0A> > >= > > > > >=0A> > > > > > > > > > > > > 2) For ISATAP/VET routers that use p= ublic IPv4 addresses=0A> > > > > > > > > > > > > and that do not have assur= ance that their neighbor cache=0A> > > > > > > > > > > > > is coherent, the= router can check for the interface ID=0A> > > > > > > > > > > > > "0200:5E= FE:". In pseudo-code:=0A> > > > > > > > > > > > >=0A> > > > > > > > > > > >= >=A0 isatap_rcv() {=0A> > > > > > > > > > > > >=A0 =A0 ...=0A> > > > > > >= > > > > > >=A0 =A0 if (v6dst =3D=3D "foreign_prefix::0200:5efe:")=0A> > > = > > > > > > > > > >=A0 =A0 =A0 drop_pkt();=0A> > > > > > > > > > > > >=A0 = =A0 ...=0A> > > > > > > > > > > > >=A0 }=0A> > > > > > > > > > > > >=0A> > = > > > > > > > > > > >=A0 isatap_xmt() {=0A> > > > > > > > > > > > >=A0 =A0 = ...=0A> > > > > > > > > > > > >=A0 =A0 if (v6src =3D=3D "foreign_prefix::02= 00:5efe:")=0A> > > > > > > > > > > > >=A0 =A0 =A0 drop_pkt();=0A> > > > > >= > > > > > > >=A0 =A0 ...=0A> > > > > > > > > > > > >=A0 }=0A> > > > > > > = > > > > > >=0A> > > > > > > > > > > > > Does anyone see a problem with this= ?=0A> > > > > > > > > > > >=0A> > > > > > > > > > > > Looks fine.=0A> > > >= > > > > > > >=0A> > > > > > > > > > > OK, but since I sent this I began to= wonder whether cases=0A> > > > > > > > > > > 1) and 2) should be reversed = (i.e., do the 0x00:5EFE check=0A> > > > > > > > > > > first). I came to bel= ieve that it almost doesn't matter=0A> > > > > > > > > > > from a performan= ce standpoint, and perhaps should be left=0A> > > > > > > > > > > up to the= implementer. Do you have an opinion on this?=0A> > > > > > > > > > >=0A> >= > > > > > > > > > > > 3) For ISATAP/VET routers that use private IPv4 =0A>= addresses=0A> > > > > > > > > > > > > and that do not have assurance that = their neighbor cache=0A> > > > > > > > > > > > > is coherent, the router ca= n make the checks that =0A> Christian=0A> > > > > > > > > > > > > has propo= sed. But, will we see any of these case 3)=0A> > > > > > > > > > > > > situ= ations in operational practice?=0A> > > > > > > > > > > > >=0A> > > > > > >= > > > > >=0A> > > > > > > > > > > > I can not tell for sure. Why this case= seems to you less=0A> > > plausible=0A> > > > > > > than=0A> > > > > > > >= > case=0A> > > > > > > > > > > 2?=0A> > > > > > > > > > >=0A> > > > > > > = > > > > Case 3) is the case in which source address spoofing within=0A> > >= > > > > > > > > a private IPv4 addressing range is possible. It seems to m= e=0A> > > > > > > > > > > that it may correspond to either a poorly managed= =0A> deployment,=0A> > > > > > > > > > > or one in which there are multipl= e administrative =0A> authorities=0A> > > > > > > > > > > with diverse poli= cies and operational practices.=0A> > > > > > > > > > >=0A> > > > > > > > >= >=0A> > > > > > > > > > I agree. However, remember that the spoofed packet= may also=0A> > > originate=0A> > > > > from=0A> > > > > > > > > within the= site, which is=0A> > > > > > > > > > very hard to defend against.=0A> > > = > > > > > >=0A> > > > > > > > > Spoofing is not so hard to defend against i= f Secure Neighbor=0A> > > > > > > > > Discovery (SEND) is used to set up th= e neighbor relationships=0A> > > > > > > > > and if every packet carries a = nonce that can be used to detect=0A> > > > > > > > > an off-path attack.=0A= > > > > > > > >=0A> > > > > > > > I agree again. I was referring to the cas= e where SEND is not =0A> deployed.=0A> > > > > > > >=0A> > > > > > > > > Th= at is only the case for VET and SEAL,=0A> > > > > > > > > however, so if so= urce address spoofing within the site is seen=0A> > > > > > > > > as a prob= lem then VET and SEAL should be used instead of ISATAP.=0A> > > > > > > > >= =0A> > > > > > > > > Note that for the sake of consistency it might be help= ful to=0A> > > > > > > > > consider VET as simply "ISATAP version 2 (ISATAP= v2)".=0A> > > > > > > > >=0A> > > > > > > > > Fred=0A> > > > > > > > > fred= .l.templin@boeing.com=0A> > > > > > > > >=0A> > > > > > > > > > > The check= s that Christian proposed could be used for this=0A> > > > > > > > > > > sc= enario if possible. Otherwise, the best solution IMHO=0A> > > > > > > > > >= > would be to allow only routers (and not hosts) on the=0A> > > > > > > > = > > > virtual links. This final model would be best addressed=0A> > > > > >= > > > > > by VET and SEAL rather than ISATAP.=0A> > > > > > > > > > >=0A> = > > > > > > > > > > Thanks - Fred=0A> > > > > > > > > > > fred.l.templin@bo= eing.com=0A> > > > > > > >=0A> > > > > > > > ______________________________= ____________________=0A> > > > > > > > Do You Yahoo!?=0A> > > > > > > > Tir= ed of spam?=A0 Yahoo! Mail has the best spam protection around=0A> > > > > = > > > http://mail.yahoo.com=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> >= > > > >=0A> > > >=0A> > > >=0A> > > >=0A> > > >=0A> >=0A> >=0A> >=0A> >=0A= =0A=0A=0A From kevan455@accumeasure.net Sat Oct 10 12:49:51 2009 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 DF6253A6819 for ; Sat, 10 Oct 2009 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.478 X-Spam-Level: X-Spam-Status: No, score=-21.478 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_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_OB_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 7L4-hIqrYrHK for ; Sat, 10 Oct 2009 12:49:51 -0700 (PDT) Received: from alinga.newcastle.edu.au (unknown [122.162.134.63]) by core3.amsl.com (Postfix) with SMTP id C0B953A67FC for ; Sat, 10 Oct 2009 12:49:44 -0700 (PDT) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091010194946.C0B953A67FC@core3.amsl.com> Date: Sat, 10 Oct 2009 12:49:44 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.dreamglad.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://dreamglad.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 4, B614. 247 Clements Road. London. SE10 8DG

© 2009 AMAZON, Ltd. All Rights Reserved

From v6ov@bakernet.com Sun Oct 11 00:20:33 2009 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 0B5BC3A6811 for ; Sun, 11 Oct 2009 00:20:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 VIAGRA \256 Offic[...] X-Spam-Flag: NO X-Spam-Score: -23.468 X-Spam-Level: X-Spam-Status: No, score=-23.468 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FAKE_HELO_MAIL_COM=1.317, FAKE_HELO_MAIL_COM_DOM=3.199, FB_GET_MEDS=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_QUAL_MEDS=3.568, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZSLCPDizn2Q for ; Sun, 11 Oct 2009 00:20:32 -0700 (PDT) Received: from mx54.mail.com (163-202-124-91.pool.ukrtel.net [91.124.202.163]) by core3.amsl.com (Postfix) with SMTP id 297EF3A67FF for ; Sun, 11 Oct 2009 00:20:30 -0700 (PDT) From: © VIAGRA ® Official Subject: Dear v6ops-archive@lists.ietf.org 86% 0FF on Pfizer ! MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20091011072031.297EF3A67FF@core3.amsl.com> Date: Sun, 11 Oct 2009 00:20:30 -0700 (PDT) To: undisclosed-recipients:; Dear v6ops-archive@lists.ietf.org Get ready to make her happy. Discount price store:ID750459 http://www.rxtoxic.cn We do guarantee high-quality medications, instant worldwide delivery and friendly support. 2001-2009 Pfizer Inc. All rights reserved. From mmeged@alahrambeverages.com Mon Oct 12 06:05:31 2009 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 9E51228C1B5 for ; Mon, 12 Oct 2009 06:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.717 X-Spam-Level: X-Spam-Status: No, score=-25.717 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_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, 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 Y45wr6xny9d1 for ; Mon, 12 Oct 2009 06:05:30 -0700 (PDT) Received: from pool-108-1-41-162.chi01.btas.verizon.net (pool-108-1-41-162.chi01.btas.verizon.net [108.1.41.162]) by core3.amsl.com (Postfix) with SMTP id 0485228C1BF for ; Mon, 12 Oct 2009 06:05:25 -0700 (PDT) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091012130528.0485228C1BF@core3.amsl.com> Date: Mon, 12 Oct 2009 06:05:25 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.smilepious.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://smilepious.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 9, B505. 277 Clements Road. London. SE49 3DG

© 2009 AMAZON, Ltd. All Rights Reserved

From mercerunitarian@acado.ch Mon Oct 12 06:44:51 2009 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 06B9F3A68EC for ; Mon, 12 Oct 2009 06:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.56 X-Spam-Level: X-Spam-Status: No, score=-31.56 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, 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_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 JP0fU8+ec8o7 for ; Mon, 12 Oct 2009 06:44:40 -0700 (PDT) Received: from aebi.com (unknown [79.164.176.2]) by core3.amsl.com (Postfix) with SMTP id 497A13A6870 for ; Mon, 12 Oct 2009 06:44:30 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091012134432.497A13A6870@core3.amsl.com> Date: Mon, 12 Oct 2009 06:44:30 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.wingvalue.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://wingvalue.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 1, B268. 212 Clements Road. London. SE42 6DG

© 2009 AMAZON, Ltd. All Rights Reserved

From montoyae@airbomber.com Tue Oct 13 01:53:00 2009 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 2D87B28C282 for ; Tue, 13 Oct 2009 01:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.017 X-Spam-Level: X-Spam-Status: No, score=-46.017 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=2.02, MANGLED_OFF=2.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_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU46uO4msn+E for ; Tue, 13 Oct 2009 01:52:53 -0700 (PDT) Received: from ambac-uk.com (unknown [113.161.160.28]) by core3.amsl.com (Postfix) with SMTP id 45F2428C20B for ; Tue, 13 Oct 2009 01:52:51 -0700 (PDT) To: Subject: v6ops-archive, sun, 13 Oct 2009 +2026 80% 0FF. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091013085252.45F2428C20B@core3.amsl.com> Date: Tue, 13 Oct 2009 01:52:51 -0700 (PDT)
       Not seeing images? Click here.
Not seeing images? Click here.

At Pfizer, we're inspired by a single goal: your health. That's why we're dedicated to developing new, safe medicines to prevent and treat the world's most serious diseases.

And why we are making them available to the people who need them most. We believe that from progress comes hope and the promise of a healthier world.

Onlyfor you! Today 83% 0FF.
Start Shopping
 

Rates do not include taxes, gratuities or any additional charges that may apply. For complete
terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
v6ops-archive@{DOMFR} to your address book. Find out how.
Starwood Le Méridien Four Points by Sheraton Westin The Luxury Collection Aloft Sheraton element St. Regis W Hotels Starwood Preferred Guest
© 2009 Pfizer, Inc.

You are subscribed as v6ops-archive@ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-634-258-7608 from the U.S. & Canada or +318-31-1255564in all other countries to learn more about our data collection and usage practices.

Review the Pfizer Guest program Terms and Conditions.

Let us know if you prefer not to receive future promotional emails from Starwood Hotels & Resorts. It may take up to ten business days to make the requested change and there is a slight chance that you may receive email from us within that time.




From owner-v6ops@ops.ietf.org Tue Oct 13 10:19:08 2009 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 496973A67F4 for ; Tue, 13 Oct 2009 10:19:08 -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 ajPXYjOvcg7n for ; Tue, 13 Oct 2009 10:19:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52CDB3A672E for ; Tue, 13 Oct 2009 10:19:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxkvU-000DXg-4x for v6ops-data0@psg.com; Tue, 13 Oct 2009 17:12:44 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxkv7-000DTf-7C for v6ops@ops.ietf.org; Tue, 13 Oct 2009 17:12:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=70; q=dns/txt; s=sjiport03001; t=1255453941; x=1256663541; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20|Subject:=20draft =20deadlines|Date:=20Tue,=2013=20Oct=202009=2010:12:20=20 -0700|Message-Id:=20|To:=20IPv6=20Operations=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20v9 36)|Content-Transfer-Encoding:=207bit; bh=eNoKkgnIejESYLFgFeA5LjqTFQMyTR8V5+wa5JvF8FQ=; b=XCTofpA+8iUJS2CjZZUINbdcJ+aWe34bDsEzd8xk8SQanDBEGhpBQrcJ nPHDJhjGzH1PSu2Hz86LgTnOu6WH1ZZC5dEZzP9KCvaoXFUyIm6E4R3bQ nSJsSoNrHjX2rhEg5zDnIJtaZh6jiuqXIV5xoLVNz+ysG/DQunkYXCcx6 4=; 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: ApoEADdS1EqrR7Ht/2dsb2JhbADBI5gGhC0E X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="196378653" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 13 Oct 2009 17:12:20 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DHBKgE020468 for ; Tue, 13 Oct 2009 17:12:20 GMT Message-Id: From: Fred Baker To: IPv6 Operations Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: draft deadlines Date: Tue, 13 Oct 2009 10:12:20 -0700 X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -00 drafts have to be in by Monday, updates by a week from Monday... From krisseeann@adventinc.com Wed Oct 14 06:08:35 2009 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 A66C53A67AD for ; Wed, 14 Oct 2009 06:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.643 X-Spam-Level: X-Spam-Status: No, score=-12.643 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 GbaIsWesb9eh for ; Wed, 14 Oct 2009 06:08:29 -0700 (PDT) Received: from advbiol.com (unknown [200.80.189.5]) by core3.amsl.com (Postfix) with SMTP id D689928C115 for ; Wed, 14 Oct 2009 06:08:23 -0700 (PDT) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091014130825.D689928C115@core3.amsl.com> Date: Wed, 14 Oct 2009 06:08:23 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.partdesire.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://partdesire.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 1, B700. 803 Clements Road. London. SE76 9DG

© 2009 AMAZON, Ltd. All Rights Reserved

From keltnerl@ahdubai.com Wed Oct 14 09:21:25 2009 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 905BA3A6816 for ; Wed, 14 Oct 2009 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.222 X-Spam-Level: X-Spam-Status: No, score=-15.222 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 9RbWEtNgELaq for ; Wed, 14 Oct 2009 09:21:18 -0700 (PDT) Received: from advertisingmadeeasy.com (unknown [187.78.197.53]) by core3.amsl.com (Postfix) with SMTP id 8020F3A67DB for ; Wed, 14 Oct 2009 09:21:14 -0700 (PDT) To: Subject: Order Shipped -- Order #52518 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091014162115.8020F3A67DB@core3.amsl.com> Date: Wed, 14 Oct 2009 09:21:14 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.partdesire.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://partdesire.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 4, B666. 489 Clements Road. London. SE63 4DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Wed Oct 14 19:45:17 2009 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 92F0F3A68A3 for ; Wed, 14 Oct 2009 19:45:17 -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 t7YuUySRApzE for ; Wed, 14 Oct 2009 19:45:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF7383A6821 for ; Wed, 14 Oct 2009 19:45:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyGGC-000IZy-Dv for v6ops-data0@psg.com; Thu, 15 Oct 2009 02:40:12 +0000 Received: from [209.85.216.182] (helo=mail-px0-f182.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyGFu-000IY7-R9 for v6ops@ops.ietf.org; Thu, 15 Oct 2009 02:40:05 +0000 Received: by pxi12 with SMTP id 12so374432pxi.9 for ; Wed, 14 Oct 2009 19:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8cR6j66yL3jOOzkB4MyIAq/0lZMn/r2Z1PydE4q7kMA=; b=vI6/9mN99Aio0ObvizYnJc/rDlSagJyvHZNeEF864gHhXB/INwkJUtp1qFdUlajIg4 wGmQDKmZ/DDfAPctR8LjuteUMDIQhjBlw+TTl1FnkquNZFZLdZgH/qxmIOi6Z0pAAV0s 10RxSwj3/9rM5euGpQmuewY/BHtQ72beggzYc= 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=Rfz8VsAX7vSDDSarghzkyfYt3dYeNWQEvOq3lo/zhltALivyN6JbLpzx2xiSfKfX4W cG37mo1ORuC4uNwRWPdzGkOub45NObtFRmdEx6Jt6RZgrDFMZWPgEuSVA0QoxRdJOUUe gTnEM9dH1yn2qfe8QuY/Ug/mqTWMeCbw7HDt0= Received: by 10.115.66.29 with SMTP id t29mr3702281wak.187.1255574393834; Wed, 14 Oct 2009 19:39:53 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm1345051pxi.6.2009.10.14.19.39.52 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Oct 2009 19:39:53 -0700 (PDT) Message-ID: <4AD68B80.70001@gmail.com> Date: Thu, 15 Oct 2009 15:40:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker CC: IPv6 Operations Subject: Re: Agenda call 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: Fred, Sheng and I would like a slot to introduce draft-carpenter-v6ops-isp-scenarios and to ask for input. Maybe 15 minutes? Brian On 2009-10-08 04:54, Fred Baker wrote: > We have two sessions scheduled in Hiroshima. This is a call for agenda > items. Who wants time to talk? > > From owner-v6ops@ops.ietf.org Wed Oct 14 19:45:28 2009 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 E88523A68A3 for ; Wed, 14 Oct 2009 19:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=-0.947, 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 BfTKYQJc8yxw for ; Wed, 14 Oct 2009 19:45:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD42E3A684E for ; Wed, 14 Oct 2009 19:45:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyGEf-000IRU-C4 for v6ops-data0@psg.com; Thu, 15 Oct 2009 02:38:37 +0000 Received: from [209.85.222.174] (helo=mail-pz0-f174.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyGEN-000IQA-0V for v6ops@ops.ietf.org; Thu, 15 Oct 2009 02:38:33 +0000 Received: by pzk4 with SMTP id 4so1569905pzk.32 for ; Wed, 14 Oct 2009 19:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=rg0TC8yxRLUopXZL6/8ddt94iWbhFoO5+g0aGfdGEWA=; b=lVXo0ZNEgcXFupOYtQMib0QsKv+oxK0oUJ2eUZVZ+StzIW3J1/2zNBngfnyedRagDf JVilJnaxx8MWuO+svSMVS5oSZwSfYcO6MjmGpjhPxYcdefCy6leEnZ2BPYJ5Nf9k8vAK GMFXBlOivboU50e3yT07moRtOp/tq4na2EdnM= 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=TXYiVzOj5GNJ8HAfM0trJMbr/jYPkIhteUTGagQ8hXrTmdEbm82h4VOgoVgvltKXPp qTcFOwhiRhDDoVosWUe0ialRD7IHLZ+2Ak01wLNyYx4uMDAWU5Ey8i+yq/6fktcn2Jxb lBmFHVxp1rkwSE/UjByOM9ey2DhIhP6i1z+7w= Received: by 10.115.84.39 with SMTP id m39mr16831924wal.62.1255574298020; Wed, 14 Oct 2009 19:38:18 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm1888464pxi.13.2009.10.14.19.38.16 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Oct 2009 19:38:17 -0700 (PDT) Message-ID: <4AD68B20.5020806@gmail.com> Date: Thu, 15 Oct 2009 15:38:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Subject: [Fwd: I-D Action:draft-carpenter-v6ops-isp-scenarios-00.txt] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: FYI. Sheng and I will be asking for structured input on this topic; this initial draft is intentionally short on content. Brian -------- Original Message -------- Subject: I-D Action:draft-carpenter-v6ops-isp-scenarios-00.txt Date: Wed, 14 Oct 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Emerging Service Provider Scenarios for IPv6 Deployment Author(s) : B. Carpenter, S. Jiang Filename : draft-carpenter-v6ops-isp-scenarios-00.txt Pages : 9 Date : 2009-10-14 This document describes scenarios that are emerging among Internet Service Providers for the deployment of IPv6. They are based on practical experience so far, as well as current plans and requirements, but they are not intended as binding recommendations. [[ NOTE: This a preliminary version with incomplete content. ]] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-isp-scenarios-00.txt From owner-v6ops@ops.ietf.org Thu Oct 15 13:58:01 2009 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 647A428C178 for ; Thu, 15 Oct 2009 13:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[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 G+tTs2zPk5cn for ; Thu, 15 Oct 2009 13:58:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 371C028C172 for ; Thu, 15 Oct 2009 13:58:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyXJ1-000AdK-VV for v6ops-data0@psg.com; Thu, 15 Oct 2009 20:52:15 +0000 Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyXIs-000AbO-8s for v6ops@ops.ietf.org; Thu, 15 Oct 2009 20:52:13 +0000 Received: from 114-30-98-65.ip.adam.com.au ([114.30.98.65] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1MyXIo-0002Z8-9T; Fri, 16 Oct 2009 07:22:02 +1030 Received: from opy.nosense.org (localhost.localdomain [127.0.0.1]) by opy.nosense.org (Postfix) with ESMTP id 4FC8A49298; Fri, 16 Oct 2009 07:22:01 +1030 (CST) Date: Fri, 16 Oct 2009 07:22:01 +1030 From: Mark Smith To: Brian E Carpenter Cc: IPv6 Operations Subject: Re: [Fwd: I-D Action:draft-carpenter-v6ops-isp-scenarios-00.txt] Message-ID: <20091016072201.2d411bce@opy.nosense.org> In-Reply-To: <4AD68B20.5020806@gmail.com> References: <4AD68B20.5020806@gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi Brian, On Thu, 15 Oct 2009 15:38:24 +1300 Brian E Carpenter wrote: > FYI. Sheng and I will be asking for structured input on this topic; > this initial draft is intentionally short on content. > The "bones" look good so far. > Brian > > -------- Original Message -------- > Subject: I-D Action:draft-carpenter-v6ops-isp-scenarios-00.txt > Date: Wed, 14 Oct 2009 15:45:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Emerging Service Provider Scenarios for IPv6 Deployment > Author(s) : B. Carpenter, S. Jiang > Filename : draft-carpenter-v6ops-isp-scenarios-00.txt > Pages : 9 > Date : 2009-10-14 > > This document describes scenarios that are emerging among Internet > Service Providers for the deployment of IPv6. They are based on > practical experience so far, as well as current plans and > requirements, but they are not intended as binding recommendations. > [[ NOTE: This a preliminary version with incomplete content. ]] > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-isp-scenarios-00.txt > > From mujicamoniney@anbbank.com Thu Oct 15 15:07:34 2009 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 5C29F28C119 for ; Thu, 15 Oct 2009 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.203 X-Spam-Level: X-Spam-Status: No, score=-19.203 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_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 MjZNVi3-MHIB for ; Thu, 15 Oct 2009 15:07:33 -0700 (PDT) Received: from wana-188-244-12-196.wanamaroc.com (wana-188-244-12-196.wanamaroc.com [196.12.244.188]) by core3.amsl.com (Postfix) with SMTP id 355DA28C172 for ; Thu, 15 Oct 2009 15:06:55 -0700 (PDT) To: Subject: Hi From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091015220704.355DA28C172@core3.amsl.com> Date: Thu, 15 Oct 2009 15:06:55 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.matterthin.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://matterthin.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 4, B882. 719 Clements Road. London. SE36 5DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-v6ops@ops.ietf.org Mon Oct 19 14:35:45 2009 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 197563A6926 for ; Mon, 19 Oct 2009 14:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTd8NrTSXVXq for ; Mon, 19 Oct 2009 14:35:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3ACF43A659A for ; Mon, 19 Oct 2009 14:35:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzzRX-000JzY-RW for v6ops-data0@psg.com; Mon, 19 Oct 2009 21:07:03 +0000 Received: from web45511.mail.sp1.yahoo.com ([68.180.197.143]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzzE4-000IMv-5q for v6ops@ops.ietf.org; Mon, 19 Oct 2009 20:57:08 +0000 Received: (qmail 93617 invoked by uid 60001); 19 Oct 2009 20:53:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1255985586; bh=0EHhjk+1uQM9HoP+0szi9/nA7aFn4NGnTrJQ2KVZyJI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tqYfSzpEWlPLz1Xu8/lcl+e/tgBY17AWrCFp1atiMpZ/uQKVcu5BG8QRHIFUkzOn7fq6ULSEuetmklsxzwEIM2ysDtRYAexMHZdwpUKWusoR8iWguvAGjUPI99jqrq1DAz9jilmMLLRMncMm0BQez6ojpWRe1D7Q7BHqwgIv0Uc= 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:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6KV1c47ziqvbNxNpJYfZeAifmCx2Xf2AuQZc3tw8y6XsNAzwjpJVIrNG0PMKwH8IBJVLC8dzBjQC/p7zkrH/hUfiQjDFi/kyitsApcGWr+ZxuizIcNHBi5sDfzdzxQX13t/zN9hjXgV5MIH8Ybp6E8TToOJ9KWUdzt8S5dU1Jkg=; Message-ID: <884469.92855.qm@web45511.mail.sp1.yahoo.com> X-YMail-OSG: gsne2n4VM1lqf13bpGBfjOQEDBcdfiHwEikUajpIBtIblbw.CRlLimgcjpwO5a_LQtZXTYDSmYfVLQLuG7pfbv2oiss..KKhz2dZAZrDfusJOSRjFlirTw8s15JntXnrallczcoByVGNd6wXNkytt4u5hbncGZpYj9H4V5GCkI1xMkTgxNpIjKMYTmqafFYCdoYeP51hUQ92bLPPgwWZ1Y4zokrkn_uBdBd1IMMJkf9xtJNvRniZCyWssK6njQ4QP0G16GZFuinGOr8wTcxQagWLkwY2lXx5RdEKgDVe6E6s6rsVRyenWgBh Received: from [89.138.46.188] by web45511.mail.sp1.yahoo.com via HTTP; Mon, 19 Oct 2009 13:53:06 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 Date: Mon, 19 Oct 2009 13:53:06 -0700 (PDT) From: Gabi Nakibly Subject: draft-nakibly-v6ops-tunnel-loops To: v6ops Cc: Fred L Templin 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: I have posted an I-D that is intended to sum up our efforts concerning the = mitigation of the=A0routing loop attacks for ISATAP and 6to4. The current v= ersion is a straw draft with little content. Its main purpose is to get a 5= -min slot at IETF76.=0Ahttp://www.ietf.org/id/draft-nakibly-v6ops-tunnel-lo= ops-00.txt=0A=0AGabi=0A=0A=0A From owner-v6ops@ops.ietf.org Mon Oct 19 18:43:23 2009 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 D12613A69BD for ; Mon, 19 Oct 2009 18:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.286 X-Spam-Level: X-Spam-Status: No, score=-103.286 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 Kz2okVTsMrd7 for ; Mon, 19 Oct 2009 18:43:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F48E3A6405 for ; Mon, 19 Oct 2009 18:43:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03VZ-000524-Kg for v6ops-data0@psg.com; Tue, 20 Oct 2009 01:27:29 +0000 Received: from [64.170.98.32] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03Cd-0003kQ-PL for v6ops@ops.ietf.org; Tue, 20 Oct 2009 01:11:56 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3FB293A6883; Mon, 19 Oct 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020004501.3FB293A6883@core3.amsl.com> Date: Mon, 19 Oct 2009 17:45:01 -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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-08.txt Pages : 36 Date : 2009-10-19 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-08.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-cpe-simple-security-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19173121.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 19 19:21:28 2009 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 BDDA83A69E4 for ; Mon, 19 Oct 2009 19:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.992 X-Spam-Level: X-Spam-Status: No, score=-4.992 tagged_above=-999 required=5 tests=[AWL=-1.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5M+J1aSWQgJ for ; Mon, 19 Oct 2009 19:21:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E40E3A699E for ; Mon, 19 Oct 2009 19:21:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03CT-0003jr-Gb for v6ops-data0@psg.com; Tue, 20 Oct 2009 01:07:45 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N02xh-0002vE-OI for v6ops@ops.ietf.org; Tue, 20 Oct 2009 00:56:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2379; q=dns/txt; s=sjiport06001; t=1255999949; x=1257209549; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20|Reply-To:=20|Subject:=20Building=20IPv6=20Applicatio ns=20which=20Access=20IPv4=20Servers=20-=20draft-wing-v6o ps-v6app-v4server-00|Date:=20Mon,=2019=20Oct=202009=2017: 49:25=20-0700|Message-ID:=20<028701ca511f$2bf3bb70$c4f020 0a@cisco.com>|To:=20"'IPv6=20Operations'"=20,=20,=0D=0A=20=20=20=20=20 =20=20=20"Behave=20WG"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit; bh=lrSODG7T8yLiaWzd2jrZf+Scn2LpUHpoafo+R4HlVtg=; b=h4JdqnygsRXxHDXUCEUULLuXdkpyYHTXTZIj1uQLmrabFVMK9vSy0C3E 5qBfr36fhI5oP884scKt9BgBeGuATD79LyasBzfWz8iojxBNievuylIMc Ui5AlP4yxZo+fJL4+p/rHnJgYSXF1tbawEz7yB89vBT2XkEIh2Kn6mL6a E=; 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: ApsEAJ+l3EqrR7Hu/2dsb2JhbACKYLdfl0uEMQSBWw X-IronPort-AV: E=Sophos;i="4.44,588,1249257600"; d="scan'208";a="413019968" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2009 00:49:25 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9K0nPXO025680; Tue, 20 Oct 2009 00:49:25 GMT Reply-To: From: "Dan Wing" To: "'IPv6 Operations'" , , "Behave WG" Subject: Building IPv6 Applications which Access IPv4 Servers - draft-wing-v6ops-v6app-v4server-00 Date: Mon, 19 Oct 2009 17:49:25 -0700 Message-ID: <028701ca511f$2bf3bb70$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpRHyuxTiUCYKaIT2eZtZLH/JbKZg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: (Please reply to v6ops@ops.ietf.org) V6Ops, Apps-Discuss, Behave, I just submitted a short draft, "Building IPv6 Applications which Access IPv4 Servers" which may be interesting to apps area, behave, and v6ops, as it has some bearing on each. The document applies to IPv6 hosts operating in BEHAVE's scenarios 1 ("an IPv6 network to IPv4 Internet"), and scenario 5 ("an IPv6 network to an IPv4 network"). It explains that while DNS64 and 6/4 translation is helpful and functional for many IPv6 applications, there are some IPv6 applications that will need to additional functionality -- either (a) in the application itself using the translator (e.g., an IPv6 SIP application could be extended to do this) or (b) using some sort of application-level proxy functionality (e.g., a SIP application can use a TURN-IPv6 relay; an HTTP application can use an HTTP proxy that is connected to IPv4 and IPv6). The purpose of this document is to examine 6/4 translation in more detail, and show what IPv6 applications need to add so that we can avoid Application Layer Gateways (ALGs) in hosts, in CPEs, and in 6/4 translators. Some protocols, notably SIP, have already finished their efforts to explain how the protocol will transition to IPv6 (in fact, two SIP documents explain two different mechanisms; that might not be a bad thing). Other protocols such as FTP are being examined by BEHAVE. Other protocols, such as RTSP, XMPP, and probably others, I have no idea of their status regarding IPv6 and if/how they have decided to handle IPv6-only applications communicating with IPv4 addresses. This draft hopes to start that discussion. Abstract: When an application runs on a host or network that only supports IPv6 ("IPv6-only"), it is sometimes necessary that the application communicate with IPv4 peers. When that communication involves DNS, DNS64 and a 6/4 translator works well without any changes to most applications. However, when that communication does not involve DNS, it can require additional features be configured on or programmed into the IPv6 application. This document explains why this functionality is important and describes mechanisms for applications to provide such functionality. http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-00 Comments welcome. -d From owner-v6ops@ops.ietf.org Mon Oct 19 19:22:55 2009 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 A0E773A699E for ; Mon, 19 Oct 2009 19:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, 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 zpEjxWo5eT-i for ; Mon, 19 Oct 2009 19:22:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE22E3A68FB for ; Mon, 19 Oct 2009 19:22:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03Lc-0004KG-AA for v6ops-data0@psg.com; Tue, 20 Oct 2009 01:17:12 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N02qc-0002UB-Dk for v6ops@ops.ietf.org; Tue, 20 Oct 2009 00:49:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3FB293A6883; Mon, 19 Oct 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020004501.3FB293A6883@core3.amsl.com> Date: Mon, 19 Oct 2009 17:45:01 -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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-08.txt Pages : 36 Date : 2009-10-19 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-08.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-cpe-simple-security-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19173121.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 19 19:22:59 2009 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 01DA23A68FB for ; Mon, 19 Oct 2009 19:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, 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 ASSvtJqfwI6E for ; Mon, 19 Oct 2009 19:22:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2A053A67E2 for ; Mon, 19 Oct 2009 19:22:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03Lc-0004KE-4q for v6ops-data0@psg.com; Tue, 20 Oct 2009 01:17:12 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N039j-0003au-JN for v6ops@ops.ietf.org; Tue, 20 Oct 2009 01:08:55 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3FB293A6883; Mon, 19 Oct 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020004501.3FB293A6883@core3.amsl.com> Date: Mon, 19 Oct 2009 17:45:01 -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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-08.txt Pages : 36 Date : 2009-10-19 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-08.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-cpe-simple-security-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19173121.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 19 20:05:43 2009 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 5003D3A683E for ; Mon, 19 Oct 2009 20:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, 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 37JXLyCn+QBM for ; Mon, 19 Oct 2009 20:05:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 725A93A63C9 for ; Mon, 19 Oct 2009 20:05:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N04mg-000CDI-1Q for v6ops-data0@psg.com; Tue, 20 Oct 2009 02:49:14 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N04df-000BLE-Nn for v6ops@ops.ietf.org; Tue, 20 Oct 2009 02:43:55 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3FB293A6883; Mon, 19 Oct 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020004501.3FB293A6883@core3.amsl.com> Date: Mon, 19 Oct 2009 17:45:01 -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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-08.txt Pages : 36 Date : 2009-10-19 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-08.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-cpe-simple-security-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19173121.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 19 20:30:27 2009 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 1E6643A67DB for ; Mon, 19 Oct 2009 20:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.291 X-Spam-Level: X-Spam-Status: No, score=-103.291 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 jjQ4OCUIPaOu for ; Mon, 19 Oct 2009 20:30:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 487AE3A67E2 for ; Mon, 19 Oct 2009 20:30:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N04ga-000Bdd-CL for v6ops-data0@psg.com; Tue, 20 Oct 2009 02:42:56 +0000 Received: from [64.170.98.32] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N04ga-000BdT-1y for v6ops@ops.ietf.org; Tue, 20 Oct 2009 02:42:56 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3FB293A6883; Mon, 19 Oct 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-cpe-simple-security-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020004501.3FB293A6883@core3.amsl.com> Date: Mon, 19 Oct 2009 17:45:01 -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 : Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Author(s) : J. Woodyatt Filename : draft-ietf-v6ops-cpe-simple-security-08.txt Pages : 36 Date : 2009-10-19 This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-08.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-cpe-simple-security-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19173121.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Tue Oct 20 02:27:53 2009 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 E470D3A68E7 for ; Tue, 20 Oct 2009 02:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.640, 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 ermq75sFJm2A for ; Tue, 20 Oct 2009 02:27:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27D4C3A6783 for ; Tue, 20 Oct 2009 02:27:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0AMN-000ILg-94 for v6ops-data0@psg.com; Tue, 20 Oct 2009 08:46:27 +0000 Received: from [119.145.14.66] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0AIR-000Hy0-QK for v6ops@ops.ietf.org; Tue, 20 Oct 2009 08:46:26 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRT005TP1IKXP@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Tue, 20 Oct 2009 16:42:20 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRT007ES1IKFQ@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Tue, 20 Oct 2009 16:42:20 +0800 (CST) Received: from j66104a ([10.111.12.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRT00HC71IKOB@szxml06-in.huawei.com> for v6ops@ops.ietf.org; Tue, 20 Oct 2009 16:42:20 +0800 (CST) Date: Tue, 20 Oct 2009 16:42:19 +0800 From: Sheng Jiang Subject: FW: New Version Notification for draft-jiang-v6ops-nc-protection-00 To: v6ops@ops.ietf.org Cc: chenxu0128@huawei.com Message-id: <006701ca5161$3c587c70$3a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpQuBT/y1GnaN7ZTKKdQP6DLoeRpwAqQ/YA Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Dear all, A new draft draft-jiang-v6ops-nc-protection has been submitted to the V6OPS WG. Comments are always welcomed! Best regards, Sheng > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, October 19, 2009 8:31 PM > To: shengjiang@huawei.com > Cc: chenxu0128@huawei.com; songxuan@huawei.com > Subject: New Version Notification for > draft-jiang-v6ops-nc-protection-00 > > > A new version of I-D, draft-jiang-v6ops-nc-protection-00.txt > has been successfuly submitted by Sheng Jiang and posted to > the IETF repository. > > Filename: draft-jiang-v6ops-nc-protection > Revision: 00 > Title: Neighbor Cache Protection in Neighbor > Discover Protocol > Creation_date: 2009-10-19 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > In Neighbor Discover Protocol, routers and hosts record the > neighbor information in the local Neighbor Cache database. It > is vulnerable by malicious attacks. This document analyzes > these security threats and proposes a solution, mainly using > reverse detection mechanism, to prevent the potential damage. > > > > > The IETF Secretariat. > > From owner-v6ops@ops.ietf.org Tue Oct 20 08:53:16 2009 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 A2E713A67F7 for ; Tue, 20 Oct 2009 08:53:16 -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 vXzK9CaqIrbb for ; Tue, 20 Oct 2009 08:53:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C21323A67E3 for ; Tue, 20 Oct 2009 08:53:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0GXX-0002Rk-UX for v6ops-data0@psg.com; Tue, 20 Oct 2009 15:22:23 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0GOl-0001LD-GA for v6ops@ops.ietf.org; Tue, 20 Oct 2009 15:17:19 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 2949C7C7575E; Tue, 20 Oct 2009 08:13:19 -0700 (PDT) X-AuditID: 11807130-b7b18ae00000724f-ac-4addd38e8b91 Received: from [17.116.224.139] (Unknown_Domain [17.116.224.139]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 23.37.29263.E83DDDA4; Tue, 20 Oct 2009 08:13:19 -0700 (PDT) Subject: Re: I-D Action:draft-ietf-v6ops-cpe-simple-security-08.txt Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: james woodyatt In-Reply-To: Date: Tue, 20 Oct 2009 08:13:18 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: 7bit Message-Id: References: <20091020004501.3FB293A6883@core3.amsl.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1076) X-Brightmail-Tracker: AAAAAQAAAZE= Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On Oct 19, 2009, at 21:36, Cameron Byrne wrote: > > 1. I could not find the specific recommendation for disallowing > spoofed traffic by beans of uRPF like in RFC 3704 I suppose the draft would be improved by an explicit reference to reverse path forwarding and a cite to RFC 3704. > > 2. Is management outside of scope? For example, does it make sense > to say that the WAN interface is by default not interface to be used > for management That's a security consideration, so I'd say it would be in scope and a worthy point to mention. I'll update. -- james woodyatt member of technical staff, communications engineering From owner-v6ops@ops.ietf.org Tue Oct 20 09:40:52 2009 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 AF7903A68E4 for ; Tue, 20 Oct 2009 09:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 4U4RadMkHmA4 for ; Tue, 20 Oct 2009 09:40:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C2763A6841 for ; Tue, 20 Oct 2009 09:40:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0H3j-0006Be-Ra for v6ops-data0@psg.com; Tue, 20 Oct 2009 15:55:39 +0000 Received: from [209.85.219.215] (helo=mail-ew0-f215.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0Guj-00051A-QJ for v6ops@ops.ietf.org; Tue, 20 Oct 2009 15:50:22 +0000 Received: by ewy11 with SMTP id 11so6045312ewy.11 for ; Tue, 20 Oct 2009 08:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tKhXFrGMwtiH0n9sErn24a6MJx5VPaVLAKttWV1DrJc=; b=KgX96Fceg6jdg2AmcBzfkk4cq9DI44zEyQN8SGKFHbzlTfpNQYJ102aXson0TdacPa 1g59zaqIsvNJRbwIFqzDwAYRYyk/5s5hpbpwl0h+aF6gytC2TTTMQaU6YSxXXrhsVhmO OJ1KecTrJi86kS+FPKgCnUzF2V9kal6ivwTZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BYaRii4/DA3o0fHVAskSX3I7HW8NgDzvr16Gg3lE+7dC4xUG4wSZyB14FK9D2L+MoK EQIP7XnyQLFrx4VzD9kmAjfc5xhhrxSAgKcJELSjjZF3n+16fBvOtTPCpdTidyS7AL5w oHTnOnxUQAS7VNNiWr5++bmKaFkLfkxM43pO8= MIME-Version: 1.0 Received: by 10.216.88.83 with SMTP id z61mr2269016wee.140.1256053580372; Tue, 20 Oct 2009 08:46:20 -0700 (PDT) In-Reply-To: <20091019015435.5A3BE3A63C9@core3.amsl.com> References: <20091019015435.5A3BE3A63C9@core3.amsl.com> Date: Tue, 20 Oct 2009 23:46:20 +0800 Message-ID: Subject: Fwd: New Version Notification for draft-qin-v6ops-icp-transition-00 From: Jacni Qin To: v6ops@ops.ietf.org Cc: liugy@gsta.com Content-Type: multipart/alternative; boundary=0016e6d641777a1c0404765fc3b1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --0016e6d641777a1c0404765fc3b1 Content-Type: text/plain; charset=ISO-8859-1 Dear all, i posted a new draft, draft-qin-v6ops-icp-transition-00.txt to v6ops. comments are welcome! many thanks! Jacni ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Oct 19, 2009 at 9:54 AM Subject: New Version Notification for draft-qin-v6ops-icp-transition-00 To: jacniq@gmail.com Cc: liugy@gsta.com A new version of I-D, draft-qin-v6ops-icp-transition-00.txt has been successfuly submitted by Jacni Qin and posted to the IETF repository. Filename: draft-qin-v6ops-icp-transition Revision: 00 Title: Recommendations for the ISPs' provision of IPv6 transition services to the ICPs Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 11 Abstract: The exhaustion of IPv4 addresses is coming, while due to many reasons, no significant IPv6 deployment has occured. The transition of users, networks and services from IPv4 to IPv6 is not so smoothly and expeditiously as expected. The solutions now available are not sufficient for all the scenarios, so the IPv6 deployment models are revisited, and some new methods used for transition have been developed to complement the existing ones. This document discusses the transition of services and the use of these new mechanisms from the ISP's point of view to provide approaches to the transition for ICPs. The IETF Secretariat. --0016e6d641777a1c0404765fc3b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

i posted a new draft, draft-qin-v6ops-icp-transition-00.tx= t to v6ops.
comments are welcome!

many thanks!

Jacni
---------- Forwarded message ----------
Fro= m: IETF I-D Submission Tool <idsubmission@ietf.org= >
Date: Mon, Oct 19, 2009 at 9:54 AM
Subject: New Version Notification for= draft-qin-v6ops-icp-transition-00
To: jacniq@gmail.com
Cc: liugy@gsta= .com



A new version of I-D, draft-qin-v6ops-icp-transition-00.txt has been succes= sfuly submitted by Jacni Qin and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-qin-v6ops-icp-transition
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Recommendations for the ISPs' provision of I= Pv6 transition services to the ICPs
Creation_date: =A0 2009-10-19
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 11

Abstract:
The exhaustion of IPv4 addresses is coming, while due to many
reasons, no significant IPv6 deployment has occured. =A0The transition
of users, networks and services from IPv4 to IPv6 is not so smoothly
and expeditiously as expected. =A0The solutions now available are not
sufficient for all the scenarios, so the IPv6 deployment models are
revisited, and some new methods used for transition have been
developed to complement the existing ones. =A0This document discusses
the transition of services and the use of these new mechanisms from
the ISP's point of view to provide approaches to the transition for
ICPs.



The IETF Secretariat.



--0016e6d641777a1c0404765fc3b1-- From johnsmithsvt@aspireyou.com Wed Oct 21 07:16:48 2009 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 1B8743A683A; Wed, 21 Oct 2009 07:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 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, 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, 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_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, 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 iEfxxZZ9ZY8E; Wed, 21 Oct 2009 07:16:47 -0700 (PDT) Received: from 201-27-3-126.dsl.telesp.net.br (201-27-3-126.dsl.telesp.net.br [201.27.3.126]) by core3.amsl.com (Postfix) with SMTP id 1C9493A679C; Wed, 21 Oct 2009 07:16:15 -0700 (PDT) Subject: Vacheron Constantin better than original Date: Wed, 21 Oct 2009 10:16:23 -0500 From: "Xavier Allison" To: "Manuela Russo" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Hello Dee Get the Finest Vacheron Constantin Watches here! We only sell premium watches. These original watches sell in stores for thousands of dollars. We sell them for much less. - Rep-licated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings Visit us: http://itcwmpea.cn/ Christmas discount this week only! Make your order before the prices go up. Best regards, Mr. Plummer From lk-qe@amchk.com Wed Oct 21 08:27:06 2009 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 DBEDB3A699C for ; Wed, 21 Oct 2009 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.683 X-Spam-Level: X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 b2kjDme5Go-c for ; Wed, 21 Oct 2009 08:27:06 -0700 (PDT) Received: from 60.85-84-155.dynamic.clientes.euskaltel.es (60.85-84-155.dynamic.clientes.euskaltel.es [85.84.155.60]) by core3.amsl.com (Postfix) with SMTP id 0E5B33A6998 for ; Wed, 21 Oct 2009 08:27:00 -0700 (PDT) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091021152703.0E5B33A6998@core3.amsl.com> Date: Wed, 21 Oct 2009 08:27:00 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.preferplease.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://preferplease.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 8, B040. 040 Clements Road. London. SE90 1DG

© 2009 AMAZON, Ltd. All Rights Reserved

From reclineu3@rothbaecher.com Wed Oct 21 16:14:46 2009 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 C2EDB3A6870; Wed, 21 Oct 2009 16:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.392 X-Spam-Level: X-Spam-Status: No, score=-32.392 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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, URIBL_AB_SURBL=10, URIBL_BLACK=20, 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 3wPQmD1QlQ6w; Wed, 21 Oct 2009 16:14:46 -0700 (PDT) Received: from tdev251-92.codetel.net.do (tdev251-92.codetel.net.do [200.88.251.92]) by core3.amsl.com (Postfix) with ESMTP id 6E5433A6805; Wed, 21 Oct 2009 16:14:44 -0700 (PDT) Received: from rothbaecher.com by mail2.asplogin.de; Thu, 22 Oct 2009 01:14:08 +0100 Date: Thu, 22 Oct 2009 01:14:08 +0100 Message-Id: From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: A watch that will not make your wallet lighter Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
 
 

If you received this email from a friend and would like to subscribe to this and other newsletters, please click here .

You are subscribed to this newsletter as: kvachdmitry@gmail.com Click here to update your email address.

To unsubscribe from this newsletter, please click here .
Or, send an Unsubscribe Request C/O WFAA, 322 Ahsahka St, Kaleigh, 2K 14418.
 
From reclineu3@rothbaecher.com Wed Oct 21 16:14:46 2009 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 C2EDB3A6870; Wed, 21 Oct 2009 16:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.392 X-Spam-Level: X-Spam-Status: No, score=-32.392 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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, URIBL_AB_SURBL=10, URIBL_BLACK=20, 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 3wPQmD1QlQ6w; Wed, 21 Oct 2009 16:14:46 -0700 (PDT) Received: from tdev251-92.codetel.net.do (tdev251-92.codetel.net.do [200.88.251.92]) by core3.amsl.com (Postfix) with ESMTP id 6E5433A6805; Wed, 21 Oct 2009 16:14:44 -0700 (PDT) Received: from rothbaecher.com by mail2.asplogin.de; Thu, 22 Oct 2009 01:14:08 +0100 Date: Thu, 22 Oct 2009 01:14:08 +0100 Message-Id: From: v6ops-archive@ietf.org To: v6ops-archive@ietf.org Subject: A watch that will not make your wallet lighter Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
 
 

If you received this email from a friend and would like to subscribe to this and other newsletters, please click here .

You are subscribed to this newsletter as: kvachdmitry@gmail.com Click here to update your email address.

To unsubscribe from this newsletter, please click here .
Or, send an Unsubscribe Request C/O WFAA, 322 Ahsahka St, Kaleigh, 2K 14418.
 
From owner-v6ops@ops.ietf.org Fri Oct 23 08:06:08 2009 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 AAD383A6836 for ; Fri, 23 Oct 2009 08:06:08 -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, HTML_MESSAGE=0.001, 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 faSm45qm0x29 for ; Fri, 23 Oct 2009 08:06:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 503E03A6824 for ; Fri, 23 Oct 2009 08:06:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Li1-0009Cg-9v for v6ops-data0@psg.com; Fri, 23 Oct 2009 15:05:41 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Lhx-0009Bu-Ku for v6ops@ops.ietf.org; Fri, 23 Oct 2009 15:05:38 +0000 Received: from [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8] (unknown [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 869D23084C2; Fri, 23 Oct 2009 13:05:38 -0200 (UYST) Cc: v6ops@ops.ietf.org Message-Id: <8D72B45C-5553-48D7-AE21-3C4F5BB434F3@lacnic.net> From: Roque Gagliano To: Fernando Gont In-Reply-To: <4ACF7CBE.9070200@gont.com.ar> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-41-977743746" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Some comments on draft-ietf-v6ops-v6inixp-03.txt Date: Fri, 23 Oct 2009 13:05:34 -0200 References: <4ACF7CBE.9070200@gont.com.ar> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-41-977743746 Content-Type: multipart/alternative; boundary=Apple-Mail-40-977743705 --Apple-Mail-40-977743705 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks Fernando for your review. On Oct 9, 2009, at 4:11 PM, Fernando Gont wrote: > Hello, Roque, > > Here's some feedback on the aforementioned I-D. > > * Editorial * > > Abstract: > >> This document provides a guide for IPv6 deployment in Internet > > s/a guide for/guidance on/ > done. > >> Exchange Points (IXP). It includes information regarding the >> switch > > s/information/advice/ > In SFP we decided to be informational and not BCP. > >> fabric configuration, the addressing plan and general >> organizational >> tasks to be performed. IXPs are mainly a layer 2 infrastructure >> and > > s/to be/that need to be/ > done > > >> in many case the best recommendations state that the IPv6 data, > > s/case/cases/ > s/state/suggest/ > > done > Introduction: > >> Most Internet Exchange Points (IXP) work on the Layer 2 level, >> making >> the adoption of IPv6 an easy task. > > s/work on/work at/ > > > I found it hard to parse this sentence: > >> This document clarifies the impact of IPv6 >> on a new or an existing IXP that may or may not fit any particular >> deployment. > > I deleted the sentence. > > Section 2: > >> However, some management >> functions require explicit IPv6 support (such as switch management, >> SNMP support and flow analysis exportation) and this should be >> assessed by the IXP operator. > > Include a (Informative) reference to the SNMP spec. > done > >> scenario, participants will typically configure dual stack > > s/dual stack/dual-stack/ > done. > > BTW, in this text: > >> scenario, participants will typically configure dual stack >> interfaces, although independent port can be an option. > > You meant something like "...will typically configure interfaces as > dual-stack, although independent interfaces could be possibly used for > each version of IP"? > correct. > >> traffic. If IXP participants are already using Virtual LAN >> (VLAN) tagging on their routers interfaces that are facing the >> IXP switch, > > Rephrase as "If IXP participants are already using Virtual LAN (VLAN) > tagging on those interfaces of their routers that are facing the IXP > switch...." > > done. > >> Conversely, the dual stack implementation allows a quick and >> capital >> cost-free start-up for IPv6 support in the IXP, allowing the IXP to > > s/dual stack/dual-stack/ > > Maybe s/capital cost-free/inexpensive/ ? > not the same concept. I rather leave the original sentence. > P.S.: More in the pipeline! > Thanks again. Roque. > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-40-977743705 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks Fernando for your = review.

On Oct 9, 2009, at 4:11 PM, Fernando Gont = wrote:

Hello, Roque,

Here's some feedback on the = aforementioned I-D.

* Editorial = *

Abstract:

  This = document provides a guide for IPv6 deployment in = Internet

s/a guide for/guidance = on/

done.


  Exchange = Points (IXP).  It includes information regarding the = switch

s/information/advice/


In SFP we decided to be informational and not = BCP.


  fabric configuration, the addressing plan and = general organizational
=   tasks to be performed.  IXPs are mainly a layer 2 = infrastructure and

s/to be/that need to = be/

done



  in = many case the best recommendations state that the IPv6 = data,

s/case/cases/
s/state/suggest/


done
Introduction:

=   Most Internet Exchange Points (IXP) work on the Layer 2 = level, making
  the = adoption of IPv6 an easy task.

s/work on/work = at/


I found it hard to parse this = sentence:

This document clarifies the = impact of IPv6
  on = a new or an existing IXP that may or may not fit any = particular
=   deployment.


I = deleted the sentence.


Section = 2:

However, some = management
=   functions require explicit IPv6 support (such as switch = management,
  SNMP = support and flow analysis exportation) and this should = be
  assessed by = the IXP operator.

Include a (Informative) =  reference to the SNMP = spec.


done


=       scenario, participants will = typically configure dual stack

s/dual = stack/dual-stack/


done.

BTW, in this = text:

=       scenario, participants will = typically configure dual stack
=       interfaces, although independent = port can be an option.

You meant something like = "...will typically configure interfaces as
dual-stack, although = independent interfaces could be possibly used for
each version of = IP"?


correct.


=       traffic.  If IXP participants = are already using Virtual LAN
=       (VLAN) tagging on their routers = interfaces that are facing the
=       IXP = switch,

Rephrase as "If IXP participants are already = using Virtual LAN (VLAN)
tagging on those interfaces of their routers = that are facing the = IXP
switch...."



done.=


=   Conversely, the dual stack implementation allows a quick and = capital
  cost-free = start-up for IPv6 support in the IXP, allowing the IXP = to

s/dual stack/dual-stack/

Maybe s/capital = cost-free/inexpensive/ = ?


not the same concept. I = rather leave the original sentence.


P.S.: More in the = pipeline!


Thanks = again.

Roque.


Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 = 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 = FFF1





-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =

= --Apple-Mail-40-977743705-- --Apple-Mail-41-977743746 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) iEYEARECAAYFAkrhxj4ACgkQnk+WSgHpbO76bwCfSweKu5dsotRYlHhC16thRlec AnQAoLDOzJXR3bHRxTiGSSy08ULWLVQI =+yFr -----END PGP SIGNATURE----- --Apple-Mail-41-977743746-- From owner-v6ops@ops.ietf.org Fri Oct 23 08:06:14 2009 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 8C1633A68A5 for ; Fri, 23 Oct 2009 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Zcmm1vqjT8 for ; Fri, 23 Oct 2009 08:06:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F2A13A6824 for ; Fri, 23 Oct 2009 08:06:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1La7-0007Ej-0F for v6ops-data0@psg.com; Fri, 23 Oct 2009 14:57:31 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1La4-0007EL-6e for v6ops@ops.ietf.org; Fri, 23 Oct 2009 14:57:28 +0000 Received: from [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8] (unknown [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6DB9C308504; Fri, 23 Oct 2009 11:40:56 -0200 (UYST) Cc: v6ops WG Message-Id: From: Roque Gagliano To: ALAIN AINA In-Reply-To: <98E78CDB-C9DD-4DCD-8825-95668028969E@trstech.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Date: Fri, 23 Oct 2009 11:40:51 -0200 References: <20090909020014.0D00128C1DA@core3.amsl.com> <98E78CDB-C9DD-4DCD-8825-95668028969E@trstech.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 alain, Thanks for your reviews. I will correct all the typos that you pointed out. Also, refering to your comment on the last paragraph of section 3 I am =20= introducing the text that we discussed in the list: - --------- IPv6 prefixes for IXP LANs are typically publicly well known and taken =20= from dedicated IPv6 blocks for IXP assignments reserved for this =20 purpose by the different RIRs.The current practice that applies to =20 IPv4 about publishing IXP allocations to the DFZ (Default Free Zone) =20 should also apply to the IPv6 allocation. When considering the routing =20= of the IXP LANs two options are identified: =09 - IXPs may decide that LANs should not to be globally routed in = order =20 to limit the possible origins of a Distributed Denial of Service =20 (DDoS) attack to its particpant's AS boundries. In this configuration =20= participants may route these prefixes inside their networks (e. g. =20 using BGP no-export communities or routing the IXP LANs within the =20 participants' IGP) to perform fault management. Using this =20 configuration, the monitoring of the IXP LANs from outside of its =20 participants' AS boundaries is not possible. - IXP may decide that LANs should be globally routed. In this = case, =20 IXP LANs monitoring from outside its participants' AS boundaries =20= is possible but the IXP LANs will be vulnerable to DDoS from outside =20= of those broundries. =09 IXP external services (such as dns, web pages, ftp servers) need to be =20= globally routed. Strict prefix length filtering could be the reason =20 for requesting more than one /48 assignment from a RIR (i.e. =20 requesting one /48 assignment for the IXPs LANs that may not be =20 globally routed and a different /48 assignment for the IXP external =20 services that will be globally routed). - --------- Regards, Roque On Oct 5, 2009, at 10:40 PM, ALAIN AINA wrote: > > On Sep 9, 2009, at 2:25 AM, Roque Gagliano wrote: > >> Hi, >> >> I issued a new ID of the draft with the changes that came up at the =20= >> Stockholm meeting. Changes were: >> - I explained why ULA is not a good idea. >> - I added that addressing can use two different /48, one for the =20 >> LANs and the second one for the internal services and not =20 >> necessarily one /47, as comments at the meeting. >> - I included comments from Nick Hilliar about BGP sessions. >> - I added text about having different participants in different =20 >> solocited-node multicast group. >> - I mention of RA-Guard based on comments from Nick Hilliar. >> >> I will now request Alain and Bernard to review the doc as they are =20= >> the WG volunteers. > > > attached is a .doc version with my comments > > > hope this helps > > --alain > > >> >> Regards, >> >> Roque. >> >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: September 8, 2009 11:00:14 PM GMT-03:00 >>> To: roque@lacnic.net >>> Subject: New Version Notification for draft-ietf-v6ops-v6inixp-02 >>> >>> >>> A new version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been =20 >>> successfuly submitted by Roque Gagliano and posted to the IETF =20 >>> repository. >>> >>> Filename: draft-ietf-v6ops-v6inixp >>> Revision: 02 >>> Title: IPv6 Deployment in Internet Exchange Points = (IXPs) >>> Creation_date: 2009-09-08 >>> WG ID: v6ops >>> Number_of_pages: 10 >>> >>> Abstract: >>> This document provides a guide for IPv6 deployment in Internet >>> Exchange Points (IXP). It includes information regarding the switch >>> fabric configuration, the addressing plan and general organizational >>> tasks to be performed. IXPs are mainly a layer 2 infrastructure and >>> in many case the best recommendations state that the IPv6 data, >>> control and management plane should not be handled differently than >>> in IPv4. >>> >>> >>> >>> The IETF Secretariat. >>> >> >> ------------------------------------------------------------- >> Roque Gagliano >> LACNIC >> roque@lacnic.net >> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE >> > - ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEUEARECAAYFAkrhsmMACgkQnk+WSgHpbO7aygCYyI1TtFrarx2z5xCcArpn0IV+ zQCgggTUcboEcDN7VzSfHll0VHD28+c=3D =3DOqXk -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Oct 23 08:37:50 2009 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 334BB3A691A for ; Fri, 23 Oct 2009 08:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.308, 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 avFFyLr8GC+b for ; Fri, 23 Oct 2009 08:37:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A99E3A6910 for ; Fri, 23 Oct 2009 08:37:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1M5p-000DUN-6v for v6ops-data0@psg.com; Fri, 23 Oct 2009 15:30:17 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1M5m-000DTp-PK for v6ops@ops.ietf.org; Fri, 23 Oct 2009 15:30:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id AF61B3A67E4; Fri, 23 Oct 2009 08:30:02 -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-v6inixp-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023153002.AF61B3A67E4@core3.amsl.com> Date: Fri, 23 Oct 2009 08:30:02 -0700 (PDT) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Deployment in Internet Exchange Points (IXPs) Author(s) : R. Gagliano Filename : draft-ietf-v6ops-v6inixp-03.txt Pages : 11 Date : 2009-10-23 This document provides guidance on IPv6 deployment in Internet Exchange Points (IXP). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a layer 2 infrastructure and in many cases the best recommendations suggest that the IPv6 data, control and management plane should not be handled differently than in IPv4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6inixp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-v6inixp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23082913.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 23 08:37:58 2009 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 A472028C0E4 for ; Fri, 23 Oct 2009 08:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4rYWxRrISd1 for ; Fri, 23 Oct 2009 08:37:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 464393A6910 for ; Fri, 23 Oct 2009 08:37:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1M6K-000DZH-1W for v6ops-data0@psg.com; Fri, 23 Oct 2009 15:30:48 +0000 Received: from [2001:13c7:7001:4000::3] (helo=mail.lacnic.net.uy) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1M6G-000DYt-H0 for v6ops@ops.ietf.org; Fri, 23 Oct 2009 15:30:45 +0000 Received: from [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8] (unknown [IPv6:2001:13c7:7001:5128:225:ff:fe4b:94a8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 5C9603084CE for ; Fri, 23 Oct 2009 13:30:42 -0200 (UYST) Message-Id: From: Roque Gagliano To: v6ops WG In-Reply-To: <98E78CDB-C9DD-4DCD-8825-95668028969E@trstech.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-43-979247609" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: New Version Notification for draft-ietf-v6ops-v6inixp-02 Date: Fri, 23 Oct 2009 13:30:38 -0200 References: <20090909020014.0D00128C1DA@core3.amsl.com> <98E78CDB-C9DD-4DCD-8825-95668028969E@trstech.net> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.936) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-43-979247609 Content-Type: multipart/alternative; boundary=Apple-Mail-42-979247567 --Apple-Mail-42-979247567 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG. I just issued version 03 that includes all the comments from Alain, Bernard, Martin, Fernando and Mawatari. Changes: - typos and editorial changes found by reviewers. - changes in section 3, addressing plan as discussed in the list. I look forward to hear your comments, Roque. A new version of I-D, draft-ietf-v6ops-v6inixp-03.txt has been successfuly submitted by Roque Gagliano and posted to the IETF repository. Filename: draft-ietf-v6ops-v6inixp Revision: 03 Title: IPv6 Deployment in Internet Exchange Points (IXPs) Creation_date: 2009-10-23 WG ID: v6ops Number_of_pages: 11 Abstract: This document provides guidance on IPv6 deployment in Internet Exchange Points (IXP). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a layer 2 infrastructure and in many cases the best recommendations suggest that the IPv6 data, control and management plane should not be handled differently than in IPv4. The IETF Secretariat. On Oct 5, 2009, at 10:40 PM, ALAIN AINA wrote: > > On Sep 9, 2009, at 2:25 AM, Roque Gagliano wrote: > >> Hi, >> >> I issued a new ID of the draft with the changes that came up at the >> Stockholm meeting. Changes were: >> - I explained why ULA is not a good idea. >> - I added that addressing can use two different /48, one for the >> LANs and the second one for the internal services and not >> necessarily one /47, as comments at the meeting. >> - I included comments from Nick Hilliar about BGP sessions. >> - I added text about having different participants in different >> solocited-node multicast group. >> - I mention of RA-Guard based on comments from Nick Hilliar. >> >> I will now request Alain and Bernard to review the doc as they are >> the WG volunteers. > > > attached is a .doc version with my comments > > > hope this helps > > --alain > > >> >> Regards, >> >> Roque. >> >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: September 8, 2009 11:00:14 PM GMT-03:00 >>> To: roque@lacnic.net >>> Subject: New Version Notification for draft-ietf-v6ops-v6inixp-02 >>> >>> >>> A new version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been >>> successfuly submitted by Roque Gagliano and posted to the IETF >>> repository. >>> >>> Filename: draft-ietf-v6ops-v6inixp >>> Revision: 02 >>> Title: IPv6 Deployment in Internet Exchange Points (IXPs) >>> Creation_date: 2009-09-08 >>> WG ID: v6ops >>> Number_of_pages: 10 >>> >>> Abstract: >>> This document provides a guide for IPv6 deployment in Internet >>> Exchange Points (IXP). It includes information regarding the switch >>> fabric configuration, the addressing plan and general organizational >>> tasks to be performed. IXPs are mainly a layer 2 infrastructure and >>> in many case the best recommendations state that the IPv6 data, >>> control and management plane should not be handled differently than >>> in IPv4. >>> >>> >>> >>> The IETF Secretariat. >>> >> >> ------------------------------------------------------------- >> Roque Gagliano >> LACNIC >> roque@lacnic.net >> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE >> > ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-42-979247567 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear WG.

I = just issued version 03 that includes all the comments from Alain, = Bernard, Martin, Fernando and = Mawatari.

Changes:

- = typos and editorial changes found by reviewers.
- changes in = section 3, addressing plan as discussed in the = list.

I look forward to hear your = comments,

Roque.


A new version of I-D, draft-ietf-v6ops-v6inixp-03.txt has been = successfuly submitted by Roque Gagliano and posted to the IETF = repository.

Filename: =  draft-ietf-v6ops-v6inixp
Revision: =  03
Title:  IPv6 Deployment in Internet = Exchange Points (IXPs)
Creation_date:  2009-10-23
WG ID: =  v6ops
Number_of_pages: 11

Abstract:
This = document provides guidance on IPv6 deployment in Internet
Exchange = Points (IXP).  It includes information regarding the = switch
fabric configuration, the addressing plan and general = organizational
tasks that need to be performed.  IXPs are mainly = a layer 2
infrastructure and in many cases the best recommendations = suggest
that the IPv6 data, control and management plane should not = be
handled differently than in IPv4.



The IETF = Secretariat.

On Oct 5, 2009, at 10:40 = PM, ALAIN AINA wrote:


On Sep 9, 2009, = at 2:25 AM, Roque Gagliano wrote:

Hi,

I issued = a new ID of the draft with the changes that came up at the Stockholm = meeting. Changes were:
- I explained why ULA is not a good = idea.
- I added that addressing can use two different /48, one = for the LANs and the second one for the internal services and not = necessarily one /47, as comments at the meeting.
- I included = comments from Nick Hilliar about BGP sessions.
- I added text = about having different participants in different solocited-node = multicast group.
- I mention of RA-Guard based on comments = from Nick Hilliar.

I will now request Alain and = Bernard to review the doc as they are the WG = volunteers.


attached= is a .doc version with my = comments


hope this = helps

--alain
<aina-review-of-draft= -ietf-v6ops-v6inixp-02.doc>

From: = IETF I-D Submission Tool <idsubmission@ietf.org>=
Date: September 8, 2009 11:00:14 PM = GMT-03:00
Subject: = New Version Notification for = draft-ietf-v6ops-v6inixp-02 


A new = version of I-D, draft-ietf-v6ops-v6inixp-02.txt has been successfuly = submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-ietf-v6ops-v6inixp
Revision: 02
Title: IPv6 = Deployment in Internet Exchange Points (IXPs)
Creation_date: = 2009-09-08
WG ID: v6ops
Number_of_pages: = 10

Abstract:
This document provides a guide for IPv6 = deployment in Internet
Exchange Points (IXP).  It includes = information regarding the switch
fabric configuration, the addressing = plan and general organizational
tasks to be performed.  IXPs are = mainly a layer 2 infrastructure and
in many case the best = recommendations state that the IPv6 data,
control and management = plane should not be handled differently than
in = IPv4.



The IETF = Secretariat.


-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =



=
-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE
 =

= --Apple-Mail-42-979247567-- --Apple-Mail-43-979247609 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) iEYEARECAAYFAkrhzB4ACgkQnk+WSgHpbO6uCgCgnW2EoA5bNkrft2zukSoIo22H 4K0AnjsWOWmGJn3T8bYjLR7ZxZtHI5Qh =rnQ4 -----END PGP SIGNATURE----- --Apple-Mail-43-979247609-- From owner-v6ops@ops.ietf.org Fri Oct 23 18:10:21 2009 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 38FF23A67C2 for ; Fri, 23 Oct 2009 18:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.424 X-Spam-Level: X-Spam-Status: No, score=-105.424 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 84JwMMT3g06S for ; Fri, 23 Oct 2009 18:10:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B46C3A66B4 for ; Fri, 23 Oct 2009 18:10:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Ug6-0003LW-Q6 for v6ops-data0@psg.com; Sat, 24 Oct 2009 00:40: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.69 (FreeBSD)) (envelope-from ) id 1N1Ufe-0003ER-Bx for v6ops@ops.ietf.org; Sat, 24 Oct 2009 00:39:53 +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: ApoEAN/n4UqrR7Ht/2dsb2JhbADBU5gtgkCBfwSBXQ X-IronPort-AV: E=Sophos;i="4.44,615,1249257600"; d="scan'208";a="416553768" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 24 Oct 2009 00:35:22 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9O0ZMP7024573; Sat, 24 Oct 2009 00:35:22 GMT Message-Id: <0165865F-8554-4FEC-BA6F-C96C2AA09BCB@cisco.com> From: Fred Baker To: IPv6 Operations In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Is this the agenda? Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Oct 2009 17:35:20 -0700 References: X-Mailer: Apple Mail (2.936) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: I believe that I have been asked for slots for the following (alphabetical by draft name). Have I missed anything or included too much? I need the slides folks plan to use, please. http://tools.ietf.org/html/draft-carpenter-v6ops-isp-scenarios "Emerging Service Provider Scenarios for IPv6 Deployment", Brian Carpenter, Sheng Jiang, 14-Oct-09, http://tools.ietf.org/html/draft-cui-softwire-pet "IPv4/IPv6 Coexistence Framework (PET)", Yong Cui, Mingwei Xu, Shengling Wang, Jianping Wu, Xing Li, Chris Metz, 7-Jul-09, http://tools.ietf.org/html/draft-cui-softwire-pet-framework "PET-based framework for IPv4/IPv6 coexistence", Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu, 6-Jul-09, http://tools.ietf.org/html/draft-cui-softwire-pet64 "PET for IPv6 to IPv4 communication", Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu, 19-Oct-09, http://tools.ietf.org/html/draft-defeche-ipv6-traffic-in-p2p-networks "Measuring IPv6 Traffic in BitTorrent Networks", Martin Defeche, Eric Vyncke, 18-Oct-09, http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 19- Oct-09, http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 18- Aug-09, http://tools.ietf.org/html/draft-ietf-v6ops-v6inixp "IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano, 23-Oct-09, http://tools.ietf.org/html/draft-jiang-v6ops-incremental-cgn "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng Jiang, Dayong Guo, Brian Carpenter, 24-Sep-09, http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection "Neighbor Cache Protection in Neighbor Discover Protocol", Sheng Jiang, Xu Chen, Huawei Building, 19-Oct-09, http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops "Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions", Gabi Nakibly, 19-Oct-09, http://tools.ietf.org/html/draft-qin-v6ops-icp-transition "Recommendations for the ISPs' provision of IPv6 transition services to the ICPs", Jacni Qin, Guangyi Liu, 18-Oct-09, http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions "Teredo Extensions", Dave Thaler, 4-Sep-09, http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis "IPv6 CPE Router Recommendations(bis)", Hemant Singh, Wes Beebee, 18-Aug-09, http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server "Building IPv6 Applications which Access IPv4 Servers", Dan Wing, 19-Oct-09, From owner-v6ops@ops.ietf.org Fri Oct 23 21:03:56 2009 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 9FB7A3A68B9 for ; Fri, 23 Oct 2009 21:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 UO1yn1JbmPKo for ; Fri, 23 Oct 2009 21:03:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 778C93A6405 for ; Fri, 23 Oct 2009 21:03:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Xim-000EbG-7h for v6ops-data0@psg.com; Sat, 24 Oct 2009 03:55:16 +0000 Received: from [211.151.89.50] (helo=mail.jzland.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Xih-000EaH-Mr for v6ops@ops.ietf.org; Sat, 24 Oct 2009 03:55:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 87DDF30B097C; Sat, 24 Oct 2009 11:55:06 +0800 (CST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Oct 24 11:55:05 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4ae27a9933877904110913 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVvYz8jZCszb; Sat, 24 Oct 2009 11:55:01 +0800 (CST) Received: from LENOVO (unknown [219.143.135.92]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 743B130B097A; Sat, 24 Oct 2009 11:55:00 +0800 (CST) Date: Sat, 24 Oct 2009 11:55:03 +0800 From: "Yong" To: "Fred Baker" , "IPv6 Operations" Subject: Re: Is this the agenda? X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20091024035506.87DDF30B097C@mail.jzland.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Hi, Fred, Please update the drafts of PET to these two: IPv4/IPv6 Coexistence Framework (PET) http://tools.ietf.org/html/draft-cui-softwire-pet PET for IPv6 to IPv4 communication http://tools.ietf.org/html/draft-cui-softwire-pet64 Thanks for the arrangement. Yong ======= 2009-10-24 08:35:20 You wrote ======= >I believe that I have been asked for slots for the following >(alphabetical by draft name). Have I missed anything or included too >much? > >I need the slides folks plan to use, please. > >http://tools.ietf.org/html/draft-carpenter-v6ops-isp-scenarios > "Emerging Service Provider Scenarios for IPv6 Deployment", Brian >Carpenter, > Sheng Jiang, 14-Oct-09, > >http://tools.ietf.org/html/draft-cui-softwire-pet > "IPv4/IPv6 Coexistence Framework (PET)", Yong Cui, Mingwei Xu, >Shengling > Wang, Jianping Wu, Xing Li, Chris Metz, 7-Jul-09, > > >http://tools.ietf.org/html/draft-cui-softwire-pet-framework > "PET-based framework for IPv4/IPv6 coexistence", Yong Cui, Mingwei >Xu, > Shengling Wang, Xing Li, Jianping Wu, 6-Jul-09, > > >http://tools.ietf.org/html/draft-cui-softwire-pet64 > "PET for IPv6 to IPv4 communication", Yong Cui, Mingwei Xu, >Shengling Wang, > Xing Li, Jianping Wu, 19-Oct-09, > >http://tools.ietf.org/html/draft-defeche-ipv6-traffic-in-p2p-networks > "Measuring IPv6 Traffic in BitTorrent Networks", Martin Defeche, >Eric Vyncke, > 18-Oct-09, > >http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security > "Recommended Simple Security Capabilities in Customer Premises >Equipment for > Providing Residential IPv6 Internet Service", James Woodyatt, 19- >Oct-09, > > >http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router > "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 18- >Aug-09, > > >http://tools.ietf.org/html/draft-ietf-v6ops-v6inixp > "IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano, > 23-Oct-09, > >http://tools.ietf.org/html/draft-jiang-v6ops-incremental-cgn > "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng >Jiang, > Dayong Guo, Brian Carpenter, 24-Sep-09, > > >http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection > "Neighbor Cache Protection in Neighbor Discover Protocol", Sheng >Jiang, Xu > Chen, Huawei Building, 19-Oct-09, protection-00.txt> > >http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops > "Routing Loops using ISATAP and 6to4: Problem Statement and Proposed > Solutions", Gabi Nakibly, 19-Oct-09, > > >http://tools.ietf.org/html/draft-qin-v6ops-icp-transition > "Recommendations for the ISPs' provision of IPv6 transition >services to the > ICPs", Jacni Qin, Guangyi Liu, 18-Oct-09, > > >http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions > "Teredo Extensions", Dave Thaler, 4-Sep-09, > > >http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis > "IPv6 CPE Router Recommendations(bis)", Hemant Singh, Wes Beebee, >18-Aug-09, > > >http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server > "Building IPv6 Applications which Access IPv4 Servers", Dan Wing, >19-Oct-09, > > > > ======================================= Best regards, 11:52:23 2009-10-24 ******************************************************** * Yong Cui * * Ph.D, Department of Computer Science & Technology * * Tsinghua University, Beijing, P.R.China(100084) * * Tel: (8610)-62603059 * * Email: yong@csnet1.cs.tsinghua.edu.cn * ******************************************************** From owner-v6ops@ops.ietf.org Sun Oct 25 12:22:26 2009 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 9A0213A6914 for ; Sun, 25 Oct 2009 12:22:26 -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 M9TT56kqqf-W for ; Sun, 25 Oct 2009 12:22:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39D163A692A for ; Sun, 25 Oct 2009 12:22:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N28Zq-0004Mf-Hs for v6ops-data0@psg.com; Sun, 25 Oct 2009 19:16:30 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N28Zl-0004MM-St for v6ops@ops.ietf.org; Sun, 25 Oct 2009 19:16:26 +0000 Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoAAApB5EqQ/uCWe2dsb2JhbACbNQEBFiQGoyqWZYJAgX8EgV4 X-IronPort-AV: E=Sophos;i="4.44,621,1249257600"; d="scan'208";a="52720671" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2009 19:16:23 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9PJGNw4003130 for ; Sun, 25 Oct 2009 19:16:23 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 20:16:23 +0100 Received: from 10.55.185.70 ([10.55.185.70]) by XMB-AMS-110.cisco.com ([144.254.74.85]) with Microsoft Exchange Server HTTP-DAV ; Sun, 25 Oct 2009 19:16:23 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 25 Oct 2009 20:16:22 +0100 Subject: Re: Is this the agenda? From: evyncke To: Fred Baker , IPv6 Operations Message-ID: Thread-Topic: Is this the agenda? Thread-Index: AcpVp6M8HkHnkpKDpk60q4V0aMX34g== In-Reply-To: <0165865F-8554-4FEC-BA6F-C96C2AA09BCB@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Oct 2009 19:16:23.0561 (UTC) FILETIME=[A42A3790:01CA55A7] Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Mark Townsley and I would also love to have 15 minutes of air time to present our work: http://www.ietf.org/id/draft-vyncke-advanced-ipv6-security-00.txt Thanks in advance -=E9ric On 24/10/09 01:35, "Fred Baker" wrote: > I believe that I have been asked for slots for the following > (alphabetical by draft name). Have I missed anything or included too > much? >=20 > I need the slides folks plan to use, please. >=20 > http://tools.ietf.org/html/draft-carpenter-v6ops-isp-scenarios > "Emerging Service Provider Scenarios for IPv6 Deployment", Brian > Carpenter, > Sheng Jiang, 14-Oct-09, >=20 > http://tools.ietf.org/html/draft-cui-softwire-pet > "IPv4/IPv6 Coexistence Framework (PET)", Yong Cui, Mingwei Xu, > Shengling > Wang, Jianping Wu, Xing Li, Chris Metz, 7-Jul-09, > >=20 > http://tools.ietf.org/html/draft-cui-softwire-pet-framework > "PET-based framework for IPv4/IPv6 coexistence", Yong Cui, Mingwei > Xu, > Shengling Wang, Xing Li, Jianping Wu, 6-Jul-09, > >=20 > http://tools.ietf.org/html/draft-cui-softwire-pet64 > "PET for IPv6 to IPv4 communication", Yong Cui, Mingwei Xu, > Shengling Wang, > Xing Li, Jianping Wu, 19-Oct-09, >=20 > http://tools.ietf.org/html/draft-defeche-ipv6-traffic-in-p2p-networks > "Measuring IPv6 Traffic in BitTorrent Networks", Martin Defeche, > Eric Vyncke, > 18-Oct-09, >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security > "Recommended Simple Security Capabilities in Customer Premises > Equipment for > Providing Residential IPv6 Internet Service", James Woodyatt, 19- > Oct-09, > >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router > "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 18- > Aug-09, > >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-v6inixp > "IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano, > 23-Oct-09, >=20 > http://tools.ietf.org/html/draft-jiang-v6ops-incremental-cgn > "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng > Jiang, > Dayong Guo, Brian Carpenter, 24-Sep-09, > >=20 > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection > "Neighbor Cache Protection in Neighbor Discover Protocol", Sheng > Jiang, Xu > Chen, Huawei Building, 19-Oct-09, protection-00.txt> >=20 > http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops > "Routing Loops using ISATAP and 6to4: Problem Statement and Proposed > Solutions", Gabi Nakibly, 19-Oct-09, > >=20 > http://tools.ietf.org/html/draft-qin-v6ops-icp-transition > "Recommendations for the ISPs' provision of IPv6 transition > services to the > ICPs", Jacni Qin, Guangyi Liu, 18-Oct-09, > >=20 > http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions > "Teredo Extensions", Dave Thaler, 4-Sep-09, > >=20 > http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis > "IPv6 CPE Router Recommendations(bis)", Hemant Singh, Wes Beebee, > 18-Aug-09, > >=20 > http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server > "Building IPv6 Applications which Access IPv4 Servers", Dan Wing, > 19-Oct-09, > >=20 >=20 From owner-v6ops@ops.ietf.org Mon Oct 26 14:50:59 2009 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 1E6EC28C163 for ; Mon, 26 Oct 2009 14:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ChYhqXA5ko+E for ; Mon, 26 Oct 2009 14:50:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40D1628C150 for ; Mon, 26 Oct 2009 14:50:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2XNQ-000MuZ-BK for v6ops-data0@psg.com; Mon, 26 Oct 2009 21:45:20 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2XNM-000Mtw-L7 for v6ops@ops.ietf.org; Mon, 26 Oct 2009 21:45:16 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id DF8C23A6950; Mon, 26 Oct 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026214501.DF8C23A6950@core3.amsl.com> Date: Mon, 26 Oct 2009 14:45:01 -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 : Requirements for IPv6 Customer Edge Routers Author(s) : H. Singh, et al. Filename : draft-ietf-v6ops-ipv6-cpe-router-02.txt Pages : 14 Date : 2009-10-26 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv6-cpe-router-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26143910.I-D@ietf.org> --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 26 17:53:09 2009 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 DAE4D3A69E5 for ; Mon, 26 Oct 2009 17:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 5SJmSu9moq6K for ; Mon, 26 Oct 2009 17:53:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1FF43A69D6 for ; Mon, 26 Oct 2009 17:53:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2aCf-0001P5-Cw for v6ops-data0@psg.com; Tue, 27 Oct 2009 00:46:25 +0000 Received: from [209.85.210.194] (helo=mail-yx0-f194.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2aCd-0001Oh-18 for v6ops@ops.ietf.org; Tue, 27 Oct 2009 00:46:23 +0000 Received: by yxe32 with SMTP id 32so11335777yxe.5 for ; Mon, 26 Oct 2009 17:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=u89IBzQ9Lzd+5tOeI3f+H48q6EqxjH09nCOk/8xgrDs=; b=sTep6OvdtcxuRCWVhfgkvcbcXUU1uwXO6twVr/0j8oBOhuqkQlgnQvEo7ooT68awkt tBpHnzIVirdJ5656d5V0tQLWxRR9wyMMUf/McHrlh/A09JH1pZPkumcfkpUtRRehPKOu LiPaul4UI4QtltYUAFEpDphPUvgdxpoBTxsZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=f4wf3oayymjdSES2YHWiflJKM084iCRqvMEuH2JwjNYDMGmyG26LC1jOVqBDY6ppFN cy44oKRPhQJsXJLhwyMDXnZKT2KJjWB1wXUFGJcAp+bfJwbaIh9CCm8IzplV1bphXA1B LNu8JevBUC7pPv6ZEH/ewHjapDV8XIzVj2p4U= Received: by 10.91.55.24 with SMTP id h24mr8933607agk.62.1256604382222; Mon, 26 Oct 2009 17:46:22 -0700 (PDT) Received: from ?10.201.65.143? ([203.98.18.214]) by mx.google.com with ESMTPS id 22sm1565068yxe.21.2009.10.26.17.46.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 17:46:21 -0700 (PDT) In-Reply-To: <20091026214501.DF8C23A6950@core3.amsl.com> References: <20091026214501.DF8C23A6950@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5739044E-7277-453D-8ADD-CC081785EBB5@gmail.com> Cc: shemant@cisco.com Content-Transfer-Encoding: 7bit From: Michael Newbery Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt Date: Tue, 27 Oct 2009 13:46:34 +1300 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.753.1) Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: On 27/10/2009, at 10:45 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of > the IETF. > > > Title : Requirements for IPv6 Customer Edge Routers > Author(s) : H. Singh, et al. > Filename : draft-ietf-v6ops-ipv6-cpe-router-02.txt > Pages : 14 > Date : 2009-10-26 > IPv6 Neighbor Discovery and DHCP protocols operate over any type of > IPv6 supported link-layer and there is no need for a link-layer > specific configuration protocol for IPv6 network layer > configuration > options like what's e.g. in PPP IPCP for IPv4. This section makes "e.g." is superfluous options like what's in PPP IPCP for IPv4. This section makes or better options, as is in PPP IPCP for IPv4. This section makes > G-2: The IPV6 CE router SHOULD support the following RFCs: > > * Internet Protocol, Version 6 (IPv6) Specification > [RFC2460] > > * Stateless Dynamic Host Configuration Protocol (DHCP) > Service > for IPv6 [RFC3736] > > * Default Router Preferences and More-Specific Routes > [RFC4191] > > * IP Version 6 Addressing Architecture [RFC4291] > > * IPv6 Subnet Model: the Relationship between Links and > Subnet > Prefixes [I-D.ietf-6man-ipv6-subnet-model] SHOULD seems inappropriate. RFC2460 must be MUST, especially considering the immediately preceding > G-1: An IPv6 CE router is an IPv6 node and MUST follow the IPv6 > Node > Requirements [RFC4294] specification. since RFC4294 says > The Internet Protocol Version 6 is specified in [RFC-2460]. This > specification MUST be supported. From owner-v6ops@ops.ietf.org Tue Oct 27 05:13:47 2009 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 B67B13A6964 for ; Tue, 27 Oct 2009 05:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eT2XmAoh3Wr for ; Tue, 27 Oct 2009 05:13:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4D393A67D6 for ; Tue, 27 Oct 2009 05:13:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2kr8-000JtE-5s for v6ops-data0@psg.com; Tue, 27 Oct 2009 12:08:54 +0000 Received: from [216.239.58.187] (helo=gv-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2kr5-000Jra-VW for v6ops@ops.ietf.org; Tue, 27 Oct 2009 12:08:52 +0000 Received: by gv-out-0910.google.com with SMTP id e6so900gvc.2 for ; Tue, 27 Oct 2009 05:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=EBfrIsY4v7u66xz9nKG2QmaK5tWvBxfA+ZkDSkAiYlA=; b=PccpyEiPE4JMmH9fs3ANy/wgXmf10SJp0ph9zN+/TxY6DCnMBMhQDUAavljVnI7eX1 rEPtlrPy1v7a4rVnJZr2uVu1g7Ks/SKnn7yUguhaAHuQJIlbbjDtTzHNsOpSHkti2bJ5 LGBf6lKABPQACcRw3EHBS6XlAwweIC0axPlGw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DWGOgURbqQ5zo9DJ27IsR+i7FtKpPKhk8E5mkHwJDG0elEiHiwxq32KeBZL2a3iXVn sQ3Bu8NTnyKCM740cEmbArC2nTanbRvn9Q9BK0FiSToqAeEHBvbLfx2yc25Ahje1MlxO j/xluFnZnwZlapKAr4QJueCraWMi+iZZqkeQg= MIME-Version: 1.0 Received: by 10.103.126.33 with SMTP id d33mr6686496mun.109.1256645330511; Tue, 27 Oct 2009 05:08:50 -0700 (PDT) In-Reply-To: <5739044E-7277-453D-8ADD-CC081785EBB5@gmail.com> References: <20091026214501.DF8C23A6950@core3.amsl.com> <5739044E-7277-453D-8ADD-CC081785EBB5@gmail.com> Date: Tue, 27 Oct 2009 13:08:50 +0100 X-Google-Sender-Auth: 926567eca1e6607a Message-ID: <2bbba3c10910270508w16a06eb1p7c495393e836b26b@mail.gmail.com> Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt From: Ole Troan To: Michael Newbery Cc: v6ops@ops.ietf.org, shemant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk List-ID: Michael, thanks, we'll incorporate your comments into the next version. cheers, Ole On Tue, Oct 27, 2009 at 1:46 AM, Michael Newbery wrote: > > On 27/10/2009, at 10:45 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >> >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Requirements for IPv6 Custome= r Edge Routers >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Singh, et al. >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-ipv6-cpe-route= r-02.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 14 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-10-26 > > > > >> =A0 IPv6 Neighbor Discovery and DHCP protocols operate over any type of >> =A0 IPv6 supported link-layer and there is no need for a link-layer >> =A0 specific configuration protocol for IPv6 network layer configuration >> =A0 options like what's e.g. in PPP IPCP for IPv4. =A0This section makes > > "e.g." is superfluous > =A0options like what's in PPP IPCP for IPv4. =A0This section makes > or better > =A0options, as is in PPP IPCP for IPv4. =A0This section makes > >> =A0 G-2: =A0The IPV6 CE router SHOULD support the following RFCs: >> >> =A0 =A0 =A0 =A0 * =A0Internet Protocol, Version 6 (IPv6) Specification [= RFC2460] >> >> =A0 =A0 =A0 =A0 * =A0Stateless Dynamic Host Configuration Protocol (DHCP= ) Service >> =A0 =A0 =A0 =A0 =A0 =A0for IPv6 [RFC3736] >> >> =A0 =A0 =A0 =A0 * =A0Default Router Preferences and More-Specific Routes >> =A0 =A0 =A0 =A0 =A0 =A0[RFC4191] >> >> =A0 =A0 =A0 =A0 * =A0IP Version 6 Addressing Architecture [RFC4291] >> >> =A0 =A0 =A0 =A0 * =A0IPv6 Subnet Model: the Relationship between Links a= nd Subnet >> =A0 =A0 =A0 =A0 =A0 =A0Prefixes [I-D.ietf-6man-ipv6-subnet-model] > > SHOULD seems inappropriate. RFC2460 must be MUST, especially considering = the > immediately preceding >> >> =A0 G-1: =A0An IPv6 CE router is an IPv6 node and MUST follow the IPv6 N= ode >> =A0 =A0 =A0 =A0 Requirements [RFC4294] specification. > > since RFC4294 says >> >> =A0 The Internet Protocol Version 6 is specified in [RFC-2460]. =A0This >> =A0 specification MUST be supported. > > > From depressivetb95@lohmann.com Tue Oct 27 17:50:40 2009 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 3CF8328C178 for ; Tue, 27 Oct 2009 17:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.364 X-Spam-Level: X-Spam-Status: No, score=-12.364 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_NJABL_PROXY=1.643, 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, 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 ss-UbMfRkBlX for ; Tue, 27 Oct 2009 17:50:37 -0700 (PDT) Received: from 201-1-68-97.dsl.telesp.net.br (201-1-68-97.dsl.telesp.net.br [201.1.68.97]) by core3.amsl.com (Postfix) with ESMTP id EC91C28C16D for ; Tue, 27 Oct 2009 17:50:36 -0700 (PDT) Received: by mail2.lohmann.com with SMTP id 56ax213002etei.53.647125441362; Tue, 27 Oct 2009 22:50:43 -0300 Received: by 75.146.102.24 with SMTP id 40rqh29604189cug.83.485691325777; Tue, 27 Oct 2009 22:50:43 -0300 Date: Tue, 27 Oct 2009 22:50:43 -0300 To: v6ops-archive@lists.ietf.org From: "Ricky Crabtree" Subject: Natural and safe enhancing Message-ID: <46ON4Y1EO1D4L802PKR.50YHNAJVY5.JL1A4681UUX9@depressivetb95> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1"
If you are having trouble reading this email, go to Online version
  eNewsletter
October, 2009

Image loading was cancelled. Click here to re-load it


Support Us | Contact Us | Privacy Policy | Unsubscribe
You are subscribed as v6ops-archive@lists.ietf.org

2009 Independent Men's Sexual Institute
All Rights Reserved
36 Alplaus St., 2nd Floor, NY 36825
 
From expressionistso7@e-mis.com Thu Oct 29 00:26:11 2009 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 C9EED3A69E0 for ; Thu, 29 Oct 2009 00:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.14 X-Spam-Level: X-Spam-Status: No, score=-78.14 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA+iYX6fSZDD for ; Thu, 29 Oct 2009 00:26:10 -0700 (PDT) Received: from 20151040090.user.veloxzone.com.br (20151025136.user.veloxzone.com.br [201.51.25.136]) by core3.amsl.com (Postfix) with ESMTP id B7DDA3A69EF for ; Thu, 29 Oct 2009 00:26:08 -0700 (PDT) Received: from 201.51.25.136 by lists.ietf.org; Thu, 29 Oct 2009 05:25:40 -0300 Message-ID: <000d01ca5869$04900c40$6400a8c0@expressionistso7> From: To: Subject: OEM downloadable 100% full version Date: Thu, 29 Oct 2009 05:25:40 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA5869.04900C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA5869.04900C40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable BestPrice | View online version Last Chance to get 80% Off - SHOP NOW=20 =20 * MST, October 28, 2009. If an item is already on sale you'll receive the b= etter of the two discounts=2E 69.4990.6605  | Published by lists.ietf.org.com lists.ietf.org.com . 8610 South 83572 West . Suite A | Allegan City, MJ 3= 5909 Copyright =A92009 lists.ietf.org.com. All rights reserved=2E ------=_NextPart_000_0007_01CA5869.04900C40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
BestPrice | View online= version
3D"If=20
* MST, October= 28, 2009. If an item is already on sale you'll receive the better of the t= wo discounts.


------=_NextPart_000_0007_01CA5869.04900C40-- From truncation5375@tachometry.com Thu Oct 29 20:25:29 2009 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 69A583A6970 for ; Thu, 29 Oct 2009 20:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.049 X-Spam-Level: X-Spam-Status: No, score=-80.049 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_URI_OEM=0.533, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBKQvEMgFhA2 for ; Thu, 29 Oct 2009 20:25:28 -0700 (PDT) Received: from bl4-188-24.dsl.telepac.pt (bl4-188-24.dsl.telepac.pt [81.193.188.24]) by core3.amsl.com (Postfix) with ESMTP id BE1F23A679C for ; Thu, 29 Oct 2009 20:25:25 -0700 (PDT) Received: by mail.tachometry.com with SMTP id 44fa031392pp.49.93729408198; Fri, 30 Oct 2009 02:24:54 -0100 Received: by 207.36.7.250 with SMTP id 58uam61984606zqu.31.68031626; Fri, 30 Oct 2009 02:24:54 -0100 Date: Fri, 30 Oct 2009 02:24:54 -0100 To: v6ops-archive@lists.ietf.org From: "Destiney Hatcher" Subject: full version OEM soft Message-ID: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1"
BestPrice | View online version
If you have any difficulty viewing this newsletter
* MST, October 28, 2009. If an item is already on sale you'll receive the better of the two discounts.


From middletondd@air-worldwide.com Thu Oct 29 23:15:36 2009 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 302D43A681E for ; Thu, 29 Oct 2009 23:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.302 X-Spam-Level: X-Spam-Status: No, score=-85.302 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klYGpaeJXsfy for ; Thu, 29 Oct 2009 23:15:35 -0700 (PDT) Received: from acebmx.com (unknown [217.145.202.42]) by core3.amsl.com (Postfix) with SMTP id 77F6E3A6924 for ; Thu, 29 Oct 2009 23:15:33 -0700 (PDT) To: Subject: RE: Message 6495 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091030061534.77F6E3A6924@core3.amsl.com> Date: Thu, 29 Oct 2009 23:15:33 -0700 (PDT)
Click here to view as a web page.

View image in browser now
Unsubscribe | Change e-mail address | Privacy Policy | About Us

Copyright 2009 3936 Inc. All rights reserved.