From markzzzsmith@yahoo.com.au Mon Oct 1 02:45:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC3A21F8555 for ; Mon, 1 Oct 2012 02:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQA4jcdoTU3O for ; Mon, 1 Oct 2012 02:45:55 -0700 (PDT) Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (nm20-vm4.bullet.mail.ne1.yahoo.com [98.138.91.180]) by ietfa.amsl.com (Postfix) with SMTP id EAB5521F8559 for ; Mon, 1 Oct 2012 02:45:52 -0700 (PDT) Received: from [98.138.226.179] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 01 Oct 2012 09:45:44 -0000 Received: from [98.138.89.162] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 01 Oct 2012 09:45:44 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 01 Oct 2012 09:45:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 344382.21880.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 83296 invoked by uid 60001); 1 Oct 2012 09:45:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1349084743; bh=xfevtpvFzop6NFIQ/vZS2wcAyWbkCnV4+Y3LAbuLp7Q=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ju2gK5jU7mG28/RLiY2+7qlmSGVxGLSXfYCm3TX9t9GZsXUH61YTfubI6nU1BngFR+4Sr7qOmwdvcH3Z6S4o7bPl04yEAh90BRc2LXmtnrHKVVMFVZL8HuOvgB3aLhWvXORCQvM3wIhHpY5LSy3j25OgLf3fo47TdAza0L76xPg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NzniAOCzZbBQZkrdYLdYG2ZFWguGHzCo3h3m13KZyQZtXqwNFBaJlygZlSGBJSep47jxwCZ4PDWsB6EmrFBxUClDAWewmgsrbSmy3CP9I02PG5SuUsiarK8VqQRXiTvUnKzeuKA6erB4OnQ+0s6tn3SoGTmeCBiN+hV6ftfsDZ8=; X-YMail-OSG: kkIjQ.sVM1lfyTvm.DimYowjoT96txvhBlS09b61E71dN9g k8mLF4rzCedc6U68IGbhXcVKiycEtV6LPJdXy_OvTA1dFLoPiIB194RmrT.T jXT990mUbPx8pFRET1lCuT8RIK_W679edpgTfoT2ZUso8hSuUk.Y_eZe55j2 ensJkA_7cZnu3.s.G6mi7r483zGXA4clguwM__th98lO0tARxtuz8hG9A3mN clfbfawX1EsuAkbd9A.A.mVPOMW.AXGuPoYkSef88nh22xZ8wwbS2fkGq0ck REP_QUarjI3dIQJM1qmXGWE9Lm2tHZHsF7WQDlWnH4Zw4fR8xRPx2dQRqiWl j4n_WDkXUBvy6cN2gG81JfM7wnzI7OXsvtvchDlXS8ugmuTfg211qoYF33cV TklB3oC.Ng2sfFdZysMbFqhe0FG5XmlRV.pVz8OP4x4QcPcmkrA9vazFf9R3 beiNoiqEDbAHrxkGP9rjOOFKOe9RBovhA3tZJRn0uTZae40KK1kAfzUZNfaP NC_5y6u3PI3Ewcg-- Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Mon, 01 Oct 2012 02:45:43 PDT X-Mailer: YahooMailWebService/0.8.122.442 References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> Message-ID: <1349084743.97421.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Mon, 1 Oct 2012 02:45:43 -0700 (PDT) From: Mark ZZZ Smith To: Daniel Roesen , "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" In-Reply-To: <20121001000808.GB25686@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:45:56 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Daniel Roesen =0A> To: v6ops@ietf.org; "draft-byrne-v6ops-64share@tools.ietf.org" =0A> Cc: =0A> Sent: Monday, 1 Octob= er 2012 10:08 AM=0A> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64sh= are=0A> =0A> On Sat, Sep 29, 2012 at 02:50:49PM -0700, Cameron Byrne wrote:= =0A>> On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke)=0A>> wrote:=0A>> > Isn't it easier to copy the MTU option from the= RA received by the =0A> handset to the RA sent on the LAN? Of course, when= there is no MTU option in the =0A> received RA on the WAN link, then, a SH= OULD set MTU option to 1480 seems good=0A>> =0A>> Yes, this will be the lo= gic that we will bring to the text of=0A>> draft-binet-v6ops-cellular-host= -reqs-rfc3316update=0A> =0A> I strongly disagree with that. Let PMTUD do it= s work, it's there=0A> for that. I really really don't want to see routers = on a LAN=0A> arbitrarily mucking around with the LAN MTU to work around ran= dom=0A> problems of upstream infrastructure.=0A> =0A> This artificial MTU l= owering in the LAN also breaks connectivity with=0A> nodes statically confi= gured, disregarding RAs. Suddenly you have nodes=0A> with interface MTU=3D1= 500 trying to communicated with other nodes on the=0A> same LAN with other,= RA-derrived lower MTUs...=0A>=A0=0A=0ARAs are for more than just announcin= g a default router, they're for all network layer parameters (perhaps "Netw= ork Layer Configuration Protocol" might have been a better name than Router= Advertisements). Even a statically addressed host should be listening to t= hem, as they'll inform it of all of the on-link prefixes, including the pre= fix it's address comes from. Unlike IPv4, in IPv6, a host does not assume t= hat other addresses that fall within it's configured prefixes are on-link -= they learn that information from the Prefix Information Option in the RAs.= A host with a static IPv6 address that is ignoring RAs will send all of it= 's traffic to it's default router, regardless of whether the destination ad= dress falls within the prefix that the static address is assigned from. Thi= s could be useful where the router is also performs some sort of policy enf= orcement or traffic accounting.=0A=0AIt's a subtle but significant differen= ce between IPv4 and IPv6. See RFC5942, "IPv6 Subnet Model: The Relationship= between Links and Subnet=A0Prefixes".=0A=0ARegards,=0AMark. From dr@cluenet.de Mon Oct 1 02:55:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1293321F85F0 for ; Mon, 1 Oct 2012 02:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5asufdA4qPA8 for ; Mon, 1 Oct 2012 02:55:18 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3137E21F85EF for ; Mon, 1 Oct 2012 02:55:18 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 95E0E1087AE; Mon, 1 Oct 2012 11:55:16 +0200 (CEST) Date: Mon, 1 Oct 2012 11:55:16 +0200 From: Daniel Roesen To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Message-ID: <20121001095516.GA9562@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:55:19 -0000 On Mon, Oct 01, 2012 at 03:17:33PM +0900, Lorenzo Colitti wrote: > On Mon, Oct 1, 2012 at 9:08 AM, Daniel Roesen wrote: > > > I strongly disagree with that. Let PMTUD do its work, it's there > > for that. I really really don't want to see routers on a LAN > > arbitrarily mucking around with the LAN MTU to work around random > > problems of upstream infrastructure. > > > > Bad idea. PMTUD causes a ~1 RTT latency hit to every new server you talk to. Well, that's life. If you want to avoid PMTUD at all cost, restrict everything to 1280 in the first place. BTW, ~1 RTT between which nodes? Certainly not between the user's client and the server being connected, but just between the user's client and the mobile device. If you really care about delay, MSS clamping is an option which isn't intrusive to the LAN as it affects only connections via the mobile gateway. > Why do you need 1500 anyway? Pardon? > So that devices talking to each other via the phone's hotspot (!) Misconception. We're discussing of messing with RAs to the LAN. Wether that's a WiFi hotspot, or a wired link, or a WiFi link to a WiFi bridge into a wired LAN doesn't matter. > can use 1500-byte packets instead of 1480-byte packets, > thus gaining a whopping 0.05% performance boost? ((1440÷1500) / (1420÷1480) > - 1) It's not a matter of performance. It's a matter of mucking around with a shared network's MTU dependent on the MTU of some uplink WAN interface. That's just wrong. The mobile device isn't necessarily the "boss on the link" but just a participant offering default routing (at time where it has a working WAN link, that is). > That's really not worth the latency hit. I beg to differ, for reasons of technical correctness, not throughput. What happens when some other router exists in the LAN, with a different notion of LAN link MTU? What about endpoints that do ignore MTU received in RAs? (I think I observed several that flat-out do ignore MTU) > Statically configured addresses on the tethering hotspot? How would that > even happen, given that in most cases your prefix is dynamically assigned? > If you don't know the prefix in advance, you can't configure the address. "most cases" - what about business connections with static prefixes? Oh, and it's not a handset, but a SOHO backup router. You have a specific deployment scenario in mind, but your approach breaks others. Not good. Perhaps I'm confused? Do I miss something? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From ietf@meetecho.com Mon Oct 1 02:58:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD4D21F8617 for ; Mon, 1 Oct 2012 02:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.717 X-Spam-Level: * X-Spam-Status: No, score=1.717 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT2qbJ3y7FB8 for ; Mon, 1 Oct 2012 02:58:13 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out12.aruba.it [62.149.158.32]) by ietfa.amsl.com (Postfix) with SMTP id 74AEB21F860E for ; Mon, 1 Oct 2012 02:58:12 -0700 (PDT) Received: (qmail 27282 invoked by uid 89); 1 Oct 2012 09:58:09 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq04.aruba.it with SMTP; 1 Oct 2012 09:58:09 -0000 Received: (qmail 31534 invoked by uid 89); 1 Oct 2012 09:58:09 -0000 Received: from unknown (HELO ?143.225.229.163?) (alex@meetecho.com@143.225.229.163) by smtp8.ad.aruba.it with ESMTPA; 1 Oct 2012 09:58:09 -0000 Message-ID: <50696923.2010307@meetecho.com> Date: Mon, 01 Oct 2012 11:57:55 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [v6ops] Meetecho session recording available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:58:13 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS session at IETF interim in Amsterdam is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf-interim/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From dr@cluenet.de Mon Oct 1 03:04:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7449A21F84AF for ; Mon, 1 Oct 2012 03:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwAU4WZdHeLT for ; Mon, 1 Oct 2012 03:04:20 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F221F84AE for ; Mon, 1 Oct 2012 03:04:19 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id EEC961087AE; Mon, 1 Oct 2012 12:04:18 +0200 (CEST) Date: Mon, 1 Oct 2012 12:04:18 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20121001100418.GB9562@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:04:20 -0000 On Sun, Sep 30, 2012 at 06:49:52PM -0700, Cameron Byrne wrote: > That said, it is not "arbitrarily mucking around with the LAN MTU to > work around random problems" > > It is in fact deterministicly working around a systemic problem in > 3GPP network using the correct IETF tools to do so: RA MTU info. MTUs were never meant to get "propagated" but are a link-specific attribute. Tying link A MTU to link B MTU is just wrong. > Keep in mind, this problem is "solved" today by "adjusting" the MSS in > HTTP proxies, which are also common in 3GPP networks. Nobody asked > for the IETF's permission for this pervasive yet effective technique > (which is also common in DSL network, and will soon popup in DS-lite > networks... but IPv4 does not have RA to communicate the MTU) I'm well aware of that, having deployed DS-Lite in residential access network with tunnel payload MTU 1460 and LAN MTU 1500, using MSS clamping to optimize for Lorenzo's considerations. Works beautifully. MSS clamping is a far "better" hack for the problem discussed than mucking with LAN MTUs. > Yes, PMTU will discover the correct MTU. But why not start out in the > right place? Because it's only the "right place" for WAN-facing traffic, not for traffic within the LAN. > If the 3GPP network operator knows that the MTU is of > the WAN link is 1440, why not cascade the information down via RA ? Again, because you're influencing intra-LAN communication as well. > > This artificial MTU lowering in the LAN also breaks connectivity with > > nodes statically configured, disregarding RAs. Suddenly you have nodes > > with interface MTU=1500 trying to communicated with other nodes on the > > same LAN with other, RA-derrived lower MTUs... > > PMTU will be quicker and more effective in a LAN than a WAN if this > problem occurs. Can you elaborate? Two hosts trying to communicate with different MTU settings on their interfaces will just lead to traffic blackholing, as the node with the smaller MTU setting will just discard "too large" packets. There is no router which will send "packet too big, max XYZ". Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From tore.anderson@redpill-linpro.com Mon Oct 1 03:15:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4AA21F8551 for ; Mon, 1 Oct 2012 03:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgThHRTDqgPO for ; Mon, 1 Oct 2012 03:15:32 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 673ED21F852E for ; Mon, 1 Oct 2012 03:15:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 6EF9A1820014 for ; Mon, 1 Oct 2012 12:15:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtJttQ5Rme-Q; Mon, 1 Oct 2012 12:15:31 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id F03E0182003C; Mon, 1 Oct 2012 12:15:30 +0200 (CEST) Message-ID: <50696D42.5050906@redpill-linpro.com> Date: Mon, 01 Oct 2012 12:15:30 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001100418.GB9562@srv03.cluenet.de> In-Reply-To: <20121001100418.GB9562@srv03.cluenet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:15:33 -0000 * Daniel Roesen > Can you elaborate? Two hosts trying to communicate with different MTU > settings on their interfaces will just lead to traffic blackholing, as > the node with the smaller MTU setting will just discard "too large" > packets. There is no router which will send "packet too big, max XYZ". I think you are confusing MTU with MRU here. A host with a interface MTU of, say, 1280 may very well be capable of receiving and processing 1500 byte large packets. MTU is the Maximum *Transmission* Unit, it has nothing to do with receiving behaviour. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From swmike@swm.pp.se Mon Oct 1 03:26:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844CE21F85B6 for ; Mon, 1 Oct 2012 03:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcugCD-yNFIR for ; Mon, 1 Oct 2012 03:26:42 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D4C7B21F8578 for ; Mon, 1 Oct 2012 03:26:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EBFD1A0; Mon, 1 Oct 2012 12:26:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E5D869F; Mon, 1 Oct 2012 12:26:38 +0200 (CEST) Date: Mon, 1 Oct 2012 12:26:38 +0200 (CEST) From: Mikael Abrahamsson To: Daniel Roesen In-Reply-To: <20121001095516.GA9562@srv03.cluenet.de> Message-ID: References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:26:42 -0000 On Mon, 1 Oct 2012, Daniel Roesen wrote: > BTW, ~1 RTT between which nodes? Certainly not between the user's client > and the server being connected, but just between the user's client and > the mobile device. User device sends SYN with MTU 1500 based MSS. After a while server will most likely start sending 1500 byte frames, which will get PMTUD PTB message from the GGSN (the network facing device which does GTP encapsulation). That's where the problematic RTT is. > If you really care about delay, MSS clamping is an option which isn't > intrusive to the LAN as it affects only connections via the mobile > gateway. But it only helps TCP, not everything else. > It's not a matter of performance. It's a matter of mucking around with a > shared network's MTU dependent on the MTU of some uplink WAN interface. > That's just wrong. The mobile device isn't necessarily the "boss on the > link" but just a participant offering default routing (at time where it > has a working WAN link, that is). I wish we had a way to put a separate MTU on just the default route being installed due to seeing RA, instead of just being able to set MTU on the LAN. > What happens when some other router exists in the LAN, with a different > notion of LAN link MTU? What about endpoints that do ignore MTU received > in RAs? (I think I observed several that flat-out do ignore MTU) Then we will see GTP fragmentation, but at least most cases will mean we will not see GTP fragmentation. The aim is to keep it down, not eliminate it completely. -- Mikael Abrahamsson email: swmike@swm.pp.se From dr@cluenet.de Mon Oct 1 04:55:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3B21F85B4 for ; Mon, 1 Oct 2012 04:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTp4o2a2MPAL for ; Mon, 1 Oct 2012 04:55:25 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id AA09221F85BB for ; Mon, 1 Oct 2012 04:55:25 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 187801087AE; Mon, 1 Oct 2012 13:55:24 +0200 (CEST) Date: Mon, 1 Oct 2012 13:55:24 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20121001115524.GA23182@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001100418.GB9562@srv03.cluenet.de> <50696D42.5050906@redpill-linpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50696D42.5050906@redpill-linpro.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:55:26 -0000 On Mon, Oct 01, 2012 at 12:15:30PM +0200, Tore Anderson wrote: > > Can you elaborate? Two hosts trying to communicate with different MTU > > settings on their interfaces will just lead to traffic blackholing, as > > the node with the smaller MTU setting will just discard "too large" > > packets. There is no router which will send "packet too big, max XYZ". > > I think you are confusing MTU with MRU here. A host with a interface MTU > of, say, 1280 may very well be capable of receiving and processing 1500 > byte large packets. MTU is the Maximum *Transmission* Unit, it has > nothing to do with receiving behaviour. Do you know any popular host implementation distinguishing MTU and MRU? Last time I looked at the Linux Ethernet+IP stack, it didn't differentiate, as far as I can remember. Anything above MTU setting gets dropped. In fact, the Linux kernel doesn't even have the infrastructure in the netdev struct to distinguish both. Oh, and devices happen to reset their interface when MTU changes (I confirmed in code of the e1000 driver), sometimes results in link flaps, usually breaking all higher-level sessions crossing that link that way. Anyway, you cannot rely on a node being able to receive packets/frames that are larger than the configured MTU. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Mon Oct 1 05:01:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E056B21F8606 for ; Mon, 1 Oct 2012 05:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCS7CTMr5u2d for ; Mon, 1 Oct 2012 05:01:58 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id DD37021F8679 for ; Mon, 1 Oct 2012 05:01:57 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 2F7521087AE; Mon, 1 Oct 2012 14:01:57 +0200 (CEST) Date: Mon, 1 Oct 2012 14:01:57 +0200 From: Daniel Roesen To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Message-ID: <20121001120157.GB23182@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:01:59 -0000 On Mon, Oct 01, 2012 at 12:26:38PM +0200, Mikael Abrahamsson wrote: > On Mon, 1 Oct 2012, Daniel Roesen wrote: > >> BTW, ~1 RTT between which nodes? Certainly not between the user's client >> and the server being connected, but just between the user's client and the >> mobile device. > > User device sends SYN with MTU 1500 based MSS. After a while server will > most likely start sending 1500 byte frames, which will get PMTUD PTB > message from the GGSN (the network facing device which does GTP > encapsulation). That's where the problematic RTT is. Oh, you're completely right. OK, so it's server-GGSN RTT, correct. >> If you really care about delay, MSS clamping is an option which isn't >> intrusive to the LAN as it affects only connections via the mobile >> gateway. > > But it only helps TCP, not everything else. LAN MTU trickery doesn't either. > I wish we had a way to put a separate MTU on just the default route being > installed due to seeing RA, instead of just being able to set MTU on the > LAN. Indeed. But RA MTU signalling is about a _link_, not a path (like the default route). Don't abuse it for that, pretty please. :) >> What happens when some other router exists in the LAN, with a different >> notion of LAN link MTU? What about endpoints that do ignore MTU received >> in RAs? (I think I observed several that flat-out do ignore MTU) > > Then we will see GTP fragmentation, but at least most cases will mean we > will not see GTP fragmentation. The aim is to keep it down, not eliminate > it completely. MSS clamping will do that just fine. Or do you see relevant amount of non-TCP traffic with relevant high packet sizes in those mobile networks? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From swmike@swm.pp.se Mon Oct 1 05:26:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84D1F0C54 for ; Mon, 1 Oct 2012 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrVVQ59crpYW for ; Mon, 1 Oct 2012 05:26:58 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8F22421F884E for ; Mon, 1 Oct 2012 05:26:58 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0ECA99E; Mon, 1 Oct 2012 14:26:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 083779C; Mon, 1 Oct 2012 14:26:57 +0200 (CEST) Date: Mon, 1 Oct 2012 14:26:57 +0200 (CEST) From: Mikael Abrahamsson To: Daniel Roesen In-Reply-To: <20121001120157.GB23182@srv03.cluenet.de> Message-ID: References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> <20121001120157.GB23182@srv03.cluenet.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:26:59 -0000 On Mon, 1 Oct 2012, Daniel Roesen wrote: >> I wish we had a way to put a separate MTU on just the default route being >> installed due to seeing RA, instead of just being able to set MTU on the >> LAN. > > Indeed. But RA MTU signalling is about a _link_, not a path (like the > default route). Don't abuse it for that, pretty please. :) I wouldn't call it abuse, I think it's the least bad option. If RA had a default route MTU option, we wouldn't need to lower LAN MTU. > MSS clamping will do that just fine. Or do you see relevant amount of > non-TCP traffic with relevant high packet sizes in those mobile > networks? Isn't MSS clamping even worse hackery? Why do you prefer MSS clamping above changing the MTU? If we change the MTU, then all the standard tools (PMTUD) should work as designed. If it doesn't, then why not fix that instead? -- Mikael Abrahamsson email: swmike@swm.pp.se From tore.anderson@redpill-linpro.com Mon Oct 1 05:44:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5221F8793 for ; Mon, 1 Oct 2012 05:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJuJS8QsMAx8 for ; Mon, 1 Oct 2012 05:44:22 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0221F878B for ; Mon, 1 Oct 2012 05:44:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 833131820015 for ; Mon, 1 Oct 2012 14:44:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8l7mih3hNUM; Mon, 1 Oct 2012 14:44:18 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id C0895182003E; Mon, 1 Oct 2012 14:44:18 +0200 (CEST) Message-ID: <50699022.9020207@redpill-linpro.com> Date: Mon, 01 Oct 2012 14:44:18 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001100418.GB9562@srv03.cluenet.de> <50696D42.5050906@redpill-linpro.com> <20121001115524.GA23182@srv03.cluenet.de> In-Reply-To: <20121001115524.GA23182@srv03.cluenet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:44:23 -0000 * Daniel Roesen > Do you know any popular host implementation distinguishing MTU and MRU? > Last time I looked at the Linux Ethernet+IP stack, it didn't differentiate, > as far as I can remember. Anything above MTU setting gets dropped. In > fact, the Linux kernel doesn't even have the infrastructure in the > netdev struct to distinguish both. 192.168.0.42 is running Linux 3.5.4, Fedora 17. "ping -M do -s 1472 192.178.0.42" running on the 192.158.0.2 host - starting out with an MTU of 1500 on both hosts: 14:26:35.075642 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1500) 192.168.0.2 > 192.168.0.42: ICMP echo request, id 10293, seq 114, length 1480 14:26:35.075677 IP (tos 0x0, ttl 64, id 26631, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.0.42 > 192.168.0.2: ICMP echo reply, id 10293, seq 114, length 1480 [running "ip link set mtu 1280 dev em1" on 192.168.0.42 here] 14:26:41.077492 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1500) 192.168.0.2 > 192.168.0.42: ICMP echo request, id 10293, seq 120, length 1480 14:26:41.077538 IP (tos 0x0, ttl 64, id 26518, offset 0, flags [+], proto ICMP (1), length 1276) 192.168.0.42 > 192.168.0.2: ICMP echo reply, id 10293, seq 120, length 1256 14:26:41.077617 IP (tos 0x0, ttl 64, id 26518, offset 1256, flags [none], proto ICMP (1), length 244) 192.168.0.42 > 192.168.0.2: icmp [...] 14:26:46.076060 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1500) 192.168.0.2 > 192.168.0.42: ICMP echo request, id 10293, seq 125, length 1480 14:26:46.076104 IP (tos 0x0, ttl 64, id 26523, offset 0, flags [+], proto ICMP (1), length 1276) 192.168.0.42 > 192.168.0.2: ICMP echo reply, id 10293, seq 125, length 1256 14:26:46.076110 IP (tos 0x0, ttl 64, id 26523, offset 1256, flags [none], proto ICMP (1), length 244) 192.168.0.42 > 192.168.0.2: icmp [running "ip link set mtu 1500 dev em1" on 192.168.0.42 here] 14:26:51.075830 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1500) 192.168.0.2 > 192.168.0.42: ICMP echo request, id 10293, seq 130, length 1480 14:26:51.075883 IP (tos 0x0, ttl 64, id 26518, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.0.42 > 192.168.0.2: ICMP echo reply, id 10293, seq 130, length 1480 So, as you can see, reducing the MTU did not in any way impair .42's ability to receive, process, and respond to .2's full-sized packets. However, it had to start fragmenting its responses, which is as expected. > Oh, and devices happen to reset their interface when MTU changes (I > confirmed in code of the e1000 driver), sometimes results in link flaps, > usually breaking all higher-level sessions crossing that link that way. Four packets were lost in my tcpdump, but this wasn't something the higher level protocols didn't deal with like any other packet loss. My Spotify stream didn't skip a beat, for example. .42 has a Intel 82579LM GE LOM NIC btw (desktop/consumer grade stuff). > Anyway, you cannot rely on a node being able to receive packets/frames > that are larger than the configured MTU. Perhaps not. But you can certainly not rely on the configured MTU having anything to do with the effective MRU value, as demonstrated above. I'm guessing that in the common case, the MRU is determined by limitations in the chipset. The MTU, on the other hand, is a setting in the OS networking stack (which obviously may not be set arbitrarily high without eventually running into some chipset limitation). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From despres.remi@laposte.net Mon Oct 1 06:34:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE5021F88F1 for ; Mon, 1 Oct 2012 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3XkJr2B+zKe for ; Mon, 1 Oct 2012 06:34:35 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4900021F8873 for ; Mon, 1 Oct 2012 06:34:33 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id 67E4F700030F; Mon, 1 Oct 2012 15:34:30 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2219.sfr.fr (SMTP Server) with ESMTP id DEA517000065; Mon, 1 Oct 2012 15:34:29 +0200 (CEST) X-SFR-UUID: 20121001133429912.DEA517000065@msfrf2219.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 1 Oct 2012 15:34:29 +0200 Message-Id: <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> To: Daniel Roesen , Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] LAN vs WAN MTUs (was new draft: draft-byrne-v6ops-64share) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:34:35 -0000 Hi, Daniel, Mikael,=20 2012-10-01 12:26, Mikael Abrahamsson : > On Mon, 1 Oct 2012, Daniel Roesen wrote: > ... >> If you really care about delay, MSS clamping is an option which isn't = intrusive to the LAN as it affects only connections via the mobile = gateway. >=20 > But it only helps TCP, not everything else. Since it does help TCP and doesn't hurt anything, it's IMHO worth = recommending. FYI, something was proposed about this in May, ref. = www.ietf.org/mail-archive/web/v6ops/current/msg13015.html, namely: "In any node, before entering of just after leaving a link whose MTU is = the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS = advertised in a received TCP SYN packet exceeds the link MTU minus the = TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it to this = value, and adjust IP and TCP checksums accordingly." In principle, I can't any longer afford to be active in v6ops, but still = look at some of the exchanged mails and may provide brief comments. Dan = Wing is added as cc because he privately said in May he liked this = proposed behavior. Regards, RD From Fred.L.Templin@boeing.com Mon Oct 1 08:59:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6111E8112 for ; Mon, 1 Oct 2012 08:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROfGOKN9kocd for ; Mon, 1 Oct 2012 08:59:26 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7311E8117 for ; Mon, 1 Oct 2012 08:59:25 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q91FxOKF024768 for ; Mon, 1 Oct 2012 08:59:24 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q91FxN9T024745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Oct 2012 08:59:23 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 1 Oct 2012 08:59:23 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Daniel Roesen , Mikael Abrahamsson Date: Mon, 1 Oct 2012 08:59:22 -0700 Thread-Topic: [v6ops] LAN vs WAN MTUs (was new draft: draft-byrne-v6ops-64share) Thread-Index: Ac2f3bQWxZVT3OrKR7us6u/TWGjAmQADqzug Message-ID: References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net> In-Reply-To: <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: v6ops WG Subject: Re: [v6ops] LAN vs WAN MTUs (was new draft: draft-byrne-v6ops-64share) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:59:27 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > R=E9mi Despr=E9s > Sent: Monday, October 01, 2012 6:34 AM > To: Daniel Roesen; Mikael Abrahamsson > Cc: v6ops WG > Subject: Re: [v6ops] LAN vs WAN MTUs (was new draft: draft-byrne-v6ops- > 64share) >=20 > Hi, Daniel, Mikael, >=20 > 2012-10-01 12:26, Mikael Abrahamsson : >=20 > > On Mon, 1 Oct 2012, Daniel Roesen wrote: > > ... > >> If you really care about delay, MSS clamping is an option which isn't > intrusive to the LAN as it affects only connections via the mobile > gateway. > > > > But it only helps TCP, not everything else. >=20 > Since it does help TCP and doesn't hurt anything, it's IMHO worth > recommending. >=20 > FYI, something was proposed about this in May, ref. www.ietf.org/mail- > archive/web/v6ops/current/msg13015.html, namely: > "In any node, before entering of just after leaving a link whose MTU is > the same in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS > advertised in a received TCP SYN packet exceeds the link MTU minus the > TCP/IP header length (40 octets in IPv4, 60 in IPv6), reduce it to this > value, and adjust IP and TCP checksums accordingly." >=20 > In principle, I can't any longer afford to be active in v6ops, but still > look at some of the exchanged mails and may provide brief comments. Dan > Wing is added as cc because he privately said in May he liked this > proposed behavior. The alternative of course is to fix tunnel MTU for good, as specified here: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag/ https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ Thanks - Fred fred.l.templin@boeing.com > Regards, > RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Mon Oct 1 13:28:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1851F0D5A for ; Mon, 1 Oct 2012 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl0Lar1RpL54 for ; Mon, 1 Oct 2012 13:28:15 -0700 (PDT) Received: from nm27-vm0.bullet.mail.ac4.yahoo.com (nm27-vm0.bullet.mail.ac4.yahoo.com [98.139.52.244]) by ietfa.amsl.com (Postfix) with SMTP id 5F8E91F0CD6 for ; Mon, 1 Oct 2012 13:28:15 -0700 (PDT) Received: from [98.139.52.188] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 01 Oct 2012 20:28:11 -0000 Received: from [98.139.52.177] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 01 Oct 2012 20:28:11 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 01 Oct 2012 20:28:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 618579.49772.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 42955 invoked by uid 60001); 1 Oct 2012 20:28:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1349123290; bh=oDas6ZV5N+Nb4GbOHRjnwaoMqdh1pTu2xaAWqgQn9xY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n8oXmFSH+24Onjav8c2SHB9TcbAVs4K9Uwn40W+EPQQt7rPYJxi5/xAUHecmZ0Vl3NqciifE1btzHk01KIFo/7DZ3sMn9EtEygBpw/L3n47lEooxr1s1kiTwfy8m0hfCxAONjxi0HHjdVY1MhGvTo103f9bU/1aOB0spowHOkl4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jv+ZirZjTtXZSPXgk4F/+jEgtlEAwPvRH2ekYYBQqBf0Asozn9J/QSTDE7DlUORkkHSew3nt4lZ8E0CE4BaZYhXqE66lcz3SNn1JXvH2MfGXzWo152Sc4WjMnV1SgFi/nwmpVjjSgmiSarA7iMCZ25qyV3/R5NS6GfRyxfdUTl8=; X-YMail-OSG: g.zQG5AVM1kn62uIWDKz8AZWxNhh_KNNPMvScYo_YWn0vqB NFURBmjDiOobpPgFn5E8B9KKwMPmarZcxgYsuWNcWzSjdme8LqsF4jv7ckMW BX8nGN.nbwjmdIQkmWL4y5mLiPuUBbpoo0Rjp.dxYlPzDfFumFqbfBbIIg0k yqnQnicIu6nkzypSwW6jN_gPYlT2Sgaf.B1Mught20Vq_oIXzt96wztOnNUA tNH4ySvC0X4rpxV3EZf__Y4eXesI7HxAJCughEgX7BlT2HNwwhXcoTQc5Zvk hnAiYD32ek3viHXck7XFsW_16FgafE0p_jYcYAnxsP7SQFXPnqNts1s5ztvQ O8_8gNEry.mLVz4AZXINgALm4En1caWB1.SdTwC.76t8qP7ZKRLKd0UGLaId KNokP4RTPs_X0JyMcQFChq2kv8UfrFailPWuI632LwpUmNVV2S66.7HLla4b O_Qlrps.vvKILAAZUhwHYkrQvQVVX3AJ31tMCUtmL5oW1xkxaPS8BJMjdcos r7O5bQ4wB7HHnZeK0Tj.alYTOr4kjO5Wi Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Mon, 01 Oct 2012 13:28:10 PDT X-Mailer: YahooMailWebService/0.8.122.442 References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001100418.GB9562@srv03.cluenet.de> Message-ID: <1349123290.35314.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Mon, 1 Oct 2012 13:28:10 -0700 (PDT) From: Mark ZZZ Smith To: Daniel Roesen , "v6ops@ietf.org" In-Reply-To: <20121001100418.GB9562@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 20:28:16 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Daniel Roesen =0A> To: v6ops@ietf.org=0A> Cc: =0A> Sent: Monday, 1 October 2012 8:04= PM=0A> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share=0A> =0A> = On Sun, Sep 30, 2012 at 06:49:52PM -0700, Cameron Byrne wrote:=0A>> That s= aid, it is not "arbitrarily mucking around with the LAN MTU to=0A>> work a= round random problems"=0A>> =0A>> It is in fact deterministicly working ar= ound a systemic problem in=0A>> 3GPP network using the correct IETF tools = to do so: RA MTU info.=0A> =0A> MTUs were never meant to get "propagated" b= ut are a link-specific=0A> attribute. Tying link A MTU to link B MTU is jus= t wrong.=0A>=A0=0A=0ACan you point to an RFC that says that? I don't think = there are any statements about where the MTU value used in an RA is allowed= or not allowed to come from.=0A=0AI think what is being proposed is a good= use for the RA MTU option.=A0=0A=0A=0A>> Keep in mind, this problem is "s= olved" today by =0A> "adjusting" the MSS in=0A>> HTTP proxies, which are a= lso common in 3GPP networks.=A0 Nobody asked=0A>> for the IETF's permissio= n for this pervasive yet effective technique=0A>> (which is also common in= DSL network, and will soon popup in DS-lite=0A>> networks... but IPv4 doe= s not have RA to communicate the MTU)=0A> =0A> I'm well aware of that, havi= ng deployed DS-Lite in residential access=0A> network with tunnel payload M= TU 1460 and LAN MTU 1500, using MSS=0A> clamping to optimize for Lorenzo's = considerations. Works beautifully.=0A>=A0=0A> MSS clamping is a far "better= " hack for the problem discussed than=0A=0A> mucking with LAN MTUs.=0A>=A0= =0A=0AI think MSS hacking is far worse than what is being proposed. It only= works for TCP, not UDP, DCCP, SCTP, GRE, IPsec etc., and also involves far= more work per packet when forwarding any packet (Is it TCP? Is it a TCP Sy= n? Where is the MSS Option (and in IPv6 that could behind a number of exten= sion headers)? Change the MSS value, re-calculate and update the TCP and IP= header checksums). Given that these devices are likely to be battery power= ed, this amount of additional per-packet processing could measurably shorte= n battery life.=0A=0A>> Yes, PMTU will discover the correct MTU.=A0 But wh= y not start out in the=0A>> right place?=0A> =0A> Because it's only the "r= ight place" for WAN-facing traffic, not =0A> for=0A> traffic within the LAN= .=0A> =0A>> If the 3GPP network operator knows that the MTU is of=0A>> th= e WAN link is 1440, why not cascade the information down via RA ?=0A> =0A> = Again, because you're influencing intra-LAN communication as well.=0A>=A0= =0A>> > This artificial MTU lowering in the LAN also breaks connectivity w= ith=0A=0A>> > nodes statically configured, disregarding RAs. Suddenly you = have nodes=0A>> > with interface MTU=3D1500 trying to communicated with ot= her nodes on the=0A>> > same LAN with other, RA-derrived lower MTUs...=0A>= > =0A>> PMTU will be quicker and more effective in a LAN than a WAN if thi= s=0A>> problem occurs.=0A> =0A> Can you elaborate? Two hosts trying to com= municate with different MTU=0A> settings on their interfaces will just lead= to traffic blackholing, as=0A> the node with the smaller MTU setting will = just discard "too large"=0A> packets. There is no router which will send "p= acket too big, max XYZ".=0A> =0A> Best regards,=0A> Daniel=0A> =0A> -- =0A>= CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0=0A> ___= ____________________________________________=0A> v6ops mailing list=0A> v6o= ps@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From marka@isc.org Mon Oct 1 17:50:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC221F890A for ; Mon, 1 Oct 2012 17:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2ohvCCVOLzn for ; Mon, 1 Oct 2012 17:50:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 18CCC21F8909 for ; Mon, 1 Oct 2012 17:50:49 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id DF699C958D; Tue, 2 Oct 2012 00:50:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9C6E7216C3D; Tue, 2 Oct 2012 00:50:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6C3E3282B59B; Tue, 2 Oct 2012 10:50:35 +1000 (EST) To: =?iso-8859-1?q?R=E9mi_Despr=E9s?= From: Mark Andrews References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net> In-reply-to: Your message of "Mon, 01 Oct 2012 15:34:29 +0200." <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net> Date: Tue, 02 Oct 2012 10:50:35 +1000 Message-Id: <20121002005035.6C3E3282B59B@drugs.dv.isc.org> Cc: v6ops WG , Daniel Roesen Subject: Re: [v6ops] LAN vs WAN MTUs (was new draft: draft-byrne-v6ops-64share) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 00:50:49 -0000 In message <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net>, =?iso-8859-1?q?R =E9mi_Despr=E9s?= writes: > Hi, Daniel, Mikael, > > 2012-10-01 12:26, Mikael Abrahamsson : > > > On Mon, 1 Oct 2012, Daniel Roesen wrote: > > ... > >> If you really care about delay, MSS clamping is an option which isn't intr > usive to the LAN as it affects only connections via the mobile gateway. > > > > But it only helps TCP, not everything else. > > Since it does help TCP and doesn't hurt anything, it's IMHO worth recommendin > g. It hurts everyone by not making sites aware that they need to generate and expect PTB packets. It hurts everyone because it lets sites that block all ICMP continue to operate despite the configuration being broken. It rewards bad behaviour. > FYI, something was proposed about this in May, ref. www.ietf.org/mail-archive > /web/v6ops/current/msg13015.html, namely: > "In any node, before entering of just after leaving a link whose MTU is the s > ame in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS advertised i > n a received TCP SYN packet exceeds the link MTU minus the TCP/IP header leng > th (40 octets in IPv4, 60 in IPv6), reduce it to this value, and adjust IP an > d TCP checksums accordingly." > > In principle, I can't any longer afford to be active in v6ops, but still look > at some of the exchanged mails and may provide brief comments. Dan Wing is a > dded as cc because he privately said in May he liked this proposed behavior. > > Regards, > RD > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Tue Oct 2 01:01:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCC321F8B55 for ; Tue, 2 Oct 2012 01:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWsOlBuBNv8j for ; Tue, 2 Oct 2012 01:01:20 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBF5021F8B54 for ; Tue, 2 Oct 2012 01:01:19 -0700 (PDT) Received: by iec9 with SMTP id 9so16228528iec.31 for ; Tue, 02 Oct 2012 01:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=MMGWj4F9gwivp2GVDTfOqqWhdwNfMhOfVuLnV2/+mkA=; b=TQrilx22mIduR3KOqOSxznMIBN56iN8Bq4oL0ZNrB8hNKjd0M8uNxY9KqfdkFjrcUf RdrkwhfWcEMXSs0mXvRBhth1yWjq3GOuGosvwmcIyFf/G1Ymv9iEzXJ95HCuJDu96tHh BLryXa63Iu0NB6YYbK4AwV82NhSTNvhKMeOfraATdtmpR4M/nEbcf0px5IPvJcbQcl5o PsDSqBy4i+3wr5yTm0EUZKqGwCmfgq6x/iBWnklLXrGTbqmW0r1Dq69W2qOdkCN60bYK 8mjgcSpFu0I+FbvS2eK6HtaiXLHbN3cJXPJtQFXPT5vTYICS0vRe987RUYDLNEn8R0fG Jowg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=MMGWj4F9gwivp2GVDTfOqqWhdwNfMhOfVuLnV2/+mkA=; b=dazzPtqukSnDx9BOrLl5Cmg3DaUbKyVB2AfChChm5csQRveqv6J9y7dU5vQEo5lmil ce/uOl9WYfWyeGun9PHDRKsEC2FGHPezjvesdQhS70u/eM94lAEAn3f4t7y3Lp2o/K/F gEINbxrZcLTemwx6bMzlaie1NyZegusbYZPwO+s6VB89RdemRKG/XznQIAtnzUnFZ3J+ TydpfP73yl+z3uHtP4LHQwSeeaL8F5lo+1VqEBYgvsdbtnTnWUAFn8AezmhEC1uQHBHS qo7xFLkVoDbh3oUS6ixDcYrF1PpmIOPdQ0gCN/svT47/IAWkYnsGZWFLUxtEnPHY2Xyj zpMg== Received: by 10.50.149.228 with SMTP id ud4mr8026746igb.16.1349164879256; Tue, 02 Oct 2012 01:01:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Tue, 2 Oct 2012 01:00:58 -0700 (PDT) In-Reply-To: <20121001095516.GA9562@srv03.cluenet.de> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> From: Lorenzo Colitti Date: Tue, 2 Oct 2012 17:00:58 +0900 Message-ID: To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba5935f1d6804cb0eed9a X-System-Of-Record: true X-Gm-Message-State: ALoCoQm/5GKBUrEmCRF5doYk6lEJ1guavXfhXrys0Va9FbckxFSpjxezGmRMwVcD49XUzoOKw3lni2W4eDRxkpiLQITWWzYac6/i92UksWjddaQb6MdDVSD9CZyszrPxj+eSrNhIQzeQfW2Y7hnK0i+xgJvtlkucVo1n2GlIf+Kv2FoONCCAqlSIDEVN6Rbv5+0D5dpe3nak Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:01:21 -0000 --e89a8f3ba5935f1d6804cb0eed9a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 1, 2012 at 6:55 PM, Daniel Roesen wrote: > > Bad idea. PMTUD causes a ~1 RTT latency hit to every new server you talk > to. > > Well, that's life. If you want to avoid PMTUD at all cost, restrict > everything to 1280 in the first place. > How? By statically configuring the MTU on all the hosts behind the phone and all the servers on the Internet? > BTW, ~1 RTT between which nodes? Certainly not between the user's client > and the server being connected, but just between the user's client and > the mobile device. > Not just between the client and the phone, but in the reverse path as well. If the MTU of the phone-GGSN link is 1480, then the first >1480 packet that the server sends to the client will cause the GGSN to send a "packet too big, MTU=1480" message back to the server. That's much more expensive and subject to loss than the path from the client to the phone. > If you really care about delay, MSS clamping is an option which isn't > intrusive to the LAN as it affects only connections via the mobile > gateway. > You're suggesting that the network rewrite all the TCP packets emitted by the hosts behind it, instead of informing said hosts that the MTU to every other address on the Internet is lower. That doesn't seem to make sense to me. > That's really not worth the latency hit. > > I beg to differ, for reasons of technical correctness, not throughput. > I would argue it's more correct to tell the hosts something ("if you send packets larger than this MTU, you're going to have a bad time") than to tell them nothing. The hosts are free to ignore the MTU - its use is only (lower-case) recommended by RFC 4861. > What happens when some other router exists in the LAN, with a different > notion of LAN link MTU? That router is is unable to offer bidirectional connectivity to hosts on the link, because if the hosts send it packets from the mobile carrier space, they get dropped by the ISP on the other side due to ingress filtering. What about endpoints that do ignore MTU received in RAs? (I think I > observed several that flat-out do ignore MTU) > They use PMTUD, which we all agree must work. > > Statically configured addresses on the tethering hotspot? How would that > > even happen, given that in most cases your prefix is dynamically > assigned? > > If you don't know the prefix in advance, you can't configure the address. > > "most cases" - what about business connections with static prefixes? Oh, > and it's not a handset, but a SOHO backup router. > Well, but it's a soho backup router with a /64 from that can't be routed but requires the whole environment to be bridged, and that doesn't allow the network to use the same IPv6 addresses that it uses when the main link is up. Not a great backup router. --e89a8f3ba5935f1d6804cb0eed9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 1, 2012 at 6:55 PM, Daniel Roesen <dr@cluenet.de> wr= ote:
> Bad idea. PMTUD causes a ~1 RTT latency hit to every= new server you talk to.

Well, that's life. If you want to avoid PMTUD at all cost, restri= ct
everything to 1280 in the first place.

= How? By statically configuring the MTU on all the hosts behind the phone an= d all the servers on the Internet?
=A0
BTW, ~1 RTT between which nodes? Certainly not between the user's clien= t
and the server being connected, but just between the user's client and<= br> the mobile device.

Not just between the= client and the phone, but in the reverse path as well.=A0If the MTU of the= phone-GGSN link is 1480, then the first >1480 packet that the server se= nds to the client will cause the GGSN to send a "packet too big, MTU= =3D1480" message back to the server. That's much more expensive an= d subject to loss than the path from the client to the phone.
=A0
If you really care about delay= , MSS clamping is an option which isn't
intrusive to the LAN as it affects only connections via the mobile
gateway.

You're suggesting that the= network rewrite all the TCP packets emitted by the hosts behind it, instea= d of informing said hosts that the MTU to every other address on the Intern= et is lower. That doesn't seem to make sense to me.

> That's really not worth the latency hit.

I beg to differ, for reasons of technical correctness, not throughput= .

I would argue it's more correct t= o tell the hosts something ("if you send packets larger than this MTU,= you're going to have a bad time") than to tell them nothing. The = hosts are free to ignore the MTU - its use is only (lower-case) recommended= by RFC 4861.
=A0
What happens when some other router exists in the LAN, with a different
notion of LAN link MTU?
=A0
That router is is un= able to offer bidirectional connectivity to hosts on the link, because if t= he hosts send it packets from the mobile carrier space, they get dropped by= the ISP on the other side due to ingress filtering.

What about endpoints that do = ignore MTU received=A0in RAs? (I think I observed several that flat-out do = ignore MTU)

They use PMTUD, which we all agree must wo= rk.
=A0
> Statically configured addresses on the tethering hot= spot? How would that
> even happen, given that in most cases your prefix is dynamically assig= ned?
> If you don't know the prefix in advance, you can't configure t= he address.

"most cases" - what about business connections with static = prefixes? Oh,
and it's not a handset, but a SOHO backup router.
=
Well, but it's a soho backup router with a /64 from that= can't be routed but requires the whole environment to be bridged, and = that doesn't allow the network to use the same IPv6 addresses that it u= ses when the main link is up. Not a great backup router.
--e89a8f3ba5935f1d6804cb0eed9a-- From despres.remi@laposte.net Tue Oct 2 01:18:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1ABD21F8B42 for ; Tue, 2 Oct 2012 01:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQbO8LTJagoI for ; Tue, 2 Oct 2012 01:18:17 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id B059721F8B3F for ; Tue, 2 Oct 2012 01:17:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 32D907000770; Tue, 2 Oct 2012 10:17:58 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id AAAD67000750; Tue, 2 Oct 2012 10:17:57 +0200 (CEST) X-SFR-UUID: 20121002081757699.AAAD67000750@msfrf2108.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <20121002005035.6C3E3282B59B@drugs.dv.isc.org> Date: Tue, 2 Oct 2012 10:17:57 +0200 Message-Id: <357D529A-C84D-4505-91C1-5CFA6BCA7427@laposte.net> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> <20121001095516.GA9562@srv03.cluenet.de> <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net> <20121002005035.6C3E3282B59B@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Daniel Roesen Subject: Re: [v6ops] LAN vs WAN MTUs (was new draft: draft-byrne-v6ops-64share) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:18:18 -0000 Le 2012-10-02 =E0 02:50, Mark Andrews a =E9crit : >=20 > In message <15E22D4F-CC95-45BD-9437-898E3A0862DF@laposte.net>, = =3D?iso-8859-1?q?R > =3DE9mi_Despr=3DE9s?=3D writes: >> Hi, Daniel, Mikael,=20 >>=20 >> 2012-10-01 12:26, Mikael Abrahamsson : >>=20 >>> On Mon, 1 Oct 2012, Daniel Roesen wrote: >>> ... >>>> If you really care about delay, MSS clamping is an option which = isn't intr >> usive to the LAN as it affects only connections via the mobile = gateway. >>>=20 >>> But it only helps TCP, not everything else. >>=20 >> Since it does help TCP and doesn't hurt anything, it's IMHO worth = recommendin >> g. >=20 > It hurts everyone by not making sites aware that they need to > generate and expect PTB packets. It hurts everyone because it lets > sites that block all ICMP continue to operate despite the = configuration > being broken. It rewards bad behaviour. Different understanding: (a) Gandma won't be hurt, on the contrary, if her applications that = happen to be TCP (without her being aware) work in more circumstances = than before. (She couldn't care less about PTB and ICMP!) (b) Proper PMTUD operation, with PTB propagation everywhere, is still = needed for UDP applications, and even for TCP applications if PMTU = bottlenecks are remote with no MSS clamping done where they take place. = It definitely remains a MUST. Some prefer to offer as good a service as possible *in the world as is* = (including with temporary PMTUD unreliability, a current fact of life).=20= Others, to accelerate worldwide debugging (they think), prefer to = purposely maintain for some customers adverse consequences of wrong = behaviors for which they aren't responsible.=20 Each one remains free to make his own choice. Regards, RD >=20 >> FYI, something was proposed about this in May, ref. = www.ietf.org/mail-archive >> /web/v6ops/current/msg13015.html, namely: >> "In any node, before entering of just after leaving a link whose MTU = is the s >> ame in both directions (Ethernet, 6rd, DS-lite, ...), if the MSS = advertised i >> n a received TCP SYN packet exceeds the link MTU minus the TCP/IP = header leng >> th (40 octets in IPv4, 60 in IPv6), reduce it to this value, and = adjust IP an >> d TCP checksums accordingly." >>=20 >> In principle, I can't any longer afford to be active in v6ops, but = still look >> at some of the exchanged mails and may provide brief comments. Dan = Wing is a >> dded as cc because he privately said in May he liked this proposed = behavior. >>=20 >> Regards, >> RD >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From randy@psg.com Tue Oct 2 03:13:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C971B21F8679 for ; Tue, 2 Oct 2012 03:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZumtTlhAflIM for ; Tue, 2 Oct 2012 03:13:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7013421F8674 for ; Tue, 2 Oct 2012 03:13:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TIzTg-000DlL-In for v6ops@ietf.org; Tue, 02 Oct 2012 10:13:24 +0000 Date: Tue, 02 Oct 2012 11:13:24 +0100 Message-ID: From: Randy Bush To: IETF v6ops list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:13:26 -0000 so, is double nat really worse than single nat? is it formally different? except in the case of overlapping spaces, of course. draft-donley-nat444-impacts-04.txt seems to back off reports of application issues. anyone care to swing the clue by four as to where multiple layers of nat are formally worse than one layer? randy From akaliwod@cisco.com Tue Oct 2 03:26:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6087321F8AC7 for ; Tue, 2 Oct 2012 03:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OBmIkHlai+n for ; Tue, 2 Oct 2012 03:26:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 70D5021F8ACC for ; Tue, 2 Oct 2012 03:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=784; q=dns/txt; s=iport; t=1349173580; x=1350383180; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w8f1G5hxaDAjPbPYhFVkSes5VoPIaZ2zfJ03cLACMq0=; b=LIZxgTti84eCcVvSixBK1N5iiHtNinK+LmxXW1DMJbFmU949b9XwaBUM p6sXs/K1Gq24t0EL9tzyKED8wCkMMu64/Y4qbjofhaSfefvhuGH83YWl5 cy4pFw9Xr1qsLJeivMKEE/nMPj1boyC4KGBA8NE89rKKMy4KAkKIkkBDI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABjBalCtJV2d/2dsb2JhbABFvlmBCIIhAQEEEgEnTwIBCCIUEDIlAgQBGhqHY5lzj1aQbpEFYAOkK4FpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="127413058" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 02 Oct 2012 10:26:08 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q92AQ7N7001895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Oct 2012 10:26:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.206]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 2 Oct 2012 05:26:07 -0500 From: "Arkadiusz Kaliwoda (akaliwod)" To: Randy Bush , IETF v6ops list Thread-Topic: [v6ops] double nat Thread-Index: AQHNoIanrO8XilLaAEy6aEJUa3GU6ZelzNpg Date: Tue, 2 Oct 2012 10:26:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.94.108] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19230.001 x-tm-as-result: No--32.770000-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 Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:26:21 -0000 so, is double nat really worse than single nat? is it formally different? = except in the case of overlapping spaces, of course. draft-donley-nat444-impacts-04.txt seems to back off reports of application= issues. anyone care to swing the clue by four as to where multiple layers= of nat are formally worse than one layer? [Kali] IMHO it is not only important how many NAT layers exist but where NA= T is implemented. DS-Lite is technically speaking NAT44 and it is no better= or worse imho from the NAT444; simply because in case of DS-Lite, NAT44 is= not where it should i.e. not at the home gateway. Then we move NAT44 back = to the home gateway, while keeping IPv6 transport, with MAP-E/T, and we hav= e yet another characteristics of NAT impact.=20 Kali From nick@inex.ie Tue Oct 2 04:17:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0539C21F8B18 for ; Tue, 2 Oct 2012 04:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa+LVE16QTQC for ; Tue, 2 Oct 2012 04:17:55 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E68021F8B11 for ; Tue, 2 Oct 2012 04:17:54 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q92BHSoP028903 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 12:17:28 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <506ACD5D.60907@inex.ie> Date: Tue, 02 Oct 2012 12:17:49 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: X-Enigmail-Version: 1.4.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 11:17:56 -0000 On 02/10/2012 11:13, Randy Bush wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. it's twice as secure, yo. Any questions? Nick From nick@inex.ie Tue Oct 2 04:24:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D194921F8A31 for ; Tue, 2 Oct 2012 04:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lRCocNlyhIx for ; Tue, 2 Oct 2012 04:24:22 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id EAFFA21F8A2F for ; Tue, 2 Oct 2012 04:24:15 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q92BNq0i028980 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 12:23:52 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <506ACEDD.2080501@inex.ie> Date: Tue, 02 Oct 2012 12:24:13 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: X-Enigmail-Version: 1.4.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 11:24:22 -0000 On 02/10/2012 11:13, Randy Bush wrote: > draft-donley-nat444-impacts-04.txt seems to back off reports of > application issues. anyone care to swing the clue by four as to > where multiple layers of nat are formally worse than one layer? on a slightly less facetious note, you will run into the problem that your feature set will be reduced to the lowest common denominator feature set of all the nat implementations on your network path + some delta breakage. For many services this probably won't make a whole pile of difference, but for protocols which require ALG support, you can run into difficulties either through implementation or policy. E.g. PASV followed by no PASV for ftp, broken sip implementations, etc. Nick From lorenzo@google.com Tue Oct 2 04:44:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B0021F8AFD for ; Tue, 2 Oct 2012 04:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IweOMGWeUvxh for ; Tue, 2 Oct 2012 04:44:06 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A79E21F85F0 for ; Tue, 2 Oct 2012 04:44:06 -0700 (PDT) Received: by oagn5 with SMTP id n5so7363032oag.31 for ; Tue, 02 Oct 2012 04:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=DHKV1mHDD/MIsuas4ithWaTFla3We0GUDwxKlG4Wu6U=; b=esOeRlK+1MpY67RLoP0VZVh+b9t5O7kYconm2eIlMkSCUCIk9jtIDym+cbfhlvEfoB zXzDicmgXOMQrRgIETEc2Mpy7vyfhk3xgJYKW0eR1c/UfFQA9jDZ5ohx3LzzdIXP8yNG xD/tIVBqK5xsgFeH0UF2i6FgNDdxa80Tbg0KJfc+oJE4PdQPOsET1P8v5PTX/w10hAGP dCZTZwUhVZ2efrM6V64kxD1nZjXFOlYzX6Y5waX/N866ORv3VeNc8JAjjHr4RGpQeBHm rjrbTRIQbywME3soeuyuYZwitubp0ocUbyMbA3neWqJmMUAiGJZ8hq0HfglR0AgzBQr5 J2kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=DHKV1mHDD/MIsuas4ithWaTFla3We0GUDwxKlG4Wu6U=; b=gW2ynOUd5zRRP4P5BDJYofNLP1PjVLGg3ZlHxAG6AnwoVT2CAb6Z7Qyz0F42FsB78z 0zQrpW8ns6UYBuX7eJsY44wuK6BpmCsedy9z4JKyL7cBJRdEz/BZJus8cVPTD1JdO8cE BUPCjkiN8xi6Vfx3sez60u67KkdoN4nYpJSLcFyKAv8BHQFG1AGQGu9klKvIGa/wIDck u15eyYpBRM/J5u5j/fRuLGi7IP+6jIk3ue+E1OL5yjCAZtbEt8VGMgUE9XiQPIDRnELh KKMbxrTKVWtmXNYe5DDWzF37CcMMyv6KGRqacBKfvbrfLOL54lC2MEP2Xs1X4zXOlnyW qc1Q== Received: by 10.182.160.7 with SMTP id xg7mr277641obb.46.1349178240279; Tue, 02 Oct 2012 04:44:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.104.66 with HTTP; Tue, 2 Oct 2012 04:43:40 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 2 Oct 2012 13:43:40 +0200 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=f46d0447f254c0255e04cb1209c1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl1nm4Y00wJTry2z+T6rcnsg9WSpXtQA+FJ0X8ryI5v5fI5UP34CfUXOrRnQtosBvcULw76B/adTIPAkpi6+WgL9GhP3sHWA64RUdTXWYTLMAJZoexzp3UL14+yHD78o5VbwiQfrFdpTEFqssNHiUOlXe1Lo5rGJjWTcCh+GTHVJTJ5s07g+8qQ1OGGFno2qZcdt6Oo Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 11:44:07 -0000 --f46d0447f254c0255e04cb1209c1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 2, 2012 at 12:13 PM, Randy Bush wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. > AIUI, double NAT requires you to use PCP if you want to open ports. If you only have one NAT, you can get by with UPNP, which while not particularly pretty is at least currently implemented. --f46d0447f254c0255e04cb1209c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 2, 2012 at 12:13 PM, Randy Bush <randy@psg.com> wr= ote:
so, is double nat really worse than single nat? =A0is it formally
different? =A0except in the case of overlapping spaces, of course.

AIUI, double NAT requires you to use PCP if you= want to open ports. If you only have one NAT, you can get by with UPNP, wh= ich while not particularly pretty is at least currently implemented.=A0
--f46d0447f254c0255e04cb1209c1-- From akaliwod@cisco.com Tue Oct 2 04:49:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13C821F8B21 for ; Tue, 2 Oct 2012 04:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGtHVAeSa5bC for ; Tue, 2 Oct 2012 04:49:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2623821F8B0F for ; Tue, 2 Oct 2012 04:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4138; q=dns/txt; s=iport; t=1349178564; x=1350388164; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KKaWKSFS11XtZ8xPZ84bEaw14MVoZBBr9rgRmGTV4co=; b=gqEq1SK2324JFrE1xNc+VaSsuyww21biUo5x2pRb9O0PFJEhhGybh3na xv+lwOtfjlG3NLtV8ez+hHxaBG3aIe0xNL37S3kVU5wNBNFiEnKdHKTTh 9WspcgSZdrVLDxKEYRUQlVElWOxlzn1yUT87pznJMTcnY/YsPiiZSC0Bb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANjTalCtJXHB/2dsb2JhbABFgku8DoEIgiEBAQQSARpMEAIBCAQeJDIlAgQBDQ0ah2OZRo9WkG2RBWADpCuBaYJnghc X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208,217";a="127427488" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 02 Oct 2012 11:49:23 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q92BnNm0021761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Oct 2012 11:49:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.206]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 2 Oct 2012 06:49:22 -0500 From: "Arkadiusz Kaliwoda (akaliwod)" To: Lorenzo Colitti , Randy Bush Thread-Topic: [v6ops] double nat Thread-Index: AQHNoIanrO8XilLaAEy6aEJUa3GU6ZemORkA//+s9gA= Date: Tue, 2 Oct 2012 11:49:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.94.108] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19230.001 x-tm-as-result: No--35.027700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_C7DD0A1145B71949BBD65DF56D408BA80F50D5A5xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 11:49:24 -0000 --_000_C7DD0A1145B71949BBD65DF56D408BA80F50D5A5xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable so, is double nat really worse than single nat? is it formally different? except in the case of overlapping spaces, of course. AIUI, double NAT requires you to use PCP if you want to open ports. If you = only have one NAT, you can get by with UPNP, which while not particularly p= retty is at least currently implemented. [Kali] When you move single NAT to the edge device, DS-Lite, PCP is also ne= eded. Again, it is equally important where NAT is, not only how many NAT la= yers we have. Then UPnP dependency problem is also popping up since state o= f UPnP IGD:2 support on both commercial gateways and applications is questi= onable. --_000_C7DD0A1145B71949BBD65DF56D408BA80F50D5A5xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

so, is double nat really worse than single nat? &nbs= p;is it formally
different?  except in the case of overlapping spaces, of course.<= /o:p>

 

AIUI, double NAT requires you to use PCP if you want= to open ports. If you only have one NAT, you can get by with UPNP, which w= hile not particularly pretty is at least currently implemented. <= /o:p>

 <= /p>

[Kali] When you move sing= le NAT to the edge device, DS-Lite, PCP is also needed. Again, it is equall= y important where NAT is, not only how many NAT layers we have. Then UPnP dependency problem is also popping up since state of UPnP = IGD:2 support on both commercial gateways and applications is questionable.=

--_000_C7DD0A1145B71949BBD65DF56D408BA80F50D5A5xmbrcdx04ciscoc_-- From gert@space.net Tue Oct 2 04:54:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4162121F8AC7 for ; Tue, 2 Oct 2012 04:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JyBLorCLBnZ for ; Tue, 2 Oct 2012 04:54:22 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id AABA121F896F for ; Tue, 2 Oct 2012 04:54:22 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9A995F8D8F for ; Tue, 2 Oct 2012 13:54:21 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 705F1F8D8C for ; Tue, 2 Oct 2012 13:54:21 +0200 (CEST) Received: (qmail 68734 invoked by uid 1007); 2 Oct 2012 13:54:21 +0200 Date: Tue, 2 Oct 2012 13:54:21 +0200 From: Gert Doering To: Randy Bush Message-ID: <20121002115421.GY13776@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 11:54:23 -0000 Hi, On Tue, Oct 02, 2012 at 11:13:24AM +0100, Randy Bush wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. > > draft-donley-nat444-impacts-04.txt seems to back off reports of > application issues. anyone care to swing the clue by four as to > where multiple layers of nat are formally worse than one layer? One of the problems with "someone else controls your NAT" is that you can't add port mappings. This seems to be an inevitable side effect of NAT444 (but can happen with single NAT44 as well, of course, depending on where it's placed). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From brian.e.carpenter@gmail.com Tue Oct 2 05:27:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5368221F8ABD for ; Tue, 2 Oct 2012 05:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4xabrltR5kJ for ; Tue, 2 Oct 2012 05:27:22 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC80521F8ABB for ; Tue, 2 Oct 2012 05:27:22 -0700 (PDT) Received: by iec9 with SMTP id 9so16709451iec.31 for ; Tue, 02 Oct 2012 05:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kNAedVrh1g8to7uIBqmlUXJTUKH8Kt2uKnqLdHjMmzc=; b=KBTGFZmfIkNt+xunAnzg3oixT8m4++RERrioEuQJ7NZvCOJyHOszOUYBiypk/zz47G uRJdmeOHXP5ZopeJtEovEY5AJexxvhashCM2EBxe4CDqcW8fyAlutxlVTnsKqtCDP/Rp MGmw3cjYcA636KGOQKOaqrym6wn6Ac4xxc8ZPAXDo7iTroRlq08xcADvHHpIbuFSZVln k5RZllIKyKcWPSOWK7f+0dEL/GveQKymCZ7+YehkQD/kazRtuHnls0S/CVBeMj+4eF5i PD4GIyYhqHBlECGSNK/2x1ICCLLSHxkpRAIaHJUKnaOlET+QhbKv0H0mL6m9b7hbrviZ W7Jg== Received: by 10.50.100.225 with SMTP id fb1mr8483397igb.12.1349180842399; Tue, 02 Oct 2012 05:27:22 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id q1sm691290igj.15.2012.10.02.05.27.21 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 05:27:21 -0700 (PDT) Message-ID: <506ADDA6.3030702@gmail.com> Date: Tue, 02 Oct 2012 13:27:18 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:27:23 -0000 On 02/10/2012 11:13, Randy Bush wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. > > draft-donley-nat444-impacts-04.txt seems to back off reports of > application issues. anyone care to swing the clue by four as to > where multiple layers of nat are formally worse than one layer? If you think the referrals problem is serious, multiple NAT makes it worse by creating additional addressing realms. The probability of losing a session due to NAT state loss is presumably greater when there are more NATs on the path. Brian From jared@puck.nether.net Tue Oct 2 05:42:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F9121F88BB for ; Tue, 2 Oct 2012 05:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5nKTUhZrBSM for ; Tue, 2 Oct 2012 05:42:05 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5695E21F889A for ; Tue, 2 Oct 2012 05:42:05 -0700 (PDT) Received: from [10.0.0.205] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q92Cg21H022829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Oct 2012 08:42:03 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3B167F13-459F-4705-AD99-8E77D2F73954@puck.nether.net> X-Mailer: iPad Mail (10A403) From: Jared Mauch Date: Tue, 2 Oct 2012 08:42:04 -0400 To: Randy Bush X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 02 Oct 2012 08:42:03 -0400 (EDT) Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:42:05 -0000 For users:=20 Only in the case of inbound traffic. The only devices that I am aware of thi= s majorly breaks is the Xbox 360. These also break when more than one is out= there as well. I'm sure there are others but for 98% of users it just looks like the intert= ubes to them. Now for the admins they need to worry about state and other resource exhaust= ion, but that's the case with single nat as well. - Jared=20 On Oct 2, 2012, at 6:13 AM, Randy Bush wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. From ipepelnjak@gmail.com Tue Oct 2 05:44:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A410521F87C9 for ; Tue, 2 Oct 2012 05:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB1nOjfoxS29 for ; Tue, 2 Oct 2012 05:44:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF28D21F87AD for ; Tue, 2 Oct 2012 05:44:26 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so5463870bkc.31 for ; Tue, 02 Oct 2012 05:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=avDN+DIBcbFMVV7G4KCxiR5ZJ+JidUBPMUmKi8DcCfs=; b=RZtynaCE4xmBPMdK1qgXHnKNqxN1SkUeJx6MfxPNcs1zA/2hw7Fs2cAJzE0v3Zgzc6 eomZ+riLAlJsTYiqVZ7fMC2OB3tQGZz2x6pUIU/3sPfJF4h77gD930gVZIGa4LNRoXEe efBuCcFZMYsHSrIk1T2btEG9tX6JAtxAAmUbgzd4K5e36PzEJXn3xBMgNFdoDQgbVAqX oal4aYq5jZJjrcVVf0g1rONfFbj1qBTDLjKcr8g9IdFzsfkwwBVpniM5hk/WrdeMyuH/ AJ22AYq7PRZ8ZCN4EBIjj1LDbpOka2q0SilQzpIDf2VVKXUhNCv+y1KicBfLpRKvkegJ pQsg== Received: by 10.204.148.12 with SMTP id n12mr6566962bkv.62.1349181865836; Tue, 02 Oct 2012 05:44:25 -0700 (PDT) Received: from Ivans-MacBook-Air.local ([193.110.145.6]) by mx.google.com with ESMTPS id gy18sm1097567bkc.4.2012.10.02.05.44.23 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 05:44:24 -0700 (PDT) Message-ID: <506AE1A6.8090802@gmail.com> Date: Tue, 02 Oct 2012 14:44:22 +0200 From: Ivan Pepelnjak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <506ADDA6.3030702@gmail.com> In-Reply-To: <506ADDA6.3030702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:44:27 -0000 I always wondered how P2P applications react when forced to deal with multiple addressing realms. Example: one host sits behind CGN and another one behind the same CGN and a CPE NAT. Will we get hairpinning through outside NAT (= CGN)? Any real-life experience with such a monstrosity? Ivan On 10/2/12 2:27 PM, Brian E Carpenter wrote: > On 02/10/2012 11:13, Randy Bush wrote: >> so, is double nat really worse than single nat? is it formally >> different? except in the case of overlapping spaces, of course. >> >> draft-donley-nat444-impacts-04.txt seems to back off reports of >> application issues. anyone care to swing the clue by four as to >> where multiple layers of nat are formally worse than one layer? > If you think the referrals problem is serious, multiple NAT makes it > worse by creating additional addressing realms. > > The probability of losing a session due to NAT state loss is presumably > greater when there are more NATs on the path. > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Tue Oct 2 05:54:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C2D21F8760 for ; Tue, 2 Oct 2012 05:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed25ivqceD8A for ; Tue, 2 Oct 2012 05:54:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 030CF21F8503 for ; Tue, 2 Oct 2012 05:54:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TJ1zx-000EAB-5a; Tue, 02 Oct 2012 12:54:53 +0000 Date: Tue, 02 Oct 2012 13:54:52 +0100 Message-ID: From: Randy Bush To: Gert Doering In-Reply-To: <20121002115421.GY13776@Space.Net> References: <20121002115421.GY13776@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:54:55 -0000 >> so, is double nat really worse than single nat? is it formally >> different? except in the case of overlapping spaces, of course. > One of the problems with "someone else controls your NAT" is that > you can't add port mappings. This seems to be an inevitable side > effect of NAT444 (but can happen with single NAT44 as well, of > course, depending on where it's placed). i asked *formally*. i am not concerned with all the ops, social, stuff. and not about issues not directly connected to the nat. what does double translation do that single does not? randy From martin@millnert.se Tue Oct 2 06:13:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3C21F8754 for ; Tue, 2 Oct 2012 06:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDAHCcO2rRAb for ; Tue, 2 Oct 2012 06:13:55 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 5352721F8665 for ; Tue, 2 Oct 2012 06:13:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id B43327AEA; Tue, 2 Oct 2012 15:09:30 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBJiWA8-DUTu; Tue, 2 Oct 2012 15:09:30 +0200 (CEST) Received: from [192.168.121.47] (h-165-144.a189.priv.bahnhof.se [37.123.165.144]) by ncis.csbnet.se (Postfix) with ESMTPSA id 155DCF3; Tue, 2 Oct 2012 15:09:29 +0200 (CEST) Message-ID: <1349183630.28287.1.camel@galileo.millnert.se> From: Martin Millnert To: Randy Bush Date: Tue, 02 Oct 2012 15:13:50 +0200 In-Reply-To: References: <20121002115421.GY13776@Space.Net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:13:56 -0000 On Tue, 2012-10-02 at 13:54 +0100, Randy Bush wrote: > what does double translation do that single does not? Formally, adds two translation tables while single NAT adds one. /M From gert@space.net Tue Oct 2 06:14:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B33E21F876E for ; Tue, 2 Oct 2012 06:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzSQjbYwY0fQ for ; Tue, 2 Oct 2012 06:14:05 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id B98F821F8762 for ; Tue, 2 Oct 2012 06:14:03 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1C008F8DD7 for ; Tue, 2 Oct 2012 15:14:03 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D5BB1F8DD3 for ; Tue, 2 Oct 2012 15:14:02 +0200 (CEST) Received: (qmail 93528 invoked by uid 1007); 2 Oct 2012 15:14:02 +0200 Date: Tue, 2 Oct 2012 15:14:02 +0200 From: Gert Doering To: Randy Bush Message-ID: <20121002131402.GC13776@Space.Net> References: <20121002115421.GY13776@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2q8i8dr6a1t7O97+" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:14:05 -0000 --2q8i8dr6a1t7O97+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Oct 02, 2012 at 01:54:52PM +0100, Randy Bush wrote: > >> so, is double nat really worse than single nat? is it formally > >> different? except in the case of overlapping spaces, of course. > > One of the problems with "someone else controls your NAT" is that > > you can't add port mappings. This seems to be an inevitable side > > effect of NAT444 (but can happen with single NAT44 as well, of > > course, depending on where it's placed). >=20 > i asked *formally*. i am not concerned with all the ops, social, > stuff. and not about issues not directly connected to the nat. > what does double translation do that single does not? OK, sorry, I misunderstood. =20 Just focusing on the technical aspects, I'd say a double-NAT doesn't do=20 anything different than a single NAT. This is assuming - identical implementations (like FTP ALGs that handle the same subset of PORT/PASV features, not different subsets in both NATs) - no shortage of port space on the second NAT (which is again one of the "real deployment" issues, not a pure theoretical "put two NAT boxes behind each other, without adding extra users" issue) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --2q8i8dr6a1t7O97+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUGromqkuBuNlUUl1AQJvsgQAnXehmkC5KVMprbGzjZS5LMjZygg/mYL6 7YX21cZvQUG6fgen/V1CtFdW8gB3M96zzD+HmqNMmj6uZGBKesratnPduVTGnFHG W+THxpYruR1rCCDHyK9afhzCWu6paWnZvRh/yZzqMeuw2hQZ83ZMNO5pnPZOqr9j K6zIu80xLg8= =Jc0g -----END PGP SIGNATURE----- --2q8i8dr6a1t7O97+-- From brian.e.carpenter@gmail.com Tue Oct 2 11:00:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDFF21F84DD for ; Tue, 2 Oct 2012 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsRj9FMT2GBx for ; Tue, 2 Oct 2012 11:00:19 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E977921F84F0 for ; Tue, 2 Oct 2012 11:00:18 -0700 (PDT) Received: by iec9 with SMTP id 9so17657206iec.31 for ; Tue, 02 Oct 2012 11:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=56bu4rGjxeRJ0SDbBkOAITuU9O+Z209TCMgsiWWcfio=; b=QoA1TX9tpggSCpt4Vl1p4CIgEeH5GDfV7FTI4SCHql9gBmpmCDV6BXKtwivvPgzV0Y dkacvOpPba7Qwt4kUZXJVcIslLbQ3P/U+3RhuJBUiYpDtn2rFZrTycFLWoJnqFjaMhWz le/4K74TlWEkuaZ1xs0HxwRdxOKX/x/GpY8MBfvmIeqIvh/gYs8yRySe+0njgSTqASWL JTkSfDNwdghet9Skw5XEQ3KQvTZkya847vr1B/+gXSKVO2ZHAmsK53MqHWX1A20/AK/u nX2dTWg/mdjthCHrEYO3BG6JGfdW1tNhwzuahO2k9CDASPbKV4apRKQZQRt4Tgqi9mBk duPQ== Received: by 10.50.202.73 with SMTP id kg9mr9706233igc.42.1349200818453; Tue, 02 Oct 2012 11:00:18 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id ez8sm1320104igb.17.2012.10.02.11.00.16 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 11:00:17 -0700 (PDT) Message-ID: <506B2BAE.3050905@gmail.com> Date: Tue, 02 Oct 2012 19:00:14 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20121002115421.GY13776@Space.Net> <20121002131402.GC13776@Space.Net> In-Reply-To: <20121002131402.GC13776@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:00:19 -0000 On 02/10/2012 14:14, Gert Doering wrote: > Hi, > > On Tue, Oct 02, 2012 at 01:54:52PM +0100, Randy Bush wrote: >>>> so, is double nat really worse than single nat? is it formally >>>> different? except in the case of overlapping spaces, of course. >>> One of the problems with "someone else controls your NAT" is that >>> you can't add port mappings. This seems to be an inevitable side >>> effect of NAT444 (but can happen with single NAT44 as well, of >>> course, depending on where it's placed). >> i asked *formally*. i am not concerned with all the ops, social, >> stuff. and not about issues not directly connected to the nat. >> what does double translation do that single does not? > > OK, sorry, I misunderstood. > > Just focusing on the technical aspects, I'd say a double-NAT doesn't do > anything different than a single NAT. I don't see how to separate the "formal" impact of NAT from environmental issues such as placement of middleboxes. If the traffic passes through some kind of upper-layer-aware middlebox in between the two NATs, I am sure the e2e result will be different than if the middlebox is at one side or the other of both NATs, assuming the middlebox messes with the IP header or packet size, or causes fragmentation. I doubt if there is any general statement to be made beyond that, due the variety of NAT behaviours and middlebox behaviours. I think that means that there isn't a guaranteed formal equivalence between the operation NAT() and the operation NAT(NAT()), because in the real world we might have NAT(MIDDLEBOX(NAT())). Another point is that geolocation will find the nearest NAT, and so will forensic traceback. Observational data: http://tools.ietf.org/html/draft-donley-nat444-impacts-05 > > This is assuming > > - identical implementations (like FTP ALGs that handle the same subset > of PORT/PASV features, not different subsets in both NATs) > - no shortage of port space on the second NAT (which is again one of > the "real deployment" issues, not a pure theoretical "put two NAT > boxes behind each other, without adding extra users" issue) Right, making a few false assumptions does simplify mathematics ;-) Brian From AAnchev@a10networks.com Tue Oct 2 11:39:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531221F8522 for ; Tue, 2 Oct 2012 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbFgAv+tmfkF for ; Tue, 2 Oct 2012 11:39:00 -0700 (PDT) Received: from mail.a10networks.com (mail.a10networks.com [12.207.16.167]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4921F8456 for ; Tue, 2 Oct 2012 11:39:00 -0700 (PDT) X-AuditID: c0a80b0a-b7faa6d0000014c5-cf-506b34c39967 Received: from webmail.a10networks.com (Unknown_Domain [192.168.1.101]) by mail.a10networks.com (Symantec Messaging Gateway) with SMTP id 64.65.05317.3C43B605; Tue, 2 Oct 2012 11:38:59 -0700 (PDT) Received: from SJ-MB02.corp.a10networks.com ([fe80::8022:2e09:bc7a:35fa]) by SJ-CASHT01.corp.a10networks.com ([fe80::fc72:b0c5:8503:b166%13]) with mapi id 14.02.0283.003; Tue, 2 Oct 2012 11:37:50 -0700 From: Andrew Anchev To: Jared Mauch , Randy Bush Thread-Topic: [v6ops] double nat Thread-Index: AQHNoIZ5WtpEVgxBm0aShD4FdNNTOZemavIA///VVKA= Date: Tue, 2 Oct 2012 18:37:49 +0000 Message-ID: <4D992130DD0EFA478BB1173F595F22DB01034413@SJ-MB02.corp.a10networks.com> References: <3B167F13-459F-4705-AD99-8E77D2F73954@puck.nether.net> In-Reply-To: <3B167F13-459F-4705-AD99-8E77D2F73954@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.122] Content-Type: multipart/related; boundary="_004_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsVyYAVjqu5hk+wAg/YGWYsri+6wWzxrfclk cfrYXmYHZo8lS34yeUydOZvRo7dpGmMAcxSXTUpqTmZZapG+XQJXxqH+G4wFh3pZKk4d7mJs YGz/xdzFyMkhIWAicWdLIyuELSZx4d56ti5GLg4hgeOMEv+bfzBDOGcZJS69/sEEUsUmoCvx df8GRhBbRMBZ4snyx0AdHBzMAioSm/64gJjCAvISHzYJQVQoSKzYt4EJwraSuPH1IyNICQtQ 9aO39SBhXoFgids79rGD2EICSRJzf15nAbE5gYZvuDAT7DRGoNO+n1oDNoZZQFzi1pP5TBAn i0g8vHiaDcIWlXj5+B/UK4oSDXveM0LUdzNKrNlQC7FLUOLkzCcsExhFZyEZNQtJ2SwkZRDx fImlXyczQtg6Egt2f2KDsLUlli18zQxjnznwmAlTXEfi97cuqHpFidtXp7LOAgYos8AyRok3 T9exwhT1vDgLVzSl+yH7AkbeVYwiuYmZOXqJhgZ5qSXl+UXZxXrJ+bmbGMEpgZtrB+Pa0waH GAU4GJV4eIsYswOEWBPLiitzDzFKcDArifBa388KEOJNSaysSi3Kjy8qzUktPsQozcGiJM5b XH7JX0ggPbEkNTs1tSC1CCbLxMEp1cCYckN28j3vbQv+Ra0MYZgXZ8s5t/NK3c/PNlvXqVT/ m+r65My3D5u2tj6R/JjvW7B8SsqxOc9l0qd+F5kvKP/9dkgbe0OL6OKlel481++uEuzm52Kz 27Tk1+ITF39K7T0VLv5y877LbvKR3Se2dlSx5qXyye5wbc4+YzH/wfGm/M/W22tm6hZOUmIp zkg01GIuKk4EAE1aFqUFAwAA Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:39:01 -0000 --_004_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_ Content-Type: multipart/alternative; boundary="_000_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_" --_000_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is this the issue you are referring to? [Description: cid:image001.png@01CC76CE.0EF06D80] This was corrected last December when Microsoft pushed out their latest OS = update to all of their users. Andy Anchev -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of J= ared Mauch Sent: Tuesday, October 02, 2012 5:42 AM To: Randy Bush Cc: IETF v6ops list Subject: Re: [v6ops] double nat For users: Only in the case of inbound traffic. The only devices that I am aware of th= is majorly breaks is the Xbox 360. These also break when more than one is o= ut there as well. I'm sure there are others but for 98% of users it just looks like the inter= tubes to them. Now for the admins they need to worry about state and other resource exhaus= tion, but that's the case with single nat as well. - Jared On Oct 2, 2012, at 6:13 AM, Randy Bush = > wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is this the issue you are referring to? <= /p>

 

3D"Description:

 

This was corrected last December when Microsoft push= ed out their latest OS update to all of their users.

 

Andy Anchev

 

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of J= ared Mauch
Sent: Tuesday, October 02, 2012 5:42 AM
To: Randy Bush
Cc: IETF v6ops list
Subject: Re: [v6ops] double nat

 

For users:

 

Only in the case of inbound traffic. The only dev= ices that I am aware of this majorly breaks is the Xbox 360. These also bre= ak when more than one is out there as well.

 

I'm sure there are others but for 98% of users it= just looks like the intertubes to them.

 

Now for the admins they need to worry about state= and other resource exhaustion, but that's the case with single nat as well= .

 

- Jared

 

On Oct 2, 2012, at 6:13 AM, Randy Bush <randy@psg.com> wrote:

 

> so, is double nat really worse than single n= at?  is it formally

> different?  except in the case of overl= apping spaces, of course.

_______________________________________________

v6ops mailing list

v6ops@ietf.org=

https://www.ie= tf.org/mailman/listinfo/v6ops

--_000_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_-- --_004_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=43475; creation-date="Tue, 02 Oct 2012 18:37:49 GMT"; modification-date="Tue, 02 Oct 2012 18:37:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAEOCAYAAABRmsRnAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAKloSURBVHhe7V0FmBTHEj7c3d3dg0MIQYIn6IPg kuAQJGhwd3e34O7u7u7B3d2lXv09O3uzc+u3dyvX8319tzvTWj3bf1d1iR/JS1JAUkBSQFJAUkBS INgp4BfsLcoGJQUkBSQFJAUkBSQFSAKwfAkkBSQFJAUkBSQF3EABCcBuILpsUlJAUkBSQFJAUkAC sHwHJAUkBSQFJAUkBdxAAQnAbiC6bFJSQFJAUkBSQFJAArB8ByQFJAUkBSQFJAXcQAEJwG4gumxS UkBSQFJAUkBSQAKwfAckBSQFJAUkBSQF3EABCcBuILpsUlJAUkBSQFJAUkACsHwHJAUkBSQFJAUk BdxAgWAH4HOn/GjUf1fdMFSlyUf/FaJO+0fTI7f1QDYsKSApICkgKSApQI57wgKAmgWwN6Np1GY/ WvBQT9artH0/lzm1QTyQAMxEeNiEOm1uQuesvYEiD9NNmww0NG4k+JmlzYy76ezRPy6L9De8qyrN eaO23dL7bhig+D0Y5kVs7vRztrkQbX+j2fxpnrtzI+rR8yM7JykQQijgOAdsYfEyLj4akFBouIEW aIDZFcAQGC42MGVd9k7YAGCxqAcAaKajGQDupFngtf1zBZ1dNl4XVOTSebOH/iqtRV5/EDUdium7 bb2PpvNHFjesLiCWrEJSIJgocPD2JNpxfVCA1vbeHEWnHiyko3dn0ZSjPxvTlv960aUnG03yP39/ g5aca2DMs/FKF3r/5QXdenFQ3NdfqBf1qNeJbnnp+oL29N2OMT87f4oen9hH7589pVO9C9GNuTXp 62fLBd/cvUOXhuWgi5Na0JdPRA92zaJbswvR7Zk/0O1Zeej2bKS8dHtOProzLx9dGpKdLs8fZ0dP lCyOA7AOUNWWxIK/HxyAjrPTLXauAIbALMaBKWs3VW1ltAoApou6parUcVji0FxBZ1vDCM7nLp03 RwDY8L6b5VZ19TjWR/vmOThpLNuSFHCUAl++faDxhwvQuUcrjUUBsLiHZwBKgOi1ZztFAnjOOF7G CKD3Xp+kQXtSEoAcQIzvAGDce/3xgSirBdtHby8an6kN3lvyC7042IW+2UDgN3eu05WRuej5qXWi 6PNTq+nFuuT04pzphkCt99tXose7B9DLTdnp86un9PLqWXq2Ji0931yCHq2rTY/Xc9pYl55sbkRP dzSnJ1ub0uM99oOvkwBsKlJWOovFBFyC+t9/GvWLkgoMpuI6HWgbuAN/cZ76XCcihDjPxnmuwk0a Euc9Z+YMOIDoMAAXbzg7NooPdRyRvr+2zpjtAGBb4kl/uioLuT6/LQBWRacmYzcrSg0oKjellw1a 6DZkZuffKr2sz7k9cxdgUXEIgC3pDSj90tLdEQB2JK+ji6LMLykQnBQAcKqACdAcvi+jAFNcAE8t gOKeCqL4PPpAThPwVvsNEAb4AsRRH8Bb+1k7vttzi9CzPcwB2wDg5+f20uPlKejVxW2i+Ke3X+j+ klL0dG0B+vDidQCSvbh0kp4uT0qPtvYSz16cXkUP/41Or65dNEteW+2bK+QEB2xmQcKCJhZR/aIU cJFSAdF/4VIARD1HExP0XxPjuRm+a8/ZlOf2KVIFEOWqQKlZ8AOKewNuMAKce5ss4AE5mXP/2VDy snUGrJ7/WgEmExqYEZPaBcAmwG2YB5N7jtLC9tzZM//mXlRzc27P3Jn9pTgIwIq42NxGw/SeQ++l mU1ecC6asi1JAVdSQOV6wd1quWE9AKviZoArwLrfroRmuwERdK/tMcUzFbDnnKwUAMzx/NbkfMyF trYpgn556TA9nJ2Cnp9YY2zzybEt9GBieAbZwSb9+PzhK91fVIkeTE9N7x4qKrvPji6jJ3Pi0OMd 45l73kYvz+2ilxf30evLB+jx4S309dNHh0nqFADrF6QAiigqcJhZuPRgahegOiXqMy/iM1kkLZ3D afttbvE1bDSEwpnZ5zbmwRYAi+Jazs8CF6rfSOi+W+OizSnTmTt7Dkgv/Xmo0s+AyncGGpg5gtBu tuyaf3ObLnvmztI0OArAATaW5jeBZpWwdJsokUeCr8MLlSzg+RQAQOK8FxeAFgAaUCnRj/7ZGlGc 7wK0AdiWLoAzQBrXmkttjYCsz3+tb3Z6tKi5TQB+fmYv3ekTn54eWGas4iuLmW9NqkF3+yakV7f+ M95/sGMB3e0Wjh5smGC893jPEno5IQk9GRaXbneLQXd7x6H7/RPS9U7R6b/ZPejb1y8OT5JzAGyy IOmATiyMBsAws9CZ5czM5Au4mPmDkF2chjVlMXVRtLgQa8ZkThvZIIpWAc4o5rYlelanxy4A9p9L tX4tyAWkgako2i4OWAcEZulqlG5wf+yghRFQTbSB/efO3vnXv8kB+mbP3LkMgPWAa37TYc97KQHY 4TVKFvACCkBErCpb4ZxXvcyJoMEhA1wBwhAvm7sgbgZQ48K5MPKtuNDMLAd8qXlqujfpT5sA/PTY drreOBY92e0PwKj/2YXTdKNpLLo9vrFo7/2Ll3S9Y3a62b0gfXz7wdi9R9sX0r2/4tGDFcPp8d6V 9GT/Kgbz1fRozyr69tmKJpeV+XMSgDULkhZwRUP+4GWO27W9ABtEoVowc4YDdikA2zAZMhDYCMS2 OBwHAdgf1GxsQjSi6KADYGu0sD13tuff/NvqbgD213Pg/gV455U+2wPAXrCWyi5KCjhEAXC7AEhw q0g4D7Z2BozKcfYLYAUQ47/+AkgD0NVzX4C1qvAFsNde52smpLvjmpoFYO2x8JPDW+m/mjHo8c6l Adq7ObED3agdlZ6eO0F3l46lGzUi0MNd/qJq8fvePJeu14xOL69fcYg+1jI7DcCqLet2MyI1BXib mJgfqZ2wuQBb5IYd5IAtiIZNRK/2iDEdNRexRyTtBADrbYctLfbq+KAdbVME7SgHbIsWdsydzfm3 8LYGGK89c2fpzXdYBK1UZKJAZklRz14piMt+wrIiSQH3UUAFRa1pEQBSqwWtVcJCfpgmAaTxGdwy wFgVNWMkKmcMYMZZMUya1MucFvT5VgXoabc8dHd8cwZiTvz/3qTWfH77Nz2e25Wuj2/LZkdP+Ox3 D92oFc0sAL++f4+uNk5LDzv/QPdbpqRrfarQ12+mdH20bwPdbhiPHg7/H90Z24zuTmhB9ya2onuT W9P9qe34fLkLt/sXPdi50u4JcR6ADZrPo3SaoKJlo6gyILdkcwHWL6xGDWNNXXYBmOEMNQAnbao5 bY8ij9k8pwyKVty/BVrPXmYUogLMhi0t6ACLeEBlKMvcljllqoDvg91n8VoRtAGETE3NuG8aWpg4 YzEzdzbn3wHQtGfuzFbnJACL93o/bywtnHnbxQHb837Y/fOVGSUF3EsBiIVxPqu/AJq4D/DVngMD bKHhrHLIYmPL3C4AGc/wH+ANEEYdOFfWX6ptsXr/+YUTdKFVfrpYJwldrJ9CSQ1S0qU/0tC1ltno eK209ObeHXpycj/tLx+bbXlXmyXao4Nb6FKr3HSlZ0V6ffdmgDxfWMx8Y84AuoD66yXndlIaUgq6 1Cg1XWmWmc7XTUZXZwW0i7Y0S4EAYIN2slknBWZEkYYe2LMAm5z/AowCLJgaBSVHTFiYazG3SOrP m81xjkbxsu78V3Wo4P+SWXLaoJkCC2epSrv+AKp9cfV9srrYG+p3OQesmUNLfbM1d/bMv/mX1fyc 2zN35jdAOi9jQvt7g+K1TWO2Zuqy1PJ7jTbMKmHpvcNJAHYvYsjWJQU8iAKBAmAPGofsiqSApICk gKSApIBXUUACsFdNl+yspICkgKSApICvUEACsK/MpByHpICkgKSApIBXUUACsFdNl+yspICkgKSA pICvUEACsK/MpByHpICkgKSApIBXUUACsFdNl+yspICkgKSApICvUEACsK/MpByHpICkgKSApIBX UUACsFdNl+yspICkgKSApICvUEACsK/MpByHpICkgKSApIBXUUACsFdNl+yspICkgKSApICvUMCv C7vKM5e6bvIjc+kfvm8udeP75lJ3vi/SRtPUg7/rU0++p029+Ls29ebvIm0wTX34uzb15e/a1I+/ a1P/9X6kpgH8WZsG8nekQbo0eJ0fadMQ/o40VJeG8XeR1ippuCGN4P/aNJK/I41CWqOk0YY0hv9r 09jVfoQ0zpDG839tmrDKj5Am6tIk/o402ZCmrPQjpKm6NG2FH003pBn8X5tmLvcjpFmGNJv/I80x pLnL/Eib5vF3pH+XKmm+IS3g/0gLl5imRfwdafFiP1piSEv5P9KyRUparksrFvoR0kpDWrXAj5BW G9Ia/o+0dr5pWsffkdb/q6QNhrRxnh8hbeK02ZC2zPUjbdo6x4+QthnSdv6PtGO2knYa0q5ZfqRN u2f6EdIeQ9rL/5H2zVDSfkM6MN2P1HRwmh8hHTKkw/wf6chU03R0ih8hHTOk45P9COmEIZ2c5Efa dGqiHyGdNqQzE/xIm87yd6Rz4/3ovJrG8WdOFwzp4lg/QrqkpjH8mdNlQ7oy2o+06Sp/R/pvlJKu qWkkf+Z03ZBujPAjbbo53I9uqWkYf+Z0W01D+TOnO4Z0l/+LNERJ99Q0mD9zuq9LDwb5EdJDNQ3k z5weqWkAf+b0WJOe9PcjbXraz4+06Rl/F6mvkp7rUx++x+mFLr3s7Ufa9KqXH+nTa74nUk8lvVFT D/6sSW/5s0jdTdM7/m6SuvF3Tu8tpA//+JE+feR7H7taTp+6+JHV1Jmfc/psI33p5Ee20teOfuRI +sb5RergWPr+tx8FNhHXIVJ788mvMwOwNlkCZPW+K4DZEVAGSLsCmB0BZYBzkACzI6AcRMDsCCgH FTA7AspBDcz2gHJQAbMjoAxwDgpgPsUgbS8oBzkw2wHKQQ3MjoAyADoogNkeUAZIBycwmwNl3LMG ynjmCmC2Bcjqc0dAGXmdAebAArJaXgVmP9XxvB6IXQHMQckt2wLmoOCW7QXmwQzgQcYtOwjMQcEt OwrMQcEtOwrMQcEtOwrMQcEtOwrMQcEtOwrMQcEtOwzMQcgt2w3MQcAtOwzMQcAtBxqYXcgtA5wd AWZnQBmctbPALM+AfeUwQY5DUkBSQFJAUsCrKCAB2KumS3ZWUkBSQFJAUsBXKCAB2FdmUo5DUkBS QFJAUsCrKCAB2KumS3ZWUkBSQFJAUsBXKCAB2FdmUo5DUkBSQFJAUsCrKCAB2KumS3ZWUsAxCjx/ /pyOHz9BJ06clEnSQL4DQfQOHD9+kp4+ferYj5NzSwB2mGSygKSA91CgSpXK1LRpA2rXriW1bddc JkkD+Q64+B3Abwu/sYoVf3N4YZAA7DDJZAFJAe+hQNWqFenT5/vc4c+c3sskaSDfAZe/A5/Fb6xq 1UoOLwwSgB0mmSwgKeA9FKhevSq9fHWdO/yK0zOZJA3kO+Dyd+CV+I3ht+boJQHYUYoFyH+IhpYt T0MPBroiWYGkgMspgEXhxctrXO9L+k5PfTYpm4vXmqRsOFw/5icGDvKbgaZPTNpQ+gFpwzu+b/rM 0b6Yjsl/LEQvDOMMivE5/474j/19oMfuKK3cmR+/LfzGfBuA7yyh5gx0pdU07JDLFyt3VHhgmGZM ZVvTojvu6IVs01cpEFIA+Nv3J8yF3KDnL67Rs+f/0Zu3t3lKPwqgCiwQahd31Ldv/wYaM3YQK91c 5br9NzZYiF+9vkn16/9O4ycMFUAdWGDAmF68VCQY38WG4hm9/3CPXry4Thiz9fqxWfjA6Sun5y6l g75d9A99rV69Eo0dN9glYw8s7YKrvO8DsABfU3C6s3gJHfD2VfPgcGq+WIO4/L102eHePy5vnxcf 6n9IAGAA3fnz+ylJkkQUO3ZMihAhHP+PRY0b16Pnz28auUV/EfwLHdcKjhJJy2U+D8BBK3k+U9my JcnPjyNjbV8pvmOhB8ChH/fvnxfPylf4RQCfCgJKWX0bypGAUl7/7AMdObqNEidOSAkTxqeZs8YZ gPQrDRzYnRIkiE/3H1zge28M5VEX6gDQKlwsQHHvvvU079/J9PHTA2MbpnlQTlvG9Lv/2EzrVu+b jP2BMvayZUoY+qrUFTSSCOc5dVcDc8gA4JZLyBpzqOUk/UHtDi1qqXKYWgCH2Ji/H/Tnqk1EyAII /TlT/2e6cqJPhnuazplwtTb6bbrWoy4JwKY0kd8CQ4GQAcAf6SiDFRb/AgXy0IwZM6hc+V/E9yZN 6wuQBFAp3CAU0dSz8Jf8+YsACXCT6nNwzIo4W8nr//2tqOfqf0dp/fpF9O79XX4GgEG9EHm/o3fv 7oh2q9eAQo5St/L/haENcOUATbSB9t9xwj09EH6mzVuWibqQ4sePx1zvDfEqdOzYSty7fecMf0Of UMcH+vrtsaEfGC/a/UalShUTee8zOBJ9MrSJcSkcsX95cPL4DjqhThU80feXhr6jnU+GfHiOfBi7 Uubho4uirWrVoA0Mrhvt4JlnicolAIvXyJHLAKQWwOzO4tZU2vjsDh04qKChAEJVVA0u2phHObc1 ljHhPLmtYRqwN3mmKydaMQVg077o+mBryGjLIcC2VaF8HtIpEFIA+PjxHWLxb9asoZhycHyRIkWi dOlT87fXbIbVjPr07Upt2zaj9BlS05OnV+jr11fUs1dHSps2FSVKlECIT8+dw9HWW6pVq5qhrheo jfbsXU+lmbM7cHAjbdy0hOrUrS6AGECzY+dqKlQoH6VOnYK6dm1L4cOHo99/r2wAoXc0ffpoypo1 EyVLlojq1PkfPXx4hZ99pvkLpvD36jR5ykjRh+XLZ4v7Clf5ibZuWyHGVLRoYfEffcXVhdvwB+Bv dP36aapcuTxLABLQDz9kpyVLZ3Ku7zRocE+KESO6yPvDDzlo0qThNHJUf6pYqRy9fnOL83yhCSwq r1ChFN26fVq0vWr1v1S6dHG6dv246ANE6dmyZeYNQFxxf8eONaLc4ydXqErVCjR9xhgqXvwnAboQ yYcKFYr+9z/FHGfixOH0008F6fDhzfwt8OJ4VwOnq+rzfQ7YsIoKcNMCpxkA9F9w9ZwpQFzlgvXP AnKx5usxl097z9Jze7haa30I6TAix+8sBUIaADcVHC/R2XP7KHToUJQ/f24BLD/kziGAKHLkSJQv Xz5xVty6dWNxr2696tT+b4WrTJUqOX3+8tzIOV65ekTU16hRbfH8+o0TRgA8cHATi7jvUIyYMbit 0FSz5v8oTpxYSp0M0LggOsb3Nm2a0tSp48WmoHjxIvzkG/Xt11U8A2hlyZKRgXOW6KsegHGmmj59 GooePRqfbT8wlnv0+BK9ffuIgT8l9zsFzZw5nX77rYyo88SJ3TRl6hiKGze2+F6kSAFasGAG9ezZ UXzfLsTn3ylb9szi+6zZ40V/y/AmA99fvb5L48YPFZ/BRffo0ZkiRozI/Y9Id+5cpAcPFW4XKV78 ONSgQV0G5ctiLE2a1GeJxC7xrHjxH+n164dcs+8qAYYYAFYXIQWIVVCzJLY1cKtaxS3jObJ1ADYC vbGsJeBGj/QArAdbe4BValI7CzCynHUKhDQATpMmJdWoUY2iRYsqAEABNaKCBfMK8Dhxcpf4DvGt wl0WMhIQ3DHu7dm7ljZtXiI+T548QoBiwoQJmIvNKECrc5c24tm5c/tp5co54vPIkf1FPceObRff a9euJvLmypWdz2vj0YMHl+jVq5f0qwEgP395QKNHDxR5hw/vw3khstUqdH0SZ8x4PnfeJOaOZ4nP gwb3oBEj+4nPUDTbsHGR+Dxq9AB6+fIlbd+xSnxv17656E+lSuXF90ePL4vve/auE9979e5Eb9/d 5g1JZPH9jz/qsC3rK4oZMzpzxKU55xtx/pw0aWIWP0PcTAzoI0XeseMGCQ46TJgwlDFjOt7MQOHt mxBBA6Sx6cFGBtzvu3eKmNuVinCu4lxdVU+IA2Dik1ec7Spns5YAzl6uVldHADGwPRyuLYC2xgHb A9DWF1n5VFLAEgVCGgDHihWTcubMxk4RfqV16xczWXC++lZwwAAT5az2Gx1isSjABN7BlOs7zWOg w705cyYwGD1hZa4IDGDl6PSZ3eJ+/wHdRM4OhjPYc6z4pYLolq3LxLO3DIrIW7NmFf72hTJkSCeA Hxxq8uRJmEOOLbjZL1+f0IgRCpCeOr2b8wKAtUpg/gA8kUXHEAcD7MDR/s51hw0bls+g79A45o5R B8aWImUyFnMnYRCNQUOG9hb9+fVXhSO+dfsUf2OHESyax3kywHHBwqkCZMvzeXm6dKkZ8BWR9yzm 2uFYQuV+lTP0L3TwkEKzf/5pJ8AbnytXriBoh3NoADC4dMwBnilieDyTZ8CWfp/eYQes1xbWga7J WS+Ds9kzYBMKWOGAdQCscMO2ANZfwUv0RXOOa9o3/TRI8LX0Ysr7rqFASANgcHLKBeUhAMcLTm8o d56cAmy+fH0k7p87v0+AxG8VyxoJ3bNXJ3Fv/fqF4h7OSgEoVav9KkSr57kMLi0Az54z3gBaigj3 woUDCgfMZ70A1TRpUgnt7AcPLwmNbHCtX75CWeq70GZGXoiyFeUmf81efFc54NFjBom6ly6bKfKH CxdW9AsAPHfuRAMH3o+50mfMjV6nDx/h+Qzj/mDU2IZplkqXemwmhU1B7tw52X1iWeb2lwoR+i+/ /CyA/eatk4Yz9IiUKVN6LgZlKqJFi6eLtiZOGsZtKQCscMvKJgcADDo1bFSLOnRoIZ6jzxir5ICN r5nJB+8AYAPHa14zGePRajtrnWLoxNAmSlhmtKKF7pZpXc3Z3EloTItnts6AFdraqwVtagOsal3b c15sfjLlXUkBPQVCBgB/oqNHFC1oKE8pXJdiWqNoA7+hTJkzCIUkBYDf0OfPz4WoVIhjGXhHjR7M ItXQQnT6+g0A7DtziNPEcySIkr9/h2Y0Ueu/moh7MBO6ceO0kQPt2bO74HTxTFVE6tChpfjeoUMr 2r9/F4PXcOrRs4Oop2/fLuIZTIXUs19/EyJ/Lehhw/uK/N+/v+Hz6x9EGQAmFMlu37nASl/hmbtO SqtXL6FtrLgF8TO0wsHpY0OC/A0b1qLFi6HkRfxfAVKkIUN7MS2eUEQGZHyHspaiufyZ6tWvIe7h XH3KlAnMfcehKFEi0737l40azyVK/MR5FQB+8PCCyA9ltrfvHglTMOS/cVPR1naVyNfT6gmBImi5 0EoKSArYQ4GQAcDv6eLFg5Q9exbq3aczkwXmNqp9LQD4tRDbgsNTTHVecHpP166dYBFtaeb6wgjw /eWXYszBQgsapjWvhVYvlJegwTxzJuxwFa4a573Zc2ShM2f3CpAbM2awACdoP3ft2k6Iv9sJ0fZn dk5xl5o2ayDEwuAu48WLY3j2lWbMHCv6fPrMHtEfUw74vQB4PAfnqXDzn9gJyEbKmSsb/fxzYXY4 Ag9nX2nlqvkiH8YQNWoUysPc/pmz4NY/85n3bvEsQoTwvNEA8H/l8+iLvPnIw/cz01E+s8a9Zs0b inGOHz/EQL83DPDXqQEDt3pOnDdvTj5jhhb0N2HWhHrbt2/hT69nVwVdsOnAhX5nYLH5hIlwSqIo l/likgBsz0ok80gKhEAKhAQAVjjdZwZbVfPnjQG9RkE5CHatbwWY3GMHGopdq+pGEc8B1M8ZtFW7 YH8AUeyGVS77k/C+pSg6Kba2anvKmfMn4c0Kpj1v2U5YC7ZKPeb7HHBMqt2uaqPr3z48ZN26dZrB VXHOoXoAw5g+fX4gOFalHX+HHUrbUPzCvZdGO2IFJNUxfxQmR4rNMejhLyrX0kAFVuWe6gjkjaDD p88PfRJ4/aUVIcEVZQhcPOWQJQUCS4GQA8CqNyl/r06mHCXAw9QDllZErYBWwLIqCCtgDTAFRw2R K5LivEKpB+Jp1cEGOGhwfOozRYtY4WIhHodbSQV4/T1gqYCverZCezh7xX9TgFa9agUcn+IoRD8O xeGH6X1/z1zoK2ij7Yv2LBr3Vecc5jyImdJM643Lv07zc+Ir3LDkgAO7SsnykgI+SoGQAsBBuZgD bNdvWMQetsbyeekzYcoExx9fv6nAq3J8AKt3wtRnxcq5BgB9ITho2AP/d+04LV4yUzi9+G4EcxVc nws/0sqzZ3T5yhE6dGiL4KyVwA5aUFQAU+X8lU2Byg2bc2vp/1wpg/IvBTfevfvf9JRFx8qmwDdF xEE9LgnAPrp4ymFJCgSWAhKAAwcqChf3nkqULErLV8xh06ZFQpsa58nFihVhsTMAEpwt8oFDJnHG W64cfEGD2/0stJ6TCSWpf6nrP20NZkfIqQChAqCf+Cx3HvuQLiU0peFcA23gnBVt4lxaAc8PBkUy lWNVNb3B/aKut+xIBI4vwDmrri5Vzh1c+geDX2hwvp+oTNkS7O0K577+fquDGrB8rX4JwIFdpWR5 SQEfpYAE4MAC8GsG2UvCBvfN21vszWqUcKYBhSyYAs2cNZb69OkqzHIWL5nB7iWnCfeNcAiCoA0d O7Zm29vHlCNHVnYtuZwGD+klvGntP7BJuHBs0bIRvX8PretvAuDhdQocaYYMafn89CnVq1eDFE1j hD98K9qvVasqLVw0g06f3kPNWzRiRbJS7ImqJtfznMZylCa4hWzE2s+o98LFw1SKXUjWqVONHj26 yt6thog6u3Vvz5z5R2HHDKUxCcDOvycSgH108ZTDkhQILAUkADu/sKoc5/4DGxmAYQ/7UkQWAjfb uEldwZ1evHRI+F+GRjI0sOFyEnaycPyxf/8OSpQ4gfAjXZh9RW/YuERoMK9dt4AKF85P06aNZlH2 XuHUAgAIsTVA+9XrG5QyZXIBovBlPUNoYMNRx1vKwt64GjepxxraD9g71hzhw3rXrq3CCQc2AMe4 vrlzp7C2dVxaxr6l4ZoSvqNPn2bx9+IZIv+06eOFVvbuPau5T4uFaZPCLQc8I/c1bjUoxiMBOLCr lCwvKeCjFJAAHHgARvxfcMBYaOew44tkyRIz5ziE7t69wFzqYxGsAJGRuvF5aufOfwlXkUo0JGKv V2mFaBnBGgB2P7Hry0UMhHBwcePGSZFHAfrPzAHPFb6YEVcXdr0A8127NgjgVWIBv6YzZw5SlSoV hG0uzHzKlisp6ihW7EcONtGFOeo/RRCG1MyBT2FuOTdvBNAurkWLpgvgBdc7gJ2A3Lx1kVavmU95 BQCbnhMHBVD5ap0SgH108ZTDkhQILAUkAAcWgF8LMyW4aoT/42nTRomzWeX6KJSywM3iLBVca1+O uATgA4BCFAyO9+GjK5SLuWQAYcFCeWnX7rXCNhihE5s0aSDMfADDS5fNopJ81vyE7Y/TpktjMB1C O4rZEcx5xowZIsAXwAvwhLOLWrWqcP/SsBOONWIzAHBNxZGZFi6aRoMG9RDi7z/+aEAbNy5lG+Fc bA/cUbiqfP/hkXBliUhKio1z4GjlqwBra1wSgAO7SsnykgI+SgEJwIEDFQX83rHjix85YtA4evLk vnD6gTjACuf6im1kTwuu9iwHZ7h37xznuULn2SXlQva1fOPmSc7zRjjtgC0w7kPkDMUsiIx37FzF Hq7A3b4UZ794DqA9xee77z/cM7ajcMAvhNcsiMFfvHgkPFqBw121ejFzxnAK8pHPfA+Kek+yAw5E fEL/1qydTxtYixuf79w9K5yKbNiwhMMxvhYbBwRykGfAzr8nEoA9evF0tb/nwNRnK0CF1o2nI0QN TJ8caUfmdZQCEoCdX1j9HS18EP6SEftW4RS1XqvUIPbQRobdLjSNoXUMLWTcUyIBKc9UreQX/BkJ zxXtZiWP+hygDy1lc3bJqAd9+Mqc9BrhzlK5FAciSrtwBoLyqA91oR3YLWPDAJtelP/CYvN7wi0m PH5JMyTn3xMJwIZX0P+fqT9n/9CFATIGww1Xg1Ng6gtMWWukCqp6XT09Vvp5Zwk114auHAaXhLgM /sQ1ATb8e+X545YA7PzC6i96VIFNcbRhSyQZPM9VwA5cqD+9Q5Hg6bsr5sRz6pAAbLJOKwtm88Ui eoJy8eK6SIQudMfl6kU6MPUFpqwPA7AAX21wDn5lOAjHAS0A698p4zPTcu54w6y1KQHYcxbqoAA3 Xw/1FxQ0c3WdEoA1KxAiDJmAr5nVyXK0IgNAHfTnhpSYw4YLoQqNXJJp1CKbdRr3A1ruXLd4W6k/ ANel6WNADt9SGwHH508rM3GPLdGBO6Mdr2nEKAtwYGlsJvf1kayYPvo+aPKbzI1JFCtLoGhhAwIA Nsvhqhww6lM2dqZtBtWGxnUwLgHYtwHY1WAi63P8fQkRAGxc8C0ulOpiaT2cn4jvazFer07cKBZ7 tT48M1+37Tp18YJV8abJwm+5ftPlOKBI1Gr7AdrQxCsOMD5t2EVL+cAdmtLQNGayOfCwNDbeKAxb wtCp3eBo6a3vA39XaWfSd8OGwCxdtf2xBJiGDYstMbOuTfPhKV0Hnq6oSQKw4wuqBCFJM0fegRAA wNq4vlZEfkKUaA2ALcXz1S76luIEW1q8HalTnxcLv7VYw5bATE8DM9yrCcdtqQ1L5fT9tFa/lku0 BBn2corW2nGkT1q62gPASh5lI6EBfTNiZtPNh73jcgWUOleHBGAJJo6Aiczr+PsSAgBYI/IMFAds jhNzdNHnBdpEFOlIndqNhFJPaZOzR//npqJOWyCiB3K1bn0b9oKYrXz6TY49QGR+bEbQM4r27dks 6EHfFl1V+tnTTxWILW3KFG5ZEd3bV59z0OmaUhKAHV9QJQhJmjnyDoQIALZvOVIWR8fASwug1oDH EggGhgN2hmN0pD19/baA1R7ws9S+vcpImvIQ6ZpsqBzdDLlCemBuDrTvkbXxSgB2ZKGSeSWw+eI7 IAFYu4YalHRMQFijBS3Okq2eAVsSQWsbMQV6R+oUeY0mLpYA2NpGwsDtaerQ12m5DVcAsO68lYeg nM/bC8CasekA2PQs2dZmyPS5fXS1AJjcD1PFPVsidx60URnM3nHbt4V0dS7JAUvQ80XQ86QxSQDW r1p6m06d2Np+jWX9Quwv2tVrWjtWp0ZEbOybqRjVsia3oU+LNRrZAcTyOpGsSRv2nHHbAj9TO+uh B21xgpbGZlqPqTa1rT6Ye26OrnrJhal4XqGz3m7cjDa2xqpNrdGxjYerodW++iQASwD2JLDyxb5I ALZvLZK5JAVCHAUkAEsA9kXQ86QxSQAOccuqHLCkgH0UkAAsAdiTwMoX+yIB2L61SOaSFAhxFJAA LAHYF0HPk8YkATjELatywJIC9lFAArAEYE8CK1/siwRg+9YimUtSIMRRQAKwBGBfBD1PGpME4BC3 rMoBSwrYRwEA8MtX1zkzQuQhNJ1MwU8DJdygEi4wcPR3VT2B7Ycsr53HV+I3ht+ao5efowVkfm+k gD1mQqZ+oC07M/HG8YfcPlepUpEDu8OGCvFhEQvWHektt4s4tu5o291tIj4w+vCV0zd6/OYVPX/7 mj58eU8fHUgfPr+nL98Q0xexfF/Ql68PDZsqd49Pto/fFn5jVatWdHihkQDsMMm8sYAjAOzM+LR2 tHDhqHcNaeqs4sAwz3Ze4QwFPLVM5cqVqFGj2tSyZWNOf7otNWlSn1q1auK29t019iZN69PMaRPo 3MPXdPLuczp3/wVVnbyFEnSaRym7L6SMfZdShj62U/reSygL5xu46RS9/vCeTh7eSZ06tKbmzRuF OJq6ay4tt9uYf2N1qGLF3xxeBiQAO0wybywQ1AAMmlj2HhUggIFVf97eSF/P7fOjR4/o+PEThnSS /wdvOnHiJM2cOYtSp05DJ7htfA/uPrizvWPHjtPtGzdozM7zFKnJJPpn9RE6dvsJjdt5juL+PZv8 6owmv/pj7Uv1OF+tkZSw8zwavPEEHTp5lk7y3IY0mrpzPs23rfy+Hjx44PBC4JMAbBqr1t+FkU1v VXbFnjUAjbV4vPbGuDUCkZUYwcYptdWuHW4mLfbZuutFS/Q0fdvs9OMML2UmIQVVz1TWw0g6/GbL Ah5DgQkTJlCYMGHo1q1bHtOn4O7I1H0XyQ8A2mAsJe/6L03cc56uPHpJ687cpLVnb9E6OxPyLjl+ jRYd/Y/uv/kU3MOQ7bmYAj4HwKbc1h06cFABYNsxe+2NPWsQr2q4OH2bdse4NUymiR9ji8HhbbVr C4BNfWBbDqtnWo8legZ8D+0EYJMNhQRdF/+ePbK6EiVKkJ+fH40ZM8Yj+xccnRIA3Gg8hW41jfyY EwbXu//aQxq85RSVHLmGykzYYEgbqfT4DSKVmbDReK8Mfy81Tr2n5Ck8YjUVGr6a7r98FxxDkG0E AQV8DIAtiVrN3cc9e+IAWxevKnNiTcRry7G/vqwjsWztBT1L4zcXTchWfy29hfaKoNXytsTiQfC2 yyqDnQK3b9+mKFGiCAAuWbJksLfvKQ1qAThUy6nk12wy7bhyjwCsQgzdeKKSGKSFSJqf+/3J3/+Y oPxvyqCNZw3G+ef9g783nUzXnkDDXV7eSAEfBGBzXJUWbM0BgCOO/80Bhylo2h/jVgVvS/F7ta+U rXZtccB6xSd9DGFLYGwvl6oHYO2YLNXhr6wlta69cfmw3efRoxlcGHzVdOXKFduFfDCHOQDeyQBc ecoWBlgW0bc2cMYMvEOYK/551FoBtOH/mk5+zadQDD4vHrX9DCXsMk+Achhw0i2mUIS/ZtCNp9C0 lpc3UsAHAdichm1wcMAGkHEoxq0t7tkWANvLxTsyftdzwLZ/GJIbtk0j78wBsXPBggUFF/zrr7/S vn37vHMggez1jAOXjCJolQPWAjC423gMsmv4TBhXxj5LKCKD7/hd5yhcawZh5nTP3ntOFx68oPQ9 F5FfQ+aEJQAHclbcX9zHAFgfq9b/DNiRmL0BRcpmuDtL8XgdinGrvAD2x7I1jSVsWk5R5FLDGAaM rWutrGXQ1behnqkHfHWdBW7UZC3+sft/JLIHgaPA7t27KX369IGrxMtLj9t1XoAmzoC1AFxx8mby qzGCCgxZQRcevhCjfPjqPYVn0C0xdr34Xo7PgqH9/O+Rq+L7/VfvqAQ45LpjBDhLDth7Xw6fA2B9 bFetaNOmFrRRYdoOca7FeLyOxLhVXxx/UWzpsqbKUv6vlqFP1uIAa7SvzcbWtVjWGnjqY/+ae9nN 2QHbsvU1HbPl+Mfe++OSPVcosHXrVkqbNm2IJceXb98p37BVQqQM0bEKwNsv3aNfJ22iWtO30bvP cLChXOB0IWZecFQB3K0X75JfzZFsA3zSmOfjl2/UcO5OCsvnydflGbDXvls+CMBBPRfuEpe6q92g pqes39cpsGHDBoofP76vD9Pi+JaeuM6AyhrQLaf5AzArVa08dYOTInLWXhBDJ+Cz3jcfPxtvZ+q3 hOrO2REgb61ZO+js/echlrbePnAJwA7PoLuA0F3tOkwgWUBSwIQCFy9epI4dO4ZYqhRicyFVcUrL AR+88YgqshJWrelb2UUlXIUq1whWtmq1ZL8JvWYevExFWeysvbqyU49YbWfQ+QcSgL315ZIA7PDM uQsI3dWuwwSSBSQFJAUMFICDDZgRhTJwv0J7mRWuKk/dQvvYDjhsEzYxYs1niJ1H7WDPVnee0tCt p+jwzccmNPz89Ru1WryPrrPG8wTOB2WsYqPXkV/14dRtzVFJby+lgARgL5042W1JAUkBz6dA4RFr TLnfFlMpdLMpdIi530oMwgDQIQy4K1gc7Vd7lFCqStljAf3EzjlqztxORxiIoYT1CytkZe63lGJ2 YPeVfB78O4ueT9x+SqH5XDlG+1nSGYfnvwpmeygB2EsnTnZbUsAbKfDu3Ttat26dN3bd4T77c79T xdmv4H4bjqdG/+6mnVfuC7eUSf/5l/5jJar0fRYrHrLYtEg44WCN6bid5tL6c8xBM2j7NWKzI9xn m+BQ+M55d129T3/M30N+/xtGXdcccbh/soD7KSAB2P1zIHsgKeA1FBg6dCjNmjVL9Hf9+vW0fPly 8fn58+fUtm1bOnz4sPg+adIkatKkibjXuHFjOnXqlLiPssWKFSM45GjZsqV4vmvXLuP4J0+eTP37 9xffz549K8oiD+qCT2lvun4ezaZCBqcZ4uyXwTUi/z919xkVxbPfR9CkvRfEmS88XMFEyQjUDLYp eyykzRfuUDTmcAHM6jMB5Oy8A24oT7DIOiKDctwOc+jpW4QrlJc3UUACsDfNluyrpIAbKfDt2zdK liyZ8Gr18OFDat++PVWpUkX0aMaMGeJ+rVq1xHfY/jZr1oxixYpF8+bNI7ikxFWhQgVavHgxzZ8/ n1KlSkXTpk2jOHHi0KVLl+jDhw+UOHFiCh06NN28eZPu3r0ryuI5gHjnzp1uHL1jTe+4fI9CMZcK kyMjqDLIdlh5iFazljPcT0KkfJwjI8Vqz2JlBlwTgLUBwMKnNHPJcw5doY4rD5NftWHUX2Om5Fhv fT/3169fCcnTLgnAnjYjsj+SAh5Kgc+fP1OZMmUoX758HNu3leBUGzZsKHpbuXJlGj9+POXOnZvu 3bsn7m3bto3y5MljHA1ANWPGjPT+/XuaPn06lS1blt6+fSu8ZJ05c4aWLVtGDRo0ENxu7969jeXQ 3saNGz2UKua7BScaMD0ygi9zqbGYk7308CXlGrRcONGYffAKNV24V4ilteArOFwbACzysCkTuOQ9 Vx9QfK47Xsc59Oyd5IKPHTtG9evXJ2wYccEMDlKX8uXLi03d2LFjqXTp0uI5PLO1aNHCbe+WBGC3 kV42LCngXRT49OmTWMi2b99OuXLlEgta586d6cmTJ4IzXrt2LSVPnpwmTpwoBrZq1SqRT72GDRtG lSpVEl/nzJlDMWLEIERKQh244KoSi2GXLl3ohx9+MJYDqC9dutRriAUHG36NA3K/AzefpLmHrwju N0PfJbT3vwdC6QqiaWcAWIAwc9UTdp+nFkv2sUet4dSf4wSH9GvTpk2UIkUKIwCnTJlSbOgghXnx 4gU1bdpUSGumTp0q3tlMmTK5jWQSgN1GetmwpIB3UQAAnD17dhF4fPjw4WIR69mzJ40aNYoyZ84s PgNQCxQoIAa2YsUKypAhg3GQP/30Ey1cuFB8h4/oHDlyiLNjXFgcEyVKRG3atKF27dpR5MiRCZwM LiyQajlvoFhJcL9samTkfplTTfrPfLrM8X9T91woQDP/0JW0/TJ7uGKFKq2Y2t4zYGM+bmcAA3sn Fm371RlDiTjW8Mv3ITtOMCQvWbJkMYqcsaGLFy+eeGdxQfcAEpu8efMKbrho0aJue61CEAArrg/d F3UnOOx4Xd2GK+pzRR2B/X14Qh8COwb3l4cIGiLnO3fuiPPaX375haA0BScbcDeJC88g3oNo+cCB A1SvXj1xHwpV8Af96pUSOg8cbevWrY2DWrNmDTVv3tz4HVwKzodxQZy4Y0dAL1Dup0jAHhy4/lCI hlVQFWe1DLiT9lygMTvPKuEE+Ww4z+AVAoDhHSuwAIyYwn8vP6iEK2Rx9mi2Ew7JF95FbBS1F6Q2 0CWAcuBff/0ldAvwjqVLl84olXEHzXwPgBHQHv6U1aQJmhC8BLYV4jAoehNYoAmKPge2T87QKSjG 4Uw/Qm4Z9fxNpQC0p3FubOnS50c+c/c8naIVp3BwBS33y2CbgU2McPaboDOHEoQpUVACMNedovsC evXB342lp9PM1f0DBwy9AmjNr1y5UkhbcA4MUIa0BptIADHOgyHFgSTGXZdvAbAAX9MgAHcWL6ED bqGuO0AgsGAXFH0ObJ+cmbygGIcz/ZBlVApA1Ayu2ZcvuJYMxQALO12IiFVN5QXH/qM+G44L7lec 2wYhAKsc98gdZ3yZ1FbHduvWLSFmrl27tgBhKAf+/vvvNGTIECGWXrBgAe3du1fUAX0FgLK7Lt8D 4JZLOLiductMxJ+D/tyyXjStjZzkH6lHG/XHSrQfs1y4oX1Nm6YRgMzXjX6Y5AsQb1g71oBtlC5r iFOsyWY2KpRTfdbRWRONyb9dG+M2KaM9ItCVM86rjTlwahx2zqs6XLPj5If2jkU9CtHkN33/HOyP u1YP2a4JBX5DaEEt98teqvLyWe95DpYQvd1MCsWa0EENwGr9yQUXHLLPgr3h9fQaADaChkWABbkN C5fZPHoA1oT9EwuhP1CJWLqaBV+NgWsSGxcLvdW+mOPCLLdpsW70TRd72HLoPkOIP02/TMfCFDIZ mz4WsWN9Nn3BUTYg2CuxlS2Nm+drmGbDZDIPAceC9uybA8fGYV+d6mgtjdOBsajAq86r7v1zrD+e v8xAeQviPl++jt56zC4mtdwve6tiJxzrz92mv5YeEDa7RsWpIOSAtZz3xD3nfZnkPjE2LwFgw2Is znVtxZk1gEyAuLpmOGCz8X8tiUz19wH21vpiSwxqrT/aurULPu6bAzktOOj7ZK0dlNPW70if9e+/ vXSzJpK2p6/a8VmaA0fGEdh5tbQO2Pu+qXOgjsvR/nj+OgSnHFqzIs/vseM9rMm+mbX2vADfX8at Z3/NTygCFK0MYung4IBFG2wGBfeW7zVxhh0flSwR1BTwEgA2cD4Wg9WbJ5Pg9oxcmb0Log1OTqvg ZXUz4CgIaBTHdBsNcERCRAmu26pSmTlwswTm5kDbkT6bo7n/RslfpGq9TmWOtGO3BEQqUFmmk3+P HBmHdnOn1m1rk2dunJqNn3E8lsZirX/O9Ceol4nA1a/aZQauFs8tferOMwrHHq9Ue15oNQMAd7O/ 57pzdpqIpYMLgJXz5/E0Ze9FzyWc7Bl5DQA7N1eKSFoBA0cA2NwCbI1zswRG2npsLbpWFn2DGBpg Zd2MylwfrXG4ruSAtTSwk9YBzrMd5YDt4T71c2/rXXDkTdP016GxBOJdcKR7HpJ3y5YtlDZtWg/p jWu78Z2rQ9QiE+6Xz4H/N30bwSQpVFMWS2vcUaoAnJfNkHZdvWfVDCl1z0W0n0MWRjfjC1prBzx0 62nquILtgDXnzwoXPFFwwR8+e54LRtfOgvfW5lsAzIug6fmopQXdOodkcgbH58pmz4BtzrkjXJj+ LFZfOdfFomck6xrdBu5Jd2asP0P2P9+25wzY2ibCEhEsbXx04KcDLYUbtsYB26KTOa7eFgDbW6e5 sWrG6dBYHHn/bL5oHp8BZiG+CsCI05uGgRKazSLgAsCWla2O3XpCFSZtMgnGoD8D3mbFDhgKWwm6 zBOerSK3ZQUujQjbxGc0g67WDlj7TOWCZxy45PHvSEjtoG8BsKqEpRFpmheF2gJHrRaqXjNXIwK1 qoSlEUkKQLTVpk70qKvbdFNgg/NbDKUyQz/N9NGsFrShSqNI2K4+67lef9r4b4SsjduUzs3ZZGyo DQA2KnVZGR965dg4rNPelNqmec1ryENz3dpYAvcueNtiBQCGwwNc37+DZ/SdCwCcsc8SIwCDC222 aC9tucg2phyxSBvhSAXH0AzSiHCUkd1R6l1QmgAonx3rgzTo84dmN5bQeE7MHrBCmwFpcMHZBy4j 9FNenkcBHwNgzyOwq3pkPAd2VYWyHkmBYKBA3759hVvASJEiUaFChYwes4Kh6WBpQgvAoZpPpRjM rUIjuvCI1QzAEy0CrDgnZo9Z1gBYaDQzCNvKo8YJNpdPcMG8KUDUJHl5HgUkAHvenATskbBttSV+ 9oaByD6GNArA1y68Danp6tWrPkUCLQADULMNWMbi58cUpjUDnwWxsS1AdfVzv/pjqfH8PT5Fd18Z jARgD59JRVxsSyvXwwchuxdiKQDf0HALCAAuWbKkz9FBD8BZ+y+lQ+wRK1Jbjo/sKQDMHriaL9rn c7T3hQFJAPaFWZRjkBTwYAogQhIAGD55fe3yFgBuIQHYI189CcAeOS2yU5ICvkMBNXThpUu+p40L AEaoQZz3QgTtqRywBGDP/D1JAPbMeZG9khTwGQpcvnyFypUt5zPj0Q+k/ZqTwtzIr8FYjwXg5guV 4APy8iwKSAA2zoctRxt6m+LgjC2smL7YH8vY0fye9VI61xtb86et1ZG8zvXGU0qtW7eO+vbtRwMG DKSBbkmDqHu3HvS/av+jwYMGu6kPQTP2Af0H0oD+A2grh7pbfPQ6pey6gBKxOdBBdsARoc108mNb Xmg7uztBCavdqmN07OA+6tunn0/NgXveadP3Cb+tfn370+rVqx3+2UsAdgqAHaYzF9DavEKjWe9y 0F5Fq5ADHo5R2RpdbNndOtaSN+X+ucRPNGja3zRxUV8at7CXW9KExX1o+qrBbmk76Mfck2atGUwv P52nh+/e0ujtF2j31YfCfMivCcf+bTbF/anOGGqz7DhdvrifRv7b1UfnwT3vNt4v/LbwGytarIjD S4ME4GADYDRk2dWiPkqR5ZmUAGyeNhKAzdGlao1KdPP7PnpLF+klnZEpCGjwnE7RbdpHT+k4T8Fz ev3xI4Pwfdp15Z5wN+nutOPSHbry6CV9onvcu5PyHXDxO4DfFn5j+K05evkYABsWYU3MXdN4uHb4 4LWrbMDF3nz8YP10WPN1bAeAmPSNzZMsBmbQ1WUpfq22exZj2XImu+LfqnbKjtFYiNWdjItrSnOt 5ynNwFwYH9ix2MyO/hSDJn+V6hXp3MvN9ICOsgzmoExBSIPbtJ+BeD89ZkB+Rxc4nfeQdIFeMOjc YQYgqN+Bu9wGUlC340n147eF3xh+a45ePgjAmtizEPyaxL+1BQ72ljWtx1L84ICTEUgAFuET7eGA 9e3YcuJhK5atpTi/lu5b8h9tELur7jEDERfXbJxji/bS5uY9qGMzO/pTDJr8IQWAseg/Zg70CZ0Q 6REdCxIguM2HR88YYN8wuD6gIwy4B0zABv14xWD3hPtyi7liFZQd/78PXuh5HEdFwmfUh3RfjBX3 APj2t4E6ghK47nG/njGHjXkI6raCchyO1i0B2KoY2V7QMwdslspaq9PaQuqsCNrR9hzN7winrua1 tBGwtclxNkKUPqyitbjH1sZjbhNjjV7OxmYOGkB1tNaQAMB3mau9/e0AHb27hg7dXEkHb6ygs882 s0hYAQM9SDq6wGrzo755m0bR330a06lHG+ihRrKAhfj8i61UuXZp6jvub9G+s20ByG9/V8Z05M5q Afa4d48O08VX2+jw7VV069t+q5sMjPs5nRabBZS7HYTcP+hw4eU2Klo6P3Ud1ILbPeX02J2lmbvK SQC2CsDWFm5bQGWprKMcpjnQMnCDxsAR1rhUW/20B3CUQAmWNKktx+VVActcef8x2Bf/1xo464FR Tx+tRzA809PLDhG+kCDYA8CuiM3sKFQGTf6QAMDgSLefm0/RYkSl8OHDCacfESNFEEB45uEmwQ0D gBQAOyTATF2sAd74jkVUKzpFfuT1z6eUe0VnqWSFwqKNJTsniO/Ic5+fAeyO318nnpUoX1gAn1oe z/VtqICq9MG0fQDY2sMzKFr0KBQlaiQB6KjvNaf2vf8U947fX2vgNg+KvgIE0Y7aJjYL/24cRX3G tKfrH/eYgLh2XBirpe/q2FC3Nh/u+9P0sJAKHH+wXoy9WNmCop8Y330D3d0FjsHRrgRgmxywA+eT xkVaXajNlXUUEC0BsDOaz46KoLULu4WyVmPZ2lHe6VjLjnDLtvrhSgB2RWzmoAFUR2sNCQAM4Ft/ dJZY/PMUzk5z5o2kX6uXFN+r1S8rzj8BTCpHfO3THgEODxmYAaA3Pu+lq+93iecAEnCOAJdHDGCC E+XvKrhhsT10axUt3zuZrnM5PH/B7QtA+nKIrrzbRaFC+dGvNUoyCJ0T9bzkNsCtXnm3U4hoISJH nSiLzQHKX/u422QDADH2/C3+frRjxYlB555uoS/0HzXvVFuMDZwxyqNO9P3ymx2Ca4ayHdpF+4WL 5xZ50WfQSR23CqYoj40F6KMdpwq8qAN1Xnm7U9BDHau6cQG9xObi+xE69XijaKt8teICgNEnwXlz +eAAQne1IQHYBIBNlZP0sX0XtUSoOAVlA8aftVbWMuhaih8ccLEMLuC2BEbaOL2a3lmNZasdhYXy BhMrhQtW8limsb0iaOtxevXhGa37zHaE87YVH5jrsis2s6NQGTT5QwoAbzw+Wyz+dZtVZkI+pptf 91PEyBEodfpkAqR+b/QrNWlfiyrXKU1xEsSi0wwWdz4dpMZtf6e48WNR1BhRWHxagLacmCe4yuLl ClHFmr8IAHnFILRw61jKljsjLd83iaatGEw/lcpHOy8uog90mWauHkqZsqelWPFiUL0WVShc+LCi 7FtWxEJd/wxuSSlSJ6HY/LzUb0XoyI1V9JGu0rDp/whuuvOAZhQzdnQat6CPAE0ACUB04bZxYkzo F/637FKXx3afWnWtZwRgKHvtPLuQipTMRzHjRadU6ZLR8BndWOP5KrXt+QeFjxBe5E2SPCF1H9aa /u7bhPL/lIvOPd8i+tdlUHP6oUBW2n9tOffpCo39t7cY597/lgrARt+SpUxEUaJFojyFeHOzfoQo d/LheipYLDf1HtWWcuXPQqUqFhFi/1ChQ1GF/5Xgft6iTv2bUpqMKWjFvik+LZKWAKzngK3Fw9Vo 3JqN2WqxrK1zQn+xpXkxrzk7YGc4YH2sW3MLt76v5uL0BgRWNYZwQLpYivNroV5bNLZLFKxKICzF X9bHbLYuGXBlfGD7YjMHDaA6WmtIA+DaTWAK8oA2nZzLnGgoylckpxDd5sibWQBRDAa6UuWL8Hnl Vqrxx6/iXv2WVal9zz8F5xo/UVy68/kglfz1R/Fs+/kF9I2uM6CWEt+P3VtDLQ0AuObQdLr8fAdF ZnFwhIjhqVmb2pQoaXyRr2rdMvSdQWjAhI7iO8Bo3opRFJVFyj8UzCoAGPfUKFH5f8xJs9cON2gr KwC8aLsCwAMmdKCsP2SgSJEj0tWXu6ijodzpxxvo+qu9lDBJPEqTIQWtWj+N/le/vCiz7tAMmrJw oLE/pSv9RHNXjzC2+e/m0YIu6TKlFPmxGSC6aeSYr7/dS92GthLPKlQvQT36tSZw4WHChuENxGpx /q32PRVvchq1rCHugeaYgxW72Qaay5apUpTuvFNE9O7iUIO6XQnAVkXQji5ZMr+kgHUKeFNs5pAG wAkSx6PixQsxIEYQ3Ni89aOYS70kQA/nwruYa/1K14SilsJd5mduEbFy7xo5y6W7J9LC7Yr4t++4 9kIsHStuTMqZLzN9ZuBs0bmuAs7nFtDkpQOUfGPbcx1PaNelxeI7zp/fc7sZs6Wh+Anj0M7zi+jM jU3ifBTPr33ZTX1GtxOf+4/vIPJqz6a1ADx2Xi+as3GEyNuu9x/UY3hr8Rki7akrB4nP4FQv3dwh uHN8b9SmOvfnIZWtUkx8P/dii+BK1x7hKE38vdU/9dl0ZosAdXyvVKs03fl4kKJGi0xlKxcV4vnY POZkqRKLz6hrDPcDefuMaUeX3+6g0EzfdJlT0a2P+xWumAEYNM6aKwPFSxhbcO6Pvx93uSJcUAOq o/VLAJYALDEzuCjgZbGZQxoAQ5xcqNgPVKtxRVq2e5LgJCEGzpY7g+AGAXJvmfNbwwpOAJM/WAT9 jh0pAEBGz+kp7o3i/3f5PBdg8gtzwhtOKOLtniPbCKBu1lE5gwV3DBEsPi9gEfVHFkfjHFYBtFLi fDlNhuRiM5AyTVJKkjIhJUoWn0E5Ld35epB6jPhL5N18aq4Qc2uVwEw44IkduY8KmMeIFY1FvMUp bLiw4twawI86EnO9yVIloqQsLgYX34v79ZnPi3/5tYh4jjNg1Hnj8z4BjvmK5OBx9iBsWEpXKkrJ WUQ+d+NIkXc8i8Kvfd4jPkPUjjN0jGXVganiXut/GggAxueylX8W9MR5LwAYHH7c+LHFs3JVi4nz b73ylqMA5+n5JQBLAA4u+AnR7XhjbOaQBsC1GXghMgagQmEI2sEA4Ox5MjLYxOWz4X0CFHZeXChA Ame94Gqhu9Cyi3K2OpfNjIhuMPf4swAUnNuGZdHr3v+WMPd83QSAxy/sK8oMnNSJyzylbWc5MhJ/ r8JnzehD6vTJKQEDoqLEdEyIYgG08J7UeWBzkXf1wWlG0bMKNloA7stazAD+6auGiPwQA0M7Ghzw hMX9jO2jPYAdNI/xH5x7cQPHfY7No8Bl44y5VuPfhLZ4hqypqQxzu0t2TaAwYUJTgaK5BLAfvrta KKZB0xpnyo9ZaQxifZUDHjy1s3GjUbLCj4LOUCwDAPuxGP/3P3+jVt3qi36NmN1NbHA8HUQD0z8J wCEaFuTgJQUsUyAkADA4tPVHZooFv+LvivKTyk2qAJw2UwpWJIosABjavA+/HhWAgzINW/+P/uYz YHxOy2eiNz/sE2LryUsU8TJSnsLZBJcHEEN+3FvH4tyTd9ZTaAYvKFG1aFNXcLgq9weRb+vuDcT3 6g3L08xlQ8X5LZSpwC3DlhjPoKSETYEWBMBxzudzWjzvziJn9Acgl7tQNnEvFKfTTzbS2YebKVKU iBQvQWwaNa0HjZ3bi6rw+fOKvVPEZqF2k4oiP4B2zNzeQvw+dYUitkaCOBtn3hEjKcpa2VkBCxsW tF+7aSVxDxrdPfu3oegxo1KMmNHowpNtdOKBYm5VuFgewVmjbydYMUuMvVoxevDhqNjwhA4dmvZc Wsq0O+GzICwBWK7AkgKSAmYpEBIA+AkD457Li4UJEgBFNZVRbFUV+9iazBnDPOYWa0eDQwRgHL+9 TpgrQawbjbWgy7PIdP/V5cKsB2WgKQxlrDwMehOY0wVIou7BUzpT3h9z0A4WQUMLegyDHrSco8WM Qp36NRUa1635jBXcJsC8Zed6QlEKylqJkyegv9mOFwAMjhKAClG23mkH+rCRRd8Y0wzmfNEuEsyt fiyRl8qw2BiOL6BItXj7eKFsFiV6ZHFuW7DoD7TnyhJ+xoEhLi4W4ubYcWNQZ9Z4Rn+hLFW8XEHW hs4pxN+oo1mH2kKbefjMboIbB7d+9dUuqt+imtASjxwtImta5xXcunLey1rQP/9AbXs0En1HfmhB Y1PTrtcfAvyhVJY9TyYaOq1rAA4/MBynp5WVACwXX0kBSYEQC8BYkFVXlFAYMrdAAyAUF4mKP2zY vAKEYWpzic9tL73eLgAOYIJnqi2wajuslsV9LLj4rp5tArBgxwuRMDhHlAGAq3lVW+MzTzeJtiEa Vu1stfXo+4368Vx1ean2WXW3ic2F6u0KXD02DDibhRMP0OGW8Et9XIi9cV6MfiM/NiDoI+pRFb/w GXm140Qd4G7/+7CbPXxtEWVAL9WGWXX5qe037qGc2lfUp9hS+64fcgnAHnEGbI+DjMCgRHDU70jM 4cCMxRfLKp67rMdstiePa2kTEjhgFQAASJYCAVgKEqA4pjgqkrmyqvcsOJ4w9RZlGnAAi7DqltJc WwA69QzYWj0BQTjgmMzVrzgOOWZ2HHhm3guXqacvc/RDWyhrzre2+X6Y9tfanHgaJ+tsfyQASwAW FBC2rhYjJLl2YQ9Ym/0bBG+yo7VMNfvHa76OwJa3bz5DEgA7u4BaKqdysCrHqrin9HfbqC1nCcCd 6ZMW2Ky16Uzd5sqgDcVLlu9yqa6ilbl6JABLAGb0XULN1ShD9q3NLs7lCKBofWy7uBvBVp0j4zXX qcCWt2+gEoCdBxWIbhFcAQ43ALBqQASc7aquG9UFGeefqmtKa4AOkawSP9iye0aIiFG/otGsaE3D TEkVIbsSTNDWBQ7ugDHisyvrDil1SQDWA7Ambq7qElFksRDz1nqcV63HJWueqwIuqNp4taXNgKPZ GMIW4/JaX7BNx2DIayu2sfpc9M2/fqv0MNc/szF3BU8u3FIqHrZ0tEM9Nrh1SzGWLdM14LgDBInQ 0MRUXGx9nk36Mmw4NTcG0VDdl9pDP3PzopQPqljDEoCdB2AoGyHwQYNW1egkBxooXCIPB1koRH91 b0jX3u4W571QYAKgwu4X2swwaQLw4CxUPT9GHgAoFKvgAARBFqDQBUAHmGsBHWeuUFrqNqyVUGpS 2ixMTVlJ6tKr7cYzWzUkonpui3JKXxS/1DjPxnf8V3084zvygdNVoyShX+efb6XMOdIKZTD0O6QA p6vGKQHYBIAtxXm1EvNWBwbaxdBEXGqVyzQFSH28Wr3Y1XwMYVtxeS1tAPQcpXLWqAX9gHGRTZ+b xBm2SA/H+meVdjY4dksxlq3TVTdusVnQBtNwIgawKto3bqA40ulB+NK04l/aIv2suDO18g7ax+ua zyUB2DkAxtnlo+/HKFeBLELLeBVr/8Kf8oEry4V5DRxg7DixUDjvmLl2GMEeGAA8e81wAWLbODrT Cg7YAE1meJ0awdrFd98eEuZAKL/h4CzhQQruHnuyQ45r73cLbhc2s43b1RS+pHdfWiScauy9vIRS pU0qzJHg+xnnsdBGbtuzEW08NVv4pIbGMbSPF+8cL5S8Ji8bKOyV528ZIzSQz7PrTWwmhkzrIjYG cBzS6p963L85IsADNMTRF20EJ1cBlK/XIwHYogja3gg5yKddqC1FT7ImOrUVaEHfhj1+oG3VqQ5c WzfumRu3rbr0z83RQ7/IW6tT3wdzmwRLIRgtzZulcTkT7cpa323FHjZHY3voZ4te6jjQvrXwlPZD sgRg5wAYIHfqyQaCn2NEHVq1fyql5cAC6w/OpPgMoBMX9WfuNLdw8LFg7Vg2S8pO/ThkIOyITz3Y IGxnAXgLNo6hAaM6Ugr2hIVgC9XqlaPk7N5x7a4ZVL1BeWFTDI9R9VtWE+AHrrtV1/pUo1EF2nt1 CZdLIsTDSdmL1uDJnYXbzLNPNos+dB7YjA6fW01t2NY4Hru7/KNNDUqSIqEA7JHTewhPW/DAdfja KuE9C+Dfd0R7mrp0EPvGzkT9xv4tPHVdfbaLOvRtTL9xnxWPXM7RzNeB1tL4JADbCcDWYt4a/fua cCIGjkorbtSLUs22rQdE/YJt7rlSkeU+WtlMBOAmzeW1BSqmZczTw5H+2aKdrc2MOQCyh66Woi1Z 4VjFhsVSDGBLc2WtPiWikhBxB3if1P4FnCNjGcyni5TpJAA7ByYQ7R5gcTHcOyJwA3woR2U721IV fxI+nB9+OyaiBk1n38vf2WtW5hzpaCl7lILDjead6lBett/dd20pTVsymJ18NBZepwaxt6xRs3vQ b8zdwrMVAB2BIOo2rizKgHMFh6sC8KGbK9k3cxQqwRGT/hnSkm5/Vkyg4CazRYe6wk3kut0zhQcv NQoUNgDgxodP7SY2ACmZc4YHraQMzIhgROxKpCPbKuN+n+HthC/so7fXCHD/sWQewS1b0iQPqQBr a9wSgO0BYFsxbw0LJQDQcnB5a5yHPRymJU7NUK/VPtri5rWA5SinaIajM0cPh/pnrb9qe57KAWvn 2V5uXJfP5vtkpl6zZeznds3llADsHABD6eoiKycBJHezkw8EaIATDZzbwisV7G5TM/c4jsP3gWtN niqJiF6EsIXwBoVz2wdfjwi/yxBXp+egBb1GtREADC714PmVwmlFnaaVacGaMexgY6YQLUME/Sf7 p/61RgnadWGhEEFf5/jF8MClupi8/HoHrd45nd1dlqGSlX6kf1h0nDFrGhoypYsA1kGTOot2Jy0e QHHYiQZ8OCPkIETSs5cOF8EfhO/nVaNo7vqR4jwYZ8y/c3QoNRyiLdCRz/3fKwnATgCwaSxgfwBq rhP92W8yE5CD1J7Bmo1fa+RyDOeKVuPyWgM0C2fAGi7KtH1bImoL9HCwf9ZpZ1kKgNYtxVgW9zUK bdbHZUvk688tW+ur+b5Y54DVYwDT98mOTZqLYw1LAHYOgMEFQoEJHCI8Vp24uY46ccQh3Fe1lLuz ohTOUKFc1XVwC46EtIhuftlH9ZpXIYT7EwEe2EtWw1b/E+ezEGNDqxriZXClB5nDRd5a7C5y8Y7x 4mwWXPCMVUNp3PzewmNVh35N6MaXvcZwfjgnhl/pll3rUgMWW+89t1RwuuCwazWoKAIp3P98RERH AuC2YU9VUObazOEZf2M3nX/1aEA33+yjPrwpqFa/HPe7peIzmpXLoPwlAdjx90UCsD0AbKKRi4Dx S1jsaHoOa34R1oknLZr6mBcpqjF2A2pB6+PZCgG0RmtY30frHKVpiDxDXrtiG2vPkW3Rw1r/zMUp tkI7m1rQ5uij9NWmFrTZeMP2AKa9sYd1xwVio2Nh/k1EyaZ5TGMUa8bmIvEzapQA7PiCqnJ3OA8d Oas71fyzooj4o/fXDHGt6vUJ2sVYiKG89doQHQjax4oLyTMC2MDhqprPqvYyNKnxHIpbqgcufAao wwxJ0Vo2dfqBNlAGz+DbGeER/xDhB28ZAlCgnFIv2kU9AHeMB/cA4mq7ahjBoqXy0ymOL6w6E5Ec rv3vjQTgwEnpfKO0yTmwLfGvu4fsC3bAQUNDV8calgBs/0KqBx0V+FQXkp4ISgBjiMrhF9qZsH8Y I9xowo0lgNkTx+jpfZIAHDRrodfV6u8Jy7MB2H6xvtdNQeA6HASxhiUAOw/AWPgBap7MFcLHMgBA cdLh3FgVd5zmfWh7Ovh5Qv8kAAdu2fPB0p4NwD5I8EAPSRGr22Oa5lhTEoCdAyVnF/bbDIR3BCeJ gA7q5+Dtg7N9D1gOY4AjDzjnwOcznADUWi9eCLQA8D8u8inPQxYnLQHYsTVJ5pYUCDEUkAAcWPBT AQbgcopPWc9yAhABmOBSUgUcnNOyghbHyb37cY8Ao7ssGr7HClB3vNTF420G0icbRtKDq0t5zOfp 8bZx9IA1wgHEt/g8GffEOFmEfZ/DE96/t0YZ7/cDhmdK1CdfTxKAQ8xyKgcqKeAYBSQAOwMARwTA 3mItZoDsXdY6fnBtOT1iU6EnrN38mDWWH7FG88NT8+gehxi8y5rPyH+DS7xkbeh31UvQ7a8n6SPb Aj9dM1QAtjeCEED2dfvf6SObS92/upo+synV/Vur6e6j7fSU7Z9ft61Jn3/IQN8SxCa2vRLpe7iw 9JVtp982rkQPWfMadfg6RywB2LE1SeaWFAgxFJAAbD8AQ5QK0AXH+ujwLHrV4w/6+GMO+hYtshFg VKDR/v/KXqk+cnD6l71b0DO2C/7C9sLvK/9EH9i05/ZXcMjeGuSAnX682kWf8mSiL+mSijG+Ze9d FCaUoMe3mNHo4y/5GIh/pxfj/6Zns3rSyxFt6F2tsvQtTnSR51X3RgZJAcTx9s+FN+WVABxillM5 UEkBxyggAdieRf+wEJnefbuXnk/qQl/SJ1e4ufDhBBf7umMdej6rBz3ZOIqBeQY9OjaLHrPDjads r/tidFt606IafWJHF98jhjNygSiP/DfZsYbpmak9/fGcPDfZ9eXb+gy64HBDh6avyRLS68716dGh WUyvXQaR/HmxcfFPF+nu6z30ulsDUe4NB7OA6B4iem8CVnv7KgHYsTVJ5pYUCDEUkABsDcygWHRS cGhPFw6gr0njC8D4WCIvPV06mO6xz2VFFA2AQTprPPuFWFk5Dwbw4CyURdVPd9ATDoqAej4VzELv 2FOVNwMPxv7o0DT6xH6j3zarRF/YzeWdT4d4TJcMdABXax5UoZQF8H45tKWg6dPF/QSd7AU1b8on ATjELKdyoJICjlFAArBlAMb55L2HW+j9b0UU4C2Wmx4enG1QMgKoHneAawMwXWaxdSN6z8EV7nKA g2+xogklJu88A2bls+8n6X2Vn+nlwOZ0m31ff86aWihiAZjtA0iI9M/SxyI56Su71LzzCdrTvieK lgDs2Jokc0sKhBgKSAA2D8C3WDT86PBs+po4DouOw9OzeX0ZLMDtBkZUylrDLJq+f2uVqOcRhyd8 eOZfg6a054iV7QNP5my/76f77C7zztf9YjNyjz1l3WP3mI6caWOT83jPJIULXjnYoJTlbbSw3l8J wEGxnKqB51XXkybfFReLpgHdXdEJbb22/Aa7oj1ZR0AK2Jpb77KxlgAccPEE+D7eOoHPNEPR5+xp 6P4VAOYlh4DFPIhBpA3TJHDOqg2t8tk+0PM8YFLGAiUyjAefFRtn+8fD+b8fFmL591V/NmxwPG+c 9o8nYN8lAItV1NR3sNEHsy4wvX2Qo9TlD7D67/bVErhcvgjAgQEvnV/pIHBaYd98BWYM9rXgylwS gLULJuxTmfPdqXBkn37KyVq+ewyg4Aio+BaABAZ87CmLc/K3HHACIvm7n/YKxx32lPOWPBKAA6xY gV0kbTnud+USaakuCcCmlDETyMBiYIygnJ/AvltB2beAdUsAVsES4HuOHp5eQN8jhKNP+TLTnXcK x+oYRyfB11FghPLVszk9xaYHTj2g+OZoHZ6cXwKwTQA2LJoHOdC5liNWxcqGYOwKx6vjtIYNNw3W bi3yjaGe5ouN4XiMPTMbrUjNZgzAbgl07Vn0tRKAgC4NtRGETCNBWaCNiURBV58J3TQxfS3dFwIK A+3VwPf6UInqfbujTZmhlX5+uVlLkZNw32SejKEWrUe1ChhFyxLdLdE1eAG4ao1KdOXDDhFyDtF4 Qmp6wGeyd5/vJOJYvMQxfh+/28f+jy+EWHoE53sAOj/ns3AA8PPNY9hv9WWfojt+W/iN4bfm6MXG Xd5xGRdSu7gecxysaRxZIbIetoT/Gi4BHiqY2OKArXFjhti+erJqw+8xGA1t2doIAAiioICB8wBs EuDAJDKSIUyghm6msZANGw4dXS3Xh/wa0DWO09J9LSECgpvoi8X4vtbK6mmln9+A4zYZky4coj8g W+e09XGkrdMpYJ+C+9dWonQx2nBqOh26sYL2XV8S6HTg5lI6fGdloOtxRV/sruPGUjp4bzN9qFCY 3jAIHNwwjPbc3chjWOxd43DB/NlNMxe2tffGSjp0ZCp9Z9pfH9iUdt8E7QP/Lga2jgM3l7mkH/ht 4TeG35qjl5cAsJYrtcdhvS0ANUcmayJfa/XZw50aOEAD0GARH8rxiJsbuMADw9QxOQvA+j5ow/2Z 658t8baj9amSA1tzY8+8WAN4//pNgdvWGNX51tZt7bO5+dDWYem5Lbo7+vMMfP5//vmHatf7nRr+ Wc8lqX6jOlS1eiVq1Li+S+pzVb+s1VOnVRMaUzC34MDmlfmF6rRpSg3+rOs1/Q8OGgVlG/X5XWnW sDZ9CB+eVuXMRrWbNfII2rvyHa5TvyZ17tzZ4R+slwCwRpToNAccEByMAdFV8adRsccWUOgBzBxH qJ8LdXHGf+RXAUAPBLbA2NLmQRNMXoxHW4++f/YAsKX6VLBVnptqgvtvlMxriJujq7W+6TlgbZ+0 5SwBsPW6jccCJtywrbk1w3kb3x893W1tSBz+vbq9wMkTp6hpk2Zu74dDHXjxkihOPKJSpeiLQwVl ZpdR4PNXosSJidq0dVmVgano3dv3NGb0WKLvgakl8GW9BoAdG6otAOXajGd+9nA2LuCAuRllwee6 tJwvzi2N56Gu4oCti30ti7rN0cIa5S1x//betxc4bXHYznDAhneAaS8kEuL8X9+OrXqtST/slIw4 9mK7PfegQYMocuTI9Pr1a7f3xe4O/PGHcKNIN2/aXURmDAIKpEtH1LBhEFTseJXnzp2j2LFj8yvh 3ndCArBh7gKei2q5F+uAbhpg3sIZMNph0G+uOfsVmwATLtJZADZICDSKTdpX0rR/qjTBmpjVen3+ dVsyz7J0PyAoib45dQZsa5NhGIPVupX+NBcSCfObD+u0s0Yn3wTg3LlzsyTXj9atW+f4queOEkeP Kn6MJ7Ddr7zcSwF+d6hqVff2wdD6mDFjxHs8evRot/Yn5AKwzm7YrGawUUPLFkdtaoNs2UGHrh6h GWwJ6G2JifXvjb/4V9hAm4jq9f2zp25L9Zne99cktnTftJ9GsX+gtaBtAzByWNKCVkvrAdZUOoBc 1miH59bo5Fsi6GPHjlGoUKHEwtW0aVO3Llx2N166NIfLS0DX/rtKp04co+1bt9Ktm7fsLi4zuoYC b9+/py/58tPbfPnoyKkTtGPbdnr+7LlrKneilpIlS4r3uGDBgk6Udl0RHwVg1xHIJ2sSwG/PubVP jl4OykkK/PXXX2LRQkqSJAm9ffvWyZqCptjXr1/p5o3rtHnDOho4cgSNrlVLcL/DkiejNDmzU4ok iUTf48aJSxs3bgqaTsha6ePHD3T50gVas3I5De7Xl5o0bEAlKpSnUzFj0pEI4SlWogRiHtKnS0+X L18Odordvn1bHKOgD6H5aOLEiRPB3ge1QQnAbiO9uxo2cHQWxNXu6pVs17MpALDNli0bRYwYUSxa WMB2797t9k7jLHr/nj00hBf6ahV/pZxZs1DSxAkpctw4tIwX2BucksaLTwmSJBULbtiwYQ0biKT0 4oX7ODC3E87FHXjy+DFt3biBenXpTBVK/0JZM6anJAnjU6wY0Sla1Kjkx+/NTqb9YT9FgqLOw88/ O266E9iuq+JndTPZpEmTwFbpdHkJwE6TznsKmohhIZ6W4Os9k+chPf306RP9999/NG3aNEqdOjVd vXqVAeyFW3r3hTndgwf204CePalMsWKUnDnbGNGiURxWqokTKzbFSpKM2v9WmVheTutLlaYcxUpQ lChRKSZzYClTpqQYMWIIEIBCmbycpwA2ZVs3b6Ku7dpR0QL5KVH8uBSDwTZuHJ6DGDEpebKU1KVr DxoydATVbdGKjvFRwDGekwhx41LKVKkoUqRIYh42bNjgfCecKLljxw76+++/xfswdOhQWrRokRO1 uKaIBGDX0FHWIikQIiiwlc9QM2bM6JaxPn/+nObOmkU1KlekNEkTUbyYMShB/HgUhxf02HHiUExe 9KNGiUZ+kaNRX/5PESPRpllzad2OPdS8WSsKHz4CA3AqSp48BWOzIkZ/9eqVW8bizY3evnWLxrPy UoVSJShZgrgUP04siifmIQ5rFsfhDQ7PQ+SoFC5sBMqe/QcaN3E6bdy1l77kyEm72RbYL2p0Ssvi 50SJlCOBokWLBjs5rl+/TilSpAj2dvUNSgB2+xTIDkgKeA8F1qxZQ6mYewnO6/PnzzRh/HgqmPcH ihstCkXgKEaxY8USG4HozM0CdKPxoh4tWgyKzCkSf77KC/u2CBGpeuMWtGTZKtq1ax/98WdTXvBD UcKEiSh69Ohi8Z80iQMzyMsuCmAD1Kt7d8qeOT3FjByRwvEmJlHCBAJMo0bFHETj/8o8IOGzn19o 3hwloM69+tG7tOnpeZGfqVilqnyMEYbNgpOIIw3Mw969e+3qg6synTx5kpImTep2PQYJwK6aUVmP pEAIoMC2bdsof/78wTrSdiziVM/r1P8JWJwJEI0UKYoRgLHgh+KF/xe+B+WrMgaFsTp1GtKyFWto 0+btlDtPXlFXHOaY8T9nzpz07du3YB2PNzaGTVBp1ig3mQcWJ4OLjRw5CqeoLOZXNkKYBzVFZCmE KBMxKh1j8fS7goVp4YbNlJjP5AHC6jzUgsJcMF7Hjx8XImh3KxJKAA7GSQ9o4hKcjdvrHMPVffI2 e1hv66+r58t6fTgLfswKN8F1oT2ICrULf5gwYQgpAnO4ESNGpogRIgkAiByJz3ajxKR5YcPR+yiR 6X+VK1OHLl0oVeq0VLd+I1q/cStNmDiFy0UQ549RokQR9e7atSu4huO17Vy7dk3QXDsPUKSCQl6k SJGZppHEXERm8X+UyCyFiBRVAGwq1heoXacuNWrfgXYwt/s6QyZayUcC/3TvKerCJgr1YC7u3r0b bPR5+fIlLV68mL58ca9vNAnAYsqDa9ENrnbMvccSgO37dbtzjuzrYUjK9f37d/r5559NFn7YImPR jhEjFsWNG19wW+HDs3Y2A0Bi5sJe88J+ongJ+qtvP/qpaDEWU8dk8AjHvnq703Ze/CtVrmrggmOL /w09xDuTJ88rACtZsmQB5iFcuHB87huXOdl4YhOEeQjLZ78JEiSiZs1b0JjxE6jVX20oQ978tIrP 4G9Ei079ho2mDZu3Ua5cilOXWHycgP+jRo3yZBIESd8kAEsAFt6gFgWMoOiiF87bAM3b+uuiaXKy muBQYprAXqy0nBcAGBwTABgLfdKkySlGdF7Ew0Wg6uHCC/HzjyyGxvljqFBhhJg6dJiwFDdeQuaA p9K8uQs5P3NpkSMJri4uK3HhfFNe1inQrFmzAJKIqCxWjhkzNp+rJ6EkSZPxvERnmoYVgFygUGGK ykcCYu54AzSb75/lzxkyZqEFS1bQ0CEjKXSo0Eat9HzspAMbrpB0+RgAGxZPNS5sgGABZmK3molT a1/sXuU1sexpSdcX4ZnKdHFXytpwiGE2ZrGGa7c4VtO+BYxjq77mAWkWsE/WYw3rfzCOxx52gI4i 8IEZ15EaOjjaf8v99e2lAIooT548EYOET9xHjx6Jzx8/fqRDhw7Rhw8fxPeDBw8StJ+hKLNx40aj H+glS5ZQgwYN6M2bN7R9+3Y6cMDfoSfKnT9/Xpgr4YLzA5ibIM+mTZvo7NmzdhP3/v37xkVaBWLY IWPhTxA/EXNmKVi7OQ2F4e9zWST6mAE6MoNuOIilDQnnkyibO3c+WrtuM9WuWdeE+8JY5GWdAph/ /Vk8ADgW5iFBYtYuT8nHBamEQhYkDtj8KGJptgNm+o/lo4EHBk9qZdlMbMOmbVSoQGFRJzZU2Fid OXPG4WnA+/ru3TtRDiJl9TO+4zOe43rP3rgg5sZmC++UuulCGXh2w7uKDaVeFA4dAXWjic8o+/Tp U/HbefDgAcEBjLOXDwKwxg2jSYxfnd9ek5i5Oq7Hrti9NuLNqi4KTVxC+rcjXDLatMe1FbPY8lj1 cXb1cWz9XxiDK0V9vGBLPpR1sYb1L571dgO2hfLWYwLb6p+t59bm3VasZGd/Vp5fDmeriTk6TZEi RURnoQTTp08f8Xn+/PliUQTniatXr16UJ08e5nISUu3atQkmHLgqVKggtIiRD5rRZcqUoUqVKgng xmIXL148ypo1q1ByAoBXqVJFiBtLlCjhsPZx3boKYKpJEX3GpvjxElAy5oCTp0pHaVOmoxfM0c5m rsqPARicr5oAAgADlG/StAX9u2AxA3gs1tZVgLlmzZqeP2lu7iG4U9UXuDoPOEuH6VGC+AnZ7jcF pU6VnlKnTMtnuzGEODpiRGUO/Jj+A1k68YK10GOzKDoUf+43YDCNGDlGSCFUMfTAgQMdHmWPHj0Y /JMLQIVzGLyHuAC8adOmpV9//VV8xzO8e+nTp6cCBQrQyJEjxX1sHnPlykUXLlygzJkziyMP5FO9 dPXv31/07+LFi4TfTfXq1UU+vNt16tQhiOedvXwQgO3xrSyWfQ4LaCEggQZk7Ivdq5IfYKByZ+ZE mYZ7izkIg03wNTel1nw42/Lv7MgZsLW6tHTT99HKmIWI29ZzB+loV536Nm3F7A0ZImhof2IRAuex efNm+vPPPwkLGa4aNWqIRQwLkXotWLCAypcvb/wOLiBDhgyCM+jatatwbIALCzMAeuXKlfTTTz+J BVs1MQEQZ8qUySHuFwse2sL5oJ77wqIYL248dsSRguLzwl81cXIhfq7BWrl+rBSEhR+gqwXisMyF xY4Vh6bPnEs1f68j6gQAYHPhVRGenF3xnSwHTvLOnTvUunXrAGJobIQS8EYoRbJUlDpFOkqXOgOl TZOeohlAWAAwp058RPCJ6Z0M88NAnD59Jlq8dCUVZC44bFhFwUvdEDrSTdVFahdWuAOYAhxxrVq1 SnzGewonMuBUMcfZs2cnOOOAZjeuRo0a0eDBg+nGjRvCUQuuwoULU5s2bcRn2Cmn40hOeM9xYXOJ 3wg8aKlSIkf6q80bwgDYWsxcLXDbG7vX2Ti79vthdi5msXYjoAU1c2e95gBHD1LWYgNrXydb7VoC YEfpaAtE7e2/rf46+7Py/HJYiEpxfFyALhY9cLbDhg2jZ8+eCQf12P1D+/j06dNiMLPYAUa5cuWM AxvPdrkVK1YU33v37i0Wtd9//10sVljoqnLUG4B2x44dxUKFC2CNBfHw4cN2EQiADbHg7NmzBXcO LkcLwuC+AMBJEyejOKnT0yQWhX5mMeYPzIFFihGbwjGnpeWAVXE06ihVqhx79ZotOBvVIxMWb3kF pACA6tSpUzR58mTq0KGDUWqgzgWkCPHZ3WfypCkoHR8FpGcAzpAuM3PC6VgjOprghP0YdBvwfGCD lI61pkNBLA1pBNtpDxo0jCDRQMLRAoDekatly5bUuHFjIaXBu1iMvaPhAne6fPlyAbA92WuaeuGs GYFFcIF7hT05jmAA0pAK4XcAIF67di0d5WhakPTs27dPmKypWtOoE+Zxgb1CGABbUjYKCAyOxe7V gpwdHLA4r7QDhJ2OWWwvp4l+2wJFRzhCW+3aeu4IHW3R2dpzbTv6d8KR8Qb25+e+8gBgLET37t0T QAxzkJkzZ9LcuXP5PC+BOBMDZ6OKpfFMFe2h1wDaefPmiQF069aNcuTIQQsXLhRnbjgfix8/PlWr Vk1wwXBdCU4Wz7DY4XzZngsLP86NsdC1atVKcOAmyljskAPnj1AASpwqLZ1j86KjvLgnSZ+VzV8y 8OIfnRf1CIqpkoYThskMvDQNHjycNxFVjOY1qgTAnr6FpDw448exBOYA3CYkJ3pzpDisCZ00UVI+ BkhDGdNkpAxpmfNkEE6RPA2bKLHon0G4ogGA8zD9IZIOGyY8u62Mz8A+jcEzn9E/9NKlSx0iL/QQ sEEEcOI9rszmZ3CTivcY7yCkMHjX1QtArW4C8c6C28WFGMFQyMMYV69eLe6BC4b2N9qA5r2q51C/ fn0jh+xQZ3WZQxAAOxi71WbsXlvxZm2Aje582uwk6gDYkZjFtuLY+rdnOEPVhwe08t3aC+d07GGL cXtt9c/W88DESg7MT8uzywKAsTDh3Gz//v3GM1/s9sHp4P64ceOM4rw5c+YIRwy4wB3jHE1VYgFA /oGg94YL5YsXLy6UVKDQAs4V3ATOECEOdIQDhsIWFv7Gjf+kFi1a8KKa0JQLZkcPsfn8MSufP35k 7ncSa98myJidMqTPIhZ/nEGGDcvuD1kjOnTosIIjhoIWACRvvgLsp3iU8fxRK3L37NkL3t5B5App BjZlSDDbgu2vFoQRcCEhK8SlTJmaxbUZKSNvggDAmIckfETgFz4SFWH6gwMuwee/AGB1HqpWq0Fd unQX9tmoEwDoyAXJC8AXZ76QZhQqVEi8w3i/8W5D/wDADGVCXDgGUT8DrFWf4EeOHBHuSdULvxGc IWNTinrw/qMtXPjvipCcIQqALcduNSjjmAQq0AFogNi9yjTZ1II2kaaY1qmKly3HDzaNRetYzGJb cWzV10xzLi00jPWxhJHPAHIWn2t/Ls7EHraDjjg3N9t+YPtvL50cWRI8Py/ExNBEBmeKCyHZwA1D 5KxqdYIDhQgOF8AUSii4IFb+3//+ZxwkxHdw1KBe+AytZ/WCcsst9h+MC/VrtVRtUQp1YXHFGTXO H8uUKWd6Bslaz+GYUy/D9sBY3JuwGDRZ5pyUKV0WypghqwDhWHzmm+uH3BzNKYdwDgEOGAnmMn/9 9TdvFpTYsPDKBO5dXgEpAI15iHGx0QJXmJftevVKcXFYGSsZxNBpGYAzZqPMTH91HmIlSUmFosck JjrVYS1pP+aGhSSCJRTRo8Wkf/7pxUpN2USd4LAdMUcCcF66dEl0Gu/rHo6Ohf/gaNVr/fr1Ro18 6DxA9Ix3EscseH9xYUOJfKqYGXm0gSKQD1YAuLCJBE0Ce/kYAAeWHLK851HAlkjY1nPPG5G39wgL mLrgBfVYsBhCe7VTp04ChM1xwX7M3XRkZTJEPyoKLdzMOSgzA0AmBgBwYenSZqKWrf6imrXqUOyY cShe7PgUkUWiYdhMJhGLr3//vbbxHFh6xTI/o9g0QSwL8FW44EbCBaURhNkvNDSf4Wc7DZ/HZwD4 ZspGWXgeMjIXnJLTT2kyECMu9WKt9YjMLceJFZciMACHYoWszJy3EvuIhikSolVhMxjUF0B6xIgR Qd2M1folALuV/LJx2xSwBbC2nttuQebwbAqAE8FZHZRtkMqVMz0L9uMIO0tZfPmARZupeZFPz4t/ 5kzZKRMv/gDgNAzK6VNnYmDglCI9f89ASZOlpdjxklL4iNEpFUdIissmUwCTiRMnejYx3Ng7aKND tAsAhpgYynpaLhgiZJiewRYYXDDoLzZCnFIzAGdn5bivTONBseJRrDTKvCRKkppixUtC4SNEYXF1 RuNGyBNiTQcHqSUABweVZRuBoIAtgLX1PBBNy6IeQwGI/xBIHYs/uOAk7Mxfu/hf5oV9HZ9DxmHz F3C8OINMz4t+WubG0qRIS2mSp6bMWXIqykGZ8/DZdl4Wl6ZmTpg5MD6bhDga9cnoSJanHGJhOMoY MGAANWvWlMXRf5poRKvcK85RBRfMmx8cA6Tn/ykZbDOkSEMvWHFuNksd4qVjzjhLPuaSc/PZcWJW igsvzuhRB+YBYuSQcEkADgmzLMcoKeAiCuAMt3379i6qzf5qcC6Nc+p+/foKpSyYQKkAHJMX7M+c +rMYOgpzX2lSp6M0bAIDDitD+hyULffPlD0Pp6x8NsyAkDJZGkqRNBXbA8cVGtDw2oS6YJKkml3Z 37OQlRM6Azt37mSlqS7iTB5a7tqNUHiWRsRl07AUrIyVmkEYTjnSssQhXcYfKGveYnQ7agzaxIp0 8XkjlDJ5WkqWOAWLrmOKoA7qJgga9apXtqCiLkydIE1RvWQFVTu26pUAbItC8rmkgKSAkQJwsAFb SXdcWCzhQAEOEQDCMG/C4p+dExSwqvPiH4EXd3jGSpsuO+UsWJpy/ViesucrRpmy5BFOIlIxMKdk jjgqAwHKRuSISmH82E80m5/A1ApnnY4oALmDDu5uE/bceA/gfAU23mpIQRWIcTacKFFiSpokGWVg Djdn4bKU48cKlC5PUTrFUZK2sdQhAZsqJeNNkOqdLLLBS1k61q6HjoGqHBhUY4UdMM6aYWLlzksC sDupL9uWFPAyCqxbt06YErnrwuIPD0fgwOCNyI9tM8sbADgz/w/Fjhzg1Sp1GhZDZ80vwDZlstSC C0vPmtFJk6YU2rdR2AwmAQeKjxUtFhUt8hOtWbNGaMGq3pHcNT5vaRccKsxzoBEP+3AT+2wWI8M5 B2IFp8vAJmEs8k/O2uhxmBvexQB8jk2YYiZKRmEZiKPzRihB7AQUJ3psYb8LhxeY46AOEwgNZtj3 ynjA3vLGyX5KCkgKkLsBGFMAkyjYpQKEk7MP37YMvB8gQubkZ9CixeKfKEESSsUAnJYVfhIlTM52 p4jcE5PPhdldYsr0lD1zduFEBEEjYPMpwdexFxxmPFOnThWOUvQxmyFSjhU7luCEEydMyj6iM1Bs FjsvZc9Y19hXd0y2107LCnNpk6ejfHnyC7/M19kVJDjSwAQ3sHcEEoDtpZTMJykgKeAxFIB2qupr 152dgpkKOLCaLIpey6JEKGGpXBgW/xgcAzghA3Ds2PHEGWNidleZlZWwsrKTjpxZc1CTPxvTtu3b BNcLf75weykvxygAUf2VK1eEZjTcPoLueg9Zsdm2GvMAW+wI7C1rIsdufsnOU3KygtwPP+Sjjh06 0pGjRwTXiyOG4BL/w6YdDmLcPe9SBO3YOydzSwqESArAFAgLbfPmzYWLv7Fjx4roMe68rrNm9GT2 0PWEz4JXaAAYIICgCwnjJqTM6TJRjiy5KGumHFS4QBFq2aKVcK7w+MljBXi/SuANzBwCwODwAu+G 3kWlcsYeiZKw1nPWjOweNEdeGsoOU96yLXC/Nm1pJ4emhMtIAG9wAuHDhw+FJAdSEkg/wMkHF/Dr aS0BODBvnywrKRBCKACwUpWeVC5HH/83uEkB6LzKHNh3dpw/QcN9hWHHDgljJ6RUrOSTg7ndX8v/ SgP6DxDuBJ8xx4sFPzjEnMFND3e1h/NagDBcl+JcVX0/IrCv58Rs45uaTcB+yJGbKjVoSOuqsQe1 8OHoNQMfovQGJ/Cq9Onbt6+wNwbHjnjG0CWQAOyutyfI2w0OO9XgaMNJQgmf1+bcW+rr047B0mcn +xCgmAfTy1VDDIJ6ELJNXVxhKuKOxVM/rC8sumR5Mx3mmK/lWAyKs8js2bJTdXaV2a9/P9qwcQO7 GrwhtJtxxusJfQ6CqXF7laAtxNE4E4ZPbQBxvrx5qV6dusLb1M5dO+ne+3f0YdkyobH+nQHYXReO UbSichxluOvyUQ7Y1L9vaXsiDwXZDATHYh8cbVgDTEvEU+bBsq9rbTkJwEH2CrqoYsT5jRiRQ8vx AqrGRnVR1c5XAx/T3J+XLBK/+PixcLIPBZsHDx4IDVeYs0jQdZ68jpSEVAHa0eCGIR3B/8c8J+8Z eMXmB5XBwQa01g2BERyp31V58U4gvi/eY2jM43jFXZcPArASOKD5Yk0UBA6ksEgJhOGGKzjAMTja cAaAHemXBGA3vJwON4nQhVi4IM71iIsd8YsFnW1HscBDHIr03SM6FzI7ASDGHOB/ANEu4ktjvvgM 1p0XnIjgPXZFRKPAjMPnABjRiUzA1wx1bEYwEvF6lchAJtybKk4Vz0zj+dqs07gf0HLnuli0VurX D0PbnmmUJCWn5f5oazKAnqXxWqpHRIYyRE4yiSClr9tMHpMxaulrA4A1fQwg0bBYZ0BaKO+G6cZA oZUd8ZkD80vzkbIISwjxosdcDLxiQddEY/KYvsmOBKQAIg+xqRgHk3YrdeDsAwDs7uAbXgPARkDR xI0NOINYWK0vpCIEoK3Ys+pzk5i9luu2Xac/0JrEywWQGftiu+/qePXtmcYJNoRWtDhGMyBpdry2 6rGHu9Xn4c3HsCVk3IsEoK9KJz0Ym54hm47fWp36MdyhAwdNAVjUpYl97NZVIQgaf/bsGYdmO0nH jp1ySVq6dCXVrduIxbxnXVJfYPp15MRput2zD33nhfTUpm109Php0afj/H/OnH9Z23kLf3bNuAPT T0fKYq7On79IX799DYK3wQOqfPmC2BMK0ZjRbu3M06dP2J3pb/TxE1TB3Hd5CQBr49HquEYt7QRn Zg2AzYGGFvj0z+1RBnKkTjOA1NIc6Fh7ISy1Z60eS+Du6Hit0cpcn22BtD1iZ1vj1bfrwJwhxrAP gy8oU716VXaaX4FdN1bn9L9Ap7/+qkFt29Z0WX2B6VPTtrVpRf4s9DlcWOrUpBK1aF1DjK9Nm1pU tmxBqlWrNPsrVu55S/rrr1pUrFgeTiXoj0Z/Uv16DXwm1avfiBrVqUcf2ERsTY6cVPOPxm4dW/ly Fahhg0aB7kOD+g2pVs3a1KdPH4eR3EsAWCNSDRQHbA6IrC3Y5gBKL5p2pE7tRkIVz2o3FP7PLSsu 2dOefhNiCQhtAbC1emyBK97FgHkUbl0jmi5rieu1tqGAGN+fbtbrNLchU+ns+2LnypXLstnNJp6L o5ygCOGKdNjJeg6Jd8K+PqCN45ystcUB1/+pQ+zLkPPt1ozxNG3dOpLtO5fwvWN2tucKuriijgus vV2ffi39O21csY+Wzt3ofWnORlr+72Za8e8Wk74vMXz/GCMWXSn5K81fccBtY1s2dxOtXrTdJe2v nL+VZoxfTD//VMx3Adi+kdnSunWEWzUPIEo/bHFZljhFe0DLWruWnjnSHy0lbQGwXtoQSA4YImeT DVRgOGADeNpdp5lxi3Nl3wbh6tV/Yy9D6w0gtJf/uysBCE8Y0kn+f8rQJ4SdC9inr193sSbzKlbk 2WWlz1xHo/JEaZJwnn2coBiGuo6z+HkoXb260ADAB9w4bkfpfZp696lHTRv8TTfOP6fTB6+7NZ06 cI3OHr5FN84916RndPnEAzp9gPuGpO0jfz9z6CbfuyGeoewpQ55T/Pn0wZv0KVFSel6xJp0Q4+N8 5saIevjZOVHGTDtupou2z+eP3qa9m05RpYpV7IMpTS6v4YDtHplBIceEg9RoQYszWKtnwHqO1JzI 2xToHanT5AzY4qCsbyT0dSjn47pzZrvPgC2P15FxmR+KDuB1YGl6dm0NjHl8GlGxyfit1mmQnBjL BjwDJpNzaLvfMq/JCAB++RIapwAhgJ070iEOdN+eatYsQb/9VpiqVi3KThva8sZgi9jMKtyrtl+n OPbvX0JJZuzYNgawNtdvBnKuj3Kk5TysDS3AF/mO0+rVA+nixX/Zt/B2tgFGO+ozd4zfkTZPCQD+ s25bunzyAR3dfcmt6eS+/2jn+qPUqV1P+qt5J2r+Z1vq1rEfrVywhS4cvROgb8f3XhX3CuQtLEIR blt7iAH4mrh3ZO8VOrLvKn3guMBPS/1Gh07c5/uXLY7vBOdFueNczt10sNb+yf3/0fa1R6jib5Ud Xhd8D4BBAr2Wrk5sbb/Gsh4U/EWnek1rx+rUiGBNlLAs1286s6Z2zkMPBuSsHdKCNmpFOVaPUfRr 8RxVX59pv021t21wwzivVUXXJvNprU7xMghbZLWssjEz7Zc6DvvslR3+jbm1gPsBGJzpQcqVS7G7 zJ49DaVNm0R8Llw4GwPkDgN4gjsGGIMzPkPbt4+iRszd7to1lr+z6Qox2AoOF2ANMMX3i0RcB/2S lz9fNeRDPUfZBnUe3b27nNtKSr//XoLvwW0mJh/lsRlBebSF/OijfhPgCGi6Mq9nAfCFo3dp5sRF RscVkSNFEZ+jRolGY4dNo/MMwuBSwa0iXTn5kI7tuUwlfi7D8Zdz0fZ1h+nqqUfMFd+gI3z/CIPx u7QZ6XWJ8nSUNxjH9lwR5S8xGF86fl9wu0d2XRRlencdTFkyZmOw30r/nX5sBGG0o+S/R6f2A9wv uhWgJQC7dYmTjUsKeC4FPAWACxbMKhbuhw9XCaCsXFkJ5A6gffBgLa1Y0Z/u3VtB/fs3psOHJzMw b6ZNm4azr+ANdPbsbFq4sBdz8hsN4LmHVq0ZTJu3jyMqmIUeFMhC/Ye2phYtKtPixb3ZBhVgeoSD NXQTbaRhEfX8+X0EIANw37zZRpMm/U3Nmv0m6lUA2J0SAlPu35M4YHC5syYtFnQsXrSUEC+PGDhR fM/AfrbBIS+es442LN9D65bupJGDJtHhnRdo5cKttHDWGjqw7SzNmLCQ1i7ZSScZXA9z+Q858tC1 zDloy/Zzor4lc9dT/x7DafiA8bRl9QHmrO/S/i2nqfhPis15u5ZdRd0A9gvH7vLZ+F7qx/mHcf7d m04IMTdA211csgRgz13/ZM8kBdxKAU8D4MeP1zA97rMm9f/E4rpv3zj6998e4nPSpPHE/169GnDA 9wHiMwBy9ux/xOdp0zpx2Ut0/boCCL+xKJsqFKKp/Dl5puTs3SipuN+sWSX2frWHUqZMKL6HCqVE SoJi1ps3eyl//szsCzgCFSqUQ9yvXfsXPmsGdwwgdiU360xdnsYB+wNwORYbP7z2QYiUI3NM34Tx EzHwXaAsmbJTSo73GytmLEFPAGrBfEX4e2xWdNpGMaLH4HjM6ek4uFUG16+FitEyzjeL8zVuqDjE iBxZ4axR5+ZV+6l9a2XO1QRu+tqZJzRp1GyObhWDokeLTuHDh+dwk2lozeLtAoQlALt1qZGNSwpI Cugp4CkAXKhQNrGYLl/en7nR3rzgcjD26JH5fHYX+2ToLp7lzp2BDh2awVzvTs7TU9wDFwvON3To UGxaVICHd4WmTOkgni3juojB9GOtknwfIugzHOIuPcf8jcoemPbQpUvzOCpSGI7Sk4Vu3IBC1zHq 16+hKHv8+HTO/4j++aeu+H7s2FT+DkUxZ0DTlWU8F4CLMHDu3XyK2rToJGhW5pdfhTJWNg7ziO+/ FC9Ho5gD3sNcaY5sP7C5b0Q6tOM8/Vq2igLM8zbQoSN36AyHhrwSLz7tZq61L3Oy08cvECJlcM9i A/VHGwHyZUpWEN8BxmuZAwY3DfDNlT23EFGD6xb94HwXWRwNDtkdICw5YLnuSgpICpilgKcAcNGi yiKtpkyZUjBHOkoAKjhb3P/33+7iO9FZdqShcEBTp3YUXG/RornYD3V49iu8Q4ivI0eLTC+fs3JZ tjR0oXhuasb2yb/8ko/jzkYTnC/Oid+/30Lh2Ea4WLEf+DvOkSH6LiLqRX9+/jmv8TwaonDlPNiV YOpMXZ4LwNr5y8xnswBAiIszcmzfSMwRA5xvXXjBZ8E3BSjjHkTD44ZNFzTv3L4XLVqxh+bz5y+5 C9LxY/cYOO8LAP6rWUcjUDdu0JJe3P5Gf9ZvIcrNnryUHjHnPW/aCvEdHHejus2odg1lM5UiWSqh ae0uZS0JwHLxlRSQFPBoAFY54KVL+9KZM/P5nHangeM8ZQTgefO68b2TIqnnt+B2ia4bud4JE9pS 3LgxqJpQrGLb5qypqSsvwkXK5achQ9oKQE2WLJ4A4OcM0GHChKYSJXILUAeH/OuvhcWi3bt3Qxo4 sCkNG9ZCAP/Llxv4OZS8nAFNV5bxXAAGqA7pO1YA5mHmbM8fuU3QVM6QLjNFY5Hw3s0nhVkRFKMg MgYA44x2/9YzFIVFzPlZLN2sTQ+ayfSnH0sKAC7zy28UisNHFvvpF6G4hblp2ugvAbj1av4pvqO9 e1feiLNkfE+TKh1V+e13KleqIv1era44DwYISg5YLoKSApICHkUBT+GAce6KxVNRwjqjAbtTgssV nM7srkYAVjngyZP/5nsX6c6dZeLcNl485Zxx+drBfJ+ddKRKRL1YPH3m/krBwULhKkGCWAKA377d LLhmcNvnzy9gjngf9ehRT5THRoAIIfH2C3Olz5+hje0JpkqeC8A4A75z6bUQ955g5StwnAA+AHCU KFFp98bjJgAcMWIkNs85TNfOPmWw/I1ChwlDcZOmpKUA4GJlaR2bNwlpxI8l6ONTovnTV4rvTfhc +PH1j0YAHj5ggtC2hiIWnhfK/xPdvviS7l99x+1fE6Jpd3G/EHlLDtgjljxbTjYCmjT5otmLR0yF 7ISRAp4CwHnzZhKLJxSoFO9WKtd4ysjdagFYVbyaPBkcMMTHR6l8+YKiDgDsizdbiQCaKRJSa74X KXY0ysiKWAkTxhEcsMJhH2dXnMWNYu+dO0fT69e7SO1L3Lix+EwxCscQTsAcMLyFeYImtGcB8EXW OgYHCrr/VKi40EJWOU0VgJMmSS6eawE4ber04t62NQfp+tlnRs1p3FsJAGZPWAdZcSpDhiwiHzjg JImVeurXaiyUvdQzYdzD+TNMnGr+r4HIk4TPkXPnyi/Modq27CKeueP8VwKwyWJrCwSDcmW21bat 59b6prVlhecmvUtLK/6xg3LIsm6Pp4D7ARhc5T6h9LRjxxjmNAGMWk7zAN1n7hUmR4qGNMTA+5lT Xq27d5Bu317GHq6G0enTswQg02sGTT7zvVCjOI0e35UjEo4Qpky7d49jLWiYIh1kwN0kNKkhZsZn KFp9+rRDaFmPHt1aaFj/998iQ7uuFCU7W5dnATC4u60Mol079KGp4/4VnK+w+WXzIQAxHG/AHAhm RDA/AigjjRo8mfp1H0YHt58VXOq+LTyu7kOpa7chdJPB813Bn+kkFKlW7qM/6jWnCmUr08SRs2hw n9F85ruEznL9UMQa2GsU1WLQHTV4Cl05pdgYD+s/nkXQNahc6YrUsU132rxyv+BCJQC7fTkKDMgF tvO22rb13Fb7lt1N6qMj2apJPg85FHA/AKtABE9V8O2sBV+Y/eA+TIBwRqt6xcJ3fEZ+cKUAUyTc g6KUoQwAlcXSNPovvsdh7oQWM/Ko2syq0w043IC4GXXBtSXqAFeN+yc5aTlyZ4HTVeU8C4ChRIVz Xmgdn+MzX5zvwrQItsECJPk7uOSr7ChDdaIBILzI57vw5AXARB0A6iuc59KFl/QxW256wWLkQ1wf gBz5oAUNMfNl/o96VYBHu/evvKMV7HkL9sbCaQcrbqmOO8D5AuClHbC71zQrMWrt8wqFARhAzmLs WTt8J9tV1rrHKfPxjK35e7blC9rdkyPbdxcFPAeA9QC1T4iJBw9uytzuSk7r6MOHbUymffTo0WqN +0jVl7K2PO4x0AKAI0ckGtbcAKbIoz/HBcgfFlz2u3fbOTDFDla+akJPnqw1ALKrgNNV9XgWAOu5 SnifKsnKUl3/7kNTxs6jWtUbCC9V40fMpOpVaguwBiBfYVAFCKM8bHTFPc53hgH1Xeac9JrPgA/D kxU750BemDOpricBsj27DBTa1dmz5BKAD+cfeX8oIDxq+StbucfsSE8TeQZsXN0CApv1WL36ZdEg 2tW4OjQtbwuArcWttZeDVf0Vm+ubpQhBEoDdBXCe3q7nAvAxFhkPFy4qP37cxU4xstLOnWOYnOeo ZMk8Bg9V4FrBnYJzBVcLcFU5YOZcvzE3y1rONLI13wcHjTwAXJXT3ssi773Us2cDVt6Kyf6hB7F9 8CUqV64AjRjRUgPargJPV9TjuQAMkTB8O6dMkZrPdg9Rp7Y9KSfb+75gV7YDeo2k9OxiEgpa0FbG OS5ExdCUnjN1mTjPbcL2vbPYlOhNspR0Pe+PdIg5WbiqbNm4PXVp35vF1ecECCMBcOdMWUrJOW9Z tjcG6MLpxrJ5GwV37C5xs7l2JQBbBGBzYl9tRB9rIKc+Cwzn6Wy0H3PLur0A7umQIPsXnBTwXAA+ Te3aIUZxVQGEmTOnFKD79OluAcrLl/eja9eWU7VqRal06Xy0ceNwNitaT1261BE+oqvXK03TBzWh V6yQ87bfn/Th2wnq2/cPql+/DI0f346BFqC9n7nerbR+/TBW9kkuTJuI/qMJE9ozCBfUALUrgNNV dXguAIOThS0uzIDwuc8/Q4RHqtLs1xngC23mf6evEApSHf7qRlDOgg1w5V+rU+aMWdkcrDxFjRqN nkeIRBNZI3rGoq1UqkQ5NiWqJzxn1axWX4iXVV/Q547cogTxE1Lndr3YC9ZTysbuKwHM4KYlAAfn KmJ3W+Y4VHtj46IRc4CtjT1riwPWK0NZKqsHU3tC4gXUovaPq2tPebuJKDP6EAU8E4AVTrZKlZ/Y dhfi49PsBSs9pWKTovz5s7BJS0ShgFW2bH4aMKCx4FxhSnTw4GThaANAnTpHGqqXLTV9CxWKVjPo zt8whE2QEtPMmV1F+WPHpnG9OCsGR3ya8uTJYADgywzIQ4XXLeWZJ7if9Fxf0FqgO89erCaPnkup OMrReXbA0b3TAMGVjh4yVYAsfDfDocZPhYsTvSOqU72h4ISrVapFf7fuRvP5DDcdc7SUIDH15o1T /zFzBTddrXItqlThf0IZC8AODvjsoVuC88V9uKAEGGdnO+Te/wwWQRgkAHvkImUNILUcrSXAssUx OwrAWm7bHm7YGlGlmNkjXzkP75QnA3DFij+yIwzl/BZRkubP78FntVuFmRC4VYAkbHSxMc6YMYXg gnOI0IN7qQz7gZ7T4XcidjW5tGFZGjzlb2FONHp0G8EJK4EXVP/OZ0Rdiu3vNQHAuXKlF/VIALY/ 3KEaOAFhBuF5qh2b/4ArfXUPIugR7H4yF40ZOpUSJ0pCE9lnM/w/D2cxdGl2FdmMwxiOH7eA0kSL QRQ7HjVjAB49dTn9kDMvVeXYwAjEsHDmanHGCzH2/xiUYW4EkB8/fKbQcgYXjbNmc2EQ3QnIUgRt XAQtKDfZFRtX5YCtxJ41hLZTlaQCxrO1VtYygJrG93XmDFiLAoHVtvZwRJHdc4gCngnA4PhOU+vW ValNm/8JAM6YMbkIloCwgXDagehInTrVZneRuUT8YIiWL136V4QXRKSkouwXenKHmkTsaGMFmyHt PT2PsmRJxdGUmohYwu/fQ6HroDA56tixluCKC3LkpHv3Ngrf06VKIYShXivbVWLkwNTjuSJocKY4 p02dMo04n100ey316NRfKFvNn7GSwbK/0IqGghbE0l1YdAy74UFsWjSdz4VXcpCFXixu5igKNJUj K61l06RVHDUJJkXwbDWXARka0KcZ3GH2VI+55xpV67CpUQ+RD+fBm9lsSY0v7E7Q1bYtAVizJJmL UeuwFrTF2LP4TfvHpTUbz9ZiWWscrLmYtdp11pwdsCXbXwnADiGUj2f2XAA+TqtWDaScOdOxNvQ+ FhnPEGe8ULg6eXIGPXu2nm1599KCBT2FX+ivX3cLremjR6cJG9/T7Nnq/v6JROwF69FwKFRdYG9X c2ncuLbCHhhlwd1+/bqTOd4h4t7q1YPZFnibAHSIthUTpMCAZVCU9VwABujATAi+mls37cAONp4K X9Cw/wVHjM9QloKIGMpXaoAEfBbay6ztfJtBm1lbuslnxUe5LnDVAGmYIMG+GOe/SIpJErSj7wuv V726DBJa1sjrKcCr9kMCsMsWUQleLiOlrMgjKFCjRkUGoe2Cy1S0hD0lQZv5kABCuIwkumwARHaw wZrQCjgizyVDwmdwrNCMxhg4+hHHCsZiTgzkSjQkaEIjv5oHdSEvvl80tHGEueQ/BRfteTRRxjVw 8B/UvFEnusv+jwFEnpTA7cJMCFGO8BniYLV/Jp8ZKNXv6v+z7Mby5pApYs6ucUzfswzgKAvgRtKO E2XUBCAHKMPOWIC7h9EEZlQHt52nShWrOPyb57dXXv4UkAAs3wbfokDx4j/SokVd2YPUEOYEB3pQ GsCKVoPZO9YIQ58GONS3dRuH0c6Z7KaSF/NTf/+P1mwaY2f5AbR9+3DasgX0cKzN4KDfJh5HlaoF 6Mf8pWjS6Hk0YsAkj0rD+0/kkINTaPTgqXy+O9Ghvg0aNZf283nvZ56z8Z0H09Ah0+0qr7Q5VSRH 2wwO+oEWvbsMpR8LF3F48ZAAbEIyCcAOv0GygEdTYPbs2dS5c2eOe/uPR6Zu3bpxv5Ac61/n7t1p WIsWAoCX/PYbderZw+46lDYday+48nfv3o06duhIHTp0IE/upzP06NSjBx3IkoXeRo9OPXkOunrw PDg6PvzGpk9HjGnHLgnAjtFL5pYUkBTwFArcuq2IoDfBx7O8vIICv/xCVMRxTtErxuZEJyUAO0E0 WURSQFLAAyhwgJ1tAIC344xbXh5Pge/fiZIkIfrzT4/vanB1UAJwcFFatiMpICngWgpsMChhHYHD DXl5PAUePVI2TKNHe3xXg6uDEoCDi9KyHUkBSQHXUmAae7vCgn6HnRHLy/MpsJdNwzBfOziOs7wE BXwWgE1sf8uaBkmwNPemDjEs5TIEbBiGsGcWLmErbM1Ol/uDPhmTI/F8De3bWRZjGgqHQPoLfTQ7 Bn396Ke5/tmbT/7SJAWCiAIdOxLFiEHsdSOIGpDVupQCEyYQsetQ9obi0mq9uTIfBGAFGPQh/Q4M s+EvGeEMWw6noZzgxt3ypWhKN29pCTQV/8+WnwdC09oQctEEUM3d03beAtBaBGaz/rDNUcPMOMTG wxb9vPnnIvvuURQoXZoodWqP6pLsjBUK1KhB7Myb2DBdkslAAZ8DYACL+Xi61uccHrRQTv1vC4CH DmttloNUyi8RIL3IrGTMeQC2ODYAn8bdpmnftf6o1Sfm7mmf2cORW/KbbU9Z+fsLiRT49OkTffr8 mb1UfROJQxYFjgwbNxIb8zpVB9p/9+4dPXr8iF68eOFUHSGl0IcPHxgzlTn7jnlz9tq6lTjMlbOl RTm8Q5ivRw8fKu+Ql18+BsDOgpsmapHghJew12dLl9qGNQCy1g9n+2irTsucZwDgZsC2vEmxt38B 8wk3oNZE817+Y5Hdd54CU6ZMoRp16tIfLVtSs7/aULtOnakjbHF79abuffpQn4EDadBwlkCNGEkj x46lsRMn0YTJU2jazJk0a+5cTvNozrx/6d/5C2jRkiW0bMUKWrltO63euYvWszLWps2b2d3kZtq2 g11P8v8lvNDP5jKTpk6lYSNGCJvTFq1aUa06dahchfL0409FKEvWrBQvQXzKmi0bu6lc5fzgfLTk pUuXqFHjxlT3z8bUpHVrav13e/q7Sxfqwva83Xr3pp79+tGAIUNoyPARNHzUKBrNIubxkybT5GnT aebsOWLeMAfz/v2XFixaREs2bqIVrLG+avUaWrtuPW3gDRTmbMu2bbRl+w5atXYt/btwIU2fOYvG jB9Pffr3p7Z/d6BGrDVdpWo1Kl6yJOXOm4dSpkol5q0lv0uPHj/2aur7FgALcawWiLQ+lK1wZiag qw0haG5u/YFHDzj+322Bpf4M2A6xbYCxaftmAzRNOGR7xmdP/wKeATsjefDqX4/svF0U+MoixxIl SojoNn6hQ1PocOEpauzYFCZ8BAoXKRJFiBxZpIhRolCkqFE5RaPIHGc2SrRoFDV6DIrC57xR8J/v RRbPkCcqhYsYkfw4rqyo15DSZ8tOOQoWopQZM1HCZMkpRpy4FJHzhg4bjvOEMsmrLVec+ycvUwrM Z+AMHSasQjOmc2SehwhRolKYCBEovJgzzJ06ZzwnmB/MGzvaEHMm5g33eM54DjBvEblcmHCYC/85 Q568RX+mdNlzUNLUaShOgkRcNiaFxfzymbE2r/ZzaH6XNkIK4sWXbwGwOL80B2bWAUovdrYuhrYU VMHSff3bYS+H6Ug5ayJl1OMMh2/rrTYdh9h8WJUc2KpPPvdVCgCAf69egxfS0AzAYQSYxo4Xn2LG jSsWaSzqUWPGYjCOzAsu5wkFUOX/mkXa0udQHIzBZFEOH5HCRotNEXkBDxOJF3AAL+rDQh4KGwD+ b0ihwqA/SvliJTiGrbxMKLB61SqKFTuOoE+4iJEoJm9mYsWLR9F58xQhMgMq0xiga6SxmDPLgGmc J9Acc4FkmOOw0WJS+OixKTwDtR9HS8J7orwLmDP/ecOciXnj+5j7dU4eQXjKVPsYACscb0BOzFGO FBygfTGDVa7XlBu21Z4z56SWxsavktUzYOVVc/SM2/z5tXWu2z4tck959WU/gosCAOA/GjbihZO5 KV5Uk6VMST8WL0658uen9FmzUJqMGSln/nwUn500YDEPCxANG0FwSqE53q+a1MXX+J85oDDhAbDK Qp6taEKq2CQ//VonO0WIGp0iRWdQZ646TISIgusOHca/Pu1CjrKVqlTmI+lAnkkHF0GDqZ1NzF0m TpRY0BZSidwFClCBIj9R1h9+oJTp0lG23LnF/IVnLjh0uAgUllMYpnOYcNbmLBSFCRtWzCnqjZss MhWtnpHqtv2RUmdJQOEjxaKIDOphWTICCUmYsDxvhndAO/8oGzN2LHH04M2XjwEwkAZiaL3pjRVA NAteCtiZNd8JoCWsimK1oBoUAGxhbFZNnjSvplHL2xb428uhSyUsb/7hB2ffoSzTvk0bRQzMCyoA EeJFiDEhgsYCHpY5LCTxjAE4HC++YZkT0oOwuhiH4UU5XAQ8D0thGNjzl01BharloE7929FHDk1Y vGomCh2exdRcN+oMA3AIoyzmWMjVegDe+Nzwjz843OGX4CSLx7e1Z9duSssiYYAdxM5hmY7hWUqB BGkF5k6dszDYNIXD3IXn/+HEvGg3T+rnsHw/HNcViiUSiVPFoTJ/ZKMCFQrSf/cO08LNPSlKHH4X IkXlxKJqrlMB4LAUKqz/nKngnZI14Hfs3OnxdLTWQd8DYDFa+88nLWkWW1Yoskf5yBYA689YLYG9 makzbDD8bYjtOD9WeGCxqbCtJBWQdmgr4GbE/BiVeMz29smrfzuy83ZSAJzlQFbYCccLOAA4NDhS BlgkwZ1qPitgicUcCzkSuCoGWTMLOkBYcFEszu42oRHlK/UTDVtamjoM7EKTV/Wi1OkyClEm2gMA h9VwU0YABnfHIP1Ptx5Cw1Ze/hQ4cfw45cqZ0wDA/vNkdt4EAIMLZgmGmDPzIIw5UwG0dvNyVKP1 /6hOhwI0bF5TGjC9DzXrWEccP4ThzVhoQ50qx6wFdMx7/gKF6NBh7/aC5qMALH9GkgKSAp5Dge80 nb1WhedFVZwRQhRtPOOz89zQxnlwkfKpqFDltJSpQC768fdMVLhcem4rgl3nyDFixqTJU6fQh/cf PIdkHtCTa//9Rz+zcpSihGVuzuw477Uyb8lSx6VSdVNR5sKZKXfpXFSiXjpKkSq57TkzHDlUqVqV zp1H7GjvvSQAe+/cyZ5LCngNBbZv3cYKPawcxaLF6KxwFS9BQkqUJCklTZ6CUqVJS+kzZaLMWbNR 1hw5KCefMebNl58K/ViEihYrTiXZ4UaZ8uWpbIUKSipfgb9XoNLlylOJUqWp8E8/UeZsOejHCpmo RNWc1LZnbWrVpi01YzOVOg0aUJXq1ana779TyTJl6Ie8eSk9nzknS5Gc4sWPT9FYAzd1mjQcL3mD sAuWlz8FXr96RTV/r8mSg7CsjR6dYrPSXMLEiSlxsmSUnE2B0qbPQJmyZKUsrHmePWcu+iFPXsrP Gug//lSUirHJUOly5fznjOcNc4ZUskxZ+pmf58ydl3IVykJFfstAtVsWp3adW1DL1m2pUZMmVL1W LarGjjt+rVxZzC/aSJU2DbefiOJwPyLx8UW79u3p5s2bXj1lEoC9evpk5yUFPJ8COFu9xQvlAY5e dOTIYTp48CAd4nRg/37ay/6Bd/I53iYOKbiO7UCXLl1GC9gWdA7bkM5ge9ApzDmPmziRhrID/15s F9q1Zy9q27EzNW3Ziur/8SdV5UUawJr9h9zslTI+pUmTkar/rxa155i6f3fqRJ3+6SpsjJeyRu/S NWxnunQpzVywkCZMn0F9Bw+lFryI/92lMx07dozevn3r+cQMxh6+fPmSTpw4yfN1gA4dOiTmDWkf z9mePXtoKzvW2LBhPa1cuZIWLVos7H1ncfzp6TNm0MTJk2nkuPHUf+hQYTPcqVt3atGmHf3RtBnV rFuPKlSqRIUYWJOlTEMxY8RjTrskNWnSnLp0+4fa87x17dmTJs+YTitYy3kh23zP4fqnsU3xiHET 6G+2H2/QtAnN/Xce3b9/Pxgp4vqmJAC7nqayRkkBSQENBb58+UyTJk2isr/+Rj+XKEkFWZM2N3O4 2XPlpkxs+5kucxbWqk1PyVmzNmma1JSEuatEKVNQwuTJ2ZY3GcVLmoTiMucVl7WkkeLzd2hMx+d7 CfkzOLKkrFmdPCWLM7m+DOxgI2WadJSYyyNf3AQJKFacOKw1G0eY0cSJn4BTQooWKzZFZ9eI4Mwn TpxAX79IF4naFxdnwH+wEw7MWRGWRORl7hZca5YcOSkjSytSZ8hIKXjOkrEEIWnqVKxUlZISsmQh YfJklCBpUv854zmKJ+YtqZiPBJwSJUtKSXh+oBGfluvJyhx0auaok/IcJkyajOInSsSmavHEnMFc LQ5LK+Ky1CRm3HjCZC0am6+VKl1KcsBypZEUkBSQFLBFAdiU/tmsObVkjhPcELwo9R/MXpRGjqRh Y8bQaPZ8NIG9ZU1h7mnG3Dk0Z/58+pe9Jy1evoyWr15NS5nLWstmMdt27aQ9+/bRAebIjhw9SsdP nKDTZ87Q2bNnxXngiZPMsfGzvZwHHpZWouyyZTR7zhway20MYW9bAwcPpt79+nM/ulFL1s6uUq0a oX/yMqXA3bt3qStzm41btKT2nTsLTrbPAIPHMvZ8NWLsOPZYNpEmsZRi2qxZNIs50rkLFtACeCrj +VrGNF3B9N+8fRvtYo55H0tADnHoyKPHjtPJU6foDObs3Dn+f4YlI0foAHPXO3ftonV8HLCcuV5I QiazJzN42Ro0ZCj1Y0kGPKe1Yw65Tv361IbnDly6N1+SA/bm2ZN9lxSQFJAUkBTwWgpIAPbaqZMd lxSQFJAUkBTwZgpIAPbm2ZN9lxSQFJAUkBTwWgpIAPbaqZMdlxSQFJAUkBTwZgpIAPbm2ZN9lxTw MAo8ePCAxo0bR+vWrRM9g9nKaDYhev78ufgOv9Dr2bRkPCtE4d7r169pJCtiwURJvS5evEjDhg0T pi+41qxZw1rKE8VnhMgbweEFVftPeNnasmWLaANto/4JHBYPZk248B8a2Fob3wsXLtBaNnnC9ZDj yqJ9KHGhP6gH/UM9yzmk4ShWAEJ/HLmuXLlCS1gRyZ2etUCLBawQ9eTJE5tdx1hBJ8wb8qPf+LyN ldjU69atW4I26j3QCHT++PGjyIL/c1jRbRorZMH16KNHj8QcnmJlK1wzWLkO9FQv9G8MK9+p78l+ NklD/e/fvxfzgDk5ykp26nWGFe2GswIdlLVwwfRpNps8vWJb5blssob3A33Chbx4Z7zhkgDsDbMk +ygp4CUUwKKJhTF79uwC5GrWrEmtOZbsH+xrGRcAdxlrJddiRwvt2rWjTqzR2qFDByrDtrzQusWF hRT3snGc3kWsCY06/uSYsP3ZDrhhw4bUmTVyq1SpIkASYDGVNWUrs8OGunXrikUccWJ//fVXAZ71 WVu2UaNG1IdjDv/Hnp1gN9qiRQvKwQ4/ABSNOd5tF45xi/yITTuYNaRTsmkMAKkABx8AoKj9sjYF b968EeOqxhrVkdlJRCo2pXLnBcCEB6tEbM7ThB1bbOc4vJZ8Xat9r8OxkjEnAM6//vqLihUrZgRQ ACTonCdPHprJMZoxf5jTQYMGiWFiIwOAxJyhPOYc81S7dm1BU9D5t99+MwIj6kNZ0Hop22ajPpSB ZnN71pTHnJQqVYqwWcKmC/0fyFrQP//8s6gD9WK+BwwYIMAY9SM/NmS//PKL6Ls3XBKAvWGWZB8l BbyEAgBEAGV59lw1hc2KAJzgaEqzNyv12rFjBxUuXFhwWQAscD0AVjjlUK/du3dTDXaygUUX3PL5 8+cFqCMfrkrsyOHDB3/XkQDyHhwoHvUBaAECmTNnpsnsEOLq1avUrFkz0R9wRwBhgMGzZ8+M/QL4 AGjRF/QNHHHFihWpadOmdPjwYYvUB3eMMcZgu1STGLcchQkgUJyjPrkjYfOAgAfaPiVlO1wA2717 9wKMB441fvzxRyEtAG3v3LkjgHAhmwLhAkiDxr+zRzHMLzY3p0+fFiCovbCRAVBjgwQwBG0Aypg/ 3McGSb0A2iXZIxaAG/MDkyL0QX1XsFFCGSTMFQAfm6t+bMKGTQAkJABtXPiPDdC/7AykJzvxaNu2 rVf8YiQAe8U0yU5KCngHBSAShG1n0aJFBacJ7hMABsCDePPp06dicQewguvFfYgpsWADdJHnODuA AKcFzgcA2rVrV8HlgMMBUOJ+OXZziHoA7siDZ1jAUQ88NHXs2FHUD1AGx4QFHiCCDQK4qiJFioiy AAD0F8ANcTnqxUIO7hh9BWBhM2HpAphNnz5dAFNydiyhAh4AGZzfUPYE5Y70999/m4BvRna/CS4R EgW97Sw4Y9ASm5YK7DISNMRmCNID0AJjfPHihZgn0A0Sid5sEwyRMrhriJtRJ2iMdiGOxuYDoIu8 mAfMAeZi7Nix9PjxY3GEALCFCBqe0Kqzu1C8J2XLlhUJGyBINdAm2sZcIV/BggUFEIO2ED0DbMHt Y8OBYwbUg41TihQpRB2efkkA9vQZkv2TFPAiCkCMi4UeIkUAG7goLKg4O8SZ4Qp2sABxMAAPZ4az 2IEDngOQscDi7G/IkCH0E7spBBcDUMaiCq4MCyrElsgPTgdgAvD93//+J56Do8Z5MBZ8iDLB+YKL BkcFUAfA7GMHHf+wc4m87BMaAAKuGCJLtAtuLzfHuG3VqhVtZKcf3dhRB0BglZ1OOrD5QDkAUVUO FODOC6AIsMLmBeJea+fROBZAPtAR8wEagsbgeE+woxPMDQAUYAvwA+epAh2OHMAR49gA7TVg39s4 /8b5LurAf9SBz3gGrrlv377iXcAmC5s0uAFV3xPMN44wMCeYa8wbxMyYa2zmkA/vAeYbm4UbN26I YwJw5LgA7tg8NG/eXGy4PP2SAOzpMyT7JyngRRSA2BEiXjW4Pc5pIT7EpZ5BglsCd6leWkUh5EEZ cFEANFwQC6uf8V3Nj3xqfnA/qi9n1A0OFhfqUTm+z58/i7qRF4CkghIWbfXCPbSF8rjvrKcllFf7 4I7pczS2McapnQft/IBmGItWdK2dE9AVz/EfYK4eDWjpivpVeqvzgO8qfVFefU+0c6y+NxiP1u8z 5loFWHcquwV2biUAB5aCsrykgKSApICkgKSAExSQAOwE0WQRSQFJAUkBSQFJgcBSQAJwYCkoy0sK SApYpADO/3B+h+v69evUq1cvcSYJjWOcseKZKq6GmBGmSzgLxoXzPZwXqvlxhruanfurol2IinH+ uHjxYmP7ULDCeSAUoyA6xQXRJc4xoTmLC2ecOIeGyBNn0jj/xXk0rtu3b4uy3izWDOzrCPEuzsNx ho4LdIPSE8TLuI851IqjMU84t1WPAKAcBVttzA9MjDBv0HhWL5z5QrlLnXfcx2e0Aw129cK5M+YJ 740619AlgNIV6oRCF7Tacc3n4B1417ztkgDsbTMm+ysp4CUUAKDCnjdTpkziLBaKO1g0oWULpR0o TcXjkHPqIgpNXJjsQFkH54RQoIISDxZcKEZBUQh2oKoTDmg6o35oQKuOPKCdC01m2PHirBeazXCM ASCAghVMWmBDChtVmMjAvhSLPEyWcMHsKDGHOdSeX3oJuV3WTShZwY4Zm6MNHJkI2tBQiMNmCMAJ eoOG6gXFLdAMzjWwGcK8gf5QeIOyFJTSunfvLrLjncBc5sqVy6S/qDdChAiifmi5A/xhrgazIyh+ oTy0qKHMhU0YlPBglgbghbY1bK9Vm2SXESIYKpIAHAxElk1ICoRUCkCxB4AIbrRevXpiEYedLRRo wNmo5kAqfQDMWOzBIWfIkEE4hMBii5SG485iMVY5J5gwAZyxOIPrwgUNXGhYA1QB6LAxBceM/1i8 0T7qVPuFMngGUyGYLwGYYeqkgnxInTdoQAPcoFEMjW5sTLABwgXwVT2TqfQBzTFnmB+ALuYQ2srQ SM+SJYsAY/UCbWEqpF4oB611aERjowSpBDZOkGbATAzSC5iCQTEMeSDBwAXtdkgsMGfQjkY+b7sk AHvbjMn+Sgp4EQXAncDkB3acMI0BtwQbUXBZ+fPnF96nwB2D6wFQwmUhgBrgjHwARQA2zJrgWhEg isUcwItFH4ANDguiUYgvoYEL7hVcNxZqiD6RYBIF7hrgAHMacGjgyKGFmy9fPtE/gDaAIWHChIIT C6kXNkuQQkDsjM0OwBCbHYAuNjAAYIjoMQeYU0grIJlQnZJAhA/AhlMOADmAEZsezCnE2BAVw8wM mtSYM4Au5hUOO9Cu+q5AtA1zJZg3YRMHEyVITyAxwdEDOGKIwmGyhDyYX/XYwVvmTgKwt8yU7Kek gJdRAIshFmAAKM4IYU+LBRYiRAAxnHVgYQbIgouFqBigiAUV9qXwmgTuC/a6sPUEcMIxBmxtcQaI s2Es8nDGACcOsBcF6EJkCm4NAIHFX7VNhtcmcGXgllAONqYQc4KDwgUgAXiDGwNnFVKvXbt2Cc4T QAvwxVk9XFQCYDE3kBBgPlWf35A+QJIBUMT5LuYQRwOoB+JmiPrhcAMerE6ePCnOkJEfmybcw9wB jCGFwMZo3rx5xrNjiLPxHe8IQBpzjY0a6sSmDReOGrBxA1h72yUB2NtmTPZXUsCLKABQAxcFMMZn rftI3Md3VakK/3FGiP+qmFl19o8hq0o+2uGjTu2FcloHDGo9+rJqOUftZb2I9E53VZ0D1ZZZTztw v1q64zvobI6mqEM7h+pGB/lt0R7PtWV9UTFOArDTr6ksKCkgKSApICkgKeA8BSQAO087WVJSQFJA UkBSQFLAaQpIAHaadLKgpICkgKSApICkgPMUkADsPO1kSUkBSQFJAUkBSQGnKSAB2GnSyYKSApIC kgKSApICzlNAArDztJMlJQUkBSQFJAUkBZymgARgp0knC0oKSApICkgKSAo4TwEJwM7TTpaUFJAU kBSQFJAUcJoCEoCdJp0sKCkgKSApICkgKWBKgaf7Z9KAQWsIfrq0n83RSQKwfHskBSQFJAUkBSQF XEiBp/sPCgDGpf2sb0ICsAuJLquSFJAUkBSQFJAUkAAs3wFJAUkBSQFJAUmB4KbA5TUsgh5KA1Zf IdJ+NtMPyQEH9+TI9iQFJAUkBSQFJAWYAhKA5WsgKSApICkgKSAp4AYKSAB2A9Flk5ICkgKSApIC kgISgOU7ICkgKSApICkgKeAGCvwfWlCsI5vKuSIAAAAASUVORK5CYII= --_004_4D992130DD0EFA478BB1173F595F22DB01034413SJMB02corpa10ne_-- From warren@kumari.net Tue Oct 2 13:28:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFEC21F8460 for ; Tue, 2 Oct 2012 13:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRv0dbJd0rvD for ; Tue, 2 Oct 2012 13:28:47 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFC621F8452 for ; Tue, 2 Oct 2012 13:28:46 -0700 (PDT) Received: from [192.168.194.120] (216-239-44-65.google.com [216.239.44.65]) by vimes.kumari.net (Postfix) with ESMTPSA id 344541B401FA; Tue, 2 Oct 2012 16:28:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: Date: Tue, 2 Oct 2012 16:28:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121002115421.GY13776@Space.Net> To: Randy Bush X-Mailer: Apple Mail (2.1498) Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 20:28:47 -0000 On Oct 2, 2012, at 8:54 AM, Randy Bush wrote: >>> so, is double nat really worse than single nat? is it formally >>> different? except in the case of overlapping spaces, of course. >> One of the problems with "someone else controls your NAT" is that >> you can't add port mappings. This seems to be an inevitable side >> effect of NAT444 (but can happen with single NAT44 as well, of >> course, depending on where it's placed). >=20 > i asked *formally*. i am not concerned with all the ops, social, > stuff. and not about issues not directly connected to the nat. > what does double translation do that single does not? I don't think anything=85 W >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From joelja@bogus.com Tue Oct 2 13:35:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A3821F85A4 for ; Tue, 2 Oct 2012 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ISJGveYXf9u for ; Tue, 2 Oct 2012 13:35:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 59EFE21F85A1 for ; Tue, 2 Oct 2012 13:35:42 -0700 (PDT) Received: from unknown-70-56-81-c1-ee-37.lan (ip56572456.direct-adsl.nl [86.87.36.86]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q92KZZ1V041246 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 2 Oct 2012 20:35:39 GMT (envelope-from joelja@bogus.com) Message-ID: <506B5018.70207@bogus.com> Date: Tue, 02 Oct 2012 13:35:36 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: Warren Kumari References: <20121002115421.GY13776@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 02 Oct 2012 20:35:41 +0000 (UTC) Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 20:35:43 -0000 On 10/2/12 1:28 PM, Warren Kumari wrote: > On Oct 2, 2012, at 8:54 AM, Randy Bush wrote: > >>>> so, is double nat really worse than single nat? is it formally >>>> different? except in the case of overlapping spaces, of course. >>> One of the problems with "someone else controls your NAT" is that >>> you can't add port mappings. This seems to be an inevitable side >>> effect of NAT444 (but can happen with single NAT44 as well, of >>> course, depending on where it's placed). >> i asked *formally*. i am not concerned with all the ops, social, >> stuff. and not about issues not directly connected to the nat. >> what does double translation do that single does not? It Instantiates state in two locations. That's inherently more fragile than doing it in one. >> I don't think anything… >> >> W >> >> >> randy >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From john.mann@monash.edu Tue Oct 2 14:42:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5925521F85F7 for ; Tue, 2 Oct 2012 14:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYJnUNI8pfPo for ; Tue, 2 Oct 2012 14:42:52 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 832D521F85EF for ; Tue, 2 Oct 2012 14:42:52 -0700 (PDT) Received: from mail-ee0-f44.google.com ([74.125.83.44]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKUGtf21CvzIFenq2nN33WccWzrHE9zcVI@postini.com; Tue, 02 Oct 2012 14:42:52 PDT Received: by eekd4 with SMTP id d4so3739375eek.31 for ; Tue, 02 Oct 2012 14:42:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=HiwnA2O/REUTyN3XC8+iEfKZE2rmSt9J5KCIPorTREc=; b=ifjwiOLvKHj/v5CaN0H9AnIlPmV05XGnA+cyiiTFUwYIbZvOOTeehIejOHgJW3rs++ GrfKWhMGykY6LKPheCsMP0l1n2P8EB7rCq68cnYRDbx873sHC+DGjWEjLiBuV06QeDs4 1zpVopV9TfTtZv7qMcrXQEk0iLabMBOSmYlUdJSiikPC9wqZGEQN2wLCKt9UcUZUpayU ZOLkfqaaYJaVOKZBbvBG8/XzGg6qB5yuVdZGwRSiP6xINRapW7lc56nhmbrqyhug07eh Lh1EBN3FqMh5J5UD2F/t4v59p0jwXSPmNItOTkDanPdxlZHJh4PwvdZSXrk0WJ9I84Kd C3oA== Received: by 10.14.215.69 with SMTP id d45mr129700eep.16.1349214170291; Tue, 02 Oct 2012 14:42:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.96.72 with HTTP; Tue, 2 Oct 2012 14:42:30 -0700 (PDT) In-Reply-To: References: <20121002115421.GY13776@Space.Net> From: John Mann Date: Wed, 3 Oct 2012 07:42:30 +1000 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=047d7b621f54589d9404cb1a675e X-Gm-Message-State: ALoCoQmKaFBkc+Cs5Cf1I7nkF8ZFavq6SuDtPeqNDvSpgVyz/nEYYcbC0Mp+lCh/rjJhn/QhMsJd Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:42:53 -0000 --047d7b621f54589d9404cb1a675e Content-Type: text/plain; charset=ISO-8859-1 Hi, On 2 October 2012 22:54, Randy Bush wrote: > >> so, is double nat really worse than single nat? is it formally > >> different? except in the case of overlapping spaces, of course. > > One of the problems with "someone else controls your NAT" is that > > you can't add port mappings. This seems to be an inevitable side > > effect of NAT444 (but can happen with single NAT44 as well, of > > course, depending on where it's placed). > > i asked *formally*. i am not concerned with all the ops, social, > stuff. and not about issues not directly connected to the nat. > what does double translation do that single does not? > Thinking in terms of full cone / port-restricted / address-restricted / symmetric NAT, does two layers of NAT using different NAT types restrict the overall NAT class? If the outer NAT is symmetric, I think that nullifies the full-cone or "DMZ" settings of an inside NAT. Does port-restricted inner NAT plus address-restricted outer NAT act like a single symmetric NAT? Thanks, John --047d7b621f54589d9404cb1a675e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 2 October 2012 22:54, Randy Bush <= span dir=3D"ltr"><ran= dy@psg.com> wrote:
>> so, is double nat really worse than single nat? = =A0is it formally
>> different? =A0except in the case of overlapping spaces, of course.=
> One of the problems with "someone else co= ntrols your NAT" is that
> you can't add port mappings. =A0This seems to be an inevitable sid= e
> effect of NAT444 (but can happen with single NAT44 as well, of
> course, depending on where it's placed).

i asked *formally*. =A0i am not concerned with all the ops, social, stuff. =A0and not about issues not directly connected to the nat.
what does double translation do that single does not?
=
Thinking in terms of full cone / port-restricted / address-r= estricted / symmetric NAT,
does two layers of NAT using different= NAT types restrict the overall NAT class?

If the outer NAT is symmetric, I think that nullifies t= he full-cone or "DMZ" settings of an inside NAT.

Does port-restricted inner NAT plus address-restricted outer NAT a= ct like a single symmetric NAT?

Thanks,
=A0 =A0 John
--047d7b621f54589d9404cb1a675e-- From jhw@apple.com Tue Oct 2 15:39:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8A21F8528 for ; Tue, 2 Oct 2012 15:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlRh+Fc9y6aD for ; Tue, 2 Oct 2012 15:39:04 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6D821F84F9 for ; Tue, 2 Oct 2012 15:39:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MBA0087MEW0MLP3@mail-out.apple.com> for v6ops@ietf.org; Tue, 02 Oct 2012 15:39:03 -0700 (PDT) X-AuditID: 11807136-b7fec6d0000064a4-ed-506b6d07ad51 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B0.6F.25764.70D6B605; Tue, 02 Oct 2012 15:39:03 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MBA00JEDEX35A40@chive.apple.com> for v6ops@ietf.org; Tue, 02 Oct 2012 15:39:03 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 02 Oct 2012 15:39:03 -0700 Message-id: <8E12D76E-11E8-45F8-8B6F-15284B64A35B@apple.com> References: To: IETF v6ops list X-Mailer: Apple Mail (2.1608) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FDMr8uemx1gsGGyhcXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfnLH+aCb2wVv7fdY2pgPMjaxcjJISFgIvFt/z0oW0ziwr31 bF2MXBxCAhOYJObsecoM4Uxhkti9/SsbSBWzgJbE+p3HmUBsXgE9iaVbTrCD2MIC8hKXLvUx gthsAioS3y7fBavhBKo/um4xC4jNIqAq8fV3KyvEHG2JJ+8usELMsZGYda0JyOYAWqYpsfZY PkhYBGjMtC/PmEHCEgKyEpPfSU1g5J+F5IhZSI6YhWToAkbmVYyCRak5iZWGpnqJBQU5qXrJ +bmbGMEBVmi2g3HHX7lDjAIcjEo8vAf+ZAUIsSaWFVfmHmKU4GBWEuG1vg8U4k1JrKxKLcqP LyrNSS0+xCjNwaIkznshITtASCA9sSQ1OzW1ILUIJsvEwSnVwGjavYN3wr09ws8rXGU3nr1x SnDGvZSc1PR6Ww+GPSs+Keup78/7xvMpofhG/r4LHVd/8jucYP+pMtl7/52v/70mhboeNF10 +pf/32yhJ0+vxjVFTZwanSd0IWC5nYq4XubEGHYftrwFy6sP9p1cXcAaUH6z1KAxTzfj6c7P pi8dhfj+GN63FFJiKc5INNRiLipOBAC+lDlYLAIAAA== Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 22:39:04 -0000 On Oct 2, 2012, at 03:13 , Randy Bush wrote: > > so, is double nat really worse than single nat? is it formally different? Yes. > except in the case of overlapping spaces, of course. That's the obvious case where NAT444 causes formal problems. Another subtle formal problem arises with UNSAF systems attempting to fix the addresses of lower NAT gateways within the same upper NAT private realm. A yet more subtle problem is NAT behavior discovery in the presence of heterogenous strategies for mapping, filtering and garbage state collection. Finally, there is problem that I-D.ietf-pcp-base is intended to address. Implementing a forwarding proxy service for PCP entails mapping all flows between lower NAT gateways through state in the upper NAT gateway. -- james woodyatt core os networking From sander@steffann.nl Tue Oct 2 15:39:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CBB21F8616 for ; Tue, 2 Oct 2012 15:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K03Sap2JDSZT for ; Tue, 2 Oct 2012 15:39:23 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 483D821F8602 for ; Tue, 2 Oct 2012 15:39:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id DA7FF2079; Wed, 3 Oct 2012 00:39:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dreB4OevbVST; Wed, 3 Oct 2012 00:39:17 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 572BC2007; Wed, 3 Oct 2012 00:39:17 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Sander Steffann In-Reply-To: Date: Wed, 3 Oct 2012 00:39:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3667D727-57EF-417D-B06D-F418134EE201@steffann.nl> References: <20121002115421.GY13776@Space.Net> To: John Mann X-Mailer: Apple Mail (2.1498) Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 22:39:24 -0000 Hi, > Thinking in terms of full cone / port-restricted / address-restricted = / symmetric NAT, > does two layers of NAT using different NAT types restrict the overall = NAT class? >=20 > If the outer NAT is symmetric, I think that nullifies the full-cone or = "DMZ" settings of an inside NAT. >=20 > Does port-restricted inner NAT plus address-restricted outer NAT act = like a single symmetric NAT? Hmmm. Interesting questions. Sander From kawashimam@vx.jp.nec.com Wed Oct 3 00:37:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF121F85A0 for ; Wed, 3 Oct 2012 00:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy2C1hPTMZVf for ; Wed, 3 Oct 2012 00:37:47 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA3D21F8532 for ; Wed, 3 Oct 2012 00:37:47 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q937bie4010808; Wed, 3 Oct 2012 16:37:44 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q937bif00799; Wed, 3 Oct 2012 16:37:44 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id q937biZA003910; Wed, 3 Oct 2012 16:37:44 +0900 (JST) Received: from genzui.jp.nec.com ([10.26.220.13] [10.26.220.13]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-1790929; Wed, 3 Oct 2012 16:35:24 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-49243; Wed, 3 Oct 2012 16:35:24 +0900 To: "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" In-reply-to: <97EB7536A2B2C549846804BBF3FD47E111845262@xmb-aln-x02.cisco.com> Message-Id: <20121003163524kawashimam@mail.jp.nec.com> References: <97EB7536A2B2C549846804BBF3FD47E111845262@xmb-aln-x02.cisco.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.68 Step12] From: Masanobu Kawashima Date: Wed, 3 Oct 2012 16:35:23 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 07:37:48 -0000 Hi Authors, The -01 version looks good to me. :-) However, the addresses "2001:DB80:AC10:F002::" should be changed to "2001:db80:ac10:f002::". Regards, Masanobu (as a co-author of RFC5952) >Good and concise document indeed, there is a typo in the addresses 2001:db8:: becomes 2001:db80:: :-) > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Mikael Abrahamsson >> Sent: samedi 29 septembre 2012 19:36 >> To: Fred Baker (fred) >> Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share >> >> On Sat, 29 Sep 2012, fred@cisco.com wrote: >> >> > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne- >> v6ops-64share. Please take a look at it and comment. >> >> I have read it and support that it's a valuable topic to publicise an RFC on. >> >> The last paragraph of section 3 about MTU makes sense, but I would like to >> see a little bit more elaboration on why 1440 was chosen (rationale). I >> understand the rationale, but I am not sure all readers of the document do. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Marketing Promotion Department and Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From simon.perreault@viagenie.ca Wed Oct 3 06:10:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94B221F8680 for ; Wed, 3 Oct 2012 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ByGqNoxbRS for ; Wed, 3 Oct 2012 06:10:50 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACDD21F867F for ; Wed, 3 Oct 2012 06:10:50 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:9dcb:5c32:7b37:b414]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 50480414AE for ; Wed, 3 Oct 2012 09:10:49 -0400 (EDT) Message-ID: <506C3958.5000002@viagenie.ca> Date: Wed, 03 Oct 2012 09:10:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20121002115421.GY13776@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:10:51 -0000 Le 2012-10-02 17:42, John Mann a écrit : > Thinking in terms of full cone / port-restricted / address-restricted / > symmetric NAT, > does two layers of NAT using different NAT types restrict the overall > NAT class? > > If the outer NAT is symmetric, I think that nullifies the full-cone or > "DMZ" settings of an inside NAT. > > Does port-restricted inner NAT plus address-restricted outer NAT act > like a single symmetric NAT? Since RFC3489 we have learned that there are many more NAT characterization axes than just "full cone / port-restricted / address-restricted / symmetric". In fact, unless the two layers of NAT are exactly the same model, they're going to have different behaviour. This means that it will assuredly be harder for an application to do NAT traversal on two layers than on just one. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mark@townsley.net Wed Oct 3 09:07:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F221F847A for ; Wed, 3 Oct 2012 09:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8X+PYeewuLX for ; Wed, 3 Oct 2012 09:07:00 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E9B5721F846E for ; Wed, 3 Oct 2012 09:06:59 -0700 (PDT) Received: by eekd4 with SMTP id d4so4475677eek.31 for ; Wed, 03 Oct 2012 09:06:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ESZXfP7ygdcKoo8teYeZtzollpiqlWzSnwr5iv32K7o=; b=clTq0pTQYT1Phm5aWjfL30TpXft1FWGZv9EKu41eKG+Zya0DFY5lEuiVDybeh/0XJs WwoV6yQwm/4/cHpFuIc3HErzrMwR07A0qBfT4Wsj7RHyvDb6GLWjJsEmOMGvPwiQU5r4 819KwNM/3OBr4+fZLPf3GFn3JpObyXfnXZwRzJmeZVg2AJ7lPz0qVBw4m2FgAGxsIFtn i3Zo4mIz+M1gfqSVN/+lDFikNI4ScBOd/6dwoNFjatsaNTpTdrxPPzpnRdWxedYCAeFZ W/dslY7QDCYfeoFE3vJixR/4TF0zv5SCFXReU4VAiQ+UfvpX7FmukoGh+6labewxUmle pCIg== Received: by 10.14.213.197 with SMTP id a45mr3526229eep.3.1349280418859; Wed, 03 Oct 2012 09:06:58 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id m42sm10439204eep.16.2012.10.03.09.06.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2012 09:06:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 3 Oct 2012 18:06:30 +0200 Content-Transfer-Encoding: 7bit Message-Id: <35420A54-C576-44B3-ACB3-ADFECCF786BC@townsley.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl7Ku+6ZTim4MihwQMgfgTKid5lxLDTjuRoE6H2+fp/zHWxAXb44D1GoEgaZouI2Dn20zSI Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:07:00 -0000 30 levels of NAT for your viewing pleasure: http://www.youtube.com/watch?v=BrlwzZZp8tM - Mark On Oct 2, 2012, at 12:13 PM, Randy Bush wrote: > so, is double nat really worse than single nat? is it formally > different? except in the case of overlapping spaces, of course. > > draft-donley-nat444-impacts-04.txt seems to back off reports of > application issues. anyone care to swing the clue by four as to > where multiple layers of nat are formally worse than one layer? > > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Wed Oct 3 09:54:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4826121F84E4 for ; Wed, 3 Oct 2012 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URJPZ1JoByAW for ; Wed, 3 Oct 2012 09:54:09 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8387F21F85C0 for ; Wed, 3 Oct 2012 09:54:08 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q93GrhpF051341 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 17:53:44 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <506C6DAE.3030907@inex.ie> Date: Wed, 03 Oct 2012 17:54:06 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mark Townsley References: <35420A54-C576-44B3-ACB3-ADFECCF786BC@townsley.net> In-Reply-To: <35420A54-C576-44B3-ACB3-ADFECCF786BC@townsley.net> X-Enigmail-Version: 1.4.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:54:10 -0000 On 03/10/2012 17:06, Mark Townsley wrote: > 30 levels of NAT for your viewing pleasure: > > http://www.youtube.com/watch?v=BrlwzZZp8tM But strangely unsatisfying because it was the same config on the same boxes with the same software. 30 levels of nat, each on a different box - well that would be a whole new playing field. Nick From v6ops@globis.net Wed Oct 3 10:14:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E5821F8530 for ; Wed, 3 Oct 2012 10:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF1XUm+M1WgI for ; Wed, 3 Oct 2012 10:14:16 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C6BD321F8551 for ; Wed, 3 Oct 2012 10:14:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 69DC88700B6; Wed, 3 Oct 2012 19:13:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNwYetNK1TZ4; Wed, 3 Oct 2012 19:13:26 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0D44487005F; Wed, 3 Oct 2012 19:13:26 +0200 (CEST) Message-ID: <506C722F.4030100@globis.net> Date: Wed, 03 Oct 2012 19:13:19 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: Warren Kumari References: <20121002115421.GY13776@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF v6ops list Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:14:16 -0000 AFAIK NAT assumes a single default outbound route and a return route via a single NAT box, and therefore stacking NAT boxes imposes use of a particular network topology (inverted tree with a root at the "top" NAT closest to the Internet GUA core). I think that's quite a significant formal difference than a single layer of NAT at the customer premises edge of a fully meshed core. Try doing inter-continental or multi-provider stateful failover without losing sessions (which you could easily do with BGP). Also how are you going to support any protocols that require source routing/RSVP et al path information if the next hop or last hop is not a GUA? In the single NAT case, the outside NAT address was always formally assumed to be a GUA, whereas the inside interface might have been an RFC1918 range or a GUA. Again I think that's significant from an architecture point of view, as even if there was an RFC1918 address in the path, it was easily resolvable by the local router processing that portion of the path to be unique (and always routed via the "inside" interface). Now you could have 2 RFC1918 addresses adjacent to each other on the path, and not know whether they were "inside" or "outside." regards, RayH Warren Kumari wrote: > On Oct 2, 2012, at 8:54 AM, Randy Bush wrote: > >>>> so, is double nat really worse than single nat? is it formally >>>> different? except in the case of overlapping spaces, of course. >>> One of the problems with "someone else controls your NAT" is that >>> you can't add port mappings. This seems to be an inevitable side >>> effect of NAT444 (but can happen with single NAT44 as well, of >>> course, depending on where it's placed). >> i asked *formally*. i am not concerned with all the ops, social, >> stuff. and not about issues not directly connected to the nat. >> what does double translation do that single does not? > > I don't think anything… > > W > > >> randy >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From alh-ietf@tndh.net Wed Oct 3 12:52:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E0E21F8562 for ; Wed, 3 Oct 2012 12:52:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qis-oBMKIfp4 for ; Wed, 3 Oct 2012 12:52:31 -0700 (PDT) Received: from express.tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id 714BD21F8552 for ; Wed, 3 Oct 2012 12:52:31 -0700 (PDT) Received: from [172.20.144.31] (helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1TJUzP-0006lt-3t; Wed, 03 Oct 2012 12:52:20 -0700 From: "Tony Hain" To: "'Randy Bush'" , "'Gert Doering'" References: <20121002115421.GY13776@Space.Net> In-Reply-To: Date: Wed, 3 Oct 2012 12:52:15 -0700 Message-ID: <006c01cda1a0$9659f6d0$c30de470$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJy/YYJ47UjDhaVa+Vz5DmB82cpogEBpR7pAgsKZwaWRNlcUA== Content-Language: en-us X-SA-Exim-Connect-IP: 172.20.144.31 X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: 'IETF v6ops list' Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:52:32 -0000 > Randy Bush wrote: > >> so, is double nat really worse than single nat? is it formally > >> different? except in the case of overlapping spaces, of course. > > One of the problems with "someone else controls your NAT" is that you > > can't add port mappings. This seems to be an inevitable side effect > > of NAT444 (but can happen with single NAT44 as well, of course, > > depending on where it's placed). > > i asked *formally*. i am not concerned with all the ops, social, stuff. and not > about issues not directly connected to the nat. > what does double translation do that single does not? At the IP header manipulation layer, nothing. At the context layer, it increases the potential for address realm collision, and as others have noted the potential for differing nat models. You say you are not concerned about the ops stuff, but the biggest issue related to N-layers of nat is who operates each. As long as they are all operated by the same entity, it is an engineering problem to get all the apps to work. Once you get more than one entity operating the path, it becomes a contracting and legal problem to get the appropriate ports mapped. I lost count of the number of times people told me I didn't understand nat when I was editing RFC 2993, but that text was actually submitted through a double layer of nat because the carrier provided one had a limitation of 1 downstream mac. The reason the carrier device did nat was so they could use the public address to manage it and avoid having 2 addresses on the box. The reason it only allowed one downstream mac was that they did not believe networks in the home were viable. Tony From newbery@gmail.com Wed Oct 3 17:31:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9BD1F0C5F for ; Wed, 3 Oct 2012 17:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzX07xM7pFNi for ; Wed, 3 Oct 2012 17:31:20 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2A8021F84C8 for ; Wed, 3 Oct 2012 17:31:19 -0700 (PDT) Received: by danh15 with SMTP id h15so2651633dan.31 for ; Wed, 03 Oct 2012 17:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=nX/nQmJhj5s8jxYyitUx5HJSSUeQWnHUIaT3MBmfTN0=; b=XzyWAlp9Cq8qbbUb5ffJMGxM6GSK5muy+bpqlHXJiCJcyhZISaJg/yDDNa1LT7pxxc /WZvB6vb7ZM/TyxmcL2IaLNJqPuR5N5NLtP4dR0yOvRSvhUt/AH7eYfIdLqjxqHexNR7 kzLn+3Ru4C61a0zEa2vJ39NSNvPXUzP1Em5QRSbHxQnYDZOo3EvS2y+y+CemoBU7L7Qa Y7AY4o+0GTYD/YGayKef3B8+TlAVjgxIPgDCSjrd+jOXXVyuqAgfuLmzLiRSwlA71kzf J0UR+PdGVelwB0yMYCo6BbKHYgI1aeW6jMu3t+P9GnSjWMYv+VkCBAyPxeSpvspig5Ze uoEg== Received: by 10.68.232.71 with SMTP id tm7mr17184842pbc.118.1349310679636; Wed, 03 Oct 2012 17:31:19 -0700 (PDT) Received: from ?IPv6:2001::53aa:64c:0:7de1:349d:ed29? ([2001:0:53aa:64c:0:7de1:349d:ed29]) by mx.google.com with ESMTPS id ih2sm3363420pbc.65.2012.10.03.17.31.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2012 17:31:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Michael Newbery In-Reply-To: Date: Thu, 4 Oct 2012 13:31:13 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F4FE74C-05F2-4535-BA51-72389EE6CA60@gmail.com> References: <20121002115421.GY13776@Space.Net> To: IETF v6ops list X-Mailer: Apple Mail (2.1085) Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 00:31:20 -0000 On 3/10/2012, at 1:54 AM, Randy Bush wrote: >>> so, is double nat really worse than single nat? is it formally >>> different? except in the case of overlapping spaces, of course. >=20 > i asked *formally*. i am not concerned with all the ops, social, > stuff. and not about issues not directly connected to the nat. > what does double translation do that single does not? >=20 You may not be able to completely divorce them though. In the event that = you are legally obligated to maintain an accurate mapping between = endpoint address and public address---for instance for copyright = disputes---then you now have to maintain two (or generally, n) audit = logs, and you have to ensure that they match, such as when the host = requests a new address. And you need to be able to correlate them so as = to be able to answer the question "who did (address,port) belong to = during [t1, t2]?" If the two NATs are geographically distant, such that the speed of light = is an issue, then you have introduced a degree of fuzziness into the = mix. Now, there are simple techniques to work around this---but the = point is that you only need to work around them because of the existence = of more than one NAT. From joelja@bogus.com Wed Oct 3 19:51:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B483C21F851C for ; Wed, 3 Oct 2012 19:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQmvFG0GUFNZ for ; Wed, 3 Oct 2012 19:51:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 55EB221F851A for ; Wed, 3 Oct 2012 19:51:23 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q942pMPD058565 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 4 Oct 2012 02:51:22 GMT (envelope-from joelja@bogus.com) Message-ID: <506CA6D4.7020304@bogus.com> Date: Wed, 03 Oct 2012 13:57:56 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 04 Oct 2012 02:51:22 +0000 (UTC) Subject: [v6ops] v6ops milestones prior to IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 02:51:23 -0000 *The following are the remaining important milestones prior to IETF 85 * *** 2012-10-08 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. * 2012-10-12 (Friday): Final agenda to be published. * 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. * 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool. * 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. * 2012-10-26 (Friday): Early Bird registration and payment cut-off at UTC 24:00. * 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. * 2012-11-04 - 2012-11-09: 85th IETF Meeting in Atlanta, GA, USA. From joelja@bogus.com Thu Oct 4 13:15:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1143521F8768 for ; Thu, 4 Oct 2012 13:15:06 -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, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+g6JCWE-ri5 for ; Thu, 4 Oct 2012 13:15:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAF21F8767 for ; Thu, 4 Oct 2012 13:15:05 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q94KF4Oa068992 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 4 Oct 2012 20:15:04 GMT (envelope-from joelja@bogus.com) Message-ID: <506DEE42.5020705@bogus.com> Date: Thu, 04 Oct 2012 13:14:58 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG References: <20121004200556.15728.78023.idtracker@ietfa.amsl.com> In-Reply-To: <20121004200556.15728.78023.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121004200556.15728.78023.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 04 Oct 2012 20:15:05 +0000 (UTC) Subject: [v6ops] FYI: v6ops - Requested sessions have been scheduled for IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:15:06 -0000 -------- Original Message -------- Subject: v6ops - Requested sessions have been scheduled for IETF 85 Date: Thu, 04 Oct 2012 13:05:56 -0700 From: "IETF Secretariat" To: fred.baker@cisco.com CC: v6ops-ads@tools.ietf.org, fred.baker@cisco.com, joelja@bogus.com, wlo@amsl.com Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00:00) Thursday, Afternoon Session I 1300-1500 Room Name: Salon D --------------------------------------------- v6ops Session 2 (2:00:00) Thursday, Afternoon Session II 1510-1710 Room Name: Salon D --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 300 Conflicts to Avoid: First Priority: 6man behave homenet softwire opsarea opsawg pcp Second Priority: 6renum Special Requests: --------------------------------------------------------- From fred@cisco.com Thu Oct 4 16:18:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234E21F8650 for ; Thu, 4 Oct 2012 16:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.869 X-Spam-Level: X-Spam-Status: No, score=-109.869 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5WGZcct-I+t for ; Thu, 4 Oct 2012 16:18:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B597C21F8628 for ; Thu, 4 Oct 2012 16:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1549; q=dns/txt; s=iport; t=1349392683; x=1350602283; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=SB8KGIKJ1fboED/mG8q1MiA/XxSrXbUJo+pWXtLnPLw=; b=eMZWxnuFfrR12YnFMZn2GjulsrxIzlGx7ETdXgu62glqVN2tO3KXwMyE rIOzYGFqIVg5VrqkF52EoUDNnjnjDW9sBTZbS/sKnxL8yyPBnosiuj5BU q7k8UzOnfxVWuUR1/swmjhd+p4VX/Sk1tzl3Z2vhHSJQ/THzhbRYpVqOJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABgYblCtJXG+/2dsb2JhbABFvxyBCIIgAQEBAwESASdECwIBGQMBAgsUEDIbAggCBBMIGoddBpgikSSOZ4s+hSlgA6QsgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="125487718" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 04 Oct 2012 23:18:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q94NI3dL021256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Oct 2012 23:18:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.182]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 18:18:03 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: v6ops - Requested sessions have been scheduled for IETF 85 Thread-Index: AQHNooaAk5RVCLFGl0CGNQxebk+Z5g== Date: Thu, 4 Oct 2012 23:18:02 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B160F9F@xmb-rcd-x09.cisco.com> References: <20121004200556.15728.78023.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.60] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--37.473400-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-ID: <2CE9C2CDD96E86499E78A9AA75931391@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: v6ops - Requested sessions have been scheduled for IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 23:18:04 -0000 FYI. This is not "final"; it can change. But it is early guidance. Begin forwarded message: > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested sessions have been scheduled for IETF 85 > Date: October 4, 2012 1:05:56 PM PDT > To: > Cc: , , , >=20 > Dear Fred Baker, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > v6ops Session 1 (2:00:00) > Thursday, Afternoon Session I 1300-1500 > Room Name: Salon D > --------------------------------------------- > v6ops Session 2 (2:00:00) > Thursday, Afternoon Session II 1510-1710 > Room Name: Salon D > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name:=20 > Area Name:=20 > Session Requester:=20 >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 300 > Conflicts to Avoid:=20 > First Priority: 6man behave homenet softwire opsarea opsawg pcp > Second Priority: 6renum >=20 >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From mohamed.boucadair@orange.com Fri Oct 5 06:47:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E602F21F876C for ; Fri, 5 Oct 2012 06:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU5hgDWME4V7 for ; Fri, 5 Oct 2012 06:47:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0A83721F8767 for ; Fri, 5 Oct 2012 06:46:56 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 727ED2643F1 for ; Fri, 5 Oct 2012 15:46:55 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5999B35C045 for ; Fri, 5 Oct 2012 15:46:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 5 Oct 2012 15:46:55 +0200 From: To: IPv6 Ops WG Date: Fri, 5 Oct 2012 15:46:53 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2dQ4Q7QRt2U8qZRwml+bDWEqgsOgABPyggAW1DOXA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E5FA809AE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <87txuifydh.fsf@fatcat.cisco.com> <1B2E7539FECD9048B261B791B1B24A7C3EBFDBEFA6@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: <1B2E7539FECD9048B261B791B1B24A7C3EBFDBEFA6@PUEXCB1A.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.5.124533 Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:47:10 -0000 Dear all, We submitted an updated version of this I-D which includes the comments we = received so far.=20 The main changes are: * Remove the reference to the ND Proxy RFC. * Add a new requirement to relay RA MTU if advertised in the 3GPP link * Add a reference to RFC3596 * Re-order the requirements * A new co-author join this effort * Several edits to enhance the readability of the document=20 A more detailed diff is available at: http://tools.ietf.org/rfcdiff?url2=3D= draft-binet-v6ops-cellular-host-reqs-rfc3316update-03.txt Cheers, Med From rafiee@hpi.uni-potsdam.de Fri Oct 5 13:44:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C183721F870A for ; Fri, 5 Oct 2012 13:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci4LOEn+CPir for ; Fri, 5 Oct 2012 13:44:18 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 1959C21F8707 for ; Fri, 5 Oct 2012 13:44:17 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 880E9169E76 for ; Fri, 5 Oct 2012 22:44:15 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Fri, 5 Oct 2012 22:44:15 +0200 From: "Rafiee, Hosnieh" To: "v6ops@ietf.org" Date: Fri, 5 Oct 2012 22:44:11 +0200 Thread-Topic: draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2jOXWEqAyINx4KSHyEns/AcICDfQ== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924CD4EAE4F8MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 20:44:18 -0000 --_000_EA738325B0580041A50A364F5F76B68924CD4EAE4F8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please take a look at my new RFC draft and share your comments with me so t= hat I might improve it. Thanks, Hosnieh Filename: draft-rafiee-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorith= m in IPv6 Creation date: 2012-09-30 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-cga-tsig-00 --_000_EA738325B0580041A50A364F5F76B68924CD4EAE4F8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please take a look at my new RFC draft and = share your comments with me so that I might improve it.

Thanks,

Hosnieh

 

Filename:          &nb= sp; draft-rafiee-cga-tsig

Revision:&n= bsp;            = ; 00

Title:    &n= bsp;            = ;     Transaction SIGnature (TSIG) using CGA Algorithm = in IPv6

Creation date:   20= 12-09-30

WG ID:   &nbs= p;            &= nbsp; Individual Submission

Number of= pages: 13

URL:   &nbs= p;         http://www.ietf.org/in= ternet-drafts/draft-rafiee-cga-tsig-00.txt

Status:          http://datat= racker.ietf.org/doc/draft-rafiee-cga-tsig

Htmlized:        http://tools.ietf.org/htm= l/draft-rafiee-cga-tsig-00

&nbs= p;

 

= --_000_EA738325B0580041A50A364F5F76B68924CD4EAE4F8MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Sat Oct 6 02:24:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AC021F853B for ; Sat, 6 Oct 2012 02:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zgjGnWI2+v3 for ; Sat, 6 Oct 2012 02:24:59 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7921F8508 for ; Sat, 6 Oct 2012 02:24:58 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id D7414169EA2 for ; Sat, 6 Oct 2012 11:24:56 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sat, 6 Oct 2012 11:24:56 +0200 From: "Rafiee, Hosnieh" To: "v6ops@ietf.org" Date: Sat, 6 Oct 2012 11:24:52 +0200 Thread-Topic: draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2jpGPvmba36RKdRPmWeYVpnHbzlw== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924CD4EAE608MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 09:25:00 -0000 --_000_EA738325B0580041A50A364F5F76B68924CD4EAE608MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please take a look at my new RFC draft and share your comments with me so t= hat I might improve it. Thanks, Hosnieh Filename: draft-rafiee-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorith= m in IPv6 Creation date: 2012-09-30 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-cga-tsig-00 --_000_EA738325B0580041A50A364F5F76B68924CD4EAE608MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

P= lease take a look at my new RFC draft and share your comments with me so th= at I might improve it.

Thanks,

Hosnieh

=  

Filename:   &nb= sp;        draft-rafiee-cga-tsig

Revision:      = ;        00

Title:          = ;            Transac= tion SIGnature (TSIG) using CGA Algorithm in IPv6

Creation date:   2012-09-30

WG ID:         = ;         Individual Submission

Number of pages: 13

URL:         = ;    http://www.ietf.org/internet-drafts/draft-rafiee-cga-= tsig-00.txt

Status:  &n= bsp;       http://datatracker.ietf.org/doc/draft-rafie= e-cga-tsig

Htmlized:  &= nbsp;     http://tools.ietf.org/html/draft-rafiee-cga-tsig-00<= o:p>

 

 

= --_000_EA738325B0580041A50A364F5F76B68924CD4EAE608MXMA1Rhpiuni_-- From randy@psg.com Sat Oct 6 06:39:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA021F8585 for ; Sat, 6 Oct 2012 06:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy76EEmOKZGL for ; Sat, 6 Oct 2012 06:39:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1721F85DA for ; Sat, 6 Oct 2012 06:39:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TKUbf-0005Bo-9b; Sat, 06 Oct 2012 13:39:51 +0000 Date: Sat, 06 Oct 2012 06:39:51 -0700 Message-ID: From: Randy Bush To: "Rafiee, Hosnieh" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:39:54 -0000 definitely interesting. rather cute. but should it not be over in dns land? randy From rafiee@hpi.uni-potsdam.de Sat Oct 6 09:06:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D8621F856C for ; Sat, 6 Oct 2012 09:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlkLxxBWaIUr for ; Sat, 6 Oct 2012 09:06:34 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8821F8569 for ; Sat, 6 Oct 2012 09:06:29 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id A34E1D2C95; Sat, 6 Oct 2012 18:06:27 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sat, 6 Oct 2012 18:06:27 +0200 From: "Rafiee, Hosnieh" To: Randy Bush Date: Sat, 6 Oct 2012 18:06:22 +0200 Thread-Topic: [v6ops] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2jyBKLQgFqnLr5SpKdoV8l8OPVqQAE9OUg Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:06:37 -0000 Dear Randy, I have already discussed with DNSEXT WG and been told that it is in FIN-WA= IT. Therefore I posted this draft here. I hope I can receive good comments = and this WG adopt this draft here. Thank you, Best Regards, Hosnieh -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Saturday, October 06, 2012 3:40 PM To: Rafiee, Hosnieh Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments definitely interesting. rather cute. but should it not be over in dns land? randy From randy@psg.com Sat Oct 6 09:14:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB6021F856F for ; Sat, 6 Oct 2012 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuuvL2PZjLEd for ; Sat, 6 Oct 2012 09:14:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3FA21F8562 for ; Sat, 6 Oct 2012 09:14:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TKX1f-0005fM-Dc; Sat, 06 Oct 2012 16:14:51 +0000 Date: Sat, 06 Oct 2012 09:14:51 -0700 Message-ID: From: Randy Bush To: Hosnieh Rafiee In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:14:53 -0000 > I have already discussed with DNSEXT WG and been told that it is in > FIN-WAIT. Therefore I posted this draft here. I hope I can receive > good comments and this WG adopt this draft here. > > but should it not be over in dns land? imiho, dnsext should have been sent an RST looooong ago. but how about dnsop? but v6ops should not be hacking on aspects of the dns which have nothing to do with ipv6. randy From Ted.Lemon@nominum.com Sat Oct 6 09:26:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450A721F84FD for ; Sat, 6 Oct 2012 09:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKSPc5bYsfkE for ; Sat, 6 Oct 2012 09:26:49 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id A296621F84F9 for ; Sat, 6 Oct 2012 09:26:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUHBbyQDurWJwQIYEwKNkWvo0Jlo7gw52@postini.com; Sat, 06 Oct 2012 09:26:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B48311B82BF for ; Sat, 6 Oct 2012 09:26:48 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AA6CE19005C; Sat, 6 Oct 2012 09:26:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sat, 6 Oct 2012 09:26:48 -0700 From: Ted Lemon To: Randy Bush Thread-Topic: [v6ops] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2jpGPvnXZ+GspkRJ6N8oLgvD0ccAAXlfKAAAUd9gAAAEvZgAAAaosA Date: Sat, 6 Oct 2012 16:26:48 +0000 Message-ID: <8433A338-37C5-4258-AEA3-F18829B8C038@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <419E7E6877305E4383F9BF0852B264E5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:26:50 -0000 On Oct 6, 2012, at 12:14 PM, Randy Bush wrote: > imiho, dnsext should have been sent an RST looooong ago. but how about > dnsop? It's a standards-track document. Neither dnsop nor v6ops is chartered to = work on standards-track documents. DNSEXT should just do the work before = finishing. It could be brought up in intarea=97since DNSEXT seems determi= ned to commit suicide, and it was in the Internet area, it makes sense that= intarea should inherit the work. From rafiee@hpi.uni-potsdam.de Sat Oct 6 09:31:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B978321F8528 for ; Sat, 6 Oct 2012 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw6+GE0iWnvl for ; Sat, 6 Oct 2012 09:31:32 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7921F8516 for ; Sat, 6 Oct 2012 09:31:32 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 73830D2C96; Sat, 6 Oct 2012 18:31:30 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sat, 6 Oct 2012 18:31:30 +0200 From: "Rafiee, Hosnieh" To: Randy Bush , Ted Lemon Date: Sat, 6 Oct 2012 18:31:25 +0200 Thread-Topic: [v6ops] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2j3bhfSHDBg7wgShy6IbIZ0vdJbwAAHIYg Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:31:32 -0000 Dear Randy, Dear Ted > but how about dnsop? I tried that mailing list but I received no response. Moreover, they are no= t so IPv6 specific.=20 >but v6ops should not be hacking on aspects of the dns which have nothing t= o do with ipv6. I don't agree with you with regard to this sepcific draft. Because this app= roach is just for IPv6 and the authentication approach used here is just re= lated to IPv6 and does not work in IPv4. This draft focused on Neighbor Dis= covery protocol which again is just IPv6 specific. >It's a standards-track document. Neither dnsop nor v6ops is chartered to= work on standards-track documents. DNSEXT should just do the work before= finishing. It could be brought up in intarea-since DNSEXT ?>seems determ= ined to commit suicide, and it was in the Internet area, it makes sense tha= t intarea should inherit the work. I also discussed it with that group but they do not think that it is approp= riate for their group because it pretains to security and IPv6 plus DNS. Best Regards, Hosnieh =20 From randy@psg.com Sat Oct 6 09:32:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BAD21F852C for ; Sat, 6 Oct 2012 09:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY+3uXZURezz for ; Sat, 6 Oct 2012 09:32:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFD821F852A for ; Sat, 6 Oct 2012 09:32:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TKXJ4-0005jJ-53; Sat, 06 Oct 2012 16:32:50 +0000 Date: Sat, 06 Oct 2012 09:32:50 -0700 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: <8433A338-37C5-4258-AEA3-F18829B8C038@nominum.com> References: <8433A338-37C5-4258-AEA3-F18829B8C038@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:32:52 -0000 >> imiho, dnsext should have been sent an RST looooong ago. but how about >> dnsop? > It's a standards-track document. Neither dnsop nor v6ops is chartered > to work on standards-track documents. see RFC 4213 but i essentially agree > DNSEXT should just do the work before finishing. dnsext should not be given any excuses to drag on but this is all above my pay grade randy From joelja@bogus.com Sat Oct 6 09:38:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF821F8532 for ; Sat, 6 Oct 2012 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeVQY0NbmEd0 for ; Sat, 6 Oct 2012 09:38:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8035421F852C for ; Sat, 6 Oct 2012 09:38:21 -0700 (PDT) Received: from joels-MacBook-Air.local (165.sub-70-197-6.myvzw.com [70.197.6.165]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q96GcHDL094202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 6 Oct 2012 16:38:18 GMT (envelope-from joelja@bogus.com) Message-ID: <50705E75.5040501@bogus.com> Date: Sat, 06 Oct 2012 09:38:13 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 06 Oct 2012 16:38:18 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:38:22 -0000 So, dnsext is closing down. I personally don't see any harm in discussing it here, if there is interest. I don't think that CGA fits within the scope of our charter. joel On 10/6/12 6:39 AM, Randy Bush wrote: > definitely interesting. rather cute. > > but should it not be over in dns land? > > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From rafiee@hpi.uni-potsdam.de Sat Oct 6 10:33:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9E321F845D for ; Sat, 6 Oct 2012 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gQPPPXyXg5k for ; Sat, 6 Oct 2012 10:33:24 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 504BB21F846D for ; Sat, 6 Oct 2012 10:33:23 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id D5533D2C95; Sat, 6 Oct 2012 19:33:22 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sat, 6 Oct 2012 19:33:22 +0200 From: "Rafiee, Hosnieh" To: joel jaeggli , "Randy Bush (randy@psg.com)" Date: Sat, 6 Oct 2012 19:33:17 +0200 Thread-Topic: [v6ops] draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2j4P+yUqEkVJysSH+oaQEdt10YlAABuiqw Message-ID: References: <50705E75.5040501@bogus.com> In-Reply-To: <50705E75.5040501@bogus.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:33:25 -0000 I would appreciate it. if you find this draft interesting, to start a discu= ssion in this group which we can continue at the meeting in Atlanta. -----Original Message----- From: joel jaeggli [mailto:joelja@bogus.com]=20 Sent: Saturday, October 06, 2012 6:38 PM To: Randy Bush Cc: Rafiee, Hosnieh; v6ops@ietf.org Subject: Re: [v6ops] draft-rafiee-cga-tsig-00 - request for comments So, dnsext is closing down. I personally don't see any harm in discussing it here, if there is interest= . I don't think that CGA fits within the scope of our charter. joel On 10/6/12 6:39 AM, Randy Bush wrote: > definitely interesting. rather cute. > > but should it not be over in dns land? > > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gvandeve@cisco.com Sun Oct 7 02:29:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D8521F8448; Sun, 7 Oct 2012 02:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.705 X-Spam-Level: X-Spam-Status: No, score=-10.705 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBTNpm6h7xGS; Sun, 7 Oct 2012 02:29:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9125B21F850D; Sun, 7 Oct 2012 02:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6043; q=dns/txt; s=iport; t=1349602181; x=1350811781; h=from:to:subject:date:message-id:mime-version; bh=/FZwVRamVmIyYPjDJJmstMAjhyIjlmGtnt58BvHt0Jg=; b=eeR5RH+m9LZ7HaK7l0DwsvtLHATWIzMkPdMZ2dJn4tW4NMXB9b5HY4ha ZZB2lnsIw0j0qz/3YGVIzEf+nCrtKKm9a4SHnBWHQPfSShk4GPKVt+tDu 7IljCdSrzKvBp/OGvhJjkaQzTwrHYxXDwZRK5ajml9gBCCFIWyfWSjv4I M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA5LcVCtJV2d/2dsb2JhbABFgku8V4EIgiIBBBIBGl4BKlYmAQQBGgEZh2MLmg2fCJB/YAOXAI0wgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208,217";a="129075717" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 07 Oct 2012 09:29:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q979TeSO022435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 09:29:40 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 04:29:40 -0500 From: "Gunter Van de Velde (gvandeve)" To: "v6ops v6ops WG (v6ops@ietf.org)" , "opsec@ietf.org" Thread-Topic: Passive IP addresses - 2th iteration Thread-Index: Ac2kbgMQYxCCEpPZSqa8dHdhP5jyCQ== Date: Sun, 7 Oct 2012 09:29:40 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.225] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--32.857400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [v6ops] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 09:29:43 -0000 --_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, I am picking the ball up again wrt Passive IP addresses, particular in the = light of all the discussions around the tools.ietf.org/html/draft-ietf-opse= c-lla-only IP addresses. (http://www.ietf.org/id/draft-baker-opsec-passive-ip-address-01.txt) One of the considerations regarding usage of LLA-Only is that network visib= ility is undermined for a part. This is exactly one of the things that Passive addresses can aid with. It p= rovides network visilbility, while still protecting the network from some e= xternal influences. So in a nutshell: Q) What is a passive address? A) any kind of address you configure on a device or interface Q) is there need for a new address type specified by IANA A) No Q) what makes an address a passive address A) during configuration of that address on an interface/device you specify = for example: ip address foo 'passive' Q) what does the passive keyword result into A) If the recipient device receives an IP packet with this passive address = in the destination address and is destined for this device, then the packet= will be dropped. However, when the device gets for example a packet with T= TL expired (for trace-route) then this passive address could be used as the= source address Q) can a passive address be used to build a session with? A) nope, it only accommodates unidirectional traffic G/ --_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

I am picking the ball up again wrt Passive IP addres= ses, particular in the light of all the discussions around the tools.ietf.org/html/draft-ietf-opsec-lla-only IP addresses.

(http://www.ietf.org/id/draft-baker-opsec-passive-ip= -address-01.txt)

 

One of the considerations regarding usage of LLA-Onl= y is that network visibility is undermined for a part.

This is exactly one of the things that Passive addre= sses can aid with. It provides network visilbility, while still protecting = the network from some external influences.

 

So in a nutshell:

Q) What is a passive address?

A) any kind of address you configure on a device or = interface

 

Q) is there need for a new address type specified by= IANA

A) No

 

Q) what makes an address a passive address

A) during configuration of that address on an interf= ace/device you specify for example: ip address foo ‘passive’

 

Q) what does the passive keyword result into

A) If the recipient device receives an IP packet wit= h this passive address in the destination address and is destined for this = device, then the packet will be dropped. However, when the device gets for = example a packet with TTL expired (for trace-route) then this passive address could be used as the source ad= dress

 

Q) can a passive address be used to build a session = with?

A) nope, it only accommodates unidirectional traffic=

 

 

G/

--_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_-- From gvandeve@cisco.com Sun Oct 7 03:32:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D587721F853E; Sun, 7 Oct 2012 03:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m9P4d6UKumV; Sun, 7 Oct 2012 03:32:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC321F850D; Sun, 7 Oct 2012 03:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1629; q=dns/txt; s=iport; t=1349605965; x=1350815565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xZLF/28IZeouxdaSg7BMTSlz/7K8Zk+LngchwUdlgyo=; b=nBt00qz6c4Rz/F+lKF2RItPqLdeeclGGqe1tEDOYhVKmKBfAQb16Y8lu 18bY6s/dtaOuZx1ixuOF6tTttBXFqJmGVHQ/lFFMFzNiD/edOJ7W7U6ey utXQbHDQOn03FdIar1Ff3xBvyM3KbRcRWen3yTy9ssiZ7Xw9tmwZw6XOd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGJZcVCtJV2d/2dsb2JhbABFvyKBCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIGoddBguaA58Di0+FMGADpDCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208";a="129110056" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Oct 2012 10:32:44 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q97AWiSM017067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 10:32:44 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 05:32:44 -0500 From: "Gunter Van de Velde (gvandeve)" To: "Dobbins, Roland" , opsec wg mailing list Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kbgMQYxCCEpPZSqa8dHdhP5jyCQAMjGqAAApymcA= Date: Sun, 7 Oct 2012 10:32:43 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> In-Reply-To: <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.225] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--35.468800-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 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:32:46 -0000 Edge ACL tend to be wrong after a while (too much operation involved etc...= ) This is just another way to shield the infrastructure.=20 Often within a network non-LLA's are used for traffic path visibility, or f= or trace-routes. Passive addresses will in that case reduce the attack vector as they are us= eless as a destination address, because the recipient target box will drop = any packet received where this address is used as destination address. It does not mean that you should not use perimeter ACL or FW's at all. That is still good practice. G/ -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of D= obbins, Roland Sent: 07 October 2012 12:27 To: opsec wg mailing list Cc: v6ops v6ops WG (v6ops@ietf.org) Subject: Re: [OPSEC] Passive IP addresses - 2th iteration On Oct 7, 2012, at 4:29 PM, Gunter Van de Velde (gvandeve) wrote: > A) If the recipient device receives an IP packet with this passive addres= s in the destination address and is destined for this device, then the pack= et will be dropped. What's the advantage to this over ACLs? It seems just another way to fragm= ent (pardon the pun, heh) network access policy even further than it alread= y is. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From gvandeve@cisco.com Sun Oct 7 04:50:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4221F84F2; Sun, 7 Oct 2012 04:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t9Cq3xHtCe2; Sun, 7 Oct 2012 04:50:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF6621F84F1; Sun, 7 Oct 2012 04:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1349610625; x=1350820225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pi1eWu8IGhBu8BVDV90ZAV64o0E1x1eAfxPwQ0SRPO0=; b=eNn4kdVoRN9O2zHF2qSHojLIRTnOBKA2j5ZLW+LfMFOhcERSZ3xsqpDR poSudWDmvDAINDxnj5W5lUVGRdzEGcNxKKu4y7/jq+9iGaA52V+/PzzFB VC9MG15E86AZRPLWOCzdSt77KhCvbjKZU/L+4N+eZN+6aOtMqXJ7Bqe6M Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEJscVCtJXHA/2dsb2JhbABFvyKBCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIGoddBguaCp5/i08UhRxgA6QwgWmCbYFaPQ X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208";a="129083025" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 07 Oct 2012 11:50:25 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q97BoOG5018252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 11:50:24 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 06:50:24 -0500 From: "Gunter Van de Velde (gvandeve)" To: "Dobbins, Roland" , opsec wg mailing list Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kbgMQYxCCEpPZSqa8dHdhP5jyCQAMjGqAAApymcD//7BzgIAAQWzw Date: Sun, 7 Oct 2012 11:50:23 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> In-Reply-To: <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.225] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--37.031600-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 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 11:50:26 -0000 I fairly do not see what ACL have to do with Passive addresses? They serve completely different goals (and are to some degree ortogonal). ACls should still be used where ever found usefull. Passive address can be = used where deemed usefull for device protection while still allowing limite= d troubleshooting within the network (traceroute, traps as most important o= nces). Please feel free to read the draft. G/ -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of D= obbins, Roland Sent: 07 October 2012 12:42 To: opsec wg mailing list Cc: v6ops v6ops WG (v6ops@ietf.org) Subject: Re: [OPSEC] Passive IP addresses - 2th iteration On Oct 7, 2012, at 5:32 PM, Gunter Van de Velde (gvandeve) wrote: > Edge ACL tend to be wrong after a while (too much operation involved etc.= ..) Operational entropy applies to all forms of policy. > This is just another way to shield the infrastructure.=20 A potentially duplicative, confusing and unnecessary way, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From rdobbins@arbor.net Sun Oct 7 03:27:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B221F8528; Sun, 7 Oct 2012 03:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYMt7YFI52tr; Sun, 7 Oct 2012 03:27:11 -0700 (PDT) Received: from gwo3.mbox.net (gateout03.mbox.net [165.212.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1FD21F846E; Sun, 7 Oct 2012 03:27:11 -0700 (PDT) Received: from gwo3.mbox.net (localhost [127.0.0.1]) by gwo3.mbox.net (Postfix) with ESMTP id 0E3AFE0AE56A; Sun, 7 Oct 2012 10:27:10 +0000 (UTC) X-USANET-Received: from gwo3.mbox.net [127.0.0.1] by gwo3.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 332qJgkbH1024Mo3; Sun, 07 Oct 2012 10:27:07 -0000 Received: from S1HUB3.EXCHPROD.USA.NET [165.212.120.254] by gwo3.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID169qJgkbH2085Xo3; Sun, 07 Oct 2012 10:27:07 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB3.EXCHPROD.USA.NET X-USANET-MsgId: XID169qJgkbH2085Xo3 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB3.EXCHPROD.USA.NET ([10.120.220.33]) with mapi; Sun, 7 Oct 2012 10:27:07 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 10:27:05 +0000 Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kdk0alnjffXdRS26mTlyUp1/kLg== Message-ID: <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 07 Oct 2012 07:23:53 -0700 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:27:12 -0000 On Oct 7, 2012, at 4:29 PM, Gunter Van de Velde (gvandeve) wrote: > A) If the recipient device receives an IP packet with this passive addres= s in the destination address and is destined for this device, then the pack= et will be dropped. What's the advantage to this over ACLs? It seems just another way to fragm= ent (pardon the pun, heh) network access policy even further than it alread= y is. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins@arbor.net Sun Oct 7 03:41:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13B021F8550; Sun, 7 Oct 2012 03:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WggCFlbZG6d7; Sun, 7 Oct 2012 03:41:34 -0700 (PDT) Received: from gwo2.mbox.net (gateout02.mbox.net [165.212.64.22]) by ietfa.amsl.com (Postfix) with ESMTP id 722ED21F852D; Sun, 7 Oct 2012 03:41:34 -0700 (PDT) Received: from gwo2.mbox.net (localhost [127.0.0.1]) by gwo2.mbox.net (Postfix) with ESMTP id 0A09EE01D390; Sun, 7 Oct 2012 10:41:34 +0000 (UTC) X-USANET-Received: from gwo2.mbox.net [127.0.0.1] by gwo2.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 534qJgkpG2208Mo2; Sun, 07 Oct 2012 10:41:32 -0000 Received: from S1HUB4.EXCHPROD.USA.NET [165.212.120.254] by gwo2.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID747qJgkpG2438Xo2; Sun, 07 Oct 2012 10:41:32 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB4.EXCHPROD.USA.NET X-USANET-MsgId: XID747qJgkpG2438Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB4.EXCHPROD.USA.NET ([10.120.220.34]) with mapi; Sun, 7 Oct 2012 10:41:32 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 10:41:31 +0000 Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2keFDOSoyUErhnQ4qGdq/LRivDxw== Message-ID: <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 07 Oct 2012 07:23:53 -0700 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:41:35 -0000 On Oct 7, 2012, at 5:32 PM, Gunter Van de Velde (gvandeve) wrote: > Edge ACL tend to be wrong after a while (too much operation involved etc.= ..) Operational entropy applies to all forms of policy. > This is just another way to shield the infrastructure.=20 A potentially duplicative, confusing and unnecessary way, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins@arbor.net Sun Oct 7 05:36:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE9421F8569; Sun, 7 Oct 2012 05:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMEfPhQzewpG; Sun, 7 Oct 2012 05:36:45 -0700 (PDT) Received: from gwo1.mbox.net (gateout01.mbox.net [165.212.64.21]) by ietfa.amsl.com (Postfix) with ESMTP id E118621F8567; Sun, 7 Oct 2012 05:36:45 -0700 (PDT) Received: from gwo1.mbox.net (localhost [127.0.0.1]) by gwo1.mbox.net (Postfix) with ESMTP id C0CFDE037EE9; Sun, 7 Oct 2012 12:36:44 +0000 (UTC) X-USANET-Received: from gwo1.mbox.net [127.0.0.1] by gwo1.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 881qJgmKQ4832Mo1; Sun, 07 Oct 2012 12:36:42 -0000 Received: from S1HUB5.EXCHPROD.USA.NET [165.212.120.254] by gwo1.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID287qJgmKQ7646Xo1; Sun, 07 Oct 2012 12:36:42 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB5.EXCHPROD.USA.NET X-USANET-MsgId: XID287qJgmKQ7646Xo1 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB5.EXCHPROD.USA.NET ([10.120.220.35]) with mapi; Sun, 7 Oct 2012 12:36:41 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 12:36:39 +0000 Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kiGblvyMjukGkS3WZEg2juaLEXw== Message-ID: <99755C4A-1B11-4B2D-9B2C-06688AF090E1@arbor.net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 07 Oct 2012 07:23:53 -0700 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 12:36:46 -0000 On Oct 7, 2012, at 6:50 PM, Gunter Van de Velde (gvandeve) wrote: > Passive address can be used where deemed usefull for device protection w= hile still allowing limited troubleshooting within the network (traceroute,= traps as most important onces). What you're describing is a policy function already encapsulated by ACLs. And in general, it seems to follow the deplorable trend of continuing to ov= erload IP addresses with more and more significance when a) they're already= grossly overloaded and b) we're supposedly going to a world of IPv6 addres= ses, which should imply *less* significance, not more. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From gert@space.net Mon Oct 8 04:01:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB87A21F8717 for ; Mon, 8 Oct 2012 04:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTTMjvYxbHNg for ; Mon, 8 Oct 2012 04:01:01 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10421F870F for ; Mon, 8 Oct 2012 04:01:00 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E4C74F8CB1 for ; Mon, 8 Oct 2012 13:00:58 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B0FBCF8C27 for ; Mon, 8 Oct 2012 13:00:58 +0200 (CEST) Received: (qmail 54187 invoked by uid 1007); 8 Oct 2012 13:00:58 +0200 Date: Mon, 8 Oct 2012 13:00:58 +0200 From: Gert Doering To: "Gunter Van de Velde \(gvandeve\)" Message-ID: <20121008110058.GO13776@Space.Net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Dobbins, Roland" , opsec wg mailing list , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:01:02 -0000 Hi, On Sun, Oct 07, 2012 at 11:50:23AM +0000, Gunter Van de Velde (gvandeve) wrote: > I fairly do not see what ACL have to do with Passive addresses? Well, I have to agree with Roland - a "passive IP address" would be one that has a "receive ACL", or "control plane policy with drop-all" or however a vendor calls that feature "do not accept packets for a certain IP address" attached to it. Don't confuse with transit ACLs. (Now, not all vendors ship useful implementations of rRACLs or CoPP today, but those wouldn't know what a passive IP address is either) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From rafiee@hpi.uni-potsdam.de Tue Oct 9 04:13:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1921F84F0; Tue, 9 Oct 2012 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNGaPDApEs1w; Tue, 9 Oct 2012 04:13:41 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id F349F21F84F1; Tue, 9 Oct 2012 04:13:38 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 6B774169E7B; Tue, 9 Oct 2012 13:13:33 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 9 Oct 2012 13:13:33 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Tue, 9 Oct 2012 13:13:32 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Index: Ac2lkN6YCNqEW9kdTEm8XD7GV2kI9AAfe1VA Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "Int-area@ietf.org" , "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [v6ops] [dnsext] draft-rafiee-cga-tsig-00 - call for more comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:13:42 -0000 More ideas and comments would be greatly apprecitated as I want to upload a= new version of my draft RFC in which I will incorporate applicable comment= s. -----Original Message----- From: Rafiee, Hosnieh=20 Sent: Thursday, October 04, 2012 9:28 AM To: 'Mark Andrews' Cc: dnsext@ietf.org Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Fri Oct 12 01:11:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D821F8533; Fri, 12 Oct 2012 01:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmw9wf9Ne4tb; Fri, 12 Oct 2012 01:11:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2C21F84FE; Fri, 12 Oct 2012 01:11:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012081105.9925.87607.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 01:11:05 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:11:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Stateless Source Address Mapping for ICMPv6 Packets Author(s) : Xing Li Congxiao Bao Dan Wing Ramji Vaithianathan Geoff Huston Filename : draft-ietf-v6ops-ivi-icmp-address-07.txt Pages : 7 Date : 2012-10-12 Abstract: A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ivi-icmp-address-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From markzzzsmith@yahoo.com.au Fri Oct 12 18:14:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA821F845F for ; Fri, 12 Oct 2012 18:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqJgbyt3UQVI for ; Fri, 12 Oct 2012 18:14:00 -0700 (PDT) Received: from nm16-vm0.bullet.mail.ne1.yahoo.com (nm16-vm0.bullet.mail.ne1.yahoo.com [98.138.91.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2123921F845E for ; Fri, 12 Oct 2012 18:14:00 -0700 (PDT) Received: from [98.138.90.56] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 13 Oct 2012 01:13:57 -0000 Received: from [98.138.89.172] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 13 Oct 2012 01:13:57 -0000 Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 13 Oct 2012 01:13:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 82644.66121.bm@omp1028.mail.ne1.yahoo.com Received: (qmail 49572 invoked by uid 60001); 13 Oct 2012 01:13:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350090836; bh=EV1ZQUhA1CNsBeLpAv+VCG8eAE9Hi6vFWYpF6HaiA/g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=g3mbWE/b463hDZaMESrRAddsSNbOpTxWo2QGMsQwunTWvOR5OL6OAxKQUUgrMZHqQwTnEZynHPGc/kn0VEagmh5+p6E5bgq+etysfAc9f3Cms/aVn+KmJWiYN5nrHHD05MrhaBekpe/1kuls7Xj5TEz7204DrTDjpWfy+/e3HGE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o0i5zx2CI65CO0n76iHdWSCeh7rETkVIrQBXUqNqPI8vrDrcn4LlBOw+j/6xQagINLlSsrq4kQK7k+gVF88wajRg4p54kTt4v5Ol/VbP1Se1YP6de/51nFkixKdliKnhavHJFUBBYFINOR8Rc8kk+1mqqUf/P+8jl82apZkvqVw=; X-YMail-OSG: Z0a8k0wVM1mW5S2oyymq168H08kqiy_tUHqmnsc9n3xWK68 RVTNGimZ7CAtlm8pGAs8Pvs1DmC.iqkae2lfdbZHnEtl7Oj75kcgwetuKU65 S51F_qElfAzNHDp9xurucZkmu6QCjJyOXL_qru1kUn3oSnW1XDi9guzS0qG8 bKRqyZ3M01lKJzpbkAWgeGvHSvzKM_xkxOA7jHPFf_TV9z.Up6Pf0hwJ.0sT CGFLCsRTNB1itjLqTLMZ9zSWiHXbUUvh6J6B1_eiWwefaRxZzuDJBvofe0Px 7SKpwUXuq02IMLcgJYc7tERvr5Tr8OChI4tfpjXJvSd6mh6.tEDlHu5BIJFt Kz5bNNjZEEF89ynFk_kh6U8DBwHaufF50yIYDhH9f6zwmKjUqlgqZmm7_oE8 JmNPnnbFsd5uw.NqaIu9nBUa7esivqbjy8TAFAGoM1vcmhiS43usFZAFR8L9 M1MIY.zfWTGwqe6G_nHQ6J_bH4irpPrbJbUu.DHhYpf.T77EX4tTXYcZEIGL B9RIvVLGRvB0- Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Fri, 12 Oct 2012 18:13:56 PDT X-Rocket-MIMEInfo: 001.001, SGksCgpJJ20gcHJvcG9zaW5nIGEgY2hhbmdlIHRvIHRoZSBvcGVyYXRpb24gb2YgSVB2NiBuZWlnaGJvciBkaXNjb3Zlcnkgb24gcm91dGVycyB0byBtaXRpZ2F0ZSB0aGUgbmVpZ2hib3IgY2FjaGUgRG9TIGF0dGFjayBpbiB0aGUgZm9sbG93aW5nIElELiBUaGUgNm1hbiBtYWlsaW5nIGxpc3QgaXMgd2hlcmUgaXQgc2hvdWxkIGJlIGRpc2N1c3NlZCwgaG93ZXZlciBJIHRob3VnaCB0aGlzIGxpc3QncyBtZW1iZXJzIG1pZ2h0IGFsc28gYmUgaW50ZXJlc3RlZC4KCkNvbW1lbnRzIGFwcHJlY2lhdGVkLgoKVGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> Message-ID: <1350090836.44383.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Fri, 12 Oct 2012 18:13:56 -0700 (PDT) From: Mark ZZZ Smith To: "v6ops@ietf.org" In-Reply-To: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 01:14:01 -0000 Hi,=0A=0AI'm proposing a change to the operation of IPv6 neighbor discovery= on routers to mitigate the neighbor cache DoS attack in the following ID. = The 6man mailing list is where it should be discussed, however I though thi= s list's members might also be interested.=0A=0AComments appreciated.=0A=0A= Thanks,=0AMark.=0A=0A----- Forwarded Message -----=0A>From: "internet-draft= s@ietf.org" =0A>To: markzzzsmith@yahoo.com.au =0A= >Sent: Saturday, 13 October 2012 11:49 AM=0A>Subject: New Version Notificat= ion for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt=0A> =0A>=0A>A ne= w version of I-D, draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt=0A>has= been successfully submitted by Mark Smith and posted to the=0A>IETF reposi= tory.=0A>=0A>Filename:=A0=A0=A0=A0=A0draft-smith-6man-mitigate-nd-cache-dos= -slnd=0A>Revision:=A0=A0=A0=A0=A001=0A>Title:=A0=A0=A0 =A0=A0=A0=A0=A0Mitig= ating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery=0A>= Creation date:=A0=A0=A0=A0=A02012-10-13=0A>WG ID:=A0=A0=A0 =A0=A0=A0=A0=A0I= ndividual Submission=0A>Number of pages: 11=0A>URL:=A0 =A0 =A0 =A0 =A0 =A0 = http://www.ietf.org/internet-drafts/draft-smith-6man-mitigate-nd-cache-dos-= slnd-01.txt=0A>Status:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/d= raft-smith-6man-mitigate-nd-cache-dos-slnd=0A>Htmlized:=A0 =A0 =A0 =A0 http= ://tools.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-01=0A>Di= ff:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-6= man-mitigate-nd-cache-dos-slnd-01=0A>=0A>Abstract:=0A>=A0=A0=A0The IPv6 nei= ghbor discovery cache is vulnerable to a Denial of=0A>=A0=A0=A0Service atta= ck that purposely exhausts the state used during the=0A>=A0=A0=A0neighbor d= iscovery address resolution process.=A0 This attack can be=0A>=A0=A0=A0very= disruptive when the target is a router.=A0 This memo proposes a=0A>=A0=A0= =A0stateless form of neighbor discovery to be used by routers to=0A>=A0=A0= =A0mitigate this attack.=A0 It does not require any changes to hosts.=0A>= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =0A>=0A>=0A>The IETF Secretariat=0A>=0A>=0A>=0A> From joelja@bogus.com Sun Oct 14 16:44:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5121F8508 for ; Sun, 14 Oct 2012 16:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.702 X-Spam-Level: X-Spam-Status: No, score=-101.702 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXfxgN1Hlg-T for ; Sun, 14 Oct 2012 16:44:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D1E6B21F8505 for ; Sun, 14 Oct 2012 16:44:11 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9ENi9d6005004 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 14 Oct 2012 23:44:10 GMT (envelope-from joelja@bogus.com) Message-ID: <507B4E48.4080705@bogus.com> Date: Sun, 14 Oct 2012 16:44:08 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 14 Oct 2012 23:44:10 +0000 (UTC) Subject: [v6ops] Reminder, milestones before IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 23:44:12 -0000 Monday at 1700 Pacific is the deadline for 00 submissions. We've heard from some of your already about Agenda items. but we are actively accepting requests and presentations for the meeting. Thanks. joel From fred@cisco.com Mon Oct 15 05:45:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBF021F8721 for ; Mon, 15 Oct 2012 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.571 X-Spam-Level: X-Spam-Status: No, score=-110.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsJv64rwEzOb for ; Mon, 15 Oct 2012 05:45:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3622E21F871C for ; Mon, 15 Oct 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1350305101; x=1351514701; h=date:from:message-id:to:subject:cc; bh=pYmzItUczVHgzYkvei2kiF0KuErw7FGR/12DKy1GqcA=; b=E4gIN2g1ZdgM/3sJGnFtCNT2LlSbCIvsT4UtYR3KUpAkLMHRyTz0sQe3 66f5YRIQv5K1mcGV/fgCin+Om3eIYTPw2p2KJXykPRqFQd8d3FjXoqurH CP+HbgrhZi5HiaCqw1i+zMi83zoTNx3YKNjA9XeIR0W3h8KnHdANnCuE/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8IAE4EfFCrRDoJ/2dsb2JhbABFhUuoVQGRV4EIgjkBZjwtgQqHYQydZ59OjnWDIQOIWI4pjTCBa4MN X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="58788163" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 15 Oct 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9FCj0KW024296; Mon, 15 Oct 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q9FCj0O23768; Mon, 15 Oct 2012 05:45:00 -0700 (PDT) Date: Mon, 15 Oct 2012 05:45:00 -0700 (PDT) From: Message-Id: <201210151245.q9FCj0O23768@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-yang-v6ops-ipv6tran-select@tools.ietf.org Subject: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select. Please take a look at it and comment. From fred@cisco.com Mon Oct 15 05:45:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8D021F8722 for ; Mon, 15 Oct 2012 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAxt+18Qci5G for ; Mon, 15 Oct 2012 05:45:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08021F871A for ; Mon, 15 Oct 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135; q=dns/txt; s=iport; t=1350305101; x=1351514701; h=date:from:message-id:to:subject:cc; bh=RQWazNVH7IWO8Ad3EzRY1BV2XNlU7pMFHPfWIbrtON8=; b=gBONHTmkrNEHbyo2IoqfLFYLJXOVB9Gd1KTZJSm0G8ZNOrvzK43YH7MT CTUrTZb5+HJtc1LWs3eLITIYUhhkqipgzDTftybEIeOCtEDcTxGguBkx9 ghMQxct4lmlZpsujhT7gfPls9cJi3MFgbnwjJMyXJOdAYxs5xoi2rrBu9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8IAE4EfFCrRDoI/2dsb2JhbABFhUuoVQGRV4EIgjkBZjwtgQqHYQydZ59OjnWDIQOIWI4pjTCBa4MN X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="58788162" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Oct 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9FCj0BU019856; Mon, 15 Oct 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q9FCj0t23756; Mon, 15 Oct 2012 05:45:00 -0700 (PDT) Date: Mon, 15 Oct 2012 05:45:00 -0700 (PDT) From: Message-Id: <201210151245.q9FCj0t23756@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-jiang-v6ops-semantic-prefix@tools.ietf.org Subject: [v6ops] new draft: draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix. Please take a look at it and comment. From fred@cisco.com Mon Oct 15 05:45:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC94921F871E for ; Mon, 15 Oct 2012 05:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1Gv3FIPw7kw for ; Mon, 15 Oct 2012 05:45:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0F13B21F8720 for ; Mon, 15 Oct 2012 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1350305102; x=1351514702; h=date:from:message-id:to:subject:cc; bh=eV1DaWp++99NQVyvdJX9FNyYswnfmhnUtimNPSV7r7E=; b=bfgfJVR0BvKKH0WpQj/dFd5kUAbs/cI2FmbecjWC6FLvXvTKOrvg/opT Yz7v6HRDB0H45BzQmpA5rOphuthwc90KlapjcUxox/8shYRF8uwqZcud7 /WdVJ2iEGKfKfd1TyV6B+xZndLevzMFYO0pWlyMD9/Kpt8riEUxt6xHhV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8IAE4EfFCrRDoI/2dsb2JhbABFhUuoVQGRV4EIgjkBZjwtgQqHYQydZ59OjnWDIQOIWI4pjTCBa4MN X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="61287511" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 15 Oct 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9FCj0fj019858; Mon, 15 Oct 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q9FCj0123762; Mon, 15 Oct 2012 05:45:00 -0700 (PDT) Date: Mon, 15 Oct 2012 05:45:00 -0700 (PDT) From: Message-Id: <201210151245.q9FCj0123762@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-korhonen-v6ops-rfc3316bis@tools.ietf.org Subject: [v6ops] new draft: draft-korhonen-v6ops-rfc3316bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-korhonen-v6ops-rfc3316bis. Please take a look at it and comment. From iesg-secretary@ietf.org Mon Oct 15 13:10:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C5521F8995; Mon, 15 Oct 2012 13:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1d3-GXOdcgJ; Mon, 15 Oct 2012 13:10:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF2021F89D4; Mon, 15 Oct 2012 13:10:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015201053.8563.9923.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 13:10:53 -0700 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: 'Stateless Source Address Mapping for ICMPv6 Packets' to Proposed Standard (draft-ietf-v6ops-ivi-icmp-address-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:10:54 -0000 The IESG has approved the following document: - 'Stateless Source Address Mapping for ICMPv6 Packets' (draft-ietf-v6ops-ivi-icmp-address-07.txt) as Proposed Standard This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address/ Technical Summary A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the IPv4-translatable destination. This document presents recommendations for source address translation and original source address transport in ICMPv6 headers for such cases. Working Group Summary The working group process was pretty straightforward. The authors brought an initial proposal, which was not accepted, and working group discussion resulted in the document's recommendation. To the shepherd's knowledge, there is no dissent regarding the final recommendation. Document Quality There are existing implementations of the procedure and protocol in question. It has been tested in CERNET/CERNET2. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica. RFC Editor Note OLD> [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm" document. states NEW> [RFC6145] section 5.3 of the "IP/ICMP Translation Algorithm" document states From tom.taylor.stds@gmail.com Mon Oct 15 17:45:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5634721F876A for ; Mon, 15 Oct 2012 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNMZ30s3SQnW for ; Mon, 15 Oct 2012 17:44:59 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5E6821F8789 for ; Mon, 15 Oct 2012 17:44:59 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4801029iad.31 for ; Mon, 15 Oct 2012 17:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=edyvKOmd0mtEbGe+S/jn7T8SOEUfQLKKc3DBwwIBhpo=; b=AmqNnModmd9I2TeokjZ9z7Ij0VZSMom1ANgmAYtvwZK/zkPMdLWyRK5qTrDbXv94aF Ak5xbyKZ6P0Up2aJgGGCp52K/FjTSHkrZzSOULIi9h36vHjoi2QyS6Yef+5e/kCX54mA cz9Po06zY+y6i8HHaogM+vLFhBZbbQvMMiVcbYunPtRpxoZXsG3E78v4O1aWGgFHI8ol +iDV+8pi69ZY/LKQAmTH2UgUHiNhlE/UDQculiZNnCjX3xChPZzLbdgVeAZftcr1l1sm hfGbJq93QAYeUPhzLCQF1ThXlVFJmdOuLInT3RyGZo117Df8q8LgfyKs0fnH9o9hp/VI J9Jw== Received: by 10.50.194.138 with SMTP id hw10mr10423753igc.11.1350348299312; Mon, 15 Oct 2012 17:44:59 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.149]) by mx.google.com with ESMTPS id uz12sm7254808igb.16.2012.10.15.17.44.57 (version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 17:44:58 -0700 (PDT) Message-ID: <507CAE0A.7000802@gmail.com> Date: Mon, 15 Oct 2012 20:44:58 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: IPv6 Ops WG References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> In-Reply-To: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121015-1, 15/10/2012), Outbound message X-Antivirus-Status: Clean Subject: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 00:45:00 -0000 This draft captures a discussion that occurred at the end of the Amsterdam interim meeting. It's raw, but your comments will help to bring it to maturity. -------- Original Message -------- Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. ... Title: Why Operators Filter Fragments and What It Implies ... Htmlized: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 Abstract: This memo is written to make application developers and network operators aware of the significant probability that IPv6 packets containing fragmentation extension headers will fail to reach their destination. Some assumptions about the ability to use TCP or UDP datagrams larger than a single packet may accordingly need adjustment. This memo provides observational evidence for the dropping of IPv6 fragments along a significant number of paths, explores the operational impact of fragmentation and the reasons why dropping occurs, and considers the effect of fragment dropping on applications particularly including DNS. The IETF Secretariat From heard@pobox.com Mon Oct 15 19:50:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DB01F0C93 for ; Mon, 15 Oct 2012 19:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkIU097mCDBN for ; Mon, 15 Oct 2012 19:50:59 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECED91F0C92 for ; Mon, 15 Oct 2012 19:50:58 -0700 (PDT) Received: (qmail 25627 invoked from network); 15 Oct 2012 19:50:57 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Oct 2012 19:50:57 -0700 Date: Mon, 15 Oct 2012 19:50:57 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Ops WG In-Reply-To: <507CAE0A.7000802@gmail.com> Message-ID: References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 02:50:59 -0000 It's an easy read, but my reaction is: where's the beef? In particular, there needs to be justification of the bald assertion in Section 2.1 that "some cases will remain where legitimate fragments are discarded for legitimate reasons." What legitimate reasons? Those need to be spelled out. //cmh On Mon, 15 Oct 2012, Tom Taylor wrote: > This draft captures a discussion that occurred at the end of the Amsterdam > interim meeting. It's raw, but your comments will help to bring it to > maturity. > > > -------- Original Message -------- > Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt > > A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt > has been successfully submitted by Tom Taylor and posted to the > IETF repository. > > ... > > Title: Why Operators Filter Fragments and What It Implies > ... > Htmlized: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > > > Abstract: > This memo is written to make application developers and network > operators aware of the significant probability that IPv6 packets > containing fragmentation extension headers will fail to reach their > destination. Some assumptions about the ability to use TCP or UDP > datagrams larger than a single packet may accordingly need > adjustment. This memo provides observational evidence for the > dropping of IPv6 fragments along a significant number of paths, > explores the operational impact of fragmentation and the reasons why > dropping occurs, and considers the effect of fragment dropping on > applications particularly including DNS. > > > > > > The IETF Secretariat > > > > From joelja@bogus.com Mon Oct 15 20:38:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2303F21F86EA for ; Mon, 15 Oct 2012 20:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.087 X-Spam-Level: X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBtYcuDnqes2 for ; Mon, 15 Oct 2012 20:38:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 98A9621F8605 for ; Mon, 15 Oct 2012 20:38:43 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9G3cbJJ028937 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 16 Oct 2012 03:38:38 GMT (envelope-from joelja@bogus.com) Message-ID: <507CD6BC.2050006@bogus.com> Date: Mon, 15 Oct 2012 20:38:36 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: "C. M. Heard" References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 16 Oct 2012 03:38:38 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 03:38:44 -0000 On 10/15/12 7:50 PM, C. M. Heard wrote: > It's an easy read, but my reaction is: where's the beef? > > In particular, there needs to be justification of the bald assertion > in Section 2.1 that "some cases will remain where legitimate > fragments are discarded for legitimate reasons." What legitimate > reasons? Those need to be spelled out. So I have a stateless hash in front of several stateful devices. If I use the 5-tuple to hash, fragments will be dropped on the floor because by-in-large the second fragment will hash to a different device than the initial fragment (assuming the initial fragment contains the udp or tcp header). If one uses an L3-only hash that stops happening but in the 5-tuple case the dropping happens whether I deliberately filter or not. > //cmh > > On Mon, 15 Oct 2012, Tom Taylor wrote: >> This draft captures a discussion that occurred at the end of the Amsterdam >> interim meeting. It's raw, but your comments will help to bring it to >> maturity. >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt >> >> A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt >> has been successfully submitted by Tom Taylor and posted to the >> IETF repository. >> >> ... >> >> Title: Why Operators Filter Fragments and What It Implies >> ... >> Htmlized: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >> >> >> Abstract: >> This memo is written to make application developers and network >> operators aware of the significant probability that IPv6 packets >> containing fragmentation extension headers will fail to reach their >> destination. Some assumptions about the ability to use TCP or UDP >> datagrams larger than a single packet may accordingly need >> adjustment. This memo provides observational evidence for the >> dropping of IPv6 fragments along a significant number of paths, >> explores the operational impact of fragmentation and the reasons why >> dropping occurs, and considers the effect of fragment dropping on >> applications particularly including DNS. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From marka@isc.org Mon Oct 15 23:26:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53E21F8806 for ; Mon, 15 Oct 2012 23:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bft6t0lGT3b5 for ; Mon, 15 Oct 2012 23:26:52 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2E221F87FB for ; Mon, 15 Oct 2012 23:26:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B24755F989F; Tue, 16 Oct 2012 06:26:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 955F8216C7B; Tue, 16 Oct 2012 06:26:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 33DE329D6876; Tue, 16 Oct 2012 17:26:33 +1100 (EST) To: joel jaeggli From: Mark Andrews References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> In-reply-to: Your message of "Mon, 15 Oct 2012 20:38:36 PDT." <507CD6BC.2050006@bogus.com> Date: Tue, 16 Oct 2012 17:26:33 +1100 Message-Id: <20121016062633.33DE329D6876@drugs.dv.isc.org> Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:26:53 -0000 In message <507CD6BC.2050006@bogus.com>, joel jaeggli writes: > On 10/15/12 7:50 PM, C. M. Heard wrote: > > It's an easy read, but my reaction is: where's the beef? > > > > In particular, there needs to be justification of the bald assertion > > in Section 2.1 that "some cases will remain where legitimate > > fragments are discarded for legitimate reasons." What legitimate > > reasons? Those need to be spelled out. > So I have a stateless hash in front of several stateful devices. If I > use the 5-tuple to hash, fragments will be dropped on the floor because > by-in-large the second fragment will hash to a different device than > the initial fragment (assuming the initial fragment contains the udp or > tcp header). If one uses an L3-only hash that stops happening but in the > 5-tuple case the dropping happens whether I deliberately filter or not. Or one could use 5-tuple for TCP and 3-tuple everything else. > > //cmh > > > > On Mon, 15 Oct 2012, Tom Taylor wrote: > >> This draft captures a discussion that occurred at the end of the Amsterdam > >> interim meeting. It's raw, but your comments will help to bring it to > >> maturity. > >> > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt > >> > >> A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt > >> has been successfully submitted by Tom Taylor and posted to the > >> IETF repository. > >> > >> ... > >> > >> Title: Why Operators Filter Fragments and What It Implies > >> ... > >> Htmlized: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > >> > >> > >> Abstract: > >> This memo is written to make application developers and network > >> operators aware of the significant probability that IPv6 packets > >> containing fragmentation extension headers will fail to reach their > >> destination. Some assumptions about the ability to use TCP or UDP > >> datagrams larger than a single packet may accordingly need > >> adjustment. This memo provides observational evidence for the > >> dropping of IPv6 fragments along a significant number of paths, > >> explores the operational impact of fragmentation and the reasons why > >> dropping occurs, and considers the effect of fragment dropping on > >> applications particularly including DNS. > >> > >> > >> > >> > >> > >> The IETF Secretariat > >> > >> > >> > >> > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From yangtianle@chinamobile.com Mon Oct 15 23:33:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69021F89B4 for ; Mon, 15 Oct 2012 23:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIhdvJ-IK3H2 for ; Mon, 15 Oct 2012 23:33:22 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E02CE21F8909 for ; Mon, 15 Oct 2012 23:33:21 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 183B4E821; Tue, 16 Oct 2012 14:33:23 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 0BF63E6D6; Tue, 16 Oct 2012 14:33:23 +0800 (CST) Received: from yangtianle ([10.2.54.23]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012101614332193-16474 ; Tue, 16 Oct 2012 14:33:21 +0800 From: "yangtianle" To: , References: <201210151245.q9FCj0O23768@ftpeng-update.cisco.com> In-Reply-To: <201210151245.q9FCj0O23768@ftpeng-update.cisco.com> Date: Tue, 16 Oct 2012 14:33:11 +0800 Message-ID: <004501cdab68$1d164680$5742d380$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2q0vVd042RhSbRQn2x1tArPb2BXwAlHJXA X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-16 14:33:21, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-16 14:33:22, Serialize complete at 2012-10-16 14:33:22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19276.004 X-TM-AS-Result: No--15.958-7.0-31-10 X-imss-scan-details: No--15.958-7.0-31-10;No--15.958-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No X-Mailman-Approved-At: Mon, 15 Oct 2012 23:35:52 -0700 Cc: =?gb2312?B?J8DuwazUtCc=?= , =?gb2312?B?J7XLu9Qn?= Subject: Re: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:33:23 -0000 Thanks Fred helping me to broadcast the draft in the list! We find some inconvenient issues about CPE when we do IPv6 trials and experiments:=20 1=A1=A2ISP must pre-configure IPv6 transition technology in = CPE, such as dual-stack, DS-Lite, and so on. 2=A1=A2Otherwise, ISP must rely on Manage System to control = CPEs. But if CPEs are form different manufactories, they need different Manage = System, or to develop consistent interface in the Manage System. 3=A1=A2If users change the CPE ISP giving to them to another = one with incorrect configuration, or configure CPE incorrectly by mistake, they cannot access internet.=20 In this document, we propose a solution to solve the problem. But, the = most important issue is to propose this problem, not the solution. Wish for your comments. Thank you! Tianle Yang -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: fred@cisco.com [mailto:fred@cisco.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C215=C8=D5 20:45 =CA=D5=BC=FE=C8=CB: v6ops@ietf.org =B3=AD=CB=CD: draft-yang-v6ops-ipv6tran-select@tools.ietf.org =D6=F7=CC=E2: new draft: draft-yang-v6ops-ipv6tran-select A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select. Please take = a look at it and comment. From yangtianle@chinamobile.com Mon Oct 15 23:50:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7DA21F88DB for ; Mon, 15 Oct 2012 23:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2ObIrOIHfHR for ; Mon, 15 Oct 2012 23:50:52 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DAFB521F88DD for ; Mon, 15 Oct 2012 23:50:51 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 58684E828 for ; Tue, 16 Oct 2012 14:50:53 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 4F2A8E825 for ; Tue, 16 Oct 2012 14:50:53 +0800 (CST) Received: from yangtianle ([10.2.54.23]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012101614504692-17072 ; Tue, 16 Oct 2012 14:50:46 +0800 From: "yangtianle" To: Date: Tue, 16 Oct 2012 14:50:34 +0800 Message-ID: <004901cdab6a$8c91f070$a5b5d150$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2q0vVd042RhSbRQn2x1tArPb2BXwAlHJXAAADFiPA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-16 14:50:46, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-16 14:50:52, Serialize complete at 2012-10-16 14:50:52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19276.004 X-TM-AS-Result: No--15.958-7.0-31-10 X-imss-scan-details: No--15.958-7.0-31-10;No--15.958-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:50:53 -0000 We find some inconvenient issues about CPE when we do IPv6 trials and experiments:=20 1=A1=A2ISP must pre-configure IPv6 transition technology in = CPE, such as dual-stack, DS-Lite, and so on. 2=A1=A2Otherwise, ISP must rely on Manage System to control = CPEs. But if CPEs are form different manufactories, they need different Manage = System, or to develop consistent interface in the Manage System. 3=A1=A2If users change the CPE ISP giving to them to another = one with incorrect configuration, or configure CPE incorrectly by mistake, they cannot access internet.=20 In this document, we propose a solution to solve the problem. But, the = most important issue is to propose this problem, not the solution. Wish for your comments. Thank you! Tianle Yang -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: fred@cisco.com [mailto:fred@cisco.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C215=C8=D5 20:45 =CA=D5=BC=FE=C8=CB: v6ops@ietf.org =B3=AD=CB=CD: draft-yang-v6ops-ipv6tran-select@tools.ietf.org =D6=F7=CC=E2: new draft: draft-yang-v6ops-ipv6tran-select A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select. Please take = a look at it and comment. From brian.e.carpenter@gmail.com Tue Oct 16 00:07:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8695621F87B6 for ; Tue, 16 Oct 2012 00:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8JfgFZsIlNf for ; Tue, 16 Oct 2012 00:07:19 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBF321F87A5 for ; Tue, 16 Oct 2012 00:07:19 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3568732eek.31 for ; Tue, 16 Oct 2012 00:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8REhX+dwLo+ippCtaXNeytiFlQdZHwrBbp5iHt+NVfU=; b=oBYCt0IEFBetIji5hvZvDMQh34mp8zeGZHqUFt8NFI0UeFGNq5b79bX4RnQbck0QZS 6e+hOjmnrv0QR9QYH+OyACGMtym0PrjVPL/ig7U+8pctju/HwdJyNfvl5fvgYWSF0iCj hd/Rfu659Qi7WYPBXdKqdfCmBwAjsA9ES7UPIRSpINWJe5AIQB/3J43AEXlVAzG2o2Ug e6IdFC54uT0vv7osVN6qpYmi5/69NfulqyWDDZrF5swMd9FcxltWLP1BJ8kay93rat1N b/qKSVvrx76DhSfwQZUdQz+XT/XeEZpcYzWxYVOsWcETt3gsw3ADgnHSMqKqN0SXQ3+9 7aZQ== Received: by 10.14.213.65 with SMTP id z41mr19206333eeo.29.1350371233657; Tue, 16 Oct 2012 00:07:13 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-15.as13285.net. [2.102.218.15]) by mx.google.com with ESMTPS id i41sm28435988eem.7.2012.10.16.00.07.10 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 00:07:12 -0700 (PDT) Message-ID: <507D079C.1000405@gmail.com> Date: Tue, 16 Oct 2012 08:07:08 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> In-Reply-To: <20121016062633.33DE329D6876@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 07:07:20 -0000 On 16/10/2012 07:26, Mark Andrews wrote: > In message <507CD6BC.2050006@bogus.com>, joel jaeggli writes: >> On 10/15/12 7:50 PM, C. M. Heard wrote: >>> It's an easy read, but my reaction is: where's the beef? >>> >>> In particular, there needs to be justification of the bald assertion >>> in Section 2.1 that "some cases will remain where legitimate >>> fragments are discarded for legitimate reasons." What legitimate >>> reasons? Those need to be spelled out. >> So I have a stateless hash in front of several stateful devices. If I >> use the 5-tuple to hash, fragments will be dropped on the floor because >> by-in-large the second fragment will hash to a different device than >> the initial fragment (assuming the initial fragment contains the udp or >> tcp header). If one uses an L3-only hash that stops happening but in the >> 5-tuple case the dropping happens whether I deliberately filter or not. > > Or one could use 5-tuple for TCP and 3-tuple everything else. Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438. Brian > >>> //cmh >>> >>> On Mon, 15 Oct 2012, Tom Taylor wrote: >>>> This draft captures a discussion that occurred at the end of the Amsterdam >>>> interim meeting. It's raw, but your comments will help to bring it to >>>> maturity. >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt >>>> >>>> A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt >>>> has been successfully submitted by Tom Taylor and posted to the >>>> IETF repository. >>>> >>>> ... >>>> >>>> Title: Why Operators Filter Fragments and What It Implies >>>> ... >>>> Htmlized: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >>>> >>>> >>>> Abstract: >>>> This memo is written to make application developers and network >>>> operators aware of the significant probability that IPv6 packets >>>> containing fragmentation extension headers will fail to reach their >>>> destination. Some assumptions about the ability to use TCP or UDP >>>> datagrams larger than a single packet may accordingly need >>>> adjustment. This memo provides observational evidence for the >>>> dropping of IPv6 fragments along a significant number of paths, >>>> explores the operational impact of fragmentation and the reasons why >>>> dropping occurs, and considers the effect of fragment dropping on >>>> applications particularly including DNS. >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Oct 16 00:24:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E521F8802 for ; Tue, 16 Oct 2012 00:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.079 X-Spam-Level: X-Spam-Status: No, score=-102.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyowcrlKTFfX for ; Tue, 16 Oct 2012 00:24:03 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C9DF621F880B for ; Tue, 16 Oct 2012 00:24:00 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9G7Ns5T031605 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 16 Oct 2012 07:23:55 GMT (envelope-from joelja@bogus.com) Message-ID: <507D0B8A.2070201@bogus.com> Date: Tue, 16 Oct 2012 00:23:54 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> In-Reply-To: <507D079C.1000405@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 16 Oct 2012 07:23:55 +0000 (UTC) Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 07:24:04 -0000 On 10/16/12 12:07 AM, Brian E Carpenter wrote: > On 16/10/2012 07:26, Mark Andrews wrote: >> In message <507CD6BC.2050006@bogus.com>, joel jaeggli writes: >>> On 10/15/12 7:50 PM, C. M. Heard wrote: >>>> It's an easy read, but my reaction is: where's the beef? >>>> >>>> In particular, there needs to be justification of the bald assertion >>>> in Section 2.1 that "some cases will remain where legitimate >>>> fragments are discarded for legitimate reasons." What legitimate >>>> reasons? Those need to be spelled out. >>> So I have a stateless hash in front of several stateful devices. If I >>> use the 5-tuple to hash, fragments will be dropped on the floor because >>> by-in-large the second fragment will hash to a different device than >>> the initial fragment (assuming the initial fragment contains the udp or >>> tcp header). If one uses an L3-only hash that stops happening but in the >>> 5-tuple case the dropping happens whether I deliberately filter or not. >> Or one could use 5-tuple for TCP and 3-tuple everything else. > Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438. it's mostly 0. > Brian > >> >>>> //cmh >>>> >>>> On Mon, 15 Oct 2012, Tom Taylor wrote: >>>>> This draft captures a discussion that occurred at the end of the Amsterdam >>>>> interim meeting. It's raw, but your comments will help to bring it to >>>>> maturity. >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt >>>>> >>>>> A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt >>>>> has been successfully submitted by Tom Taylor and posted to the >>>>> IETF repository. >>>>> >>>>> ... >>>>> >>>>> Title: Why Operators Filter Fragments and What It Implies >>>>> ... >>>>> Htmlized: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >>>>> >>>>> >>>>> Abstract: >>>>> This memo is written to make application developers and network >>>>> operators aware of the significant probability that IPv6 packets >>>>> containing fragmentation extension headers will fail to reach their >>>>> destination. Some assumptions about the ability to use TCP or UDP >>>>> datagrams larger than a single packet may accordingly need >>>>> adjustment. This memo provides observational evidence for the >>>>> dropping of IPv6 fragments along a significant number of paths, >>>>> explores the operational impact of fragmentation and the reasons why >>>>> dropping occurs, and considers the effect of fragment dropping on >>>>> applications particularly including DNS. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Tue Oct 16 01:01:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3521F883E for ; Tue, 16 Oct 2012 01:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+2CbWErhzfD for ; Tue, 16 Oct 2012 01:01:20 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5F21F8827 for ; Tue, 16 Oct 2012 01:01:19 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3596585eek.31 for ; Tue, 16 Oct 2012 01:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JF8Gghv2vbdSdTELOFTBrypKuDp3ewBcMSzUG3bdFMI=; b=Nr+lC0X+QJX1+lTpmFqpDBTk1QPqGTmw68QIdhCgspuUj245r8rREU3DwONtveBfzd 1itZfHYIjNSSdqNrIoAin3F3jnu860AjRMgl1InvjzuWVNuHe9WSVPcli7HsdXVrhXrg xVs5JkalYtsHCF/wPXtI+AONcc3WDmrFtWlUeZ78O57+TIF8hdnSCoLUn9F8Phnj2401 pDwCkyoUVottbC7pXXT91ZhQDxW3FKZopEsK3/ZC4bPdPKL+kZHgsGMTOxfkxdL46KiR 6vT/MAJedItqP76s9KTUWPDc2yJ6fD+1gA6NR+86wj4JX4NFehaXxCphH+jiD2PwgbEm BNGA== Received: by 10.14.199.134 with SMTP id x6mr19718548een.31.1350374479111; Tue, 16 Oct 2012 01:01:19 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id 42sm28643108eee.0.2012.10.16.01.01.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:01:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <201210151245.q9FCj0123762@ftpeng-update.cisco.com> Date: Tue, 16 Oct 2012 11:01:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210151245.q9FCj0123762@ftpeng-update.cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] new draft: draft-korhonen-v6ops-rfc3316bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:01:21 -0000 Folks, We though it is about time to update RFC3316 (IPv6 for some 2G and 3G = cellular hosts). The draft follows the path of the original RFC but now leaves a lot of = the day-to-day IPv6 stuff to RFC6434 to care of. Appendix B details the changes = (excluding editorials like shoveling 4G terminology in) to RFC3316. Feedback is very much appreciated.=20 - Jouni (and the rest of the author team) On Oct 15, 2012, at 3:45 PM, wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-korhonen-v6ops-rfc3316bis. Please take = a look at it and comment. From brian.e.carpenter@gmail.com Tue Oct 16 02:25:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAEE21F8803 for ; Tue, 16 Oct 2012 02:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsWVh0xo+Xef for ; Tue, 16 Oct 2012 02:25:28 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4CF21F87B0 for ; Tue, 16 Oct 2012 02:25:27 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2720873bkc.31 for ; Tue, 16 Oct 2012 02:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lBcdgA4QTzPbp0kn+ykvqd+nPdNjJfPQjrQ1bP5xRUA=; b=DvV46u0XvRlHO8YzJrOBBjpVGvT+6h1cKRJTcNbUY2MgqSBbfRriH9VAytV9k5AWUQ BCaqc4Bcj/XPONqDr/laA0Stx0jf7o/CR4QF0uGbFP/7xrIFoWaMKgUkAeF0WvTHeG++ CiDdJyVdSIprn8dhLljlEdhOeZkVQRC9juOeRt93pGKRFG3bFTi/P8gLfwFcKZC19OBP sM9SF8LR37kgKayTf3zEsXhRryodJxLPOcD27iDPJKv4J108jqMt1A6eia1XjvcjFC+g +O3puiyKJCqHZ3t75OfVEEek5Y1JMu6oMa5vaMRfGomvXkXxdkBPqcsJ2BUChVNZWyhU D6FA== Received: by 10.204.10.74 with SMTP id o10mr3960648bko.9.1350379526684; Tue, 16 Oct 2012 02:25:26 -0700 (PDT) Received: from [128.232.110.214] (c214.al.cl.cam.ac.uk. [128.232.110.214]) by mx.google.com with ESMTPS id e3sm9969518bks.7.2012.10.16.02.25.24 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 02:25:25 -0700 (PDT) Message-ID: <507D2807.60609@gmail.com> Date: Tue, 16 Oct 2012 10:25:27 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <507D0B8A.2070201@bogus.com> In-Reply-To: <507D0B8A.2070201@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:25:28 -0000 On 16/10/2012 08:23, joel jaeggli wrote: > On 10/16/12 12:07 AM, Brian E Carpenter wrote: >> On 16/10/2012 07:26, Mark Andrews wrote: >>> In message <507CD6BC.2050006@bogus.com>, joel jaeggli writes: >>>> On 10/15/12 7:50 PM, C. M. Heard wrote: >>>>> It's an easy read, but my reaction is: where's the beef? >>>>> >>>>> In particular, there needs to be justification of the bald assertion >>>>> in Section 2.1 that "some cases will remain where legitimate >>>>> fragments are discarded for legitimate reasons." What legitimate >>>>> reasons? Those need to be spelled out. >>>> So I have a stateless hash in front of several stateful devices. If I >>>> use the 5-tuple to hash, fragments will be dropped on the floor because >>>> by-in-large the second fragment will hash to a different device than >>>> the initial fragment (assuming the initial fragment contains the udp or >>>> tcp header). If one uses an L3-only hash that stops happening but in >>>> the >>>> 5-tuple case the dropping happens whether I deliberately filter or not. >>> Or one could use 5-tuple for TCP and 3-tuple everything else. >> Use the flow label. This is one of the reasons we did RFC 6436, 6437 >> and 6438. > it's mostly 0. Right. So it's time to start leaning on o/s and router vendors to support it. I don't think there's another long-term solution to this. (There's a related issue, covered in draft-carpenter-6man-ext-transmit, which also needs fixing by vendors.) Brian >> Brian >> >>> >>>>> //cmh >>>>> >>>>> On Mon, 15 Oct 2012, Tom Taylor wrote: >>>>>> This draft captures a discussion that occurred at the end of the >>>>>> Amsterdam >>>>>> interim meeting. It's raw, but your comments will help to bring it to >>>>>> maturity. >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: New Version Notification for >>>>>> draft-taylor-v6ops-fragdrop-00.txt >>>>>> >>>>>> A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt >>>>>> has been successfully submitted by Tom Taylor and posted to the >>>>>> IETF repository. >>>>>> >>>>>> ... >>>>>> >>>>>> Title: Why Operators Filter Fragments and What It Implies >>>>>> ... >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This memo is written to make application developers and network >>>>>> operators aware of the significant probability that IPv6 packets >>>>>> containing fragmentation extension headers will fail to reach >>>>>> their >>>>>> destination. Some assumptions about the ability to use TCP >>>>>> or UDP >>>>>> datagrams larger than a single packet may accordingly need >>>>>> adjustment. This memo provides observational evidence for the >>>>>> dropping of IPv6 fragments along a significant number of paths, >>>>>> explores the operational impact of fragmentation and the >>>>>> reasons why >>>>>> dropping occurs, and considers the effect of fragment >>>>>> dropping on >>>>>> applications particularly including DNS. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops > > From despres.remi@laposte.net Tue Oct 16 02:31:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D28C21F88A2; Tue, 16 Oct 2012 02:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iJdJF89oTPf; Tue, 16 Oct 2012 02:31:45 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 272DE21F8899; Tue, 16 Oct 2012 02:31:45 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id DBF8870001A2; Tue, 16 Oct 2012 11:31:43 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2302.sfr.fr (SMTP Server) with ESMTP id AD4BD700019C; Tue, 16 Oct 2012 11:31:43 +0200 (CEST) X-SFR-UUID: 20121016093143709.AD4BD700019C@msfrf2302.sfr.fr Mime-Version: 1.0 (Apple Message framework v1085) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= Date: Tue, 16 Oct 2012 11:31:43 +0200 Message-Id: References: <20121015181509.C4615B1E002@rfc-editor.org> To: Softwires WG X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: [v6ops] FYI - RFC 6751 available - Native IPv6 behind NAT44s (6a44) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 09:31:46 -0000 Hello all, RFC 6751 is now available at http://tools.ietf.org/html/rfc6751). It describes a new tunneling solution for providers to offer IPv6 = service behind IPv4-only CPEs. Like 6rd, 6a44 is a provider-local = solution using provider allocated prefixes. As such, it has over Teredo = an advantage similar to that of 6rd over 6to4.=20 Because it couldn't fit in any WG scope, and in order to avoid too long = a delay, the choice has been to submit it in the independent stream, and = consequently with experimental status.=20 In view of its obvious commonality with Softwire solutions, drawing = attention of this WG to its existence is expected to be useful.=20 This is ONLY for information, NOT to start any discussion here. =20 Regards, RD > RFC 6751 >=20 > Title: Native IPv6 behind IPv4-to-IPv4 NAT=20 > Customer Premises Equipment (6a44)=20 > Author: R. Despres, Ed., B. Carpenter,=20 > D. Wing, S. Jiang > Status: Experimental > Stream: Independent > Date: October 2012=20 > Mailbox: despres.remi@laposte.net,=20 > brian.e.carpenter@gmail.com,=20 > dwing@cisco.com, shengjiang@huawei.com From gert@space.net Tue Oct 16 04:21:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3E21F885C for ; Tue, 16 Oct 2012 04:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eGb4VgJSoBU for ; Tue, 16 Oct 2012 04:21:55 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id A1DF221F887B for ; Tue, 16 Oct 2012 04:21:39 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 37D9EF8DD0 for ; Tue, 16 Oct 2012 13:21:38 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 024C4F8CBE for ; Tue, 16 Oct 2012 13:21:37 +0200 (CEST) Received: (qmail 99412 invoked by uid 1007); 16 Oct 2012 13:21:37 +0200 Date: Tue, 16 Oct 2012 13:21:37 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20121016112137.GG13776@Space.Net> References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507D079C.1000405@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:21:56 -0000 Hi, On Tue, Oct 16, 2012 at 08:07:08AM +0100, Brian E Carpenter wrote: > Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438. So how exactly is "filter based on an arbitrary value the attacker can control" better than "just let non-initial fragments through"? Which is what I'd do - either reassemble at the (stateful) firewall, or let non-initial fragments pass. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From warren@kumari.net Tue Oct 16 05:27:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A34C21F8818 for ; Tue, 16 Oct 2012 05:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i2B636Fq5d3 for ; Tue, 16 Oct 2012 05:27:02 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA29E21F8814 for ; Tue, 16 Oct 2012 05:27:02 -0700 (PDT) Received: from [10.196.196.235] (1-193.icannmeeting.org [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 0EE651B40038; Tue, 16 Oct 2012 08:27:02 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: <20121016112137.GG13776@Space.Net> Date: Tue, 16 Oct 2012 08:27:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1498) Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:27:03 -0000 On Oct 16, 2012, at 7:21 AM, Gert Doering wrote: > Hi, >=20 > On Tue, Oct 16, 2012 at 08:07:08AM +0100, Brian E Carpenter wrote: >> Use the flow label. This is one of the reasons we did RFC 6436, 6437 = and 6438. >=20 > So how exactly is "filter based on an arbitrary value the attacker can > control" better than "just let non-initial fragments through"? >=20 > Which is what I'd do - either reassemble at the (stateful) firewall, Reassembly at "firewalls" is wickedly expensive (in terms of CPU, = memory, etc) and often end up as bottlenecks under things like missing = fragment / incomplete fragment attacks. Also, this is assuming that = there is a stateful firewall somewhere between the Internet and your = network -- for many many people this is not true (or really possible). > or let non-initial fragments pass. Or drop them=85 W >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they = can talk but choose not to do so in case humans put them to work, = possibly in the television industry. In fact they can talk. It's just = that they talk in Orang-utan. Humans are only capable of listening in = Bewilderment. -- Terry Practhett From fred@cisco.com Tue Oct 16 05:45:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D521F8986 for ; Tue, 16 Oct 2012 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNY8IvzLVzia for ; Tue, 16 Oct 2012 05:45:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2732A21F897A for ; Tue, 16 Oct 2012 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1350391502; x=1351601102; h=date:from:message-id:to:subject:cc; bh=2X+VKDHhAar12x0oIO8kYzBfkmtYslxbesfnfUTQWxM=; b=i4UB2qf6puQ4sq3Jx1stOx4K897ylk91Iig7T68LqN7IiGF+6htBcBUA Ip4ZuhxBZTByVbrzhUGJ1tDxJPwdZv8CVC2bIT/pS0c2zpPxFLXtTHo1v p4Xr64QFf2skTENOtqmKRqUNeJPaf8zs0eG0rH37dBVzlI1hLFKrlXW7l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUOADtWfVCrRDoH/2dsb2JhbABFhUuoawGQQwQDgQGBCII5AWY8LYEKh2EMm2OPXJBNjmuDIQOIWI4ojTKBa4MN X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="61380759" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Oct 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9GCj0UW022509; Tue, 16 Oct 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q9GCj0i26478; Tue, 16 Oct 2012 05:45:00 -0700 (PDT) Date: Tue, 16 Oct 2012 05:45:00 -0700 (PDT) From: Message-Id: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-taylor-v6ops-fragdrop@tools.ietf.org Subject: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please take a look at it and comment. From fred@cisco.com Tue Oct 16 05:45:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25C221F897A for ; Tue, 16 Oct 2012 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF-2RSDdMnnc for ; Tue, 16 Oct 2012 05:45:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 07DA121F87CC for ; Tue, 16 Oct 2012 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=151; q=dns/txt; s=iport; t=1350391502; x=1351601102; h=date:from:message-id:to:subject:cc; bh=UYB+2AVsk685f9Yr4fWs9T0D8Dlxm1+3QP8g10PZ9n0=; b=MbIl8u291yWvw4dduYPJpT4OEau5FK0SFvJnpkq6qpCkbcfO7oT6cQF3 gg5XKUa/seHbzH1G9spftAtDPQ+ApE+OHDAVX6d/qjdljKtzY0kr0PK+H sWovrCe6XVAsac2JjSIpmwbqRgDDzFWTCEKFfI1m/vzHlFA3fiA6arKZS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHADtWfVCrRDoI/2dsb2JhbABFhUuoawGRS4EIgjkBZjwtgQqHYQybY49ckE2Oa4MhA4hYjiiNMoFrgw0 X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="61380758" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 16 Oct 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9GCj0fc018653; Tue, 16 Oct 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q9GCj0q26472; Tue, 16 Oct 2012 05:45:00 -0700 (PDT) Date: Tue, 16 Oct 2012 05:45:00 -0700 (PDT) From: Message-Id: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-gont-v6ops-slaac-issues-with-duplicate-macs@tools.ietf.org Subject: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-gont-v6ops-slaac-issues-with-duplicate-macs. Please take a look at it and comment. From gert@space.net Tue Oct 16 05:49:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD421F87E3 for ; Tue, 16 Oct 2012 05:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiHwpdys9SEa for ; Tue, 16 Oct 2012 05:49:10 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8CE21F87CC for ; Tue, 16 Oct 2012 05:49:10 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1899CF8DD0 for ; Tue, 16 Oct 2012 14:49:08 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id DB587F8DC5 for ; Tue, 16 Oct 2012 14:49:07 +0200 (CEST) Received: (qmail 38727 invoked by uid 1007); 16 Oct 2012 14:49:07 +0200 Date: Tue, 16 Oct 2012 14:49:07 +0200 From: Gert Doering To: Warren Kumari Message-ID: <20121016124907.GL13776@Space.Net> References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c8PmD5NyUxGbkWJr" Content-Disposition: inline In-Reply-To: <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:49:11 -0000 --c8PmD5NyUxGbkWJr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote: > > or let non-initial fragments pass. > Or drop them? If you want to break other people's communication, that's the way forward. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --c8PmD5NyUxGbkWJr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUH1Xw6kuBuNlUUl1AQJxRQQAqqdLXzT3ukBFPTKT/CAK28XapdHMOSHm /IqnCC3NUcPQzsjqLDpAN/jUaqjuuzRXOPwpEs6HNnM0EI0jK1mynlXbZ9YtJ2ag 0P4hKhC66gtP9HCsdZnh+L/OmEw/nFGvkyLt8Rw9Qkfz8zXBe0zi8JElOKzGB1WH P2w+DSHEano= =grU7 -----END PGP SIGNATURE----- --c8PmD5NyUxGbkWJr-- From ipepelnjak@gmail.com Tue Oct 16 06:11:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0CA21F88B3 for ; Tue, 16 Oct 2012 06:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkOT3UQyI6e9 for ; Tue, 16 Oct 2012 06:11:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6E21F88A7 for ; Tue, 16 Oct 2012 06:11:13 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4791127lbo.31 for ; Tue, 16 Oct 2012 06:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=4b39NF+urngCCCEWR0t6qe4D+EPR9cSwT7QWTTFHig4=; b=HCq/fUgWJGo51LPmtdXZ5q/J66mkz9XJit5+H+4sfuJX4dUAGef3y8vaRQlDz3MZuo Ens37XKjeDtxjiIjxbgCAzuwrGJQNKAIoQI0eh18fSU2dZ1tMhNYX10DWLT9ZEkTCt+5 epFHtDGmeYWQqpQ6RkZgJ2nCB02kRKBo3oa4W8i8w6VAYiX2VDGPAoVbhwRKgcSdAau5 llztdU17Ar1rfFK6Zmfd2BVnTbrnSX5Px8kFs05ZTsotdJ3SsYt3KNhGrSeGNR3dyjzd WFYynMKQHlyaVTlhUCTgddd1mLUBUpKWQ/0MuldNz4eRTch2VqUX4zGmxU7CikEoKoH1 cXmg== Received: by 10.112.29.9 with SMTP id f9mr732032lbh.22.1350393072023; Tue, 16 Oct 2012 06:11:12 -0700 (PDT) Received: from Ivans-MacBook-Air.local ([193.110.145.6]) by mx.google.com with ESMTPS id lv1sm4505614lab.14.2012.10.16.06.11.10 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 06:11:11 -0700 (PDT) Message-ID: <507D5CED.5060805@gmail.com> Date: Tue, 16 Oct 2012 15:11:09 +0200 From: Ivan Pepelnjak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gert Doering References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> In-Reply-To: <20121016124907.GL13776@Space.Net> Content-Type: multipart/alternative; boundary="------------000405010200020607040900" Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:11:18 -0000 This is a multi-part message in MIME format. --------------000405010200020607040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It's (probably ... until Fernando figures a way to hack it) safe to pass fragments without extension headers other than fragmentation header. It's also (probably) safe to drop non-initial fragments with extension headers (apart from the fragmentation header). If someone generates enough extension headers to overflow the minimum MTU, he has a problem anyway. Am I missing something? Ivan On 10/16/12 2:49 PM, Gert Doering wrote: > Hi, > > On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote: >>> or let non-initial fragments pass. >> Or drop them? > If you want to break other people's communication, that's the way forward. > > Gert Doering > -- NetMaster > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------000405010200020607040900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It's (probably ... until Fernando figures a way to hack it) safe to pass fragments without extension headers other than fragmentation header.

It's also (probably) safe to drop non-initial fragments with extension headers (apart from the fragmentation header). If someone generates enough extension headers to overflow the minimum MTU, he has a problem anyway.

Am I missing something?
Ivan

On 10/16/12 2:49 PM, Gert Doering wrote: 
Hi,

On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote:

or let non-initial fragments pass.

Or drop them?

If you want to break other people's communication, that's the way forward.

Gert Doering
        -- NetMaster



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------000405010200020607040900-- From tom.taylor.stds@gmail.com Tue Oct 16 07:06:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A844F21F887F for ; Tue, 16 Oct 2012 07:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyM6d9i8gFin for ; Tue, 16 Oct 2012 07:06:37 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0368921F8873 for ; Tue, 16 Oct 2012 07:06:36 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so11334417iec.31 for ; Tue, 16 Oct 2012 07:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=dKpRfsKXDwudvUFopl4VFjN4VTrQWJOAp4ZuOpLdS6I=; b=S6S8oqx9iIMKFpM7WxvZvZu5WUhTAqGOkN+DZMmkyjS83Ub0fkRZYRyLFKSW8VW/Xd voK1Cu/V+uxkpyE3VBwysFZAuzqBBsN7aR2F6jxsVa3gH8MkHJ3WJWLxZUFfFxqZbAlf 7pptm0wauE6teFUX8ap/c8NvNYfm40zR6NIBya5aAm5LUYaPbaPprPmDCdvkIRyBEHXI oeDKYJ2m0a5Q9ga2G+aX1qz5uitcOMcU32FXgTbf7YuYqWV02CDyc9Usa0/Vej4Vv8sO dlcbDtkuglRshcvMn7HbU8lmEOoaBq3aPedOTgbrhz3LUkcWhdu5PR0zwqb98dxNaXeq wLyg== Received: by 10.50.5.205 with SMTP id u13mr6236837igu.37.1350396396362; Tue, 16 Oct 2012 07:06:36 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.149]) by mx.google.com with ESMTPS id 7sm8477585igh.0.2012.10.16.07.06.34 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 07:06:35 -0700 (PDT) Message-ID: <507D69EB.90006@gmail.com> Date: Tue, 16 Oct 2012 10:06:35 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ivan Pepelnjak References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> <507D5CED.5060805@gmail.com> In-Reply-To: <507D5CED.5060805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121016-0, 16/10/2012), Outbound message X-Antivirus-Status: Clean Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:06:37 -0000 I expect overlapping fragments need to be handled with great care wherever the packet is reassembled. In particular it would be wrong to overwrite L4 headers. On 16/10/2012 9:11 AM, Ivan Pepelnjak wrote: > It's (probably ... until Fernando figures a way to hack it) safe to pass > fragments without extension headers other than fragmentation header. > > It's also (probably) safe to drop non-initial fragments with extension > headers (apart from the fragmentation header). If someone generates > enough extension headers to overflow the minimum MTU, he has a problem > anyway. > > Am I missing something? > Ivan > From ipepelnjak@gmail.com Tue Oct 16 07:12:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D996921F8899 for ; Tue, 16 Oct 2012 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjIkmz5itJne for ; Tue, 16 Oct 2012 07:12:53 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44921F888F for ; Tue, 16 Oct 2012 07:12:53 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2893532bkc.31 for ; Tue, 16 Oct 2012 07:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IhN+FPE87U7TksSHTJuXHnE9+MNLtSpSgoc5qDwqXJ4=; b=ei5KRJ174775YBMqoDUMpo701mnlTQFeVwqXHy+ATLGXqvQDe/K6TdJYxet3q49qFO uWAEUqHN2b+sNR+F2vINl0fNNOH9rQJr4IpV8Ni/FehZzJLRqkeNYTlZhtoAQKL7sfn/ I9ypiV+GKKqeEw8DKZVdGWb0P1h0gRVT327ibXYAb6oSva7W+Yynu9PBXfV4ognNlH/g 0wjKrXAClZW/Tndt/A7e7jicJFF6zVm+Z0BI7jT1Uc2x6UdzYHFPTxJ4EaR5xLbx8R21 FmyIXRC0WKzVgQGsZvJsryDd3lNqr8yyqPGtYAbT/CdbZ8jHAhzuE5WENmuvHfK311tA zB8A== Received: by 10.204.128.155 with SMTP id k27mr4086326bks.26.1350396771934; Tue, 16 Oct 2012 07:12:51 -0700 (PDT) Received: from Ivans-MacBook-Air.local ([84.41.102.176]) by mx.google.com with ESMTPS id e13sm10853947bkw.12.2012.10.16.07.12.49 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 07:12:50 -0700 (PDT) Message-ID: <507D6B60.6000201@gmail.com> Date: Tue, 16 Oct 2012 16:12:48 +0200 From: Ivan Pepelnjak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Taylor References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> <507D5CED.5060805@gmail.com> <507D69EB.90006@gmail.com> In-Reply-To: <507D69EB.90006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:12:54 -0000 That SHOULD be covered by RFC 5722. No idea whether the IPv6 stacks do that ... but then if the host is perfectly secured, we don't need to discuss packet filters, do we ;) On 10/16/12 4:06 PM, Tom Taylor wrote: > I expect overlapping fragments need to be handled with great care > wherever the packet is reassembled. In particular it would be wrong to > overwrite L4 headers. > > On 16/10/2012 9:11 AM, Ivan Pepelnjak wrote: >> It's (probably ... until Fernando figures a way to hack it) safe to pass >> fragments without extension headers other than fragmentation header. >> >> It's also (probably) safe to drop non-initial fragments with extension >> headers (apart from the fragmentation header). If someone generates >> enough extension headers to overflow the minimum MTU, he has a problem >> anyway. >> >> Am I missing something? >> Ivan >> From joelja@bogus.com Tue Oct 16 08:33:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1921F89A9 for ; Tue, 16 Oct 2012 08:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.128 X-Spam-Level: X-Spam-Status: No, score=-102.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr0KBml2P7En for ; Tue, 16 Oct 2012 08:33:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8921F8994 for ; Tue, 16 Oct 2012 08:33:12 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9GFXAP0036013 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 16 Oct 2012 15:33:11 GMT (envelope-from joelja@bogus.com) Message-ID: <507D7E31.9080703@bogus.com> Date: Tue, 16 Oct 2012 08:33:05 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: Gert Doering References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> In-Reply-To: <20121016124907.GL13776@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 16 Oct 2012 15:33:11 +0000 (UTC) Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 15:33:12 -0000 On 10/16/12 5:49 AM, Gert Doering wrote: > Hi, > > On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote: >>> or let non-initial fragments pass. >> Or drop them? > If you want to break other people's communication, that's the way forward. I think the point the of the draft is not to point out that this is desirable, but rather that some people who are doing this lack palatable alternatives. > Gert Doering > -- NetMaster > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Oct 16 08:39:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1629621F8848 for ; Tue, 16 Oct 2012 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.683 X-Spam-Level: X-Spam-Status: No, score=-101.683 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwFOvZVo7Qh5 for ; Tue, 16 Oct 2012 08:39:37 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64C5721F8845 for ; Tue, 16 Oct 2012 08:39:37 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2948774bkc.31 for ; Tue, 16 Oct 2012 08:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mPDASqTYFB1d+GYOyFUU2ig5euLOVaDbJOl90to0T9g=; b=d0Uo85AACccUGg9YKsXsCgbBpQ7Ca6ZvBxfCeveAPzyXLJVoES4Ka9/IaPsbWCen85 ExRE+hrHXeg6+pIoHW+S7eliFa4O5XM0WiqChTzvETsQbyz8Pc6cBdq8o70SV2JW0NdN TPSVtbQinh8HFeoemu78Um0Bg/BvKINHgY5i5oRX8xjS1UdGh8AK54TLlgMktw+Rb7bA yNC29MN1fyVIttd3Y0r1XDsb/Qk7VlB7QcpFFhOYqhhTd+p/nBUZfW9nkkugn5AyKMsc eOkVJrYfdPmbuYyvG7xmo9KQKtM7y5Leq3c/RkePKvynPRzWaViz688Fu8yZ28vqhXLS B36Q== Received: by 10.204.147.5 with SMTP id j5mr4389617bkv.21.1350401976540; Tue, 16 Oct 2012 08:39:36 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-15.as13285.net. [2.102.218.15]) by mx.google.com with ESMTPS id ht18sm11146325bkc.14.2012.10.16.08.39.33 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:39:34 -0700 (PDT) Message-ID: <507D7FB8.8020601@gmail.com> Date: Tue, 16 Oct 2012 16:39:36 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ivan Pepelnjak References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> <507D5CED.5060805@gmail.com> In-Reply-To: <507D5CED.5060805@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 15:39:38 -0000 On 16/10/2012 14:11, Ivan Pepelnjak wrote: > It's (probably ... until Fernando figures a way to hack it) safe to pass > fragments without extension headers other than fragmentation header. > > It's also (probably) safe to drop non-initial fragments with extension > headers (apart from the fragmentation header). If someone generates > enough extension headers to overflow the minimum MTU, he has a problem > anyway. > > Am I missing something? Only the fact that to allow innovation, all middleboxes need to be transparent to newly defined extension headers that they don't know about. I tend to agree that very long extension headers are probably not a good idea, but we can't predict all future innovations. Of course, if we think that innovation on the Internet is a bad thing, that's another matter. Brian > Ivan > > On 10/16/12 2:49 PM, Gert Doering wrote: >> Hi, >> >> On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote: >>>> or let non-initial fragments pass. >>> Or drop them? >> If you want to break other people's communication, that's the way >> forward. >> >> Gert Doering >> -- NetMaster >> >> From heard@pobox.com Tue Oct 16 08:50:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DF721F89E0 for ; Tue, 16 Oct 2012 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnY4VMXTyT0w for ; Tue, 16 Oct 2012 08:50:37 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776CC21F89DF for ; Tue, 16 Oct 2012 08:50:37 -0700 (PDT) Received: (qmail 31709 invoked from network); 16 Oct 2012 08:50:37 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Oct 2012 08:50:37 -0700 Date: Tue, 16 Oct 2012 08:50:36 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Ops WG In-Reply-To: <507D7E31.9080703@bogus.com> Message-ID: References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> <507D7E31.9080703@bogus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 15:50:38 -0000 On Tue, 16 Oct 2012, joel jaeggli wrote: > On 10/16/12 5:49 AM, Gert Doering wrote: > > On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote: > > > > or let non-initial fragments pass. > > > Or drop them? > > If you want to break other people's communication, that's the way forward. > I think the point the of the draft is not to point out that this is desirable, > but rather that some people who are doing this lack palatable alternatives. I agree that is the point the draft is trying to make. My complaint is that it does not justify the assertion that some people who are doing this lack palatable alternatives (e.g., by specifying what credible threats are mitigated by dropping non-initial fragments). //cmh From joelja@bogus.com Tue Oct 16 09:23:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AC21F8743 for ; Tue, 16 Oct 2012 09:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.132 X-Spam-Level: X-Spam-Status: No, score=-102.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsE-3p0Ok9Kt for ; Tue, 16 Oct 2012 09:23:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7171B21F8740 for ; Tue, 16 Oct 2012 09:23:54 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9GGNqhQ036714 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 16 Oct 2012 16:23:54 GMT (envelope-from joelja@bogus.com) Message-ID: <507D8A14.4020702@bogus.com> Date: Tue, 16 Oct 2012 09:23:48 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: "C. M. Heard" References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> <507D7E31.9080703@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 16 Oct 2012 16:23:54 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:23:55 -0000 On 10/16/12 8:50 AM, C. M. Heard wrote: > On Tue, 16 Oct 2012, joel jaeggli wrote: >> On 10/16/12 5:49 AM, Gert Doering wrote: >>> On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote: >>>>> or let non-initial fragments pass. >>>> Or drop them? >>> If you want to break other people's communication, that's the way forward. >> I think the point the of the draft is not to point out that this is desirable, >> but rather that some people who are doing this lack palatable alternatives. > I agree that is the point the draft is trying to make. My complaint > is that it does not justify the assertion that some people who are > doing this lack palatable alternatives (e.g., by specifying what > credible threats are mitigated by dropping non-initial fragments). The authors are taking feedback and working on more text. it's clearly incompletely described in present form. Where we go from here operationally is an interesting question, As brian points out there are some changes that could be made to improve the sitaution. > //cmh > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From kawashimam@vx.jp.nec.com Tue Oct 16 09:46:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BE321F8A06 for ; Tue, 16 Oct 2012 09:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqewMWZd+MRJ for ; Tue, 16 Oct 2012 09:46:51 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by ietfa.amsl.com (Postfix) with ESMTP id E175521F8A02 for ; Tue, 16 Oct 2012 09:46:50 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q9GGklFd005990; Wed, 17 Oct 2012 01:46:48 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q9GGklm22613; Wed, 17 Oct 2012 01:46:47 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q9GGklHK024608; Wed, 17 Oct 2012 01:46:47 +0900 (JST) Received: from genzui.jp.nec.com ([10.26.220.13] [10.26.220.13]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-2018087; Wed, 17 Oct 2012 01:45:54 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-509; Wed, 17 Oct 2012 01:45:54 +0900 To: "yangtianle" In-reply-to: <004901cdab6a$8c91f070$a5b5d150$@com> References: <004901cdab6a$8c91f070$a5b5d150$@com> Message-Id: <20121017014554kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.68 Step12] From: Masanobu Kawashima Date: Wed, 17 Oct 2012 01:45:51 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:46:52 -0000 Hi Tianle, I support this draft. This draft is useful to CPE vendors, especially retail product. Just for your reference, we can use DHCPv6 option in PPPv6oE network. In short, DHCPv6 over PPPv6oE works well now. However, it's necessary to discuss the situation that DHCPv6 is not provided. >In this document, we propose a solution to solve the problem. But, the most >important issue is to propose this problem, not the solution. I agree with your thoughts. :-) I have a same problem as you have. Regards, Masanobu > >We find some inconvenient issues about CPE when we do IPv6 trials and >experiments: > 1$B!#!V(BISP must pre-configure IPv6 transition technology in CPE, such >as dual-stack, DS-Lite, and so on. > 2$B!#!V(BOtherwise, ISP must rely on Manage System to control CPEs. But >if CPEs are form different manufactories, they need different Manage System, >or to develop consistent interface in the Manage System. > 3$B!#!V(BIf users change the CPE ISP giving to them to another one with >incorrect configuration, or configure CPE incorrectly by mistake, they >cannot access internet. >In this document, we propose a solution to solve the problem. But, the most >important issue is to propose this problem, not the solution. > >Wish for your comments. Thank you! > >Tianle Yang > > > >-----*******----- >From: fred@cisco.com [mailto:fred@cisco.com] >Date: 2012/10/15 20:45 >To: v6ops@ietf.org >Cc: draft-yang-v6ops-ipv6tran-select@tools.ietf.org >Subject: new draft: draft-yang-v6ops-ipv6tran-select > > >A new draft has been posted, at >http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select. Please take a >look at it and comment. > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ========================== NEC AccessTechnica, Ltd. Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ========================== From Fred.L.Templin@boeing.com Tue Oct 16 11:20:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8C021F8812 for ; Tue, 16 Oct 2012 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6th-yPoWj6oC for ; Tue, 16 Oct 2012 11:20:22 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4550521F880D for ; Tue, 16 Oct 2012 11:20:22 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9GIKKOJ025299 for ; Tue, 16 Oct 2012 13:20:21 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9GIK0bf024297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 13:20:19 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 16 Oct 2012 11:20:06 -0700 From: "Templin, Fred L" To: "fred@cisco.com" , "v6ops@ietf.org" Date: Tue, 16 Oct 2012 11:20:06 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2rnBbvE2VC5v9NQh+Rkp3+MkN8TgALDhyg Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> In-Reply-To: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:20:23 -0000 This report is troubling to me. One of the unspoken tenets of IPv6 is that it fixes fragmentation and reassembly, for example by including a large-enough Identification field to avoid wrapping issues at high data rates (see RFC4963). With this knowledge, a reasonable response from a host that receives a Packet Too Big message may be to begin fragmenting large packets (up to 1500 bytes) rather than reduce the size of the packets it sends. If a stateful middlebox needs to inspect all fragments before forwarding to the final destination, then it should do something like Virtual Fragmentation and Reassembly and then pass the fragments through to the final destination assuming filtering rules are satisfied. Either that, or simply allow non-initial fragments through and let the final destination take the appropriate actions. The choice may be dependent on whether the middlebox is located closer to the core or closer to the edge. Taking away IPv6 fragmentation/reassembly removes an important option that should be available to end systems. It would further "dumb-down" the eventual deployment of IPv6 we would see, and would make dealing with MTU diversity that much harder. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Tuesday, October 16, 2012 5:45 AM > To: v6ops@ietf.org > Cc: draft-taylor-v6ops-fragdrop@tools.ietf.org > Subject: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-taylor- > v6ops-fragdrop. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Tue Oct 16 11:25:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0EA21F89DB for ; Tue, 16 Oct 2012 11:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nC-qCSFQncO for ; Tue, 16 Oct 2012 11:25:54 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4512321F89D5 for ; Tue, 16 Oct 2012 11:25:54 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9ca5:2d61:684e:c638]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9GIP47m028675 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 19:25:09 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507DA6A3.20807@inex.ie> Date: Tue, 16 Oct 2012 19:25:39 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:25:55 -0000 On 16/10/2012 19:20, Templin, Fred L wrote: > This report is troubling to me. yeah, i suspect that the root cause is that it's difficult to process arbitrarily positioned tlv based headers in hardware. Nick From nick@inex.ie Tue Oct 16 11:29:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DA221F8857 for ; Tue, 16 Oct 2012 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFwOUTEfzXlE for ; Tue, 16 Oct 2012 11:29:11 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1E021F893D for ; Tue, 16 Oct 2012 11:29:11 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9ca5:2d61:684e:c638]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9GISTnB028709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 19:28:34 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507DA771.6010507@inex.ie> Date: Tue, 16 Oct 2012 19:29:05 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "C. M. Heard" References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <3D093C82-0AD6-416B-8DE2-BD351FF6D3A6@kumari.net> <20121016124907.GL13776@Space.Net> <507D7E31.9080703@bogus.com> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:29:12 -0000 On 16/10/2012 16:50, C. M. Heard wrote: > I agree that is the point the draft is trying to make. My complaint > is that it does not justify the assertion that some people who are > doing this lack palatable alternatives (e.g., by specifying what > credible threats are mitigated by dropping non-initial fragments). is it worth mentioning cisco PFC3 based systems by name in this draft and coming up with recommendations on whether the "platform ipv6 acl fragment hardware forward" command should be used as a matter of course? The internet is still full of older cisco 6500s and 7600s, and will be for years to come. Nick From Fred.L.Templin@boeing.com Tue Oct 16 11:43:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14AF21F8A29 for ; Tue, 16 Oct 2012 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21fNDEzvKvl3 for ; Tue, 16 Oct 2012 11:43:01 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3A121F8A1D for ; Tue, 16 Oct 2012 11:42:58 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9GIgvnt009691 for ; Tue, 16 Oct 2012 11:42:57 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9GIgup4009680 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 11:42:57 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 16 Oct 2012 11:42:57 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Tue, 16 Oct 2012 11:42:56 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2ry6uSHrtDFLlAQiu1oOTOCFvu9gAAaIHA Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> In-Reply-To: <507DA6A3.20807@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:43:02 -0000 > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Tuesday, October 16, 2012 11:26 AM > To: Templin, Fred L > Cc: fred@cisco.com; v6ops@ietf.org; draft-taylor-v6ops- > fragdrop@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > On 16/10/2012 19:20, Templin, Fred L wrote: > > This report is troubling to me. >=20 > yeah, i suspect that the root cause is that it's difficult to process > arbitrarily positioned tlv based headers in hardware. Why not just let non-initial fragments through and then forward or don't forward the initial fragment depending on whether it contains enough information in tlv headers to permit a filtering decision? Fred fred.l.templin@boeing.com > Nick From nick@inex.ie Tue Oct 16 11:44:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02B821F89EA for ; Tue, 16 Oct 2012 11:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnVcbwjmrvOf for ; Tue, 16 Oct 2012 11:44:50 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1FB21F896B for ; Tue, 16 Oct 2012 11:44:48 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9ca5:2d61:684e:c638]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9GIhx1p028883 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 19:44:04 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507DAB13.2010704@inex.ie> Date: Tue, 16 Oct 2012 19:44:35 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:44:50 -0000 On 16/10/2012 19:42, Templin, Fred L wrote: > Why not just let non-initial fragments through and then forward > or don't forward the initial fragment depending on whether it > contains enough information in tlv headers to permit a filtering > decision? i spot some DoSs there. (don't get me wrong, btw - this stuff is hard) Nick From Fred.L.Templin@boeing.com Tue Oct 16 11:49:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F074221F87FA for ; Tue, 16 Oct 2012 11:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAchiZDY61FU for ; Tue, 16 Oct 2012 11:49:48 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0C21F87EC for ; Tue, 16 Oct 2012 11:49:48 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9GInTjc005732 for ; Tue, 16 Oct 2012 11:49:29 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9GInSXP005716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 11:49:29 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 16 Oct 2012 11:49:42 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Tue, 16 Oct 2012 11:49:40 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2rzk/gqXP6zmmITtS3eZu/+4OWNAAAAu/w Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> In-Reply-To: <507DAB13.2010704@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 18:49:49 -0000 > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Tuesday, October 16, 2012 11:45 AM > To: Templin, Fred L > Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > On 16/10/2012 19:42, Templin, Fred L wrote: > > Why not just let non-initial fragments through and then forward > > or don't forward the initial fragment depending on whether it > > contains enough information in tlv headers to permit a filtering > > decision? >=20 > i spot some DoSs there. DoS'ing whom - the end systems? End systems know when to flush incomplete reassemblies. For middleboxes that sit in front of "low-end" end systems, there is also still the option of Virtual Fragmentation Reassembly. Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 fragmentation/reassembly, then all we are left with is 1280 and IPv6 is the new ATM... Fred fred.l.templin@boeing.com > (don't get me wrong, btw - this stuff is hard) >=20 > Nick From farmer@umn.edu Tue Oct 16 12:24:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7787C21F899F for ; Tue, 16 Oct 2012 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyiWcQRjzg9z for ; Tue, 16 Oct 2012 12:24:42 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9F21F87D7 for ; Tue, 16 Oct 2012 12:24:40 -0700 (PDT) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 16 Oct 2012 14:23:20 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f198.google.com [209.85.214.198] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f198.google.com with SMTP id 16so15885237obc.1 for ; Tue, 16 Oct 2012 12:23:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=5OtGJXH62nGRknhSpFdBRHAJYKTRsdLPXUzZg2DfNXc=; b=ieuBN3iIEucdDmfY3mYuqkebUtBUpKfL53lJV0c/Iz9CLDq4iZ8RBO82eiW7V/7ZBf deaeQBdS5oN6dQjxSzWlPTzglYIGsnw65P3zHnRa8rTbcJQmXcGBUxberKaIO6DOnKQR afaoDoGDxbfreKlOa2mPgQeVTr7AIaqK5U2K1l7v6jvgCfqTPor80j67vfy54z9N4lWc 0Ay8gVeJ06Xq9oNd5A62lSwCYDcbmdHtQLvYgmvduDFIe8JwrT0yUXt9DaFeAtWzt/Hm 03Elt1VcoaFVoAveVnDbBIKD3joeG2sdhSqhsXMEgqKGRDziWMm+tKFWI6Y4f10WmjFy ThEw== Received: by 10.50.163.70 with SMTP id yg6mr12795909igb.30.1350415399369; Tue, 16 Oct 2012 12:23:19 -0700 (PDT) Received: by 10.50.163.70 with SMTP id yg6mr12795895igb.30.1350415399216; Tue, 16 Oct 2012 12:23:19 -0700 (PDT) Received: from x-134-84-88-28.nts.umn.edu ([2607:ea00:101:2001:223:dfff:fe83:bf68]) by mx.google.com with ESMTPS id uj6sm9670763igb.4.2012.10.16.12.23.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 12:23:18 -0700 (PDT) Message-ID: <507DB421.8060707@umn.edu> Date: Tue, 16 Oct 2012 14:23:13 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlmybI2K0N2ZMxrvVVJRzTz1hB02lJJpeMKVp9YCeuOWl5wYt30PV7ebKaLQTFZPckigHDTrWUjEnvYlKIApgs+RkYN804sGrwSFO3dKNIkVj8t84uHu+somGS41c3jsSCHH0Nf Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:24:42 -0000 On 10/16/12 13:42 CDT, Templin, Fred L wrote: > > Why not just let non-initial fragments through and then forward > or don't forward the initial fragment depending on whether it > contains enough information in tlv headers to permit a filtering > decision? > There are fundamental differences in the security threat models between a bank and a prison. If what you are trying to do is prevent information leakage, things getting out, then the non-initial fragments could have valuable information that you don't want leaking, even if it is incomplete information. Yes, encryption can deal with this issue, but were dealing with the same mentality that says you have to decrypt everything crossing the parameter to inspect everything going out or coming in. In most situations I believe this is invalid reasoning, however I cannot say it is invalid in all situations. I also believe the reasoning is in far more common use than the situations that actually justify it. -- =============================================== David Farmer Email:farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From Fred.L.Templin@boeing.com Tue Oct 16 12:36:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821C31F0C60 for ; Tue, 16 Oct 2012 12:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlo1twyqD9So for ; Tue, 16 Oct 2012 12:36:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id A59E61F0C3A for ; Tue, 16 Oct 2012 12:36:36 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9GJaaYY001001 for ; Tue, 16 Oct 2012 12:36:36 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9GJaZ1f000464 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 12:36:35 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 16 Oct 2012 12:36:35 -0700 From: "Templin, Fred L" To: David Farmer Date: Tue, 16 Oct 2012 12:36:34 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2r07zQ8CWm63CPTU2of9nTwN83nQAAYunA Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DB421.8060707@umn.edu> In-Reply-To: <507DB421.8060707@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:36:37 -0000 > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Tuesday, October 16, 2012 12:23 PM > To: Templin, Fred L > Cc: Nick Hilliard; v6ops@ietf.org; draft-taylor-v6ops- > fragdrop@tools.ietf.org; David Farmer > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 >=20 > On 10/16/12 13:42 CDT, Templin, Fred L wrote: > > > > Why not just let non-initial fragments through and then forward > > or don't forward the initial fragment depending on whether it > > contains enough information in tlv headers to permit a filtering > > decision? > > >=20 > There are fundamental differences in the security threat models between > a bank and a prison. >=20 > If what you are trying to do is prevent information leakage, things > getting out, then the non-initial fragments could have valuable > information that you don't want leaking, even if it is incomplete > information. Data exfiltration by an adversary at work within your own network? Sounds like a good use case for Virtual Fragmentation Reassembly. Thanks - Fred fred.l.templin@boeing.com > Yes, encryption can deal with this issue, but were dealing with the same > mentality that says you have to decrypt everything crossing the > parameter to inspect everything going out or coming in. >=20 > In most situations I believe this is invalid reasoning, however I cannot > say it is invalid in all situations. I also believe the reasoning is in > far more common use than the situations that actually justify it. >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From markzzzsmith@yahoo.com.au Tue Oct 16 12:54:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EF221F886F for ; Tue, 16 Oct 2012 12:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqFTWIuYHiRd for ; Tue, 16 Oct 2012 12:54:58 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id A56EE21F886C for ; Tue, 16 Oct 2012 12:54:58 -0700 (PDT) Received: from [98.139.212.151] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2012 19:54:57 -0000 Received: from [98.139.212.246] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2012 19:54:57 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 16 Oct 2012 19:54:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 878712.11654.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 4668 invoked by uid 60001); 16 Oct 2012 19:54:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350417297; bh=stNI5gW0yKKuaONhkWrV7dnRmvAobADdT3ZZORpME5k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m6LJE43Df9PPH/n0KWMIcBajomYP6dbPnOwVYQBaMW41k+feFJ3H1WPQJGJojbBo11m4LWl0tD8bYtxl1HDRiTz8ZfAUnHlWXc4UJgKY60ia0vKqQPa0HLKlErDnprzzg2bJwnnhnOvOcl+UvdAoyoDTDsLTbHoBjI5mxBuqPMg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dyfy4+SiOPKvE/QF/NVrWEOZfP3pwWZUvRLFIIt47bqQ2fLcaLe5LF/M01DChHwtvjhTwD42coWCxY1BeyduulqRIb2BP4FkkEDi1qXM4h9d4FAmm0nT8J4oG4IvjPukwF+olEbOTCn0STmWc8MQ1sdNj38YuYb7l5ZLQtEK4II=; X-YMail-OSG: LPo4S4MVM1l7QbFIWnWpdAnjFxoOOybFDkiohhw4x6EvByE zXmHN.B3F_UPUC9fa1fYsncC.j5_x5BeZPpuTxNrF_WOvWC9ZWcMwXUhOiXj .AMevxIlasvk.L2B4bOcIXRHSj2a94bra1v9nJEse_UamEfjFZqnmVOYUvGY TnBsviCQLEToIhe05z8kIk62rmzpOZb3laRk_bFURaB_tXGutaoU1AfXgKpL f_ZV90LHGCuftH4Oi_L7qQJHrcrhUw4YcfwbSTow9deufdlxpp0h4q1CwJ0G M5r3iAWgMVK2PnXWRdQjq6W57ow8uCZx93_biurEfZnuLjj696pq3jGAJJZu sKLfpMigxnP_1qzxwc.ZGsYyoml5RkVibgPBaYrUzeTg6avOYVwyc5uy.UiQ zxmLrb8HdJtiq4_ZFESL0794GtSNnhtFZP87AbNh_Iv9Q1lNgHkJAgyzlIQf 7mbsmZq_OXYwNfjUjN58sKnZDdp5.5fmC07KhFWRg_cNgkalYjbJkMAZdrjq DvNdmUKUqLvEg3w7rMorhPBg31KutfUOtBKp72Cty3LHsTl_qdjAwDQAyAa2 uItw5O6yV81aRuNycC2kwAvAkCXjXgRVmEaSlyzta.zYbjg8ytsoZlz6Yrvg JgpsHRy_s13VqRszd_KU- Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Tue, 16 Oct 2012 12:54:56 PDT X-Rocket-MIMEInfo: 001.001, SGksCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogImZyZWRAY2lzY28uY29tIiA8ZnJlZEBjaXNjby5jb20.Cj4gVG86IHY2b3BzQGlldGYub3JnCj4gQ2M6IGRyYWZ0LWdvbnQtdjZvcHMtc2xhYWMtaXNzdWVzLXdpdGgtZHVwbGljYXRlLW1hY3NAdG9vbHMuaWV0Zi5vcmcKPiBTZW50OiBUdWVzZGF5LCAxNiBPY3RvYmVyIDIwMTIgMTE6NDUgUE0KPiBTdWJqZWN0OiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZ29udC12Nm9wcy1zbGFhYy1pc3N1ZXMtd2l0aC1kdXBsaWNhdGUtbWFjcwoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> Message-ID: <1350417296.76189.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Tue, 16 Oct 2012 12:54:56 -0700 (PDT) From: Mark Smith To: "v6ops@ietf.org" In-Reply-To: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-gont-v6ops-slaac-issues-with-duplicate-macs@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:54:59 -0000 Hi,=0A=0A----- Original Message -----=0A> From: "fred@cisco.com" =0A> To: v6ops@ietf.org=0A> Cc: draft-gont-v6ops-slaac-issues-with-du= plicate-macs@tools.ietf.org=0A> Sent: Tuesday, 16 October 2012 11:45 PM=0A>= Subject: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-m= acs=0A> =0A> =0A> A new draft has been posted, at =0A> http://tools.ietf.or= g/html/draft-gont-v6ops-slaac-issues-with-duplicate-macs. =0A> Please take = a look at it and comment.=0A> _____________________________________________= __=0A=0A=0AI haven't read it thoroughly, however a few general comments to = get the=0A=0Aball rolling:=0A=0A- duplicate MAC addresses (by hardware vend= ors) are generally much rarer=0Athan the draft suggests. I haven't ever com= e across them in 20 or so=0Ayears of dealing with ethernet, and I've only h= eard very few first hand=0Aaccounts of them being encountered. From what I'= ve heard, they've been=0Aaccidents by vendors, e.g. server bios installs at= the factory that didn't=0Aincrement MAC addresses on each new install.=0A= =0A- I think it would be worth both pointing out that the required function= al=0A"scope of uniqueness" for addresses is only the link they're attached= =0Ato. Global uniqueness of addresses is for operational convenience,=0Aall= owing them to be plugged into a link without having to set the=0Aaddress. T= hat required scope of uniqueness reduces the likelihood of=0Aaddress collis= ions, in particular the case of virtual machines that use=0Arandom MAC addr= esses. According to this player (also a interesting read=0Aabout addressing= principles in general), MAC addresses were originally=0Aintended to be per= -host rather than per-interface identifiers and therefore=0Athe same MAC ad= dress would be used on all different links the host was=0Aattached to. I th= ink the per-interface MAC addresses model we've ended=0Aup with evolved fro= m add-in ethernet cards having individual addresses.=0A=0A"48-bit Absolute = Internet and Ethernet Host Numbers", Yogan K. Dalal and=0ARobert S. Printis= =0Ahttp://ethernethistory.typepad.com/papers/HostNumbers.pdf=0A=0A- In the = broadband ADSL networks I'm familiar with, MAC address=0Atranslation (i.e. = 1:1 NAT at layer 2) is enabled on the DSL port facing=0Athe customer. Unfor= tunately the same sorts of NAT related addresses within=0Athe payload issue= s show up at layer 2 - these DSLAMs will translate MAC=0Aaddresses in PPPoE= (either that it isn't required, which I can't recall=0Aat the moment) and = IPv4, however they don't "support" IPv6 because=0Athey can't translate MAC = addresses in IPv6 fields/payloads e.g. ND NS/NA.=0AApparently=A0it isn't po= ssible to upgrade them to do this because they don't have=0Athe hardware re= sources. I see quite a lot of value in coming up with=0Aa solution to detec= t duplicate MAC addresses in this scenario, rather=0Athan translating them = "away", and disabling all or the most recent DSL=0Aport with the duplicate = address (i.e. a tack hammer rather than a sledge=0Ahammer solution). Howeve= r I think that would most likely be something=0Athe ANCP working group woul= d look at, rather than this one.=0A=0A- Assuming that the IPv6 duplicate ad= dress issue can be resolved using=0Amulticast only link layer traffic, laye= r 2 is still broken for unicast=0Atraffic for the nodes with duplicate laye= r 2 addresses, as the layer=0A2 forwarding devices won't be able to cope wi= th duplicate layer 2=0Aaddresses. I wonder if the only possible and effecti= ve way to properly=0Asolve this issue is to solve it where it is actually c= aused, at layer 2.=0A=0ARegards,=0AMark. From nick@inex.ie Tue Oct 16 15:28:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BC821F854E for ; Tue, 16 Oct 2012 15:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-15c-yWeVl4 for ; Tue, 16 Oct 2012 15:28:41 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1221F853F for ; Tue, 16 Oct 2012 15:28:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9ca5:2d61:684e:c638]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9GMRo1l030835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 23:27:56 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507DDF8A.9010607@inex.ie> Date: Tue, 16 Oct 2012 23:28:26 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 22:28:42 -0000 >>> Why not just let non-initial fragments through and then forward >>> or don't forward the initial fragment depending on whether it >>> contains enough information in tlv headers to permit a filtering >>> decision? >> >> i spot some DoSs there. > > DoS'ing whom - the end systems? End systems know when to flush > incomplete reassemblies. The intermediate systems. Well, maybe the end systems too, but that's a different issue. The problem with the intermediate systems is how you handle the packets. Most fast/dumb boxes are able to process fixed-shape packets in hardware because ASICs are pretty good at that sort of thing. If you need to process TLVs at line rate and make forwarding decisions on that basis, then you need much smarter hardware. So the issue comes down to what happens when you have a fast/dumb box forwarding ipv6 packets with interesting headers, and the dumb box is expected to do some level of filtering. For fragments, if your dedicated hardware doesn't handle them natively, then you have a choice between: - allowing them through always - dropping them always - dropping them after a certain rate limit - punting them to a more intelligent part of the forwarding device For punted packets, most vendors punt them to the management plane because they don't have a dedicated path for handling packets which are difficult to parse. This creates a management plane DoS which can be mitigated by rate limiting the punting process. So you end up with either a management plane DoS, or an initial fragment DoS, or both. Now, you could argue that dumb fast boxes shouldn't attempt ipv6 acls in the first place, but what do you do if you want to implement v6 iACLs to protect your internal infrastructure from external attacks? Do you allow all fragments through and potentially compromise your network? Or do you drop all fragments because your routing iron only has the capability to either accept all fragments or drop them all? > For middleboxes that sit in front of > "low-end" end systems, there is also still the option of > Virtual Fragmentation Reassembly. urgh, state. As a general principal, the less state you have to deal with in your intermediate systems, the better. > Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 > fragmentation/reassembly, then all we are left with is 1280 > and IPv6 is the new ATM... We had problems with this for years in the ipv4 world. IPv6 has made it much worse by implementing a difficult-to-parse IP Options style header mechanism and expecting that this is an integral part of the protocol. We fixed it in IPv4 by universally dropping packets with options and by creating an expectation that this was acceptable. IOW, there are large parts of the internet for which there is no good solution to this problem. I.e. any part which doesn't forward packets using a highly intelligent packet processing core. Nick From jhw@apple.com Tue Oct 16 15:49:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD161F0CA9 for ; Tue, 16 Oct 2012 15:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wJNxtLOwqBh for ; Tue, 16 Oct 2012 15:49:20 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id C78D21F0CA6 for ; Tue, 16 Oct 2012 15:49:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MC000FVACLR9AK3@mail-out.apple.com> for v6ops@ietf.org; Tue, 16 Oct 2012 15:48:50 -0700 (PDT) X-AuditID: 11807136-b7f896d000002596-50-507de450d939 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id A6.BE.09622.254ED705; Tue, 16 Oct 2012 15:48:50 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MC000E8LCPC0J40@chive.apple.com> for v6ops@ietf.org; Tue, 16 Oct 2012 15:48:48 -0700 (PDT) From: james woodyatt In-reply-to: <507DDF8A.9010607@inex.ie> Date: Tue, 16 Oct 2012 15:48:48 -0700 Message-id: <90E5D629-4ED7-4FE3-AB9F-3B54C5DB3CC7@apple.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1616) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FDMrxv0pDbAYNEPHovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9ap/ewF51gqnu/rYGxgPMXcxcjBISFgIvHxpkIXIyeQKSZx 4d56ti5GLg4hgQlMEuc+NbODJIQEpjBJHNnlAWIzC2hJrN95nAnE5hXQk5jdcogZxBYWsJb4 /nczWJxNQEXi2+W7YDangLpEx941YHNYBFQlVj15xgoxR09i1szfzBC2tsSTdxdYIWbaSDzt bmOFOOIHk8TvN3tYQBIiAkISO541MUFcKitxZe9ZlgmMArOQ3DQLyU2zkMxdwMi8ilGwKDUn sdLQVC+xoCAnVS85P3cTIzj0Cs12MO74K3eIUYCDUYmHd9Kk2gAh1sSy4srcQ4wSHMxKIrzm jUAh3pTEyqrUovz4otKc1OJDjNIcLErivP/WAaUE0hNLUrNTUwtSi2CyTBycUg2MvJ2Gly9P ZdyQv/5V3ByGSpdLS+sulQkZ38tm+Pd0sZ7qhm/17psubxC4OVOfMWOib8QmFWO5iJvcSu3H 91m6HtFbxKhWMZPpfUTAOvYYS5FtV5JSEy4H5MuXnVx+Q8hd+YT8GVb7ciET5b+Gf18tcXRT dAhiYWcrvGjcHqP19NSy7D72rA9KLMUZiYZazEXFiQBlMFM8OQIAAA== Cc: draft-taylor-v6ops-fragdrop@tools.ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 22:49:21 -0000 On Oct 16, 2012, at 15:28 , Nick Hilliard wrote: > >> For middleboxes that sit in front of >> "low-end" end systems, there is also still the option of >> Virtual Fragmentation Reassembly. > urgh, state. As a general principal, the less state you have to deal with > in your intermediate systems, the better. This is why you always see that horrible look splayed on my face whenever I am reminded of the discussion on this list prior to the drafting of RFC 6092 all those years ago. -- james woodyatt core os networking From Fred.L.Templin@boeing.com Tue Oct 16 16:19:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBDF1F0CAE for ; Tue, 16 Oct 2012 16:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql-SSVEkB2jS for ; Tue, 16 Oct 2012 16:19:43 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id A21D81F0CA9 for ; Tue, 16 Oct 2012 16:19:43 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9GNJhoT024839 for ; Tue, 16 Oct 2012 16:19:43 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9GNJfV3024836 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 16:19:42 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 16 Oct 2012 16:19:41 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Tue, 16 Oct 2012 16:19:40 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2r7Zfi/FAVHjUzTI++6BobClKj2gABBu2A Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> In-Reply-To: <507DDF8A.9010607@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 23:19:44 -0000 > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Tuesday, October 16, 2012 3:28 PM > To: Templin, Fred L > Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > >>> Why not just let non-initial fragments through and then forward > >>> or don't forward the initial fragment depending on whether it > >>> contains enough information in tlv headers to permit a filtering > >>> decision? > >> > >> i spot some DoSs there. > > > > DoS'ing whom - the end systems? End systems know when to flush > > incomplete reassemblies. >=20 > The intermediate systems. Well, maybe the end systems too, but that's a > different issue. >=20 > The problem with the intermediate systems is how you handle the packets. > Most fast/dumb boxes are able to process fixed-shape packets in hardware > because ASICs are pretty good at that sort of thing. If you need to > process TLVs at line rate and make forwarding decisions on that basis, > then > you need much smarter hardware. So the issue comes down to what happens > when you have a fast/dumb box forwarding ipv6 packets with interesting > headers, and the dumb box is expected to do some level of filtering. Filtering near the edges is where we have stateful filters that are good at managing state. "Stateless" filtering near the middle has no choice but to pass the fragments always. =20 > For fragments, if your dedicated hardware doesn't handle them natively, > then you have a choice between: >=20 > - allowing them through always > - dropping them always > - dropping them after a certain rate limit > - punting them to a more intelligent part of the forwarding device >=20 > For punted packets, most vendors punt them to the management plane becaus= e > they don't have a dedicated path for handling packets which are difficult > to parse. This creates a management plane DoS which can be mitigated by > rate limiting the punting process. So you end up with either a managemen= t > plane DoS, or an initial fragment DoS, or both. >=20 > Now, you could argue that dumb fast boxes shouldn't attempt ipv6 acls in > the first place, but what do you do if you want to implement v6 iACLs to > protect your internal infrastructure from external attacks? Do you allow > all fragments through and potentially compromise your network? Or do you > drop all fragments because your routing iron only has the capability to > either accept all fragments or drop them all? >=20 > > For middleboxes that sit in front of > > "low-end" end systems, there is also still the option of > > Virtual Fragmentation Reassembly. >=20 > urgh, state. As a general principal, the less state you have to deal wit= h > in your intermediate systems, the better. IPv6 nodes are required to reassemble at least 1500 bytes in any event. That is for packets explicitly addressed to the node, but also consider (temporary) fragment matching for packets passing through the node, e.g. as done by VRF. Plus, when the router gets a fragment, chances are very good that its brethren are hot on its heels and will arrive or not very quickly. So, its not a case of holding onto gobs of fragments indefinitely and can be managed by reasonably good hardware. At least, I have been informed by individuals working for major network equipment vendors that their implementations can handle router reassembly. > > Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 > > fragmentation/reassembly, then all we are left with is 1280 > > and IPv6 is the new ATM... >=20 > We had problems with this for years in the ipv4 world. IPv6 has made it > much worse by implementing a difficult-to-parse IP Options style header > mechanism and expecting that this is an integral part of the protocol. W= e > fixed it in IPv4 by universally dropping packets with options and by > creating an expectation that this was acceptable. IPv6 fixes fragmentation and reassembly, whereas filtering routers dropping fragments breaks it. IPv6 fragmentation is a necessary part of the equation needed to support path MTU diversity. RFC4821 is another part, but there is no way for the network to know when end systems are using it. =20 > IOW, there are large parts of the internet for which there is no good > solution to this problem. I.e. any part which doesn't forward packets > using a highly intelligent packet processing core. Dropping fragments violates the end-to end principles, and negates path MTU diversity. 1280 is too small of a size for us to lock into "the matrix" once and for always. Thanks - Fred fred.l.templin@boeing.com > Nick From jmkeller@houseofzen.org Wed Oct 17 05:47:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB8821F865B for ; Wed, 17 Oct 2012 05:47:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...seofzen.org for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-41+dy3nscR for ; Wed, 17 Oct 2012 05:47:11 -0700 (PDT) Received: from omega.houseofzen.org (omega.houseofzen.org [96.126.106.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87621F862B for ; Wed, 17 Oct 2012 05:47:11 -0700 (PDT) Received: from localhost ([127.0.0.1]) by omega.houseofzen.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TOT1h-0007CR-3h; Wed, 17 Oct 2012 08:47:09 -0400 Message-ID: <507EA8CB.40702@houseofzen.org> Date: Wed, 17 Oct 2012 08:47:07 -0400 From: James M Keller User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mark Smith References: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> <1350417296.76189.YahooMailNeo@web32502.mail.mud.yahoo.com> In-Reply-To: <1350417296.76189.YahooMailNeo@web32502.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "omega.houseofzen.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see postmaster@houseofzen.org for details. Content preview: On 10/16/2012 3:54 PM, Mark Smith wrote: > I haven't read it thoroughly, however a few general comments to get > the ball rolling: - duplicate MAC addresses (by hardware vendors) are > generally much rarer than the draft suggests. I haven't ever come > across them in 20 or so years of dealing with ethernet, and I've only > heard very few first hand accounts of them being encountered. From > what I've heard, they've been accidents by vendors, e.g. server bios > installs at the factory that didn't increment MAC addresses on each > new install. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 12:47:12 -0000 On 10/16/2012 3:54 PM, Mark Smith wrote: > I haven't read it thoroughly, however a few general comments to get > the ball rolling: - duplicate MAC addresses (by hardware vendors) are > generally much rarer than the draft suggests. I haven't ever come > across them in 20 or so years of dealing with ethernet, and I've only > heard very few first hand accounts of them being encountered. From > what I've heard, they've been accidents by vendors, e.g. server bios > installs at the factory that didn't increment MAC addresses on each > new install. This has become more of an issue of late with virtual hosting systems generating MAC addresses for VM NICs and then moving images between environments and ending up with a collision vs physical hardware burned-in-addresses. -- --- James M Keller From nick@inex.ie Wed Oct 17 05:52:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD6C21F87DB for ; Wed, 17 Oct 2012 05:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z59qjyMltcK for ; Wed, 17 Oct 2012 05:52:58 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8621F8781 for ; Wed, 17 Oct 2012 05:52:57 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.internal.acquirer.com ([IPv6:2001:1bb8:2004:100:9d04:11ba:6a88:6416]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9HCqEc8037778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 13:52:14 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507EAA22.20404@inex.ie> Date: Wed, 17 Oct 2012 13:52:50 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 12:52:58 -0000 On 17/10/2012 00:19, Templin, Fred L wrote: > Filtering near the edges is where we have stateful filters that > are good at managing state. "Stateless" filtering near the middle > has no choice but to pass the fragments always. I understand, but this opens up an implicit DoS vector if you use iACLs on your dumb/fast transit boxes to filter out external ipv6 traffic to core infrastructure, because you will be forced to explicitly allow fragments. > IPv6 nodes are required to reassemble at least 1500 bytes in > any event. That is for packets explicitly addressed to the node, > but also consider (temporary) fragment matching for packets > passing through the node, e.g. as done by VRF. Plus, when the > router gets a fragment, chances are very good that its brethren > are hot on its heels and will arrive or not very quickly. So, > its not a case of holding onto gobs of fragments indefinitely > and can be managed by reasonably good hardware. At least, I > have been informed by individuals working for major network > equipment vendors that their implementations can handle router > reassembly. I'll believe this when I see it. Not saying that this isn't the case, but in all networking equipment I've ever dealt with, whenever I've heard about statements like this, the list of caveats is a long as your arm. > Dropping fragments violates the end-to end principles, and negates > path MTU diversity. 1280 is too small of a size for us to lock into > "the matrix" once and for always. I agree. All I'm saying is that most core infrastructure on the internet does not have clever enough silicon to handle anything other than fixed-format packet structures, and if we expect it to make sensible decisions on TLV based packet header decoding, we're fooling ourselves. This problem may be fixed in future if we move from dumb ASICs to smarter silicon, but there will be a substantial core network upgrade cost associated with this, and it will take many years to deal with. In the interim, operators will need to choose between passing fragments (i.e. allowing core infrastructure DoS vectors) or dropping fragments (i.e. breaking ipv6 in the general case). Neither option is good. Nick From nick@inex.ie Wed Oct 17 06:47:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E260F21F8713 for ; Wed, 17 Oct 2012 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H4DnouIa+32 for ; Wed, 17 Oct 2012 06:47:27 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5821F853B for ; Wed, 17 Oct 2012 06:47:26 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.internal.acquirer.com ([IPv6:2001:1bb8:2004:100:f10d:261a:204d:2c78]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9HDkh4o038462 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 14:46:44 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507EB6E8.1040208@inex.ie> Date: Wed, 17 Oct 2012 14:47:20 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507EAA22.20404@inex.ie> In-Reply-To: <507EAA22.20404@inex.ie> X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:47:28 -0000 On 17/10/2012 13:52, Nick Hilliard wrote: > associated with this, and it will take many years to deal with. In the > interim, operators will need to choose between passing fragments (i.e. > allowing core infrastructure DoS vectors) or dropping fragments (i.e. > breaking ipv6 in the general case). Neither option is good. as someone prompted offline (for which thanks!) I should be clear that this is a platform specific issue related to the cisco pfc3b/3bxl which has three modes for handling ipv6 fragments: 1. forward them to the RP for software processing 2. drop them, overriding ACLs 3. forward them, overriding ACLs I mistakenly implied that this was a more general problem, for which apologies. Nick From warren@kumari.net Wed Oct 17 07:03:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0E621F8794 for ; Wed, 17 Oct 2012 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3hMeVYXAXl4 for ; Wed, 17 Oct 2012 07:03:18 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CBA21F8751 for ; Wed, 17 Oct 2012 07:03:17 -0700 (PDT) Received: from [10.196.219.128] (1-195.icannmeeting.org [199.91.195.1]) by vimes.kumari.net (Postfix) with ESMTPSA id A27981B40122; Wed, 17 Oct 2012 10:03:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 17 Oct 2012 10:03:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:03:18 -0000 On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" = wrote: >> -----Original Message----- >> From: Nick Hilliard [mailto:nick@inex.ie] >> Sent: Tuesday, October 16, 2012 3:28 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >>=20 >>>>> Why not just let non-initial fragments through and then forward >>>>> or don't forward the initial fragment depending on whether it >>>>> contains enough information in tlv headers to permit a filtering >>>>> decision? >>>>=20 >>>> i spot some DoSs there. >>>=20 >>> DoS'ing whom - the end systems? End systems know when to flush >>> incomplete reassemblies. >>=20 >> The intermediate systems. Well, maybe the end systems too, but = that's a >> different issue. >>=20 >> The problem with the intermediate systems is how you handle the = packets. >> Most fast/dumb boxes are able to process fixed-shape packets in = hardware >> because ASICs are pretty good at that sort of thing. If you need to >> process TLVs at line rate and make forwarding decisions on that = basis, >> then >> you need much smarter hardware. So the issue comes down to what = happens >> when you have a fast/dumb box forwarding ipv6 packets with = interesting >> headers, and the dumb box is expected to do some level of filtering. >=20 > Filtering near the edges is where we have stateful filters that > are good at managing state. "Stateless" filtering near the middle > has no choice but to pass the fragments always. >=20 >> For fragments, if your dedicated hardware doesn't handle them = natively, >> then you have a choice between: >>=20 >> - allowing them through always >> - dropping them always >> - dropping them after a certain rate limit >> - punting them to a more intelligent part of the forwarding device >>=20 >> For punted packets, most vendors punt them to the management plane = because >> they don't have a dedicated path for handling packets which are = difficult >> to parse. This creates a management plane DoS which can be mitigated = by >> rate limiting the punting process. So you end up with either a = management >> plane DoS, or an initial fragment DoS, or both. >>=20 >> Now, you could argue that dumb fast boxes shouldn't attempt ipv6 acls = in >> the first place, but what do you do if you want to implement v6 iACLs = to >> protect your internal infrastructure from external attacks? Do you = allow >> all fragments through and potentially compromise your network? Or do = you >> drop all fragments because your routing iron only has the capability = to >> either accept all fragments or drop them all? >>=20 >>> For middleboxes that sit in front of >>> "low-end" end systems, there is also still the option of >>> Virtual Fragmentation Reassembly. >>=20 >> urgh, state. As a general principal, the less state you have to deal = with >> in your intermediate systems, the better. >=20 > IPv6 nodes are required to reassemble at least 1500 bytes in > any event. That is for packets explicitly addressed to the node, > but also consider (temporary) fragment matching for packets > passing through the node, e.g. as done by VRF. Plus, when the > router gets a fragment, chances are very good that its brethren > are hot on its heels and will arrive or not very quickly. So, > its not a case of holding onto gobs of fragments indefinitely > and can be managed by reasonably good hardware. > At least, I > have been informed by individuals working for major network > equipment vendors that their implementations can handle router > reassembly. "can handle router reassembly" !=3D "can handle router reassembly at = line rate on multiple interfaces". You really need this to be line rate on all interfaces, otherwise there = is (obviously) a DoS vector here. Reassembly at 10G (or 100G) is = distinctly non-trivial and requires A: large buffers, B: short timeouts, = C: gets sad if not all bits go through the same device, D: state and E: = hardware designed specifically for this. This is much more than packet = comes in, packet goes out... W >=20 >>> Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 >>> fragmentation/reassembly, then all we are left with is 1280 >>> and IPv6 is the new ATM... >>=20 >> We had problems with this for years in the ipv4 world. IPv6 has made = it >> much worse by implementing a difficult-to-parse IP Options style = header >> mechanism and expecting that this is an integral part of the = protocol. We >> fixed it in IPv4 by universally dropping packets with options and by >> creating an expectation that this was acceptable. >=20 > IPv6 fixes fragmentation and reassembly, whereas filtering routers > dropping fragments breaks it. IPv6 fragmentation is a necessary > part of the equation needed to support path MTU diversity. RFC4821 > is another part, but there is no way for the network to know when > end systems are using it. =20 >=20 >> IOW, there are large parts of the internet for which there is no good >> solution to this problem. I.e. any part which doesn't forward = packets >> using a highly intelligent packet processing core. >=20 > Dropping fragments violates the end-to end principles, and negates > path MTU diversity. 1280 is too small of a size for us to lock into > "the matrix" once and for always. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --=20 A. No Q. Is it sensible to top-post? From Fred.L.Templin@boeing.com Wed Oct 17 08:39:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A44821F8596 for ; Wed, 17 Oct 2012 08:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w40lov9CGRFO for ; Wed, 17 Oct 2012 08:39:17 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0452E21F8595 for ; Wed, 17 Oct 2012 08:39:16 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9HFdFck015024 for ; Wed, 17 Oct 2012 10:39:16 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9HFdEZb015001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Oct 2012 10:39:14 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 17 Oct 2012 08:39:14 -0700 From: "Templin, Fred L" To: Warren Kumari , Nick Hilliard , "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Date: Wed, 17 Oct 2012 08:39:13 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2scCp363SZwtsjTsKxgH4qvSvWHgAC0VzA Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:39:17 -0000 You know, all of this discussion is moot. RFC2460, Section 5 says: "In order to send a packet larger than a path's MTU, a node may use the IPv6 Fragment header to fragment the packet at the source and have it reassembled at the destination(s). However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size." That means that a source node has every reason to expect that, if it fragments a packet that is no larger than 1500 bytes, then the destination will be able to reassemble it. Host fragmentation is therefore an integral part of correct IPv6 operation, and that's the law until someone writes a different one. Middleboxes therefore have no basis for dropping fragments, unless they can through some means be determined as malicious (e.g., VFR). Thanks - Fred fred.l.templin@boeing.com From heard@pobox.com Wed Oct 17 13:58:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5721F85ED for ; Wed, 17 Oct 2012 13:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyJauAWe2EfX for ; Wed, 17 Oct 2012 13:58:17 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A38621F857D for ; Wed, 17 Oct 2012 13:58:08 -0700 (PDT) Received: (qmail 16775 invoked from network); 17 Oct 2012 13:58:07 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Oct 2012 13:58:07 -0700 Date: Wed, 17 Oct 2012 13:58:07 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: V6 Ops In-Reply-To: Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:58:17 -0000 On Wed, 17 Oct 2012, Warren Kumari wrote: > On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" wrote: > > I have been informed by individuals working for major network > > equipment vendors that their implementations can handle router > > reassembly. > > "can handle router reassembly" != "can handle router reassembly at > line rate on multiple interfaces". > > You really need this to be line rate on all interfaces, otherwise > there is (obviously) a DoS vector here. Reassembly at 10G (or > 100G) is distinctly non-trivial and requires A: large buffers, B: > short timeouts, C: gets sad if not all bits go through the same > device, D: state and E: hardware designed specifically for this. > This is much more than packet comes in, packet goes out... Excuse me, maybe I'm as dumb as a post, but .... why in the world are participants in this thread posing this as problem for the core? Except for packets specifically destined for core infrastructure itself --- and those, surely, are not arriving at line rate -- the core has no reason to do anything other than just pass the fragments on and let edge devices deal with them. Indeed, the draft itself states that "IPv6 datagrams with fragmentation headers are a non-issue in the core of the internet, where fragments are routed just like any other IPv6 datagram. However, fragmentation creates operational ssues at the edge of the network that may lead to administratively imposed filtering or inadvertent failure to deliver the fragment to the application." //cmh From nick@inex.ie Wed Oct 17 14:43:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB24F21F873D for ; Wed, 17 Oct 2012 14:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkxFunwZf4Xi for ; Wed, 17 Oct 2012 14:43:06 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6321F8726 for ; Wed, 17 Oct 2012 14:43:05 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9031:7f05:47f2:b06a]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9HLgHxH043805 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 22:42:23 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507F265E.6030000@inex.ie> Date: Wed, 17 Oct 2012 22:42:54 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:43:06 -0000 On 17/10/2012 16:39, Templin, Fred L wrote: > You know, all of this discussion is moot. RFC2460, Section 5 says: [...] > the law until someone writes a different one. Middleboxes therefore > have no basis for dropping fragments, unless they can through some > means be determined as malicious (e.g., VFR). We're all agreed that legitimate fragments should get through. But there is a large body of installed hardware out there in the core of the Internet which has exactly the following options for dealing with ipv6 fragments: > 1. forward them to the RP for software processing, which will cause a > management plane DoS > 2. drop them unilaterally, implicitly overriding all v6 ACLs, breaking > IPv6 fragmentation > 3. forward them unilaterally, implicitly overriding all ACLs, opening up > an infrastructure DoS vector None of these are pleasant options. It's not a moot point: it's just a matter of the equipment not matching up with the requirements of the RFCs and is a serious practical problem for operators which use older equipment. So how do we deal with it? Does it deserve a mention in the draft, with recommendations on what to do, or would it be better to ignore the problem as it's a vendor/device specific issue? Nick From Fred.L.Templin@boeing.com Wed Oct 17 15:26:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742621F866C for ; Wed, 17 Oct 2012 15:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0HaHDSZo6st for ; Wed, 17 Oct 2012 15:26:17 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id EB95421F84C4 for ; Wed, 17 Oct 2012 15:26:16 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9HMQGF2023218 for ; Wed, 17 Oct 2012 17:26:16 -0500 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9HMQEqF022730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Oct 2012 17:26:15 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 17 Oct 2012 15:26:14 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Wed, 17 Oct 2012 15:26:12 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2ssG35+n6LXwaJTrasH+FfXnik/wABRpqw Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> In-Reply-To: <507F265E.6030000@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:26:17 -0000 > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Wednesday, October 17, 2012 2:43 PM > To: Templin, Fred L > Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > On 17/10/2012 16:39, Templin, Fred L wrote: > > You know, all of this discussion is moot. RFC2460, Section 5 says: > [...] > > the law until someone writes a different one. Middleboxes therefore > > have no basis for dropping fragments, unless they can through some > > means be determined as malicious (e.g., VFR). >=20 > We're all agreed that legitimate fragments should get through. But there > is a large body of installed hardware out there in the core of the > Internet > which has exactly the following options for dealing with ipv6 fragments: >=20 > > 1. forward them to the RP for software processing, which will cause a > > management plane DoS >=20 > > 2. drop them unilaterally, implicitly overriding all v6 ACLs, breaking > > IPv6 fragmentation >=20 > > 3. forward them unilaterally, implicitly overriding all ACLs, opening u= p > > an infrastructure DoS vector >=20 > None of these are pleasant options. >=20 > It's not a moot point: it's just a matter of the equipment not matching u= p > with the requirements of the RFCs and is a serious practical problem for > operators which use older equipment. So how do we deal with it? Does it > deserve a mention in the draft, with recommendations on what to do, or > would it be better to ignore the problem as it's a vendor/device specific > issue? In order to correctly observe the standards, core routers have no option other than to simply forward any IPv6 fragments that are "just passing through" - regardless of any configurable options available on certain vendor products. IPv6 fragmentation and reassembly is an end-to-end function, and according to the end-to-end principles the function is best implemented either within the end system or as close to the end system as possible. The core needs to let the edge devices and end systems deal with fragments, and even if fragments are passed all the way through to the end system without prior examination end systems nowadays have host-based firewalls. I think we may be over-thinking this. Vendor equipment needs to observe the standards in order to claim compliance. Broken equipment should be identified and reported when it does not. Fred fred.l.templin@boeing.com=20 =20 > Nick From nick@inex.ie Wed Oct 17 15:36:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54F621F86E3 for ; Wed, 17 Oct 2012 15:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DPPMN98b1xT for ; Wed, 17 Oct 2012 15:36:20 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E7D7821F86CA for ; Wed, 17 Oct 2012 15:36:19 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9031:7f05:47f2:b06a]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9HMZXlq044266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 23:35:38 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <507F32DA.30600@inex.ie> Date: Wed, 17 Oct 2012 23:36:10 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:36:20 -0000 On 17/10/2012 23:26, Templin, Fred L wrote: > Vendor equipment needs > to observe the standards in order to claim compliance. Broken > equipment should be identified and reported when it does not. So, is it appropriate to name broken kit in the draft? I haven't formed an opinion on this. Naming and shaming brings up all sorts of issues. Nick From Fred.L.Templin@boeing.com Wed Oct 17 15:46:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9E21F86FC for ; Wed, 17 Oct 2012 15:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHH16zUCjqHg for ; Wed, 17 Oct 2012 15:46:40 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id DE91621F86D8 for ; Wed, 17 Oct 2012 15:46:40 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9HMkQQ5016865 for ; Wed, 17 Oct 2012 15:46:26 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9HMkOG0016853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Oct 2012 15:46:25 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Wed, 17 Oct 2012 15:46:38 -0700 From: "Templin, Fred L" To: Nick Hilliard Date: Wed, 17 Oct 2012 15:46:36 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2st9WHbPbvua5WS7Gfj11QSJ3jzwAAAfGA Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> In-Reply-To: <507F32DA.30600@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 22:46:41 -0000 > -----Original Message----- > From: Nick Hilliard [mailto:nick@inex.ie] > Sent: Wednesday, October 17, 2012 3:36 PM > To: Templin, Fred L > Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > On 17/10/2012 23:26, Templin, Fred L wrote: > > Vendor equipment needs > > to observe the standards in order to claim compliance. Broken > > equipment should be identified and reported when it does not. >=20 > So, is it appropriate to name broken kit in the draft? I haven't formed > an > opinion on this. Naming and shaming brings up all sorts of issues. I really don't know what is the right answer to that. One thing that is missing from the draft however is that IP tunnels are another mildly important class of "application" that cannot reduce the size of the packets they send down to 1280. For them, it is either fragmentation or black hole... Thanks - Fred fred.l.templin@boeing.com > Nick From joelja@bogus.com Thu Oct 18 00:07:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DAF21F85DA for ; Thu, 18 Oct 2012 00:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHfCnp2AskLT for ; Thu, 18 Oct 2012 00:07:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA42521F85A7 for ; Thu, 18 Oct 2012 00:07:50 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9I77h9j059908 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 18 Oct 2012 07:07:44 GMT (envelope-from joelja@bogus.com) Message-ID: <507FAABE.5050601@bogus.com> Date: Thu, 18 Oct 2012 00:07:42 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 18 Oct 2012 07:07:48 +0000 (UTC) Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:07:51 -0000 On 10/17/12 3:26 PM, Templin, Fred L wrote: > >> -----Original Message----- >> From: Nick Hilliard [mailto:nick@inex.ie] >> Sent: Wednesday, October 17, 2012 2:43 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >> >> On 17/10/2012 16:39, Templin, Fred L wrote: >>> You know, all of this discussion is moot. RFC2460, Section 5 says: >> [...] >>> the law until someone writes a different one. Middleboxes therefore >>> have no basis for dropping fragments, unless they can through some >>> means be determined as malicious (e.g., VFR). >> We're all agreed that legitimate fragments should get through. But there >> is a large body of installed hardware out there in the core of the >> Internet >> which has exactly the following options for dealing with ipv6 fragments: >> >>> 1. forward them to the RP for software processing, which will cause a >>> management plane DoS >>> 2. drop them unilaterally, implicitly overriding all v6 ACLs, breaking >>> IPv6 fragmentation >>> 3. forward them unilaterally, implicitly overriding all ACLs, opening up >>> an infrastructure DoS vector >> None of these are pleasant options. >> >> It's not a moot point: it's just a matter of the equipment not matching up >> with the requirements of the RFCs and is a serious practical problem for >> operators which use older equipment. So how do we deal with it? Does it >> deserve a mention in the draft, with recommendations on what to do, or >> would it be better to ignore the problem as it's a vendor/device specific >> issue? > In order to correctly observe the standards, core routers have no > option other than to simply forward any IPv6 fragments that are > "just passing through" - regardless of any configurable options > available on certain vendor products. The focus on core devices is misguided imho... The services edge of my network where both connections terminate and policy is applied may be substantially higher capacity than the backbone of many networks it is exposed to this issue. Given that I am an end-site all traffic carried on a backbone is either coming from or in bound to an end system on our network. > IPv6 fragmentation and reassembly is an end-to-end function, and > according to the end-to-end principles the function is best > implemented either within the end system or as close to the end > system as possible. The core needs to let the edge devices and > end systems deal with fragments, and even if fragments are passed > all the way through to the end system without prior examination > end systems nowadays have host-based firewalls. > > I think we may be over-thinking this. Vendor equipment needs > to observe the standards in order to claim compliance. Broken > equipment should be identified and reported when it does not. > > Fred > fred.l.templin@boeing.com > >> Nick > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Thu Oct 18 00:12:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF0921F857D for ; Thu, 18 Oct 2012 00:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7Wg9t4xRa1s for ; Thu, 18 Oct 2012 00:12:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0F021F84F5 for ; Thu, 18 Oct 2012 00:12:27 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9I7CQKc059990 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 18 Oct 2012 07:12:26 GMT (envelope-from joelja@bogus.com) Message-ID: <507FABDA.7060106@bogus.com> Date: Thu, 18 Oct 2012 00:12:26 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: "C. M. Heard" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 18 Oct 2012 07:12:27 +0000 (UTC) Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:12:27 -0000 On 10/17/12 1:58 PM, C. M. Heard wrote: > On Wed, 17 Oct 2012, Warren Kumari wrote: >> On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" wrote: >>> I have been informed by individuals working for major network >>> equipment vendors that their implementations can handle router >>> reassembly. >> "can handle router reassembly" != "can handle router reassembly at >> line rate on multiple interfaces". >> >> You really need this to be line rate on all interfaces, otherwise >> there is (obviously) a DoS vector here. Reassembly at 10G (or >> 100G) is distinctly non-trivial and requires A: large buffers, B: >> short timeouts, C: gets sad if not all bits go through the same >> device, D: state and E: hardware designed specifically for this. >> This is much more than packet comes in, packet goes out... > Excuse me, maybe I'm as dumb as a post, but .... why in the world > are participants in this thread posing this as problem for the core? The fact that high capacity requirements exsit does not imply that it a problem for the core. From brian.e.carpenter@gmail.com Thu Oct 18 01:26:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2821F84BF for ; Thu, 18 Oct 2012 01:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id5HkjttBACq for ; Thu, 18 Oct 2012 01:26:36 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8521F861F for ; Thu, 18 Oct 2012 01:26:36 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so4809992eek.31 for ; Thu, 18 Oct 2012 01:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mHVObVXdZ+m7FKvhSZekffNRjNE8d4aVjDg1oemA19o=; b=1EbpGSHxLe/aNbe2sinaP4icdDij2pZiLM7BLiEMFiT3tIph5C5QzxzcVFUw4W1LSx hIcx4l5J6PEzx5449o/GLlCalHgYgxjJeIouoB/vdgPNJBwMZVzmReBrMVXPAyha/32m DxNEXTqKV0hGbZ0ZzgL6CMg12b2mGtYycjh3tEZ744p+cTJN1aeZK31nQhXG0m6Gkn9S VOs/ahd82tMh7ZeuGFq05en9hbR6yJ6Huq7FpbwCnyxRipjq56FqGhEDh4mdT6if1r+P JWNco4nDKYkFABb5ZtlSaiT5nAEr9hPrb0DSshaRiKsT0SzNavrSJtXujwOpbQPaMV49 zuyQ== Received: by 10.14.213.201 with SMTP id a49mr30542531eep.4.1350548795619; Thu, 18 Oct 2012 01:26:35 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-225.as13285.net. [2.102.216.225]) by mx.google.com with ESMTPS id t7sm38680787eel.14.2012.10.18.01.26.32 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 01:26:33 -0700 (PDT) Message-ID: <507FBD3D.4060909@gmail.com> Date: Thu, 18 Oct 2012 09:26:37 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507FAABE.5050601@bogus.com> In-Reply-To: <507FAABE.5050601@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:26:37 -0000 On 18/10/2012 08:07, joel jaeggli wrote: ... > The focus on core devices is misguided imho... The services edge of my > network where both connections terminate and policy is applied may be > substantially higher capacity than the backbone of many networks it is > exposed to this issue. Given that I am an end-site all traffic carried > on a backbone is either coming from or in bound to an end system on our > network. Yes, and as far as I can tell the problems arise with site-boundary devices that attempt to indulge in deep packet inspection and are stymied by extension headers and/or fragments. Load balancers have similar difficulties. These devices do violate the letter or spirit of RFC 2460, but that's life. (The fact that RFC 2460 does not spell out behaviour for extension headers not mentioned in RFC 2460 is why I wrote draft-carpenter-6man-ext-transmit. But that will not magically change the code in firewalls.) Core routers just route packets. ECMP/LAG might not work optimally in some cases, but that doesn't break e2e connectivity. Brian From fred@cisco.com Thu Oct 18 03:39:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2614A21F8552 for ; Thu, 18 Oct 2012 03:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIx61mlol-9O for ; Thu, 18 Oct 2012 03:39:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 45F8721F8540 for ; Thu, 18 Oct 2012 03:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3922; q=dns/txt; s=iport; t=1350556778; x=1351766378; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Mf1Dofz7EAMOSXUfYL31ZI8knyW7HnVHw/S72d+pfiA=; b=gwYof2k5tRYZ9tzKbz4RHUmoRvHdrDEgIjyxRPv54CvQxzYDRoyEaWuZ qQozq+AWvTtYYRKHjT+V/DptuoksyEkqk/jUyEtVM9MsbcOcu4Vrc/RIj 6P1brmIzeBFFO+tH99Rh3tnSB2SFw5RscupMNSMpX3kgRYO0bQrmJ/elb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOfbf1CtJV2Z/2dsb2JhbABFwDyBCIIhAQEEEgEnTwIBKhQQMiUCBBsMDodiC5wQoCGROmADlwCNNIFrgm+CFw X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132953511" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 18 Oct 2012 10:39:37 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9IAdbFm010187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 10:39:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 05:39:37 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Agenda prep for IETF 85 Thread-Index: AQHNrRzeDhq8jBFlakGAAd4dY7BqoQ== Date: Thu, 18 Oct 2012 10:39:37 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B17DC79@xmb-rcd-x09.cisco.com> References: <74C29719-6EA0-4462-895F-7B182769FDC3@cisco.com> In-Reply-To: <74C29719-6EA0-4462-895F-7B182769FDC3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--36.890000-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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Agenda prep for IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 10:39:39 -0000 Joel and I are starting to plan the agenda for IETF 85. We currently have t= wo two-hour slots on Thursday afternoon; due to a conflict with PCP, we're = trying to move one of those to another slot. On that point, stay tuned. That said, this is the state of play, and what I think our proposed agenda = might be. We are looking for your comments on both the agenda and (implied)= some of the new drafts that aren't yet on it. Dates and names come from my= copy of the draft directory and http://datatracker.ietf.org/doc/search/?na= me=3Dv6ops&rfcs=3Don&activeDrafts=3Don&search_submit=3D: In RFC Editor queue: Feb 21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt Sep 11 draft-ietf-v6ops-wireline-incremental-ipv6-06.txt Oct 12 draft-ietf-v6ops-ivi-icmp-address-07.txt In IESG Sep 26 draft-ietf-v6ops-6204bis-11.txt In Ron's queue May 22 draft-ietf-v6ops-ra-guard-implementation-04.txt Waiting for chairs to submit (RSN): Sep 17 draft-ietf-v6ops-icp-guidance-04.txt Sep 19 draft-ietf-v6ops-464xlat-08.txt Older, and not on our radar unless updated Apr 27 draft-jiang-v6ops-v4v6mc-proxy-01.txt Apr 30 draft-gundavelli-v6ops-community-wifi-svcs-04.txt May 10 draft-templin-v6ops-isops-17.txt May 19 draft-foo-v6ops-6rdmtu-00.txt Jun 20 draft-lopez-v6ops-dc-ipv6-02.txt Jun 29 draft-matthews-v6ops-design-guidelines-00.txt Jul 5 draft-generic-v6ops-tunmtu-09.txt Jul 16 draft-ma-v6ops-terminal-test-01.txt Jul 16 draft-liu-v6ops-ula-usage-analysis-03.txt Jul 16 draft-zhang-v6ops-ipv6oa-iwf-01.txt "ID Exists" and posted since last IETF: Aug 7 draft-ietf-v6ops-nat64-experience-00.txt Aug 17 draft-smith-v6ops-larger-ipv6-loopback-prefix-01.txt Sep 16 draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt Sep 29 draft-yang-v6ops-fast6-01.txt Oct 5 draft-binet-v6ops-cellular-host-reqs-rfc3316update-03.txt Oct 10 draft-byrne-v6ops-64share-03.txt Oct 15 draft-korhonen-v6ops-rfc3316bis-00.txt Oct 15 draft-jiang-v6ops-semantic-prefix-00.txt Oct 15 draft-yang-v6ops-ipv6tran-select-00.txt Oct 16 draft-gont-v6ops-slaac-issues-with-duplicate-macs-00.txt Oct 16 draft-taylor-v6ops-fragdrop-00.txt I have received private feedback on draft-korhonen-v6ops-rfc3316bis, and no= te that it is related to the topic of another draft that will make it to th= e agenda. I have yet to see list comments on draft-yang-v6ops-fast6 and dra= ft-jiang-v6ops-semantic-prefix, and the one comment on draft-gont-v6ops-sla= ac-issues-with-duplicate-macs isn't very supportive. We'll wait to see inte= rest before adding them to the agenda. draft-taylor-v6ops-fragdrop grew out= of a conversation at the interim meeting a few weeks ago, so I'm inclined = to entertain the discussion even though mailer discussion right now doesn't= favor its approach. My proposed agenda:=20 one meeting: draft-ietf-v6ops-nat64-experience draft-ietf-v6ops-enterprise-incremental-ipv6 draft-smith-v6ops-larger-ipv6-loopback-prefix draft-yang-v6ops-ipv6tran-select the other meeting: draft-binet-v6ops-cellular-host-reqs-rfc3316update draft-korhonen-v6ops-rfc3316bis draft-byrne-v6ops-64share draft-taylor-v6ops-fragdrop That is open to change if there is expressed interest in the drafts I didn'= t include, including drafts updated this week. >From my perspective, the primary objectives in this meeting will be: What do we want to do with draft-ietf-v6ops-nat64-experience? Is it done?= What changes does it still need? What do we want to do with draft-ietf-v6ops-enterprise-incremental-ipv6? = Is it done? What changes does it still need? Do we, and how do we, want to update RFC 3316? As we look at the issues brought up in the other drafts, of course we will = also be wondering what the best outcome is. Your thoughts?= From warren@kumari.net Thu Oct 18 10:37:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CA421F8507 for ; Thu, 18 Oct 2012 10:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSqgaib7E9sH for ; Thu, 18 Oct 2012 10:37:22 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3F321F8470 for ; Thu, 18 Oct 2012 10:37:22 -0700 (PDT) Received: from [10.196.196.235] (1-193.icannmeeting.org [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 885321B4015C; Thu, 18 Oct 2012 13:37:20 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Thu, 18 Oct 2012 13:37:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> To: C. M. Heard X-Mailer: Apple Mail (2.1499) Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:37:23 -0000 On Oct 17, 2012, at 4:58 PM, C. M. Heard wrote: > On Wed, 17 Oct 2012, Warren Kumari wrote: >> On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" = wrote: >>> I have been informed by individuals working for major network=20 >>> equipment vendors that their implementations can handle router=20 >>> reassembly. >>=20 >> "can handle router reassembly" !=3D "can handle router reassembly at=20= >> line rate on multiple interfaces". >>=20 >> You really need this to be line rate on all interfaces, otherwise=20 >> there is (obviously) a DoS vector here. Reassembly at 10G (or=20 >> 100G) is distinctly non-trivial and requires A: large buffers, B:=20 >> short timeouts, C: gets sad if not all bits go through the same=20 >> device, D: state and E: hardware designed specifically for this.=20 >> This is much more than packet comes in, packet goes out... >=20 > Excuse me, maybe I'm as dumb as a post, but .... why in the world=20 > are participants in this thread posing this as problem for the core? Er, we are not necessarily talking about problems for the core -- a = number of folk have 10G at the "edge" / security boundary of the = network, and this is where filtering type decisions happen. Even if you are not anywhere near approaching line-rate, you need to be = sure that the device can manage to do this work *at* line rate. If you = usually only push 1Mbps through your e.g 1Gbps interface, if the device = can only of reassembly with small fragments at 100Mbps, you have dropped = your DoS ability to 100Mbps. >=20 > Except for packets specifically destined for core infrastructure=20 > itself --- and those, surely, are not arriving at line rate=20 Yes, and part of the reason that packets are not reaching the core = infrastructure at line rate is because operators have the ability to = examine traffic destined for the core infrastructure and filter / = rate-limit it to something reasonable. I may want to allow e.g = traceroute to "core" stuff and toss that in one rate-limit bucket, but = never allow SSH towards my core. If I have fragments I have no way of = knowing what they are supposed to be part of, and so, er=85=20 > -- the=20 > core has no reason to do anything other than just pass the fragments=20= > on and let edge devices deal with them. Ah, but these are edge devices=85. >=20 > Indeed, the draft itself states that "IPv6 datagrams with=20 > fragmentation headers are a non-issue in the core of the internet,=20 > where fragments are routed just like any other IPv6 datagram. =20 > However, fragmentation creates operational ssues at the edge of the=20 > network that may lead to administratively imposed filtering or=20 > inadvertent failure to deliver the fragment to the application." Yup. W >=20 > //cmh > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- "Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead = in the water."=20 -- Tom Galvin, VeriSign's vice president for government relations. From warren@kumari.net Thu Oct 18 10:37:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB6621F8530 for ; Thu, 18 Oct 2012 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.842 X-Spam-Level: X-Spam-Status: No, score=-101.842 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll6boBwuOEU6 for ; Thu, 18 Oct 2012 10:37:56 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7FE21F8617 for ; Thu, 18 Oct 2012 10:37:56 -0700 (PDT) Received: from [10.196.196.235] (1-193.icannmeeting.org [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 117E91B40122; Thu, 18 Oct 2012 13:37:56 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <507FABDA.7060106@bogus.com> Date: Thu, 18 Oct 2012 13:37:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58DEF8A2-390B-4F24-88FC-8E76B21C96D2@kumari.net> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507FABDA.7060106@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1499) Cc: "C. M. Heard" , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:37:57 -0000 On Oct 18, 2012, at 3:12 AM, joel jaeggli wrote: > On 10/17/12 1:58 PM, C. M. Heard wrote: >> On Wed, 17 Oct 2012, Warren Kumari wrote: >>> On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" = wrote: >>>> I have been informed by individuals working for major network >>>> equipment vendors that their implementations can handle router >>>> reassembly. >>> "can handle router reassembly" !=3D "can handle router reassembly at >>> line rate on multiple interfaces". >>>=20 >>> You really need this to be line rate on all interfaces, otherwise >>> there is (obviously) a DoS vector here. Reassembly at 10G (or >>> 100G) is distinctly non-trivial and requires A: large buffers, B: >>> short timeouts, C: gets sad if not all bits go through the same >>> device, D: state and E: hardware designed specifically for this. >>> This is much more than packet comes in, packet goes out... >> Excuse me, maybe I'm as dumb as a post, but .... why in the world >> are participants in this thread posing this as problem for the core? > The fact that high capacity requirements exsit does not imply that it = a problem for the core. Yah, what he said=85 W > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" -- Terry Pratchett From Fred.L.Templin@boeing.com Thu Oct 18 10:48:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB0821F8523 for ; Thu, 18 Oct 2012 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPh3IfmlGtqI for ; Thu, 18 Oct 2012 10:48:40 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 061B721F84B5 for ; Thu, 18 Oct 2012 10:48:39 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9IHmdUZ019400 for ; Thu, 18 Oct 2012 10:48:39 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9IHmcjI019388 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 18 Oct 2012 10:48:38 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Thu, 18 Oct 2012 10:48:38 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Date: Thu, 18 Oct 2012 10:48:37 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2st9WHbPbvua5WS7Gfj11QSJ3jzwAAAfGAACfO9tA= Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:48:41 -0000 In follow-up to my last message: > One thing that is missing from the draft however is that IP > tunnels are another mildly important class of "application" > that cannot reduce the size of the packets they send down to > 1280. For them, it is either fragmentation or black hole... This is examined further in my draft ("Operational Issues with Tunnel Maximum Transmission Unit (MTU)") that saw list discussion prior to IETF84: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ The draft now notes the fragment dropping behavior discussed in 'draft-taylor-v6ops-fragdrop', and also suggests a way out of the mire for tunnels that need to use some form of fragmentation. Once again, tunnels are an important class of "application" that cannot do without some form of fragmentation capability for the tunneled packets, since they have no way of reducing the size of the packets they send down to 1280. Thanks - Fred fred.l.templin@boeing.com From marka@isc.org Thu Oct 18 15:31:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEC021F853C for ; Thu, 18 Oct 2012 15:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUKsxRJrz+M7 for ; Thu, 18 Oct 2012 15:31:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3C121F8500 for ; Thu, 18 Oct 2012 15:31:31 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3D3A7C947E; Thu, 18 Oct 2012 22:31:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 067B1216C80; Thu, 18 Oct 2012 22:31:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 28B2C2A0041D; Fri, 19 Oct 2012 09:31:21 +1100 (EST) To: Warren Kumari From: Mark Andrews References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> In-reply-to: Your message of "Thu, 18 Oct 2012 13:37:19 EDT." Date: Fri, 19 Oct 2012 09:31:21 +1100 Message-Id: <20121018223121.28B2C2A0041D@drugs.dv.isc.org> Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 22:31:32 -0000 repl: bad addresses: C. M. Heard -- no at-sign after local-part (<) In message , Warren Kumari writes: > > Yes, and part of the reason that packets are not reaching the core infrastr= > ucture at line rate is because operators have the ability to examine traffi= > c destined for the core infrastructure and filter / rate-limit it to someth= > ing reasonable. I may want to allow e.g traceroute to "core" stuff and toss= > that in one rate-limit bucket, but never allow SSH towards my core. If I = > have fragments I have no way of knowing what they are supposed to be part o= > f, and so, er=85 = So you want allow fragmented ICMP directed at core routers through and are worried that some non initial TCP fragments might make it through. As far as I can tell letting through non initial TCP fragments doesn't increase your risk or attack surface at all. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nick@inex.ie Fri Oct 19 03:46:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BAF21F843D for ; Fri, 19 Oct 2012 03:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmwXgm99ZTmS for ; Fri, 19 Oct 2012 03:46:34 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56B21F8437 for ; Fri, 19 Oct 2012 03:46:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9JAjrLf064031 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 11:45:54 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <50812F87.5000107@inex.ie> Date: Fri, 19 Oct 2012 11:46:31 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mark Andrews References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> In-Reply-To: <20121018223121.28B2C2A0041D@drugs.dv.isc.org> X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:46:35 -0000 On 18/10/2012 23:31, Mark Andrews wrote: > So you want allow fragmented ICMP directed at core routers through and are worried > that some non initial TCP fragments might make it through. As far as I can tell > letting through non initial TCP fragments doesn't increase your risk or attack > surface at all. other than causing bandwidth / pps DoS attacks, or alternatively tickling obscure ipv6 stack bugs, no. At least in theory. Nick From Fred.L.Templin@boeing.com Fri Oct 19 11:11:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836DF21F879E for ; Fri, 19 Oct 2012 11:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftedeo2g8NE5 for ; Fri, 19 Oct 2012 11:11:57 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA1A21F879B for ; Fri, 19 Oct 2012 11:11:57 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9JIBgM3027395 for ; Fri, 19 Oct 2012 11:11:42 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9JIBftn027392 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 19 Oct 2012 11:11:41 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Fri, 19 Oct 2012 11:11:55 -0700 From: "Templin, Fred L" To: Nick Hilliard , Mark Andrews Date: Fri, 19 Oct 2012 11:11:54 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2t5wgicxX5mqm/Qi+ma4jwR6NBQAAPUnHQ Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> In-Reply-To: <50812F87.5000107@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:11:57 -0000 > other than causing bandwidth / pps DoS attacks, or alternatively tickling > obscure ipv6 stack bugs, no. At least in theory. There's no excuse for broken IPv6 stacks that can't handle fragmentation and reassembly. About DoS concerns, if the network is going to intentionally break frag/reass out of concern for edge devices that might not be able to handle the load, then that is very bad for applications that cannot reduce the size of packets they send down to 1280. Again, tunnels fall into that category. So, if tunnels cannot rely on ICMP PTB and also cannot rely on IPv6 frag/reass then there is only one option remaining: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ Fred fred.l.templin@boeing.com From tom.taylor.stds@gmail.com Fri Oct 19 11:56:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2924E21F87AA for ; Fri, 19 Oct 2012 11:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktwWcdYh9OCL for ; Fri, 19 Oct 2012 11:56:09 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC69721F87AC for ; Fri, 19 Oct 2012 11:56:08 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so658186iad.31 for ; Fri, 19 Oct 2012 11:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=WyFzoSYCgPrphNleurRWKJqxPaZ4e3n8LnCcn+zei2c=; b=qCxetklT4QCYaQHPyyb8qk8t6J6mOxA+FARaPGR0Nw5FID1EFAHhflY1ydgCaZLrUX VrtyLZfbcZiaVA+clJethu9jWtR21M7JzPoAubcsSdj4i9IgnZLLQiwG0Qi9dl8SA7PV ziyEszYRJjmh+u+ecAbkIKgbEzaUnGsYxWp/KCqgao5Io/u/YlTnjvo6oa97PVvni1i1 lppI9e+BUrkqhWxbLGepnWXMJk/qw7cQvcZUC+SFrVb+6cSCpVnOCVpK5awq836dRKGJ duStUU7AgH2oVbZrAUqHSENs5uh/TyytDfwHSNfyVnrqwcc3T7Ndaj+WAvDNSJZe7Lfc Erfg== Received: by 10.50.151.238 with SMTP id ut14mr9655625igb.72.1350672968448; Fri, 19 Oct 2012 11:56:08 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.149]) by mx.google.com with ESMTPS id az6sm16393383igb.11.2012.10.19.11.56.06 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 11:56:07 -0700 (PDT) Message-ID: <5081A245.9050707@gmail.com> Date: Fri, 19 Oct 2012 14:56:05 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121019-0, 19/10/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:56:10 -0000 On 19/10/2012 2:11 PM, Templin, Fred L wrote: >> other than causing bandwidth / pps DoS attacks, or alternatively tickling >> obscure ipv6 stack bugs, no. At least in theory. > > There's no excuse for broken IPv6 stacks that can't handle > fragmentation and reassembly. About DoS concerns, if the > network is going to intentionally break frag/reass out of > concern for edge devices that might not be able to handle > the load, then that is very bad for applications that cannot > reduce the size of packets they send down to 1280. Again, > tunnels fall into that category. > > So, if tunnels cannot rely on ICMP PTB and also cannot rely > on IPv6 frag/reass then there is only one option remaining: > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > ... which, as a matter of fact, came up briefly in the Interim Meeting discussion. From Fred.L.Templin@boeing.com Fri Oct 19 13:17:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1225B21F887E for ; Fri, 19 Oct 2012 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9fka-JDdHxK for ; Fri, 19 Oct 2012 13:17:49 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 6626421F8852 for ; Fri, 19 Oct 2012 13:17:49 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9JKI0Jn007965 for ; Fri, 19 Oct 2012 13:18:00 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9JKI0nD007954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 19 Oct 2012 13:18:00 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 19 Oct 2012 13:17:48 -0700 From: "Templin, Fred L" To: Tom Taylor , "v6ops@ietf.org" Date: Fri, 19 Oct 2012 13:17:47 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2uK2u9hB0R1D98TQKNnabBvuavsgACuOSw Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5081A245.9050707@gmail.com> In-Reply-To: <5081A245.9050707@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 20:17:50 -0000 > > So, if tunnels cannot rely on ICMP PTB and also cannot rely > > on IPv6 frag/reass then there is only one option remaining: > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > > ... > which, as a matter of fact, came up briefly in the Interim Meeting > discussion. Thanks Tom; that is interesting. Here also is another one on "Operational Issues with Tunnel Maximum Transmission Unit (MTU)" - I have just updated it to cite 'fragdrop': https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ Thanks - Fred fred.l.templin@boeing.com From touch@isi.edu Fri Oct 19 15:43:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2979B21F87CD for ; Fri, 19 Oct 2012 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjBjIPogdiwM for ; Fri, 19 Oct 2012 15:42:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 74AA221F878B for ; Fri, 19 Oct 2012 15:42:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q9JMgmXv000257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Oct 2012 15:42:48 -0700 (PDT) Message-ID: <5081D768.1090803@isi.edu> Date: Fri, 19 Oct 2012 15:42:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507FAABE.5050601@bogus.com> <507FBD3D.4060909@gmail.com> In-Reply-To: <507FBD3D.4060909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:43:00 -0000 On 10/18/2012 1:26 AM, Brian E Carpenter wrote: > On 18/10/2012 08:07, joel jaeggli wrote: > ... >> The focus on core devices is misguided imho... The services edge of my >> network where both connections terminate and policy is applied may be >> substantially higher capacity than the backbone of many networks it is >> exposed to this issue. Given that I am an end-site all traffic carried >> on a backbone is either coming from or in bound to an end system on our >> network. > > Yes, and as far as I can tell the problems arise with site-boundary > devices that attempt to indulge in deep packet inspection and are > stymied by extension headers and/or fragments. Load balancers have > similar difficulties. These devices do violate the letter or spirit > of RFC 2460, but that's life. Life's a b*tch for such devices. Let's keep it that way. ;-) Joe From warren@kumari.net Fri Oct 19 17:49:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA17F21F8522 for ; Fri, 19 Oct 2012 17:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3nPBN7c+rGf for ; Fri, 19 Oct 2012 17:49:42 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B02F21F8903 for ; Fri, 19 Oct 2012 17:49:41 -0700 (PDT) Received: from [10.196.219.128] (1-195.icannmeeting.org [199.91.195.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 0869A1B401C3; Fri, 19 Oct 2012 20:49:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <20121018223121.28B2C2A0041D@drugs.dv.isc.org> Date: Fri, 19 Oct 2012 20:49:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 00:49:43 -0000 On Oct 18, 2012, at 6:31 PM, Mark Andrews wrote: >=20 > repl: bad addresses: > C. M. Heard -- no at-sign after local-part (<) >=20 > In message , Warren = Kumari writes: >>=20 >> Yes, and part of the reason that packets are not reaching the core = infrastr=3D >> ucture at line rate is because operators have the ability to examine = traffi=3D >> c destined for the core infrastructure and filter / rate-limit it to = someth=3D >> ing reasonable. I may want to allow e.g traceroute to "core" stuff = and toss=3D >> that in one rate-limit bucket, but never allow SSH towards my core. = If I =3D >> have fragments I have no way of knowing what they are supposed to be = part o=3D >> f, and so, er=3D85 =3D >=20 > So you want allow fragmented ICMP directed at core routers through and = are worried > that some non initial TCP fragments might make it through. As far as = I can tell > letting through non initial TCP fragments doesn't increase your risk = or attack > surface at all. Ah, sorry, I guess I was unclear -- the connection from the data plane = to the control plane is much much smaller than the data plane = interfaces. This means that I need to protect the CP / CP interface by = classifying and filtering / policing / rate-limiting traffic before it = hits the CP interface. This means that I need to be able to examine the = traffic to classify it. If I get a fragment, I have no way of knowing = what it is for, and so have no way of knowing which rate-limiter to = apply. This means I can a: just drop it, b: guess at a classification, = c: have a classifier for all fragments or d: just accept all frags. This is part of a more general problem -- if I have a router with a 10G = interface facing "the Internet"[0] and e.g a webserver connected behind = it with a 1G interface I'd like to make sure that only port 80/443 = traffic is vying for the limited bandwidth. As I cannot reassemble on = the router, I cannot classify what non-initial fragments are to know if = they should be allowed. Yes, an attacker can (obviously) still DoS me with >1Gbps of traffic on = port 80, but at least I can filter out the stupid attacks on other ports = (which works surprisingly well :-P) W=20 [0]: any network filled with badness... > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 -- Curse the dark, or light a match. You decide, it's your dark. -- Valdis Kletnieks From heard@pobox.com Sat Oct 20 11:42:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E75921F846B for ; Sat, 20 Oct 2012 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZpvXWuMTHcY for ; Sat, 20 Oct 2012 11:42:42 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514C621F89CF for ; Sat, 20 Oct 2012 11:42:40 -0700 (PDT) Received: (qmail 11216 invoked from network); 20 Oct 2012 11:42:39 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Oct 2012 11:42:39 -0700 Date: Sat, 20 Oct 2012 11:42:39 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: V6 Ops In-Reply-To: Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 18:42:43 -0000 On Fri, 19 Oct 2012, Warren Kumari wrote: > Ah, sorry, I guess I was unclear -- the connection from the data > plane to the control plane is much much smaller than the data > plane interfaces. This means that I need to protect the CP / CP > interface by classifying and filtering / policing / rate-limiting > traffic before it hits the CP interface. This means that I need to > be able to examine the traffic to classify it. If I get a > fragment, I have no way of knowing what it is for, and so have no > way of knowing which rate-limiter to apply. This means I can a: > just drop it, b: guess at a classification, c: have a classifier > for all fragments or d: just accept all frags. > > This is part of a more general problem -- if I have a router with > a 10G interface facing "the Internet"[0] and e.g a webserver > connected behind it with a 1G interface I'd like to make sure that > only port 80/443 traffic is vying for the limited bandwidth. As I > cannot reassemble on the router, I cannot classify what > non-initial fragments are to know if they should be allowed. Yes, > an attacker can (obviously) still DoS me with >1Gbps of traffic on > port 80, but at least I can filter out the stupid attacks on other > ports (which works surprisingly well :-P) Circling back to my original comments about this draft, this is precisely the sort of information that needs to be added to Section 2.1 to justify the assertion that "some cases will remain where legitimate fragments are discarded for legitimate reasons." (FWIW, I am not sure that I agree that the reasons for discarding legitimate fragments are actually legitimate, but Warren Kumari's analysis does explain why some people do it. It may or may not be in scope for the draft to suggest less destructive ways for operators to solve this class of problems.) //cmh From diego@tid.es Sun Oct 21 03:02:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DD321F8967 for ; Sun, 21 Oct 2012 03:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlm2PgeXiLwX for ; Sun, 21 Oct 2012 03:02:55 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFC5921F896B for ; Sun, 21 Oct 2012 03:02:54 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MC800M6SMKLNA@tid.hi.inet> for v6ops@ietf.org; Sun, 21 Oct 2012 12:02:53 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 2B.6A.03050.D48C3805; Sun, 21 Oct 2012 12:02:53 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MC800M7IMKTNA@tid.hi.inet> for v6ops@ietf.org; Sun, 21 Oct 2012 12:02:53 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.178]) by EX10-HTCAS6-MAD.hi.inet ([fe80::e1e3:e2fc:beda:deb9%15]) with mapi id 14.02.0318.004; Sun, 21 Oct 2012 12:02:52 +0200 Date: Sun, 21 Oct 2012 10:02:52 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: IPv6 Ops WG Message-id: Content-id: <428204E72A54674F83E6FD80BFA16145@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: New version of draft-lopez-v6ops-dc-ipv6 Thread-index: AQHNr3M8j4EugeD3fkKjjO1OoT0HCA== X-AuditID: 0a5f4068-b7f176d000000bea-6b-5083c84dda98 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsXCFe/Apet7ojnA4PxGUYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/KGfpaCF9wV5388YmlgPMDdxcjJISFgInF5QwcjhC0mceHe erYuRi4OIYGNjBK3Ltxkh3B+MkpM2ryPFcLZxCjxYPN6sBYWAVWJG8umMYPYbED2o+bf7CC2 sIChRPPPi8wQYxUk/px7zAJiiwDZO/7vZAKxeQW8JQ7uXccKYjMLmEks/rALKi4o8WPyPaB6 DqC4usSUKbkQJeISza03WSBsRYlpixrATmAUkJV4N38+K8R4M4klVzYwgrSKCOhJfD5eD3GB gMSSPeehrhGVePn4H1i5kICjxP91V1knMIrNQnLELCRHzEI4YhaSI2YhOWIBI+sqRrHipKLM 9IyS3MTMnHQDQ72MTL3MvNSSTYyQGMrYwbh8p8ohRgEORiUeXoWpjQFCrIllxZW5hxglOZiU RHmN9zQHCPEl5adUZiQWZ8QXleakFh9ilOBgVhLhbZoKlONNSaysSi3Kh0nJcHAoSfDyHwdK CRalpqdWpGXmABMFTJqJgxOknQeo/ckxkPbigsTc4sx0iPwpRlWOxp5FDxmFWPLy81KlxHl/ gBQJgBRllObBzXnFKA50sDDvR5AsDzDVwU14BTScCWi4OXcjyPCSRISUFDBerPzt/GrsPzI/ tdhweP6Gz52xzB/4GXqeG4SdLzn/ctJhK8VaC4791ck7g57I9WzIl1QR3VjMZ/9ykrbgV2e3 ned/KOQHb76k7Hjh29rHN491PZst+Hq/5w8XNYPDL7/MEP5nv3yvq2TmOd0+7XMXw45s2D7x CPta5XuKXV19Mr4Tjk/rXmakxFKckWioxVxUnAgAjo/NQjIDAAA= References: <20121020200652.28676.43201.idtracker@ietfa.amsl.com> Subject: [v6ops] New version of draft-lopez-v6ops-dc-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 10:02:56 -0000 SGksDQoNClRoaXMgbmV3IHZlcnNpb24gaW5jb3Jwb3JhdGVzIGFsbCB0aGUgY2hhbmdlcyBkaXNj dXNzZWQgaW4gVmFuY291dmVyLA0KYmVpbmcgdGhlIG1vc3Qgc2FsaWVudCBhIHRpdGxlIGNoYW5n ZSBhbmQgdGhlIHJlbmFtaW5nIG9mIHRoZSAibWF0dXJpdHkNCmxldmVscyIgKGFuZCB0aGVpciBu dW1iZXJzKSBpbnRvIG5hbWVkICJ0cmFuc2l0aW9uIHN0YWdlcyIsIHBsdXMgbW9yZQ0KZWxhYm9y YXRlZCB0ZXh0IGZvciBleGFtcGxlcyBhdCBlYWNoIHRyYW5zaXRpb24gc3RhZ2UsIGFuZCBhIGZp cnN0IGZ1bGwNCmF0dGVtcHQgZm9yIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCg0KaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2DQoN CkRpZmYgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbG9wZXotdjZvcHMt ZGMtaXB2Ni0wMw0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBE b2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0 cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpU ZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVu dsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0 dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZv ciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJh c2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5B Uy9kaXNjbGFpbWVyLmFzcHgNCg== From nick@inex.ie Mon Oct 22 04:44:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945A321F8B60 for ; Mon, 22 Oct 2012 04:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63AtPIdYemFW for ; Mon, 22 Oct 2012 04:44:45 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 00EEF21F8B3E for ; Mon, 22 Oct 2012 04:44:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.internal.acquirer.com ([IPv6:2001:1bb8:2004:100:30d1:9a8a:a66f:224e]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9MBhkYw097929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 12:43:47 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <5085319B.60707@inex.ie> Date: Mon, 22 Oct 2012 12:44:27 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:44:46 -0000 On 19/10/2012 19:11, Templin, Fred L wrote: > There's no excuse for broken IPv6 stacks that can't handle > fragmentation and reassembly. Here is a pile of excuses which many smaller providers find compelling enough to agree with: http://www.ebay.com/sch/i.html?_nkw=cisco+sup720 This kit is cheap, will drive 10G ports, provides good 1G density and does all sorts of useful packet hackery. As a result, this kit is very widely deployed and will continue to be for many years. So, what do we do? Do we: - ignore the problem - issue generic advice - name and shame - other Nick From swmike@swm.pp.se Mon Oct 22 05:44:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4D21F8B32 for ; Mon, 22 Oct 2012 05:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK0gI+5pKoX4 for ; Mon, 22 Oct 2012 05:44:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 75E5621F8A87 for ; Mon, 22 Oct 2012 05:44:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 261A39E; Mon, 22 Oct 2012 14:44:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A92A39C; Mon, 22 Oct 2012 14:44:27 +0200 (CEST) Date: Mon, 22 Oct 2012 14:44:27 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <5085319B.60707@inex.ie> Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:44:32 -0000 On Mon, 22 Oct 2012, Nick Hilliard wrote: > So, what do we do? Do we: > > - ignore the problem > - issue generic advice > - name and shame > - other Another data point: So quite a lot of people running SUP720 will in the end disable IPv6 fragment acl:s using the command provided. Quite a few others will not know about this and will thus give very different service to packets with fragmentation header and those without fragmentation header. -- Mikael Abrahamsson email: swmike@swm.pp.se From joelja@bogus.com Mon Oct 22 09:42:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D821F8B7E for ; Mon, 22 Oct 2012 09:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48JkyLf+sH7C for ; Mon, 22 Oct 2012 09:42:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD83D21F843E for ; Mon, 22 Oct 2012 09:42:44 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9MGgeof020533 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 22 Oct 2012 16:42:41 GMT (envelope-from joelja@bogus.com) Message-ID: <5085777C.2010404@bogus.com> Date: Mon, 22 Oct 2012 09:42:36 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: Tom Taylor References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5081A245.9050707@gmail.com> In-Reply-To: <5081A245.9050707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 22 Oct 2012 16:42:41 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:42:45 -0000 On 10/19/12 11:56 AM, Tom Taylor wrote: > On 19/10/2012 2:11 PM, Templin, Fred L wrote: >>> other than causing bandwidth / pps DoS attacks, or alternatively >>> tickling >>> obscure ipv6 stack bugs, no. At least in theory. >> >> There's no excuse for broken IPv6 stacks that can't handle >> fragmentation and reassembly. About DoS concerns, if the >> network is going to intentionally break frag/reass out of >> concern for edge devices that might not be able to handle >> the load, then that is very bad for applications that cannot >> reduce the size of packets they send down to 1280. Again, >> tunnels fall into that category. >> >> So, if tunnels cannot rely on ICMP PTB and also cannot rely >> on IPv6 frag/reass then there is only one option remaining: >> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ They can implement fragmentation in their upper layer encapsulation rather than using the ip fragmentation header and two or more fragmented ip datagrams in addition to seal, SSL/TLS-vpn's and SSTP have to do the same thing... >> . > which, as a matter of fact, came up briefly in the Interim Meeting > discussion. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From bs7652@att.com Mon Oct 22 10:30:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7C811E80A2 for ; Mon, 22 Oct 2012 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZFBNAY-RG1f for ; Mon, 22 Oct 2012 10:30:44 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF811E8097 for ; Mon, 22 Oct 2012 10:30:43 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 3c285805.2aaacd007940.331204.00-583.917588.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 22 Oct 2012 17:30:43 +0000 (UTC) X-MXL-Hash: 508582c3055fbc00-5bdaab335ffcc8a116c7d02fd5dd3ce933cf2bcf Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 9b285805.0.331095.00-214.917266.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 22 Oct 2012 17:30:34 +0000 (UTC) X-MXL-Hash: 508582ba607177e5-5326feafb51509f2acefa8df56ef2782e4829918 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9MHUW2O016637; Mon, 22 Oct 2012 13:30:32 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9MHUPlv016463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 13:30:26 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 22 Oct 2012 13:30:05 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 13:30:04 -0400 From: "STARK, BARBARA H" To: yangtianle , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select Thread-Index: Ac2wetzLw7pu3mdbS+yC0ux/g3O5nQ== Date: Mon, 22 Oct 2012 17:30:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61124468D5C@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.248.249] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YJMoP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=ayhGUGlgbOMA:10 a=S7D8gkT1K50A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=ZPSk82zQDygA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=gcwm6WdRUFAA:10 a=48vgC7mUAAAA:8 a=wRfcpK44pyn8BY] X-AnalysisOut: [CW_WUA:9 a=UAVRJdkkkM0A:10 a=XFkM5qLZ0iYCHMw3:21 a=7WMsgHH] X-AnalysisOut: [fFyt8AKjs:21] Subject: Re: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:30:45 -0000 Since no-one else has replied to this, I'll provide my thoughts. My personal opinion is that I do not consider the proposed DHCP options to = be particularly useful. My primary concern: The draft states that these options are being proposed for the purpose of I= Pv6 transition trials and experiments. As such, I would be opposed to recom= mending that CE router manufacturers implement the options -- I do not beli= eve that all manufacturers of retail or operator-provided CE routers worldw= ide should feel in any way obliged to provide experimental and trial capabi= lities. And if these options are not recommended and implemented, then they= serve no use. If the only routers implementing the options are from vendor= s being influenced by providers doing these trials, then the same effect co= uld be had by the provider (or even a group of providers) publishing vendor= -specific DHCPv4 and DHCPv6 options. Also note that there is not a long-ter= m need to support capabilities enabling trials and experiments of IPv6 tran= sition technologies -- at least, I sure hope it's not a long-term need. My secondary comments: The authors do not explain why existing 6rd DHCPv4 configuration option, DS= -Lite DHCPv6 options, and DHCPv4 IPv4 address offers + DHCPv6 IA_PD/IA_NA a= re insufficient for configuration of 6rd, DS-Lite, and "dual stack". It is = true that many retail CE routers disable these functions in their factory d= efault configurations. However, it is quite possible to develop code in suc= h a way that the capabilities are automatically enabled when their existing= configuration options are received. Since code that requires manual enabli= ng/disabling is much simpler, I support manufacturers' freedom to choose th= e simpler route when coding these functions. But in provider-procured CE ro= uters, it should be very possible for the provider to specify the desired b= ehavior. The authors suggest that remote management of CE routers (especially when m= ultiple vendors are involved) is problematic. However, I believe that many = providers have successfully used TR-069 or SNMP to manage the IPv6 capabili= ties of devices they provide (which may be from a variety of vendors). Thes= e are standard management protocols that are widely implemented, and there = exist standard IPv6 TR-069 data models and SNMP MIBs for managing these cap= abilities. I believe that a number of providers worldwide have done trails = and deployments of these IPv6 technologies, and have been able to successfu= lly manage these capabilities in the CE routers that they have provided.=20 I am aware that many providers choose not to manage CE routers that they pr= ovide, or do not even provide CE routers (so customers must purchase a reta= il CE router, if they want a CE router). But since this is not a practice o= r problem shared by all operators, and is a choice that each operator is fr= ee to make, I would again say that I am opposed to requiring all operators'= CE routers to have these DHCP options, and I am opposed to recommending th= at vendors of retail CE routers should feel obliged to implement a new opti= on just so their equipment can be used in such trials. I am aware of severa= l providers who have customers who do not have the option of operator-provi= ded CE routers, who are successfully conducting trials or deployments of 6r= d. Personally, I subscribe to broadband connections from 2 different provid= ers, neither of whom provides me with the option of getting a CE router fro= m them. Both have published their 6rd connectivity information and freely a= llow any of their customers to participate in these trials. I have chosen t= o participate in both of these trials. When I received an email from one of= my providers that I could do IPv6 using 6rd, I went to my local electronic= s superstore, bought the cheapest IPv6/6rd-capable router (as noted on the = packaging) that I could find, and tried it out. It was incredibly easy. But= given that I had to purposefully make the trip to the store and carefully = read the packaging, I think it's pretty clear that such trials are targeted= at people like me, and not at "average" consumers. It was also interesting= to note that most of the CE routers on the store shelves were not 6rd-capa= ble. If an "average" consumer happens (by pure coincidence) to purchase a = 6rd-capable router, I don't think it's a very good idea to try to automate = that customer's 6rd trial participation. If an operator is so unsure of or = uncommitted to a technology that they are not willing to fully deploy it, t= hen causing unsuspecting customers to participate in a trial may not be the= best idea. Because I knew that I was enabling IPv6, I could have easily di= sabled it, if my Internet connectivity experience had been negatively impac= ted. Unsuspecting, automatically-participating, "average" customers would n= ot be so fortunate. I recognize that there are regional variations in operator behavior. But, a= gain, I would like to suggest that it is possible for operators in a partic= ular region to publish their own vendor-specific DHCP options, and influenc= e manufacturers doing business in that region to implement them. Or they ca= n publish the information (as both of my providers have done) and allow for= purely voluntary participation by "technologically savvy" customers. There= is no need for a world-wide standardized DHCP option for conducting trials= and experiments of IPv6 transition technologies. Barbara > -----Original Message----- > We find some inconvenient issues about CPE when we do IPv6 trials and > experiments: > 1=1B$B!"=1B(BISP must pre-configure IPv6 transition technology i= n CPE, such as > dual-stack, DS-Lite, and so on. > 2=1B$B!"=1B(BOtherwise, ISP must rely on Manage System to contro= l CPEs. But if > CPEs are form different manufactories, they need different Manage System, > or to develop consistent interface in the Manage System. > 3=1B$B!"=1B(BIf users change the CPE ISP giving to them to anoth= er one with > incorrect configuration, or configure CPE incorrectly by mistake, they ca= nnot > access internet. > In this document, we propose a solution to solve the problem. But, the mo= st > important issue is to propose this problem, not the solution. >=20 > Wish for your comments. Thank you! >=20 > Tianle Yang >=20 > A new draft has been posted, at > http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select. Please take = a > look at it and comment. From Fred.L.Templin@boeing.com Mon Oct 22 10:46:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3A11E80A2 for ; Mon, 22 Oct 2012 10:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0fYi43XPy4g for ; Mon, 22 Oct 2012 10:46:19 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B811E80DE for ; Mon, 22 Oct 2012 10:46:19 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9MHkIOb002510 for ; Mon, 22 Oct 2012 10:46:18 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9MHkHVY002475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Oct 2012 10:46:18 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 22 Oct 2012 10:46:17 -0700 From: "Templin, Fred L" To: joel jaeggli , Tom Taylor Date: Mon, 22 Oct 2012 10:46:16 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2wdGVfBNt0PMGuQnqjus/ERL4DgAACGrZw Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5081A245.9050707@gmail.com> <5085777C.2010404@bogus.com> In-Reply-To: <5085777C.2010404@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:46:20 -0000 Hi Joel, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > joel jaeggli > Sent: Monday, October 22, 2012 9:43 AM > To: Tom Taylor > Cc: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > On 10/19/12 11:56 AM, Tom Taylor wrote: > > On 19/10/2012 2:11 PM, Templin, Fred L wrote: > >>> other than causing bandwidth / pps DoS attacks, or alternatively > >>> tickling > >>> obscure ipv6 stack bugs, no. At least in theory. > >> > >> There's no excuse for broken IPv6 stacks that can't handle > >> fragmentation and reassembly. About DoS concerns, if the > >> network is going to intentionally break frag/reass out of > >> concern for edge devices that might not be able to handle > >> the load, then that is very bad for applications that cannot > >> reduce the size of packets they send down to 1280. Again, > >> tunnels fall into that category. > >> > >> So, if tunnels cannot rely on ICMP PTB and also cannot rely > >> on IPv6 frag/reass then there is only one option remaining: > >> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ >=20 > They can implement fragmentation in their upper layer encapsulation > rather than using the ip fragmentation header and two or more fragmented > ip datagrams in addition to seal, SSL/TLS-vpn's and SSTP have to do the > same thing... Do you know whether the DoS considerations discussed in this thread apply also for SSL/TLS and SSTP when there is fragmentation in the upper layers? Thanks - Fred fred.l.templin@boeing.com > > which, as a matter of fact, came up briefly in the Interim Meeting > > discussion. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Mon Oct 22 11:27:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1311E80ED for ; Mon, 22 Oct 2012 11:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1uEB1i2OMRH for ; Mon, 22 Oct 2012 11:27:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1F11E80E7 for ; Mon, 22 Oct 2012 11:27:54 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9MIRnBw021929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 22 Oct 2012 18:27:49 GMT (envelope-from joelja@bogus.com) Message-ID: <50859022.5070709@bogus.com> Date: Mon, 22 Oct 2012 11:27:46 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5081A245.9050707@gmail.com> <5085777C.2010404@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 22 Oct 2012 18:27:49 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:27:55 -0000 On 10/22/12 10:46 AM, Templin, Fred L wrote: > Hi Joel, > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> joel jaeggli >> Sent: Monday, October 22, 2012 9:43 AM >> To: Tom Taylor >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >> >> On 10/19/12 11:56 AM, Tom Taylor wrote: >>> On 19/10/2012 2:11 PM, Templin, Fred L wrote: >>>>> other than causing bandwidth / pps DoS attacks, or alternatively >>>>> tickling >>>>> obscure ipv6 stack bugs, no. At least in theory. >>>> There's no excuse for broken IPv6 stacks that can't handle >>>> fragmentation and reassembly. About DoS concerns, if the >>>> network is going to intentionally break frag/reass out of >>>> concern for edge devices that might not be able to handle >>>> the load, then that is very bad for applications that cannot >>>> reduce the size of packets they send down to 1280. Again, >>>> tunnels fall into that category. >>>> >>>> So, if tunnels cannot rely on ICMP PTB and also cannot rely >>>> on IPv6 frag/reass then there is only one option remaining: >>>> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ >> They can implement fragmentation in their upper layer encapsulation >> rather than using the ip fragmentation header and two or more fragmented >> ip datagrams in addition to seal, SSL/TLS-vpn's and SSTP have to do the >> same thing... > Do you know whether the DoS considerations discussed in this thread > apply also for SSL/TLS and SSTP when there is fragmentation in the > upper layers? Speaking entirely for my own case the reason we actually use the stateless l3/l4 hash on our edge in front of a stateful edge that therefore has issues with hashed fragements ending up on different load balancers is becuase we have to load-balance SSL. > Thanks - Fred > fred.l.templin@boeing.com > >>> which, as a matter of fact, came up briefly in the Interim Meeting >>> discussion. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From philip_matthews@magma.ca Mon Oct 22 11:28:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DF211E80FB for ; Mon, 22 Oct 2012 11:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z4LN2d8PKf4 for ; Mon, 22 Oct 2012 11:28:56 -0700 (PDT) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id E1A8511E80F7 for ; Mon, 22 Oct 2012 11:28:55 -0700 (PDT) Received: from [74.198.165.111] (helo=[172.20.10.2]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TQMk9-0005yP-1b for v6ops@ietf.org; Mon, 22 Oct 2012 14:28:54 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2012 14:28:49 -0400 Message-Id: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> To: "v6ops@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.111] Subject: [v6ops] New version of Design Guidelines draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:28:56 -0000 Folks: I have just posted a new version (-01) of the Design Guidelines draft: = https://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines/ = OR = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01 This version is pretty much a complete rewrite of the document. It = incorporates all the tremendous feedback that I received by email and = during the lengthy discussion at IETF-84 in Vancouver. Many thanks to = the many, many people who gave me feedback. I spent quite a few hours = going through my emails and listening to the audio recording in an = effort to capture everyone's feedback. If you feel I somehow forgot or = mis-interpreted your comment, please let me know. This version of the document is somewhat more definite in some of its = recommendations than the previous version. For design choices where I = felt that the comments received overwhelming favored one option, the new = version reflects this sentiment. For example, I felt there was a strong = consensus at the last WG meeting that operators should mix IPv4 and IPv6 = traffic on a single logical link wherever possible, though I noted that = device limitations may require separating them in some cases (e.g. to = get good traffic statistics). Comments on this new version are most welcome. - Philip From fernando@gont.com.ar Mon Oct 22 19:46:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4F1F0429; Mon, 22 Oct 2012 19:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+VWE5hEUY04; Mon, 22 Oct 2012 19:45:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7B21F843B; Mon, 22 Oct 2012 19:45:59 -0700 (PDT) Received: from [186.134.30.80] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQUV8-00073w-MH; Tue, 23 Oct 2012 04:45:55 +0200 Message-ID: <5085F644.5030206@gont.com.ar> Date: Mon, 22 Oct 2012 22:43:32 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" , "opsec@ietf.org" Subject: Re: [v6ops] Passive IP addresses - 2th iteration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:46:00 -0000 Folks, [Disclaimer: I'm catching up with email, and may ahve missed important discussions] On 10/07/2012 06:29 AM, Gunter Van de Velde (gvandeve) wrote: > Q) what does the passive keyword result into > > A) If the recipient device receives an IP packet with this passive > address in the destination address and is destined for this device, then > the packet will be dropped. However, when the device gets for example a > packet with TTL expired (for trace-route) then this passive address > could be used as the source address Is this any different from an IPv6 "alias" + the corresponding ACLs? Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Tue Oct 23 01:19:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8221F846B for ; Tue, 23 Oct 2012 01:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxG9E9PsZUyz for ; Tue, 23 Oct 2012 01:19:05 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6F65721F8441 for ; Tue, 23 Oct 2012 01:19:05 -0700 (PDT) Received: from [186.134.9.99] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQZhS-0007Mq-MA; Tue, 23 Oct 2012 10:18:58 +0200 Message-ID: <508652EC.3070204@si6networks.com> Date: Tue, 23 Oct 2012 05:18:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Gert Doering References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> In-Reply-To: <20121016112137.GG13776@Space.Net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:19:06 -0000 On 10/16/2012 08:21 AM, Gert Doering wrote: > Hi, > > On Tue, Oct 16, 2012 at 08:07:08AM +0100, Brian E Carpenter wrote: >> Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438. > > So how exactly is "filter based on an arbitrary value the attacker can > control" better than "just let non-initial fragments through"? I think Brian was referring to hashing, rather than filtering. And when it comes to hashing, the FL is present in all fragments, while the upper-layer header isn't. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Oct 23 01:28:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C621F8654 for ; Tue, 23 Oct 2012 01:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wqDftCtms5p for ; Tue, 23 Oct 2012 01:28:33 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D5CD721F846B for ; Tue, 23 Oct 2012 01:28:32 -0700 (PDT) Received: from [186.134.9.99] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQZqY-0007da-5Y; Tue, 23 Oct 2012 10:28:22 +0200 Message-ID: <5086551F.6060600@si6networks.com> Date: Tue, 23 Oct 2012 05:28:15 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:28:33 -0000 Hi, Fred, On 10/16/2012 03:20 PM, Templin, Fred L wrote: > This report is troubling to me. One of the unspoken tenets of > IPv6 is that it fixes fragmentation and reassembly, for example > by including a large-enough Identification field to avoid wrapping > issues at high data rates (see RFC4963). -- that's assuming the fragments don't go trough a translator... Otherwise, the "effective" Frag-ID length is still 16 bits. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Oct 23 01:30:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3213521F86A7 for ; Tue, 23 Oct 2012 01:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxs--lcwC3+b for ; Tue, 23 Oct 2012 01:30:16 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A4DB121F869E for ; Tue, 23 Oct 2012 01:30:16 -0700 (PDT) Received: from [186.134.9.99] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQZsE-0007f5-Ko; Tue, 23 Oct 2012 10:30:06 +0200 Message-ID: <50865589.7040100@si6networks.com> Date: Tue, 23 Oct 2012 05:30:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> In-Reply-To: <507DAB13.2010704@inex.ie> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:30:17 -0000 On 10/16/2012 03:44 PM, Nick Hilliard wrote: > On 16/10/2012 19:42, Templin, Fred L wrote: >> Why not just let non-initial fragments through and then forward >> or don't forward the initial fragment depending on whether it >> contains enough information in tlv headers to permit a filtering >> decision? > > i spot some DoSs there. This is no different than the attacker sending non-initial fragments in the first place.... Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Oct 23 01:32:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9193C21F867B for ; Tue, 23 Oct 2012 01:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qABcn0iX0yCf for ; Tue, 23 Oct 2012 01:32:10 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2DD21F863B for ; Tue, 23 Oct 2012 01:32:10 -0700 (PDT) Received: from [186.134.9.99] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQZu3-0007m3-OX; Tue, 23 Oct 2012 10:32:00 +0200 Message-ID: <508655FA.1080407@si6networks.com> Date: Tue, 23 Oct 2012 05:31:54 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:32:10 -0000 On 10/16/2012 03:49 PM, Templin, Fred L wrote: > Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 > fragmentation/reassembly, then all we are left with is 1280 > and IPv6 is the new ATM... ... and that's assuming no translators, and that the IPv6 Internet really complies with the minimum IPv6 MTU (something that some argue that it's not the case). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From lorenzo@google.com Tue Oct 23 01:39:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0921F86B6 for ; Tue, 23 Oct 2012 01:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0fu7blkJoT7 for ; Tue, 23 Oct 2012 01:39:44 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43D4A21F845F for ; Tue, 23 Oct 2012 01:39:44 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3949949oag.31 for ; Tue, 23 Oct 2012 01:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4wpwlJB+f1/Nd9cMiBYJuywtA08qdrqUnoT9RuR0uxI=; b=M6aAwdgZHAzV8J+19Nkt3Xj5FDan5wNpBVcRxMnXrQeEJH2xSF+DTAQ2Cu8t+x7NV0 njWM5kfdRsaYTLdtUsdENvBo2blgRdaZVR/FPB+w3sYQNzl6qiU7Z0WE5E2OR+XSRqql y/OYPe9362cKcjRdl4ge7zioZfoqhqfEmL49b+JiI2mGibEGTK+3DSbnbTbpfuwuLH+d QLExeY3kvg0fsU25XtYD6KFR7JNgb1b2+qm12QaVTGzzqlr1TrmeDakcWTOM3P0q1/Gi BTrqwc3oGz9QJOdbv2nkdGut/AbfmKDbxvxDZ8s00wGVCwdH1dI3tcVYHXl7GEgn+3cK ARdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=4wpwlJB+f1/Nd9cMiBYJuywtA08qdrqUnoT9RuR0uxI=; b=gVD7jjif/LPDtAuhtBjq6Xi0lvJPdd3/OEAU95DTiEfHeaEti605AnbbYyFhA9sUGF OrrjTpcWIjm1EUqoSvAkVLzhDeBsAgX4/vJL3rPCXQmxSPed9rAgmyMP9ZphxnC9QnEc mSOlp/bFgV0BQnJl5BhQ5VDc2ELZxzGLvV9oT8gV1SGfRKIUFcNCOWEKYR2zHkk0UMrE pWzHdZ3UOWjLCjKr4oVS21/zdKqjn3yJVpHxDZwNT/18BIfzLWbghwNrucBIEglpKatE +y+HVFEpMoRhnJcii4K1cVxxKoY8IRTSUBF6KZBPWRL86ahQDXeZUDb2/Y8Ac8be2XU4 tJKw== Received: by 10.60.5.138 with SMTP id s10mr10183452oes.80.1350981583759; Tue, 23 Oct 2012 01:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 23 Oct 2012 01:39:23 -0700 (PDT) In-Reply-To: <5085319B.60707@inex.ie> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> From: Lorenzo Colitti Date: Tue, 23 Oct 2012 17:39:23 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=e89a8ff252ce65e84404ccb5e95b X-System-Of-Record: true X-Gm-Message-State: ALoCoQl0cdTq843YdxyDdxxkHOMBhH+fCsRjAxUZEUtoOV2AZmjGM405BDVmj0WB/7z+P6VVXS0jMvvUJIkhL6Q4s5GSzmK5pt2XR6U+7Ut+bWUIJ7yQjK7JLmJS/cc2L5Ix2umhqG0G+0syOiEr26Kg02n2ju3XEUddXTQtmTPv09MfohbySvx18U8zvRzJZS7vj6GuzOGf Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:39:45 -0000 --e89a8ff252ce65e84404ccb5e95b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: > So, what do we do? Do we: > > - ignore the problem > - issue generic advice > - name and shame > - other > Other. Document that some networks drop fragments, the reasons why they do so, and the impact on applications, but provide no advice. It's unlikely that this group, let alone the IETF, would agree on what advice to give (at least this decade), but I think it is the responsibility of an operations group to document real operational issues, so the rest of the community, including application developers and protocol developers, can be made aware of it. --e89a8ff252ce65e84404ccb5e95b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard <nick@inex.ie> wro= te:
So, what do we do? =A0Do we:

- ignore the problem
- issue generic advice
- name and shame
- other

Other. Document that some netwo= rks drop fragments, the reasons why they do so, and the impact on applicati= ons, but provide no advice.

It's unlikely that= this group, let alone the IETF, would agree on what advice to give (at lea= st this decade), but I think it is the responsibility of an operations grou= p to document real operational issues, so the rest of the community, includ= ing application developers and protocol developers, can be made aware of it= .
--e89a8ff252ce65e84404ccb5e95b-- From lorenzo@google.com Tue Oct 23 01:49:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C014621F8654 for ; Tue, 23 Oct 2012 01:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyyj6Pe7C7hw for ; Tue, 23 Oct 2012 01:49:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4133321F8643 for ; Tue, 23 Oct 2012 01:49:50 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3916293obq.31 for ; Tue, 23 Oct 2012 01:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=WK24nLJRUrsHOdTgPALyr7rLr0SWf+t5/23/CrSHa+Q=; b=XEL8eWkDO6fKWmXG8qpi1G7+QmhYHBK8leMATxq0dXvwF8qDJC888qG50dCPo2pXTY /3lbNuQsTXcopxn51FoVSVAGYQb0ehqpFFriPEQJKbZIDjjFIdqatUh0l5N6AHxsXydv Ub5UCqioq5IiGOjR25TsfSu71PXyGX6Ry3kCKh5kHI4DKtRKdAgYfrKRj+N3wxuVKfsr 5LFWYPNIMeGAKt7MPdNGiAPHel0qgNlOCQYmU5Xz57la1dyGLBFNd/kLn6j/hxe955nL vDEsoFuZB5MY9rLsqay4O+UcJBN+cnnz0PaBJdg6cAwcGpSDALV+OCMbPvGLnnt2+Isf 8ZQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=WK24nLJRUrsHOdTgPALyr7rLr0SWf+t5/23/CrSHa+Q=; b=XT5DAxhCR+1FfQg2D5h6sEBrK7Q4UcaZNfNg5XiNMRYK2oq4Pj3VHCUUJvs/aA7u26 GjpuIPVX8573bNU4CxFix7VXwGTAL2TzQ6nlGf7zGrxsnmXIKRbwHEv+Di50+UeO8AJM tdz1L3UdY9ExDlPvf1aNZvnjZs1qSkYPWlmBom9MZjdFJvtKG3aYPkN+3hbQQBhJfO/7 3FPQgj7DKSuFTwk5Lzf4Djrafgh/mGbnggzspR5BN2IVW6CFOZmBWuIEDXNdxI5NLFLM VeGquBqF+mZIGQOgU523XBYVRJiWVYpihUFigoH2kziS1g4ql3DuC++ihaB4oKNBbZ8E DIOw== Received: by 10.182.150.37 with SMTP id uf5mr9321993obb.10.1350982189762; Tue, 23 Oct 2012 01:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 23 Oct 2012 01:49:28 -0700 (PDT) In-Reply-To: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> From: Lorenzo Colitti Date: Tue, 23 Oct 2012 17:49:28 +0900 Message-ID: To: "C. M. Heard" Content-Type: multipart/alternative; boundary=bcaec51f955584c88104ccb60de1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmzsYWriBn9OkSunG56DdOCK2rMy4OvRbyoSW+3q9DJRze1desKHATcHCawWvoFieiym2WaUMBa39om61taE0pyHvUKAnhpFJsM60oWRAkehZZqHhqzUEXsETvo9R4T6+AcLG+7lE+1DRlP51cCvPFZv82vlcOEmJGRfXv+urbBKfqmB9n0yOXKCupmEj+iUBlQi57X Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:49:50 -0000 --bcaec51f955584c88104ccb60de1 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 21, 2012 at 3:42 AM, C. M. Heard wrote: > Circling back to my original comments about this draft, this is > precisely the sort of information that needs to be added to Section > 2.1 to justify the assertion that "some cases will remain where > legitimate fragments are discarded for legitimate reasons." > Suppose that you have packet filters at the edge of your network, and none of your current code can look beyond the first next header value when doing packet filtering at the edge. What do you do? - Drop all fragments, no matter what they are - Allow all fragments, no matter what they are - Replace all the hardware - Not deploy IPv6 --bcaec51f955584c88104ccb60de1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 3:42 AM, C. M. Heard <heard@pobox.com> wrote:
Circling back to my original comments about this draft, t= his is
precisely the sort of information that needs to be added to Section
2.1 to justify the assertion that "some cases will remain where
legitimate fragments are discarded for legitimate reasons."

Suppose that you have packet filters at the edge = of your network, and none of your current code can look beyond the first ne= xt header value when doing packet filtering at the edge. What do you do?

- Drop all fragments, no matter what they are
- Allow all fragments, no matter what they are
- Replace al= l the hardware
- Not deploy IPv6
--bcaec51f955584c88104ccb60de1-- From fgont@si6networks.com Tue Oct 23 01:51:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DD321F868B for ; Tue, 23 Oct 2012 01:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9B3ZdNQgFzg for ; Tue, 23 Oct 2012 01:51:48 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4965021F8654 for ; Tue, 23 Oct 2012 01:51:47 -0700 (PDT) Received: from [186.134.9.99] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQaD5-0008JW-S5; Tue, 23 Oct 2012 10:51:40 +0200 Message-ID: <50865A96.1080602@si6networks.com> Date: Tue, 23 Oct 2012 05:51:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mark Andrews References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> In-Reply-To: <20121018223121.28B2C2A0041D@drugs.dv.isc.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:51:50 -0000 On 10/18/2012 07:31 PM, Mark Andrews wrote: >> Yes, and part of the reason that packets are not reaching the core infrastr= >> ucture at line rate is because operators have the ability to examine traffi= >> c destined for the core infrastructure and filter / rate-limit it to someth= >> ing reasonable. I may want to allow e.g traceroute to "core" stuff and toss= >> that in one rate-limit bucket, but never allow SSH towards my core. If I = >> have fragments I have no way of knowing what they are supposed to be part o= >> f, and so, er=85 = > > So you want allow fragmented ICMP directed at core routers through and are worried > that some non initial TCP fragments might make it through. As far as I can tell > letting through non initial TCP fragments doesn't increase your risk or attack > surface at all. If the end-system does not implement RFC5722, then allowng non-initial fragments might still mean you're not filtering what you expected to be filtering. FWIW, we seem to be converging towards RFC5722, but that doesn't mean everyone is there (e.g., see: ). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jiangsheng@huawei.com Tue Oct 23 02:54:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1A121F865E for ; Tue, 23 Oct 2012 02:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osBWS7m4tlzv for ; Tue, 23 Oct 2012 02:54:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E400321F863F for ; Tue, 23 Oct 2012 02:54:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKW11241; Tue, 23 Oct 2012 09:54:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:54:27 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:54:33 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 17:54:26 +0800 From: Sheng Jiang To: "v6ops@ietf.org" Thread-Topic: Semantic IPv6 Prefix drafts Thread-Index: Ac2xBF57/hJL46osTme58HeDf3NSSg== Date: Tue, 23 Oct 2012 09:54:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F810E5@szxeml545-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AOsE B2ai DHuW D4c5 Eas+ Fu3r GkB6 HFoA KV4B MsM0 Qn8b SBAO S9xK UqnD U0j3 V9aR; 2; cwB1AG4AcQBpAG8AbgBnAEAAYwB0AGIAcgBpAC4AYwBvAG0ALgBjAG4AOwB2ADYAbwBwAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {E2F49A88-E35F-4598-AA0D-E4D9B40CDD1E}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 23 Oct 2012 09:54:18 GMT; UwBlAG0AYQBuAHQAaQBjACAASQBQAHYANgAgAFAAcgBlAGYAaQB4ACAAZAByAGEAZgB0AHMA x-cr-puzzleid: {E2F49A88-E35F-4598-AA0D-E4D9B40CDD1E} x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: sunqiong Subject: [v6ops] Semantic IPv6 Prefix drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:54:40 -0000 SGksIGFsbCwNCg0KVHdvIHNlbWFudGljIElQdjYgcHJlZml4IGhhdmUgYmVlbiBzdWJtaXR0ZWQg dG8gSUVURi4gQ291bGQgeW91IHBsZWFzZSByZXZpZXcgdGhlbT8gQW55IGNvbW1lbnRzL3N1Z2dl c3Rpb25zL2FkdmljZXMgYXJlIGFwcHJlY2lhdGVkLg0KDQpBIEZyYW1ld29yayBmb3IgU2VtYW50 aWMgSVB2NiBQcmVmaXggYW5kIEdhcCBBbmFseXNpcywgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAxDQoNClVzZSBjYXNlIG9mIElQ djYgcHJlZml4IHNlbWFudGljcyBmb3Igb3BlcmF0b3JzLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zdW4tc2VtYW50aWMtdXNlY2FzZS0wMQ0KDQpCZXN0IHJlZ2FyZHMsDQoNClNo ZW5nICsgUWlvbmcNCg== From brian.e.carpenter@gmail.com Tue Oct 23 02:59:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2377321F846B for ; Tue, 23 Oct 2012 02:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbN8IMvv7UR4 for ; Tue, 23 Oct 2012 02:59:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7A221F8659 for ; Tue, 23 Oct 2012 02:59:02 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1270493bkc.31 for ; Tue, 23 Oct 2012 02:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NAGfctGPbjMC9thGIJEA05lPDGanAexzmE/Rvrv8FL8=; b=rkeIvl/t/ZPSCQ4xi3QaLuC+7sClWMPFVeJPBXk3U3uH3zaR9zfBR1F4k36IJ5iDU5 8LaMIPeR7O8GIuV1o6gzEOSxqARramGta0sHIyee6RqMU+Q6mtW7gaHGl4bPj4iriEHq kaQQgp112wEfNJXEfn/WkUUnEsyJ3q9OZYJPvt7TuoztA3W2O3c5HgZRfOqCqJGGWBF3 WsN+0XViNSCCPm1XCKzsysmOk7tBO+1kMeakpvCR7wFOvZks1ZT6ufnjaZzkFv2rlqL0 A950eImOoRxYj4dFym5GkwycMnqVtNHs9j/EFz4NkqG6/F6e1kyveXxpAD1B4C/YXEHy y+Gw== Received: by 10.204.157.145 with SMTP id b17mr3471433bkx.68.1350986341385; Tue, 23 Oct 2012 02:59:01 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-57.as13285.net. [2.102.219.57]) by mx.google.com with ESMTPS id j24sm5195819bkv.0.2012.10.23.02.58.59 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 02:59:00 -0700 (PDT) Message-ID: <50866A64.9040100@gmail.com> Date: Tue, 23 Oct 2012 10:59:00 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20121015231232.4507.54646.idtracker@ietfa.amsl.com> <507CAE0A.7000802@gmail.com> <507CD6BC.2050006@bogus.com> <20121016062633.33DE329D6876@drugs.dv.isc.org> <507D079C.1000405@gmail.com> <20121016112137.GG13776@Space.Net> <508652EC.3070204@si6networks.com> In-Reply-To: <508652EC.3070204@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 Ops WG Subject: Re: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:59:03 -0000 On 23/10/2012 09:18, Fernando Gont wrote: > On 10/16/2012 08:21 AM, Gert Doering wrote: >> Hi, >> >> On Tue, Oct 16, 2012 at 08:07:08AM +0100, Brian E Carpenter wrote: >>> Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438. >> So how exactly is "filter based on an arbitrary value the attacker can >> control" better than "just let non-initial fragments through"? > > I think Brian was referring to hashing, rather than filtering. And when > it comes to hashing, the FL is present in all fragments, while the > upper-layer header isn't. That's correct. But if you're building a stateful filter, the argument applies. Brian From fred@cisco.com Tue Oct 23 08:50:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14911E80BA for ; Tue, 23 Oct 2012 08:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.918 X-Spam-Level: X-Spam-Status: No, score=-109.918 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wojumGPlJitV for ; Tue, 23 Oct 2012 08:50:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE6F11E8099 for ; Tue, 23 Oct 2012 08:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=718; q=dns/txt; s=iport; t=1351007411; x=1352217011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0DZxIlrf3WUWYH6tOwD53Z7VNW+wj5YVVpVNEk7v588=; b=fDZ1F6UkzHIuZDGW06xWCq20wLgv6SOgucrEWrOTODMmJFbDEDlAexTC In2jQUShvzRCXTbb36ICj2uq1+8zqHRUZSNRtOIIZavad9eLUU4radcf5 HYgP7gUqxWsYHPYu57phc8aK9FEUljMjA6ye0LYHrLtlLWRse2g28mgx3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAL27hlCtJV2a/2dsb2JhbABEvh6DSIEIgh4BAQEDARIBJz8FCwIBCA4KChQQMiUCBA4NGodcBpwBj1yQPItfhX5gA6Q/gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="134513555" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2012 15:50:10 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NFoABC031156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 15:50:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 10:50:09 -0500 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: AQHNsTYUCYKb2mXLAUaEZRxVoFGtdg== Date: Tue, 23 Oct 2012 15:50:09 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B184867@xmb-rcd-x09.cisco.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <508655FA.1080407@si6networks.com> In-Reply-To: <508655FA.1080407@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.219] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--31.731800-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-ID: <1C485D2E6525734880419D1650C688CB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:50:12 -0000 On Oct 23, 2012, at 1:31 AM, Fernando Gont wrote: > On 10/16/2012 03:49 PM, Templin, Fred L wrote: >> Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 >> fragmentation/reassembly, then all we are left with is 1280 >> and IPv6 is the new ATM... >=20 > ... and that's assuming no translators, and that the IPv6 Internet > really complies with the minimum IPv6 MTU (something that some argue > that it's not the case). One could argue that IPv6 setting a minimum MTU and placing requirements on= the underlying link layers is ill-considered. The underlying link layers a= re what they are. Some of the more amazing bits of 6lowpan are driven by th= at mismatch between IPv6 and 802.15.4.= From Fred.L.Templin@boeing.com Tue Oct 23 09:08:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7416621F86D2 for ; Tue, 23 Oct 2012 09:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuKJ8a9Zmh-H for ; Tue, 23 Oct 2012 09:08:29 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id EAD5A21F86E8 for ; Tue, 23 Oct 2012 09:08:28 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9NG8RYS028265 for ; Tue, 23 Oct 2012 09:08:28 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9NG8QIL028237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Oct 2012 09:08:26 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 23 Oct 2012 09:08:26 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , Fernando Gont Date: Tue, 23 Oct 2012 09:08:25 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: AQHNsTYUCYKb2mXLAUaEZRxVoFGtdpfHC0hg Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <508655FA.1080407@si6networks.com> <8C48B86A895913448548E6D15DA7553B184867@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B184867@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 16:08:29 -0000 > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Tuesday, October 23, 2012 8:50 AM > To: Fernando Gont > Cc: Templin, Fred L; v6ops@ietf.org; draft-taylor-v6ops- > fragdrop@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 >=20 > On Oct 23, 2012, at 1:31 AM, Fernando Gont wrote: >=20 > > On 10/16/2012 03:49 PM, Templin, Fred L wrote: > >> Plus, if we can't rely on ICMP PTB and we can't rely on IPv6 > >> fragmentation/reassembly, then all we are left with is 1280 > >> and IPv6 is the new ATM... > > > > ... and that's assuming no translators, and that the IPv6 Internet > > really complies with the minimum IPv6 MTU (something that some argue > > that it's not the case). >=20 > One could argue that IPv6 setting a minimum MTU and placing requirements > on the underlying link layers is ill-considered. The underlying link > layers are what they are. Some of the more amazing bits of 6lowpan are > driven by that mismatch between IPv6 and 802.15.4. Setting the minimum MTU on a tunnel has another problem; for example, what if that tunnel (tunnel 'A') enters another tunnel (tunnel 'B') that also sets the minimum MTU? The 1280 packets encapsulated by 'A' show up at 'B' as (1280 + 40) =3D 1320 packets which are then are dropped at 'B' because they are too big. Then, if the ICMP PTBs generated by 'B' are lost on the return path to 'A' -> black hole. Picking a fixed size 'S' for a tunnel always runs the risk that that size will be wrong for some paths. Setting the MTU to infinity and performing subnetwork adaptation when necessary avoids the black holes. Thanks - Fred fred.l.templin@boeing.com From ipepelnjak@gmail.com Wed Oct 24 10:45:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF5821F8711 for ; Wed, 24 Oct 2012 10:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz-BOCOJcAsk for ; Wed, 24 Oct 2012 10:45:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE04021F86BE for ; Wed, 24 Oct 2012 10:44:59 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so423853wgb.13 for ; Wed, 24 Oct 2012 10:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=KifNoM6Jj8+Hgqap/94vwiAfnss8UB1zP2YJ85tMSjw=; b=XpkCnVKwgRQrb1dCXXeeIytu6v8OvYkvoNseXO3J4+eH/Vf/GfsIDONAeLj2dS9cwy pulPCkDdrfd/Bh0XH/fhK3ZYZkzuyA7ht/Nw1R8MJO6mi2sHSrowD2wxAQLO7hF0fVNa 2yBh2WG1WnjVbDzHD2hKpRlbvIVlYbPYd/EH2bpUm0KT/dKQIfcEH+luBwUQDxUF6pQe dabAQ970HewTfUUcYFjcmQtJZ0QOY4HgLaVZyCYMz6NxYSbVCeXBhqQ96YCnszGvJKwp BPgaeuLmSo7qxGcvEZ4hQ4s4vwAWmZE73ZLRmJS64DUD2ZM04MBHdxHMEpJsq+gKlbLO VdKg== Received: by 10.216.210.16 with SMTP id t16mr9873954weo.175.1351100697341; Wed, 24 Oct 2012 10:44:57 -0700 (PDT) Received: from PIPINB2009 (BSN-61-48-75.dial-up.dsl.siol.net. [86.61.48.75]) by mx.google.com with ESMTPS id fp6sm5432528wib.0.2012.10.24.10.44.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 10:44:55 -0700 (PDT) From: "Ivan Pepelnjak" To: "'Philip Matthews'" References: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> In-Reply-To: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> Date: Wed, 24 Oct 2012 19:44:53 +0200 Message-ID: <006a01cdb20f$47db2450$d7916cf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wgyKFtVP85Z71QWenjfv+usaiHQBicgfQ Content-Language: sl Cc: v6ops@ietf.org Subject: Re: [v6ops] New version of Design Guidelines draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:45:01 -0000 Philip, Two more gotchas to add to your list: Section 2.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Combined eBGP sessions have inherent next-hop problems.=20 With next-hop-self (which is usually what eBGP sessions have to use), = the next hop advertised in a BGP update gets derived from the address = family of the endpoints of the BGP session, which means that if you use = IPv4-only eBGP session, the routers advertise IPv6 prefixes with = IPv4-mapped IPv6 next hops. Junos gracefully recovers by allowing you to = configure ::FFFF:x.y.z.w addresses on interfaces, Cisco IOS doesn't = allow that and thus requires usage of route maps to set IPv6 next hops. The reverse situation (IPv4 over IPv6 session - RFC 5549) is even worse, = see https://ripe65.ripe.net/archives/video/49/ for details, don't think = anyone has implemented it yet. Section 2.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When using BGP-over-LLA, Cisco IOS makes the interface name part of BGP = neighbor name. If you have to move the cable to another interface = (example: interface failure), you have to reconfigure all the BGP = neighbors (there's no "rename" functionality in Cisco IOS). Kind regards, Ivan > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > Philip Matthews > Sent: Monday, October 22, 2012 8:29 PM > To: v6ops@ietf.org list > Subject: [v6ops] New version of Design Guidelines draft >=20 > Folks: >=20 > I have just posted a new version (-01) of the Design Guidelines draft: > https://datatracker.ietf.org/doc/draft-matthews-v6ops-design- > guidelines/ OR > = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01 >=20 > This version is pretty much a complete rewrite of the document. It > incorporates all the tremendous feedback that I received by email and > during the lengthy discussion at IETF-84 in Vancouver. Many thanks to = the > many, many people who gave me feedback. I spent quite a few hours = going > through my emails and listening to the audio recording in an effort to > capture everyone's feedback. If you feel I somehow forgot or mis- > interpreted your comment, please let me know. >=20 > This version of the document is somewhat more definite in some of its > recommendations than the previous version. For design choices where I = felt > that the comments received overwhelming favored one option, the new > version reflects this sentiment. For example, I felt there was a = strong > consensus at the last WG meeting that operators should mix IPv4 and = IPv6 > traffic on a single logical link wherever possible, though I noted = that > device limitations may require separating them in some cases (e.g. to = get > good traffic statistics). >=20 > Comments on this new version are most welcome. >=20 > - Philip >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From kaeo@merike.com Wed Oct 24 13:49:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05721F86B8 for ; Wed, 24 Oct 2012 13:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx8EyEIh8czN for ; Wed, 24 Oct 2012 13:49:59 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 070C721F85BC for ; Wed, 24 Oct 2012 13:49:58 -0700 (PDT) Received: from [192.168.10.148] ([65.123.202.134]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q9OKnthF024049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Oct 2012 13:49:56 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Merike Kaeo In-Reply-To: Date: Wed, 24 Oct 2012 13:49:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 20:49:59 -0000 On Oct 23, 2012, at 1:39 AM, Lorenzo Colitti wrote: > On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: > So, what do we do? Do we: >=20 > - ignore the problem > - issue generic advice > - name and shame > - other >=20 > Other. Document that some networks drop fragments, the reasons why = they do so, and the impact on applications, but provide no advice. +1 > It's unlikely that this group, let alone the IETF, would agree on what = advice to give (at least this decade), but I think it is the = responsibility of an operations group to document real operational = issues, so the rest of the community, including application developers = and protocol developers, can be made aware of it. +1 on documenting known issues to make others aware - merike= From nygren@gmail.com Wed Oct 24 15:00:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AFA21F8C2F for ; Wed, 24 Oct 2012 15:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgtPTRM6VYDQ for ; Wed, 24 Oct 2012 15:00:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 158E221F8608 for ; Wed, 24 Oct 2012 15:00:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1213727vbb.31 for ; Wed, 24 Oct 2012 15:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ngNinnEpk+9uzxP3deh4jSNNKDvu90o98Llysa0b5do=; b=mIhfrngPMkm9PfaLumvQ3jTk8qNjfZ95G9/H9rqETirsNFb+ExxgMYBfFfIJ5EZp63 PXBzEp6C7mOAy+6Mu8SuJHmFnr/LNyUQReQPFkd6ECQC4uusL7vqLWHtSfFU6galV0l1 vPZloEzn6Ok0tIz+SMs0gfSLExJfQmqw9HG7fgByRpi6J+pK6+gq4DxXStfQ52edYn/a ZVHmKxXC0BYqMotyjSYSOfJ5gqsNODIz3a9K3h7G2q++aDHcXZv9/qvdL+F6RBvfB2bT Iz9P6aLPVJYvSkZ0URc8XAOkiDuigl1NmPx2Qbb/awsLj5cbG6wVL2V1mztXpXlnMnXA +gEg== MIME-Version: 1.0 Received: by 10.52.174.232 with SMTP id bv8mr23414541vdc.13.1351116045239; Wed, 24 Oct 2012 15:00:45 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.197.131 with HTTP; Wed, 24 Oct 2012 15:00:45 -0700 (PDT) In-Reply-To: <5040646F.6000103@gmail.com> References: <5040646F.6000103@gmail.com> Date: Wed, 24 Oct 2012 18:00:45 -0400 X-Google-Sender-Auth: -D9ymWP52uPLQVD0-0kc3YgJ_3Y Message-ID: From: Erik Nygren To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 22:00:47 -0000 On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter wrote: > [...] > > Other changes were relatively minor, but there are several new points from > Erik Nygren's extensive review (thanks, Erik!). Here are some detailed responses > to Erik's suggestions: > > [...] > > We prefer to refer to RFC2616 where proxy behaviour is actually specified. > RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: I've also never > understood the phrase "reverse proxy"; it's just a proxy that happens to be near the > server instead of near the client, but what it actually does is the same. Also, > "proxy" and "surrogate" mean the same thing in English.) RFC2616 would indicate that what is labelled in the diagram in section 7 isn't strictly a proxy (for example, proxies receive URLs in absolute form, and in many typical contexts, clients may be aware that they are communicating with a proxy or are configured to use non-transparent proxies, which is not the case here). In the common scenario that ICPs are likely to deploy (where the AAAA record is handed out), the client is unaware that it is talking to a surrogate/gateway rather than to an origin. A "gateway" as described in RFC2616 might be a better but less frequently used term? As a side-note, using a HTTP Proxy with IPv6 connectivity does turn out to be a light-weight way for content providers with clients who lack IPv6 connectivity to test dual-stacked sites, but that is a different scenario. (For example, it can be useful to setup a few proxies on different ports with different behaviors: IPv4-only, IPv6-only, dual-stack with IPv6-preferred, alternate IPv4/IPv6, etc. It is easier for users to switch their proxy settings between these ports for testing out different scenarios than for the users to have to make networking changes on their clients.) >>
> > We didn't understand the reason for the changes suggested here, and we don't think the CDN > topic should be embedded in the "complexity" section. It's basic for most ICPs, these days. The specific points: * Not all CDNs have an architecture which necessitate having dual stack service at each POP or which require routing to be the same between IPv4 and IPv6. For a CDN using some DNS-based techniques, the AAAA records could be for different POP(s) than the A records. Given that many ISPs have fairly different IPv4 and IPv6 routing and peering, it's often not reasonable to assume that IPv6 routing can be handled exactly like IPv4 routing. (There are some other CDN architectures where what is described in that first paragraph may be accurate.) * The note "A related side effect is that copies of the same content viewed at the same time via IPv4 and IPv6 may be different, due to latency in the underlying data synchronization process used by the CDN." isn't just a CDN issue and applies much more broadly to ICPs with services distributed across multiple POPs. Even outside of the dual-stack context it can be an issue with clients as they move between origin POPs. As such, I'd moved this text to the "Possible Complexities" section. (Right now it looks like the same text is duplicated in both sections?) * The quote in this section feels stylistically out-of-place from the rest of the draft. (Perhaps it just seems odd to me to quote a particular vendor?) >> +
>> One important recommendation here is that all applications should use domain names, which are IP-version-independent, > > That isn't restricted to clients - it should apply everywhere. In any case we can't really > tell ICPs to change their clients' software. Perhaps there is a better place to put the recommendation, but avoiding IPv4 literals is something that ICPs will need to watch out for given that it doesn't play well with DNS64. (Some streaming media servers used to hand out redirections to IPv4 addresses, although I'm not sure if any still do this.) For example, in Cameron's list of Android software that didn't play well with DNS64+NAT64, at least some of it seemed to be client software under an ICP's control that used IPv4 literals. My apologies for not responding in a more timely manner. Best regards, Erik From fred@cisco.com Wed Oct 24 16:48:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0C1F0C71 for ; Wed, 24 Oct 2012 16:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbsXcj5YsSTB for ; Wed, 24 Oct 2012 16:48:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0D00A1F0C61 for ; Wed, 24 Oct 2012 16:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5158; q=dns/txt; s=iport; t=1351122497; x=1352332097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k54tpmCxvLGGM/4IyY+LLDNZXT6KvIst3oOn9zJFuJ4=; b=MGcA1+MP4FxjiVkEeZ+1lohQ/7mYmZBykxvz1JsBS2nasl6CtSosDxOm RjN9i+At5Ad+FlnPHKcz43Z6A7gRVWeSX0hB7EjPEogP+dOFsFTRZ4ZZV IJYrySonjdDUH991/PKNelPUmKTuH96HhsGj6k8KMgDyRjjqgKDW03Rkn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADJ9iFCtJXHB/2dsb2JhbABEwg+BCIIeAQEBAwEBAQEPAVsLBQsCAQgiJCcLJQIEDgUIAQsOh1wGC5xtoBaLYYYMYQOXCo03gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,643,1344211200"; d="scan'208";a="135126048" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 24 Oct 2012 23:48:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9ONmEAs012039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 23:48:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 18:48:13 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] Agenda prep for IETF 85 Thread-Index: AQHNskIH1hgMqaNVOEuCz3Ytwz+iPA== Date: Wed, 24 Oct 2012 23:48:13 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B186694@xmb-rcd-x09.cisco.com> References: <74C29719-6EA0-4462-895F-7B182769FDC3@cisco.com> <8C48B86A895913448548E6D15DA7553B17DC79@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B17DC79@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--44.761700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops-ads@tools.ietf.org" Subject: Re: [v6ops] Agenda prep for IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 23:48:18 -0000 I have posted a draft agenda for IETF 85 at http://www.ietf.org/proceedings/85/agenda/agenda-85-v6ops If I have missed something, please drop a note to v6ops-chairs@tools.ietf.o= rg The agenda contains 11 drafts. I will need everyone's slides by Saturday ni= ght 3 November, please. Speakers, please plan on about 20 minutes, half or = more of that discussion. At this point, we still have two meetings Thursday afternoon, and Wanda has= n't given us a lot of hope otherwise. That's not for lack of our attempts, = or hers. Apologies to the PCP chairs=85 That said, in the agenda I have sim= ply said "First" and "Second Meeting", on the off chance that a change will= happen for the conflicting meeting to occur earlier in the week. On Oct 18, 2012, at 3:39 AM, Fred Baker (fred) wrote: > Joel and I are starting to plan the agenda for IETF 85. We currently have= two two-hour slots on Thursday afternoon; due to a conflict with PCP, we'r= e trying to move one of those to another slot. On that point, stay tuned. >=20 > That said, this is the state of play, and what I think our proposed agend= a might be. We are looking for your comments on both the agenda and (implie= d) some of the new drafts that aren't yet on it. Dates and names come from = my copy of the draft directory and http://datatracker.ietf.org/doc/search/?= name=3Dv6ops&rfcs=3Don&activeDrafts=3Don&search_submit=3D: >=20 > In RFC Editor queue: > Feb 21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > Sep 11 draft-ietf-v6ops-wireline-incremental-ipv6-06.txt > Oct 12 draft-ietf-v6ops-ivi-icmp-address-07.txt >=20 > In IESG > Sep 26 draft-ietf-v6ops-6204bis-11.txt >=20 > In Ron's queue > May 22 draft-ietf-v6ops-ra-guard-implementation-04.txt >=20 > Waiting for chairs to submit (RSN): > Sep 17 draft-ietf-v6ops-icp-guidance-04.txt > Sep 19 draft-ietf-v6ops-464xlat-08.txt >=20 > Older, and not on our radar unless updated > Apr 27 draft-jiang-v6ops-v4v6mc-proxy-01.txt > Apr 30 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > May 10 draft-templin-v6ops-isops-17.txt > May 19 draft-foo-v6ops-6rdmtu-00.txt > Jun 20 draft-lopez-v6ops-dc-ipv6-02.txt > Jun 29 draft-matthews-v6ops-design-guidelines-00.txt > Jul 5 draft-generic-v6ops-tunmtu-09.txt > Jul 16 draft-ma-v6ops-terminal-test-01.txt > Jul 16 draft-liu-v6ops-ula-usage-analysis-03.txt > Jul 16 draft-zhang-v6ops-ipv6oa-iwf-01.txt >=20 > "ID Exists" and posted since last IETF: > Aug 7 draft-ietf-v6ops-nat64-experience-00.txt > Aug 17 draft-smith-v6ops-larger-ipv6-loopback-prefix-01.txt > Sep 16 draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt > Sep 29 draft-yang-v6ops-fast6-01.txt > Oct 5 draft-binet-v6ops-cellular-host-reqs-rfc3316update-03.txt > Oct 10 draft-byrne-v6ops-64share-03.txt > Oct 15 draft-korhonen-v6ops-rfc3316bis-00.txt > Oct 15 draft-jiang-v6ops-semantic-prefix-00.txt > Oct 15 draft-yang-v6ops-ipv6tran-select-00.txt > Oct 16 draft-gont-v6ops-slaac-issues-with-duplicate-macs-00.txt > Oct 16 draft-taylor-v6ops-fragdrop-00.txt >=20 > I have received private feedback on draft-korhonen-v6ops-rfc3316bis, and = note that it is related to the topic of another draft that will make it to = the agenda. I have yet to see list comments on draft-yang-v6ops-fast6 and d= raft-jiang-v6ops-semantic-prefix, and the one comment on draft-gont-v6ops-s= laac-issues-with-duplicate-macs isn't very supportive. We'll wait to see in= terest before adding them to the agenda. draft-taylor-v6ops-fragdrop grew o= ut of a conversation at the interim meeting a few weeks ago, so I'm incline= d to entertain the discussion even though mailer discussion right now doesn= 't favor its approach. >=20 > My proposed agenda:=20 >=20 > one meeting: > draft-ietf-v6ops-nat64-experience > draft-ietf-v6ops-enterprise-incremental-ipv6 > draft-smith-v6ops-larger-ipv6-loopback-prefix > draft-yang-v6ops-ipv6tran-select >=20 > the other meeting: > draft-binet-v6ops-cellular-host-reqs-rfc3316update > draft-korhonen-v6ops-rfc3316bis > draft-byrne-v6ops-64share > draft-taylor-v6ops-fragdrop >=20 > That is open to change if there is expressed interest in the drafts I did= n't include, including drafts updated this week. >=20 > From my perspective, the primary objectives in this meeting will be: > What do we want to do with draft-ietf-v6ops-nat64-experience? Is it done= ? What changes does it still need? > What do we want to do with draft-ietf-v6ops-enterprise-incremental-ipv6?= Is it done? What changes does it still need? > Do we, and how do we, want to update RFC 3316? >=20 > As we look at the issues brought up in the other drafts, of course we wil= l also be wondering what the best outcome is. >=20 > Your thoughts? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From brian.e.carpenter@gmail.com Thu Oct 25 00:04:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3955E21F893B for ; Thu, 25 Oct 2012 00:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.696 X-Spam-Level: X-Spam-Status: No, score=-101.696 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2k1JTIZy85X for ; Thu, 25 Oct 2012 00:04:26 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08C8521F88CD for ; Thu, 25 Oct 2012 00:04:17 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so457959eaa.31 for ; Thu, 25 Oct 2012 00:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FvrTFRopOzMM9d7dPltm3pQh5ofmMKKYq8pZCmZV1zc=; b=a+yMVzTk7UHvNxJG8LqC+0R+ymRNu+hREuJ9xkuX0DFQMPYgOiuxNN58N93qjC5xyg OjfJaI6PP0zK+RW+DPdEEjQNjmdL6TQVehO8bCisXbaBjjdNhFER409cj12DSQxzW+F1 NPmExDQoCPoF1MOayFOPfl6rjt5eaAtlIDT9ZC+JTFBSZDBApnZFmhMr3o79MT8hOZsW 5HOoC0ifUvr/7BJQfmNBfYqHWIgGOKc6O1+Yduu5rKFScXUA+tMaiBnMzlu5ENPKFYIM GkhCEftgVNcjiVB+dlNOiHgeVOmq/x0tbG7ipoHeYmQBqmurmRCn0b6dFW5DE4HeZaci pyqA== Received: by 10.14.179.69 with SMTP id g45mr15412500eem.42.1351148656991; Thu, 25 Oct 2012 00:04:16 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-61.as13285.net. [2.102.218.61]) by mx.google.com with ESMTPS id o47sm29057991eem.11.2012.10.25.00.04.15 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 00:04:16 -0700 (PDT) Message-ID: <5088E475.1000206@gmail.com> Date: Thu, 25 Oct 2012 08:04:21 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Nygren References: <5040646F.6000103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 07:04:27 -0000 Hi Erik, On 24/10/2012 23:00, Erik Nygren wrote: > On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter > wrote: >> [...] >> >> Other changes were relatively minor, but there are several new points from >> Erik Nygren's extensive review (thanks, Erik!). Here are some detailed responses >> to Erik's suggestions: >> >> [...] >> >> We prefer to refer to RFC2616 where proxy behaviour is actually specified. >> RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: I've also never >> understood the phrase "reverse proxy"; it's just a proxy that happens to be near the >> server instead of near the client, but what it actually does is the same. Also, >> "proxy" and "surrogate" mean the same thing in English.) > > RFC2616 would indicate that what is labelled in the diagram in section > 7 isn't strictly a proxy > (for example, proxies receive URLs in absolute form, and in many > typical contexts, clients > may be aware that they are communicating with a proxy or are > configured to use non-transparent > proxies, which is not the case here). In the common scenario that ICPs > are likely to deploy > (where the AAAA record is handed out), the client is unaware that it > is talking to a surrogate/gateway > rather than to an origin. A "gateway" as described in RFC2616 might > be a better but less frequently used term? I'm not convinced, because "gateway" is an even more general term than "proxy". Personally, I hate the term "transparent proxy", because it's a lie. > As a side-note, using a HTTP Proxy with IPv6 connectivity does turn > out to be a light-weight way > for content providers with clients who lack IPv6 connectivity to test > dual-stacked sites, > but that is a different scenario. (For example, it can be useful to > setup a few proxies > on different ports with different behaviors: IPv4-only, IPv6-only, > dual-stack with IPv6-preferred, > alternate IPv4/IPv6, etc. It is easier for users to switch their proxy > settings between these ports > for testing out different scenarios than for the users to have to make > networking changes on their clients.) > >>>
>> We didn't understand the reason for the changes suggested here, and we don't think the CDN >> topic should be embedded in the "complexity" section. It's basic for most ICPs, these days. > > The specific points: > > * Not all CDNs have an architecture which necessitate having dual > stack service at each POP > or which require routing to be the same between IPv4 and IPv6. For > a CDN using some > DNS-based techniques, the AAAA records could be for different POP(s) > than the A records. > Given that many ISPs have fairly different IPv4 and IPv6 routing and > peering, it's often not > reasonable to assume that IPv6 routing can be handled exactly like > IPv4 routing. Agreed, which can lead to considerable complexity, especially when diagnosing problems. The question is whether that is a situation we can analyse in any useful way in this document. > (There are some other CDN architectures where what is described in > that first paragraph > may be accurate.) > > * The note "A related side effect is that copies of the same content > viewed at the > same time via IPv4 and IPv6 may be different, due to latency in the > underlying data synchronization process used by the CDN." isn't > just a CDN issue > and applies much more broadly to ICPs with services distributed > across multiple POPs. True, but this section is about CDNs. > Even outside of the dual-stack context it can be an issue with > clients as they move between > origin POPs. As such, I'd moved this text to the "Possible > Complexities" section. > (Right now it looks like the same text is duplicated in both sections?) Yes; because the same point arises in more than one context. That's an editorial choice we made. > > * The quote in this section feels stylistically out-of-place from the > rest of the draft. > (Perhaps it just seems odd to me to quote a particular vendor?) > > >>> +
>>> One important recommendation here is that all applications should use domain names, which are IP-version-independent, >> That isn't restricted to clients - it should apply everywhere. In any case we can't really >> tell ICPs to change their clients' software. > > Perhaps there is a better place to put the recommendation, but > avoiding IPv4 literals is something > that ICPs will need to watch out for given that it doesn't play well > with DNS64. (Some streaming > media servers used to hand out redirections to IPv4 addresses, > although I'm not sure if any > still do this.) For example, in Cameron's list of Android software > that didn't play well with DNS64+NAT64, > at least some of it seemed to be client software under an ICP's > control that used IPv4 literals. Yes, this is a general point that in fact may deserve its own draft, which might be better placed in the Apps area. Most content providers have no direct control over the apps layer code anyway. > > My apologies for not responding in a more timely manner. We'll wait for direction from the WG Chairs. Brian > Best regards, > > Erik > From markzzzsmith@yahoo.com.au Thu Oct 25 01:41:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5038321F88E2 for ; Thu, 25 Oct 2012 01:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0qLXeB3Fe2y for ; Thu, 25 Oct 2012 01:41:34 -0700 (PDT) Received: from nm33-vm1.bullet.mail.ne1.yahoo.com (nm33-vm1.bullet.mail.ne1.yahoo.com [98.138.229.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7869521F8869 for ; Thu, 25 Oct 2012 01:41:34 -0700 (PDT) Received: from [98.138.226.177] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 25 Oct 2012 08:41:28 -0000 Received: from [98.138.88.234] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 25 Oct 2012 08:41:28 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 25 Oct 2012 08:41:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 969584.71113.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 88731 invoked by uid 60001); 25 Oct 2012 08:41:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351154488; bh=t1ZUvUA4dDFaFLT+9hAvocThDvBbOCuG7TlNuDFRbtE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FhvPDIK/oS9W636gcjLdlg4SiP6w5spYNJLM+IAOUBEE/qoYY3xcLLh/9+kMIHLUqB9YoWSytVGtIL6ZyMbePIQcLuTnbNLBxkYUaWEEsG4ajxW20+tUzPsyKc+gYl726mpQFPJTm+73xWnET1wqGiSnPR6MWquy/n+M6F46Cxs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RDUP7OMtoSoZjlslxYtiM30CLRPXSg6Q8gliiA6/5bGWehQ8kGW/EnUo1Rc2ALlPJnjFiQxwNBT8x3wtqhqEVqXKwyjHMj/FRjEYPsG7b1Q5MfbNpDAEzn3CSQc2+9Ws7CXHLAJzazBVZlzqrF/Uvs9TEt6nDa+UK+l8GvTs16c=; X-YMail-OSG: y1BPs2gVM1kPC.V36gcovbW4_eTRfoAb35L7HsBAAQyRWwM .QoFWl6iEuuHGYc6WmS04EM6K9Xbsr6M5JD4nduDZoTrWsNatXc8fgnlOj8J W2vjhpdO_NYXcQ29wTx1yRvPs2q99M821VJujOHsOz_eNOmH4W0bAP0SVReX J.GaURfO.zZYKPUf3_QVGtlAL3CB.1K5v14.xotq6brUPkXFCbn14I.8lQYs wM3fDzhNPUtywZO0dUGrKo5DYN21bm3_KBsMk2Y5WPhr0P9ECSk3Y6ebRBQ6 eVJs0yVRMv9oU4tvWmeiUVFzChLwGQ7GwitRxYQnPCZP7gll5yrK_..Xb1hd StGUAWO_67DGryna37Gl1rY6HBDDcRtnOysg5Lbddvbd2iAdRNqWnoI9rBJ0 o4oOM8uLMFiWr0LYLIxDBOvk6v2337qDJP6PKQYa0rJodLPyzGr4ps6oItP9 _XRZqVl4Ekndt5D_wxDRjgr4U8Po3fkRYt2aap.RBRfgIlkJJi22QVHKoBOs r3QhIflNH1NDH7Q-- Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Thu, 25 Oct 2012 01:41:27 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNZXJpa2UgS2FlbyA8a2Flb0BtZXJpa2UuY29tPgo.IFRvOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPiBDYzogVjYgT3BzIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUaHVyc2RheSwgMjUgT2N0b2JlciAyMDEyIDc6NDkgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXRheWxvci12Nm9wcy1mcmFnZHJvcAo.IAo.IAo.IE9uIE9jdCAyMywgMjAxMiwgYXQgMTozOSBBTSwgTG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> Message-ID: <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Thu, 25 Oct 2012 01:41:27 -0700 (PDT) From: Mark Smith To: Merike Kaeo , Lorenzo Colitti In-Reply-To: <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:41:35 -0000 Hi,=0A=0A=0A=0A----- Original Message -----=0A> From: Merike Kaeo =0A> To: Lorenzo Colitti =0A> Cc: V6 Ops =0A> Sent: Thursday, 25 October 2012 7:49 AM=0A> Subject: Re: [v6= ops] new draft: draft-taylor-v6ops-fragdrop=0A> =0A> =0A> On Oct 23, 2012, = at 1:39 AM, Lorenzo Colitti wrote:=0A> =0A>> On Mon, Oct 22, 2012 at 8:44 = PM, Nick Hilliard wrote:=0A>> So, what do we do?=A0 Do we:= =0A>> =0A>> - ignore the problem=0A>> - issue generic advice=0A>> - name= and shame=0A>> - other=0A>> =0A>> Other. Document that some networks dro= p fragments, the reasons why they do =0A> so, and the impact on application= s, but provide no advice.=0A> =0A> +1=0A>=A0=0A=0AI think there should be a= dvice. If the IETF has seen fit to make=0A=0Afragmentation a capability of = IPv6, then I think that is inherently saying=0Athat the IETF strongly sugge= sts if not requires forwarding rather than=0Adropping of fragments for succ= essful IPv6 operation. This seems to me to=0Abe an RFC2775 Internet Transpa= rency issue.=0A=0AAlternatively, if fragments are more trouble than they're= worth,=0Athey should be deprecated.=A0=0A=0A>> It's unlikely that this gr= oup, let alone the IETF, would agree on what=A0=0A=0A> advice to give (at l= east this decade), but I think it is the responsibility of =0A> an operatio= ns group to document real operational issues, so the rest of the =0A> commu= nity, including application developers and protocol developers, can be made= =0A> aware of it.=0A>=A0=0A=0AIt seems to me that developing an applicatio= n that may be used over the=0A=0AInternet involves developing for the worst= case, not the best. If a small=0Abut significant enough portion of sites o= n the Internet drop fragments, then=0Aapplications will be developed to avo= id using fragments. Once applications=0Aavoid using fragments to suit some = sites on the Internet, then all sites=0Aon the Internet may as well drop th= em, because they've been rendered useless.=0A=0A> +1 on documenting known i= ssues to make others aware=0A> =0A> - merike=0A> __________________________= _____________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https:/= /www.ietf.org/mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Thu Oct 25 01:54:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002721F890B for ; Thu, 25 Oct 2012 01:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqWihghz5i+s for ; Thu, 25 Oct 2012 01:54:22 -0700 (PDT) Received: from nm22.bullet.mail.sp2.yahoo.com (nm22.bullet.mail.sp2.yahoo.com [98.139.91.92]) by ietfa.amsl.com (Postfix) with ESMTP id D639021F88FB for ; Thu, 25 Oct 2012 01:54:22 -0700 (PDT) Received: from [72.30.22.79] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 25 Oct 2012 08:54:21 -0000 Received: from [98.139.91.28] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 25 Oct 2012 08:54:21 -0000 Received: from [127.0.0.1] by omp1028.mail.sp2.yahoo.com with NNFMP; 25 Oct 2012 08:54:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 202849.76969.bm@omp1028.mail.sp2.yahoo.com Received: (qmail 80413 invoked by uid 60001); 25 Oct 2012 08:54:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351155260; bh=+rKtReQxk/Qk5Ps9GDZgfgTCJLgCYOWTBKUZpk9vHgc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DLquMVv+46nM/KpEC+4WBfSS1udJZDgUaPNbKcVq/Q7TTo6VQ2h4YaqOocS3H1VCkHEaAPrdM/sSWKJcbRswF5O6BGqUswPOzeTFReNXAXSW0GxcNlLqV3cytEeQH4LD7WqXvnTegIvFryp2qiBelUhRYfGeAM+OobGJ74u8FTY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VqsXC+fWAAFbWFmkSPKH1hIP2/ry0xKZJea+WbRwPVl/RVMZlSEzEdC+wYia6Yy7sVCv34lnQqcst/4BbZtxeWGuYvI15CyOMxUNq4oDrrbhehwDsvGe7VI+RgPAYmxMHLajTaVwlRs75FDozvyyUoYtMrDq+fC9DRj98tHBZG0=; X-YMail-OSG: J567di8VM1k4BZDPW_ujSN7ySuYmDmMXZnw2XUjnxX3mxQD NtbCeW_mJuZNWIXuxbqIe3iYN6gzW_vZNl0iNPjNjU3GIGWCRyuYai27WjIg UHte9Tte.pEzoD7pYRf.uhQfPeLw08iz2d2UK3YyiymK9kKkigKMeIr4RbIY Tb_4aMby5L4EQzb58iem0dGQ3uAieumiZQyFheCrSHKV.9Y4elKZgGn4wCmW cqbiY_tcW2.JE_smTkL3RHel4NnPUPipjfSXviR_.NeZ_Vh8tEhGO3rsDCrt ewvCN4yRxMlY6q4GRZDdG_goo4pxE7Qlp98BL8cKhGzLaegAPt1dQ3Pgo0ZJ KWweUbEC1I5cmN4dq4DX1IViwITvb9oDVhLPgZo4xidI7FsWA5KeCYa.gwFC x8kxj_ht1mYYZ3hPYHDYgnKojp9q5CPbiHcTb0HrhSWIdwR9ccv_L1Lw7Gm8 ZwErSdD7MHSTe85ctQuQscsCA9s5ES1b8RCcrcFz9jw3d.PgRzuxvpLlu0fz Knmaq2ccPRKyx Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Thu, 25 Oct 2012 01:54:20 PDT X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBFcmlrIE55Z3JlbiA8ZXJpaytpZXRmQG55Z3Jlbi5vcmc.Cj4gQ2M6IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVGh1cnNkYXksIDI1IE9jdG9iZXIgMjAxMiA2OjA0IFBNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gW0Z3ZDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1pY3AtZ3VpZGFuY2UtMDMudHh0XQoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> Message-ID: <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Thu, 25 Oct 2012 01:54:20 -0700 (PDT) From: Mark Smith To: Brian E Carpenter , Erik Nygren In-Reply-To: <5088E475.1000206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:54:23 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Erik Nygren =0A> Cc: = IPv6 Operations =0A> Sent: Thursday, 25 October 2012 6:04 P= M=0A> Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-= 03.txt]=0A> =0A> Hi Erik,=0A> =0A> On 24/10/2012 23:00, Erik Nygren wrote:= =0A>> On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter=0A>> wrote:=0A>>> [...]=0A>>> =0A>>> Other changes were rel= atively minor, but there are several new points =0A> from=0A>>> Erik Nygre= n's extensive review (thanks, Erik!). Here are some =0A> detailed responses= =0A>>> to Erik's suggestions:=0A>>> =0A>>> [...]=0A>>> =0A>>> We prefer = to refer to RFC2616 where proxy behaviour is actually =0A> specified.=0A>>>= RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: = =0A> I've also never=0A>>> understood the phrase "reverse proxy"; it's jus= t a proxy =0A> that happens to be near the=0A>>> server instead of near th= e client, but what it actually does is the =0A> same. Also,=0A>>> "proxy" = and "surrogate" mean the same thing in =0A> English.)=0A>> =0A>> RFC2616 w= ould indicate that what is labelled in the diagram in section=0A>> 7 isn't= strictly a proxy=0A>> (for example, proxies receive URLs in absolute form= , and in many=0A>> typical contexts, clients=0A>> may be aware that they = are communicating with a proxy or are=0A>> configured to use non-transpare= nt=0A>> proxies, which is not the case here). In the common scenario that = ICPs=0A>> are likely to deploy=0A>> (where the AAAA record=A0 is handed o= ut), the client is unaware that it=0A>> is talking to a surrogate/gateway= =0A>> rather than to an origin.=A0 A "gateway" as described in RFC2616 =0A= > might=0A>> be a better but less frequently used term?=0A> =0A> I'm not c= onvinced, because "gateway" is an even more general term =0A> than "proxy".= =0A> Personally, I hate the term "transparent proxy", because it's a =0A> l= ie.=0A>=A0=0A=0AI agree, I use the term "translucent proxy" because I think= it is much=0Amore accurate. If "transparent proxies" were truly transparen= t, it wouldn't be possible to=0Afind them in the network by comparing the o= utput of traditional traceroute=0Ato a host with a tcptraceroute to a servi= ce residing on that same host.=0A=0ARegards,=0AMark. From Michal.Czerwonka1@orange.com Thu Oct 25 01:54:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567AB21F8929 for ; Thu, 25 Oct 2012 01:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.986 X-Spam-Level: * X-Spam-Status: No, score=1.986 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, J_CHICKENPOX_13=0.6, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa5O7VyW8DZB for ; Thu, 25 Oct 2012 01:54:24 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id C024421F88FB for ; Thu, 25 Oct 2012 01:54:23 -0700 (PDT) Received: from 10.236.62.138 (EHLO OPE10HT04.tp.gk.corp.tepenet) ([10.236.62.138]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id CVA40865; Thu, 25 Oct 2012 10:54:07 +0200 (CEST) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_-_Hurt_TP?= To: Mark Smith , Merike Kaeo , Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: AQHNsikeX1XD7Frsmk6YGP/DxzVjRJfJkzGAgAAj0oA= Date: Thu, 25 Oct 2012 08:53:50 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B71B085403@OPE10MB03.tp.gk.corp.tepenet> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: V6 Ops Subject: [v6ops] ODP: new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:54:25 -0000 "..., they should be deprecated " and increase the MTU on the Internet,now = the minimum MTU is 8000. We forget about the fragmentation. BR, Mcz -----Wiadomo=B6=E6 oryginalna----- Od: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] W imieniu Mark S= mith Wys=B3ano: 25 pa=BCdziernika 2012 10:41 Do: Merike Kaeo; Lorenzo Colitti DW: V6 Ops Temat: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop Hi, ----- Original Message ----- > From: Merike Kaeo > To: Lorenzo Colitti > Cc: V6 Ops > Sent: Thursday, 25 October 2012 7:49 AM > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 >=20 > On Oct 23, 2012, at 1:39 AM, Lorenzo Colitti wrote: >=20 >> On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: >> So, what do we do?=A0 Do we: >>=20 >> - ignore the problem >> - issue generic advice >> - name and shame >> - other >>=20 >> Other. Document that some networks drop fragments, the reasons why they= do=20 > so, and the impact on applications, but provide no advice. >=20 > +1 >=A0 I think there should be advice. If the IETF has seen fit to make fragmentation a capability of IPv6, then I think that is inherently saying that the IETF strongly suggests if not requires forwarding rather than dropping of fragments for successful IPv6 operation. This seems to me to be an RFC2775 Internet Transparency issue. Alternatively, if fragments are more trouble than they're worth, they should be deprecated.=A0 >> It's unlikely that this group, let alone the IETF, would agree on what= =A0 > advice to give (at least this decade), but I think it is the responsibili= ty of=20 > an operations group to document real operational issues, so the rest of t= he=20 > community, including application developers and protocol developers, can = be made=20 > aware of it. >=A0 It seems to me that developing an application that may be used over the Internet involves developing for the worst case, not the best. If a small but significant enough portion of sites on the Internet drop fragments, the= n applications will be developed to avoid using fragments. Once applications avoid using fragments to suit some sites on the Internet, then all sites on the Internet may as well drop them, because they've been rendered useles= s. > +1 on documenting known issues to make others aware >=20 > - merike > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Oct 25 02:45:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B4221F8962 for ; Thu, 25 Oct 2012 02:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.269 X-Spam-Level: X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0TdnFPsYjwG for ; Thu, 25 Oct 2012 02:45:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2286521F8997 for ; Thu, 25 Oct 2012 02:45:00 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so581099bkc.31 for ; Thu, 25 Oct 2012 02:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pgVlShLAhwP0+ZFZLhcvu+Q+LyepLbuNhag7lXPPGjU=; b=nw4f7T6pR+5StFYwBiuBVBcQH1sUXzYSvMiHbcdJNDsRuve+lZ3PMSrTKVwGjjJh3X qSExyNfSUq0TMsL7eYwsHZ6yKp9SIXnmHoYR5EDIn8JCEJeKXAnvIGovGPI6OzV+qDk/ bS+DYawSbB9nRLSSieF+hLr2DpKHI3TvX7qKd24FJcRhjG4srOZ4QFmsP2x9tcDs+ots WAL9CeXMkti+1Mirq4UaSyAW4PkkKkSsfnM8WA8HF8CCZVAKAF6bOTRmkfEHWZq9Jhjf lh/SHL4zxM0eNR344IO5UJ3KsNZprxiPUvRzIjsxZTWkEPkMlglAuyyWnTnk5YxFWjzf IVog== Received: by 10.204.6.25 with SMTP id 25mr5742424bkx.126.1351158300048; Thu, 25 Oct 2012 02:45:00 -0700 (PDT) Received: from [128.232.110.214] (c214.al.cl.cam.ac.uk. [128.232.110.214]) by mx.google.com with ESMTPS id k21sm9578152bkv.1.2012.10.25.02.44.58 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 02:44:59 -0700 (PDT) Message-ID: <50890A21.9020705@gmail.com> Date: Thu, 25 Oct 2012 10:45:05 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:45:17 -0000 On 25/10/2012 09:41, Mark Smith wrote: > Hi, > > > > ----- Original Message ----- >> From: Merike Kaeo >> To: Lorenzo Colitti >> Cc: V6 Ops >> Sent: Thursday, 25 October 2012 7:49 AM >> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >> >> >> On Oct 23, 2012, at 1:39 AM, Lorenzo Colitti wrote: >> >>> On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: >>> So, what do we do? Do we: >>> >>> - ignore the problem >>> - issue generic advice >>> - name and shame >>> - other >>> >>> Other. Document that some networks drop fragments, the reasons why they do >> so, and the impact on applications, but provide no advice. >> >> +1 >> > > I think there should be advice. If the IETF has seen fit to make > fragmentation a capability of IPv6, then I think that is inherently saying > that the IETF strongly suggests if not requires forwarding rather than > dropping of fragments for successful IPv6 operation. This seems to me to > be an RFC2775 Internet Transparency issue. How about the combination of RFC 4890 and draft-carpenter-6man-ext-transmit (the latter is on the 6man agenda in Atlanta)? > Alternatively, if fragments are more trouble than they're worth, > they should be deprecated. There are days when I think that's right. Brian > >>> It's unlikely that this group, let alone the IETF, would agree on what > >> advice to give (at least this decade), but I think it is the responsibility of >> an operations group to document real operational issues, so the rest of the >> community, including application developers and protocol developers, can be made >> aware of it. >> > > It seems to me that developing an application that may be used over the > > Internet involves developing for the worst case, not the best. If a small > but significant enough portion of sites on the Internet drop fragments, then > applications will be developed to avoid using fragments. Once applications > avoid using fragments to suit some sites on the Internet, then all sites > on the Internet may as well drop them, because they've been rendered useless. > >> +1 on documenting known issues to make others aware >> >> - merike >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From arturo.servin@gmail.com Thu Oct 25 04:56:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EE521F8AFD for ; Thu, 25 Oct 2012 04:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id japghnbGH-hI for ; Thu, 25 Oct 2012 04:56:03 -0700 (PDT) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D68521F8AF9 for ; Thu, 25 Oct 2012 04:56:03 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id 56so298459yhq.31 for ; Thu, 25 Oct 2012 04:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UkAaoaJIbSauzKFgAfb7jqBZhysjFFXZBDaCY7POnA8=; b=RXb/+7p7+1d6Oyb+b2564e/n/dNG1HN9e2tAvUBNUse4EX4jmVmKohwQqU9Lk5XfEG 5KviM1jytgKLiEjnl74evNLpsjOrXsq21JMKba/owISxxG0rg2URkb9ItCfwTJ6IwhcW oxJ8NX3Pf2GkRwynpUrEzHZisSWv4fzFeTgWT+o9SWkgNAD/ZI33aNRiwhZ/niFlB5R8 gSRqenDEiNHhA9a2UVRAr1odH4x6qSIhgBIoPnNh/Kh32vkUehBg+htA63kQQEMm31xJ /iWFLQ8BTtQgZUD2tsqst3evvMD91GnAOPNCxqQnatEnPPqJ5MDm4BbpWxw5IxTYn17v FzmQ== Received: by 10.236.181.169 with SMTP id l29mr18477377yhm.44.1351166161912; Thu, 25 Oct 2012 04:56:01 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:fd50:18d0:cecf:ac29]) by mx.google.com with ESMTPS id l17sm12506290ank.4.2012.10.25.04.56.00 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 04:56:01 -0700 (PDT) Message-ID: <508928CD.4080308@gmail.com> Date: Thu, 25 Oct 2012 09:55:57 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> In-Reply-To: <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:56:04 -0000 Although it may not be correct, "reverse-proxy" is the well known term accepted by the technical community. I prefer this term (that IMHO people is familiar with) rather than a new or not well known such as "translucent proxy". I would suggest to add something like: "for example by running what is operationally known as a reverse proxy [REF] that handles IPv6 customers" And add the REF to [1] for example. http://httpd.apache.org/docs/2.2/mod/mod_proxy.html Just my humble 20 cents. /as On 25/10/2012 06:54, Mark Smith wrote: > > > > > ----- Original Message ----- >> From: Brian E Carpenter >> To: Erik Nygren >> Cc: IPv6 Operations >> Sent: Thursday, 25 October 2012 6:04 PM >> Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] >> >> Hi Erik, >> >> On 24/10/2012 23:00, Erik Nygren wrote: >>> On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter >>> wrote: >>>> [...] >>>> >>>> Other changes were relatively minor, but there are several new points >> from >>>> Erik Nygren's extensive review (thanks, Erik!). Here are some >> detailed responses >>>> to Erik's suggestions: >>>> >>>> [...] >>>> >>>> We prefer to refer to RFC2616 where proxy behaviour is actually >> specified. >>>> RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: >> I've also never >>>> understood the phrase "reverse proxy"; it's just a proxy >> that happens to be near the >>>> server instead of near the client, but what it actually does is the >> same. Also, >>>> "proxy" and "surrogate" mean the same thing in >> English.) >>> >>> RFC2616 would indicate that what is labelled in the diagram in section >>> 7 isn't strictly a proxy >>> (for example, proxies receive URLs in absolute form, and in many >>> typical contexts, clients >>> may be aware that they are communicating with a proxy or are >>> configured to use non-transparent >>> proxies, which is not the case here). In the common scenario that ICPs >>> are likely to deploy >>> (where the AAAA record is handed out), the client is unaware that it >>> is talking to a surrogate/gateway >>> rather than to an origin. A "gateway" as described in RFC2616 >> might >>> be a better but less frequently used term? >> >> I'm not convinced, because "gateway" is an even more general term >> than "proxy". >> Personally, I hate the term "transparent proxy", because it's a >> lie. >> > > I agree, I use the term "translucent proxy" because I think it is much > more accurate. If "transparent proxies" were truly transparent, it wouldn't be possible to > find them in the network by comparing the output of traditional traceroute > to a host with a tcptraceroute to a service residing on that same host. > > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Thu Oct 25 06:11:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4938221F89EF for ; Thu, 25 Oct 2012 06:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.244 X-Spam-Level: X-Spam-Status: No, score=-103.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2848ZOvKwVDt for ; Thu, 25 Oct 2012 06:11:14 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E22521F89EB for ; Thu, 25 Oct 2012 06:11:13 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so688084bkc.31 for ; Thu, 25 Oct 2012 06:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o985Dlew5vGmVF3RVOGNDoCaNe/RzYKuRVQdvxITnog=; b=n4cKPTxvkZ9z085kw1cuysqpK4z1HHN2AgROLuYWSRHuTngHqToy++PZDz+y7tO2jf xyQcvB6/eFAwBMk6hxMg8Jp0zr5Y5SIcxATxY1u6vrD0fcO3XW58BsBaXKuhc9ibTcEg uY8023J20Qlbo8uWmyKjCU+zZAEwj4zhwZFcqQnC5p6tvS3KTLH4JSZcX2gcCU4VtcFl hG56ojdu/UeEYFvgYwYQ3oE2uyK7rAGvSntPVdxgpSK/GNOebZRSLb6muUpz0vYUK+E5 ykGF+JE/cCPTByW2Jh0ytPxxcI5IK6JTNH7gwR9j38da9OnR+kM1F16lbxD0zdvkEXUx n9CQ== Received: by 10.204.129.211 with SMTP id p19mr6142766bks.94.1351170673215; Thu, 25 Oct 2012 06:11:13 -0700 (PDT) Received: from [128.232.110.214] (c214.al.cl.cam.ac.uk. [128.232.110.214]) by mx.google.com with ESMTPS id r15sm10169562bkw.9.2012.10.25.06.11.10 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 06:11:11 -0700 (PDT) Message-ID: <50893A75.6070203@gmail.com> Date: Thu, 25 Oct 2012 14:11:17 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arturo Servin References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> <508928CD.4080308@gmail.com> In-Reply-To: <508928CD.4080308@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:11:17 -0000 But what is "reverse" about it? As far as I can see it's just a proxy that happens to be near the server rather than near the client. Regards Brian On 25/10/2012 12:55, Arturo Servin wrote: > Although it may not be correct, "reverse-proxy" is the well known term > accepted by the technical community. I prefer this term (that IMHO > people is familiar with) rather than a new or not well known such as > "translucent proxy". > > I would suggest to add something like: > > "for example by running what is operationally known as a reverse proxy > [REF] that handles IPv6 customers" > > And add the REF to [1] for example. > > http://httpd.apache.org/docs/2.2/mod/mod_proxy.html > > > Just my humble 20 cents. > /as > > On 25/10/2012 06:54, Mark Smith wrote: >> >> >> >> ----- Original Message ----- >>> From: Brian E Carpenter >>> To: Erik Nygren >>> Cc: IPv6 Operations >>> Sent: Thursday, 25 October 2012 6:04 PM >>> Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] >>> >>> Hi Erik, >>> >>> On 24/10/2012 23:00, Erik Nygren wrote: >>>> On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter >>>> wrote: >>>>> [...] >>>>> >>>>> Other changes were relatively minor, but there are several new points >>> from >>>>> Erik Nygren's extensive review (thanks, Erik!). Here are some >>> detailed responses >>>>> to Erik's suggestions: >>>>> >>>>> [...] >>>>> >>>>> We prefer to refer to RFC2616 where proxy behaviour is actually >>> specified. >>>>> RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: >>> I've also never >>>>> understood the phrase "reverse proxy"; it's just a proxy >>> that happens to be near the >>>>> server instead of near the client, but what it actually does is the >>> same. Also, >>>>> "proxy" and "surrogate" mean the same thing in >>> English.) >>>> RFC2616 would indicate that what is labelled in the diagram in section >>>> 7 isn't strictly a proxy >>>> (for example, proxies receive URLs in absolute form, and in many >>>> typical contexts, clients >>>> may be aware that they are communicating with a proxy or are >>>> configured to use non-transparent >>>> proxies, which is not the case here). In the common scenario that ICPs >>>> are likely to deploy >>>> (where the AAAA record is handed out), the client is unaware that it >>>> is talking to a surrogate/gateway >>>> rather than to an origin. A "gateway" as described in RFC2616 >>> might >>>> be a better but less frequently used term? >>> I'm not convinced, because "gateway" is an even more general term >>> than "proxy". >>> Personally, I hate the term "transparent proxy", because it's a >>> lie. >>> >> I agree, I use the term "translucent proxy" because I think it is much >> more accurate. If "transparent proxies" were truly transparent, it wouldn't be possible to >> find them in the network by comparing the output of traditional traceroute >> to a host with a tcptraceroute to a service residing on that same host. >> >> Regards, >> Mark. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From arturo.servin@gmail.com Thu Oct 25 06:23:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815121F8A55 for ; Thu, 25 Oct 2012 06:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNjBRRpyg9tu for ; Thu, 25 Oct 2012 06:23:41 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5436A21F8A53 for ; Thu, 25 Oct 2012 06:23:40 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so322992ghb.31 for ; Thu, 25 Oct 2012 06:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2+Lwfpu8ktLMeohKSA91NIrwsmCRHDZy2Mi621bYLXo=; b=kl+fpvm9QLZsfkx2rx+ZP0oxOpzsoYu6BtSPC5SNhhMDk5C7XjNMBKQ7KuxmMPYUvx m0qoYeDjoARq8UOaCBJKenfIdsnIuWUP+zubMr77pms3V/PpJIGXQDD8kWnNh1FbPVOb Ur83FOCS4LoL9l4bwbL8VuLKcTumv/2fq/IAMjApPwYBZrVYGXZ2TskX1uTjbgVVjljX kYoGB2jqlMawtrMKc8uP13p8eqmUDakF+mrsIUDIQRTvIByND3oWlHOBJITSqhsoDiAw JbpnW6WsmcWee1Ydcjk7se3EHaLZKZnRu3xs9tzzjftHYmELUIGhVk60oLSRXl2BfQRE I4CQ== Received: by 10.236.73.161 with SMTP id v21mr18756776yhd.103.1351171419755; Thu, 25 Oct 2012 06:23:39 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:fd50:18d0:cecf:ac29]) by mx.google.com with ESMTPS id o5sm15955130anm.10.2012.10.25.06.23.37 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 06:23:38 -0700 (PDT) Message-ID: <50893D50.3060606@gmail.com> Date: Thu, 25 Oct 2012 11:23:28 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> <508928CD.4080308@gmail.com> <50893A75.6070203@gmail.com> In-Reply-To: <50893A75.6070203@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:23:47 -0000 Yes, basically. The difference in terms it is just for (I guess) to differentiate a proxy (near the user) from a reverse-proxy (near the server). It is "reverse" because the reference point is the user. I have no problem in using "proxy" alone or "reverse-proxy", just not use something new or not very well defined as "translucent". Regards, as On 25/10/2012 11:11, Brian E Carpenter wrote: > But what is "reverse" about it? As far as I can see it's just > a proxy that happens to be near the server rather than near > the client. > > Regards > Brian > > On 25/10/2012 12:55, Arturo Servin wrote: >> Although it may not be correct, "reverse-proxy" is the well known term >> accepted by the technical community. I prefer this term (that IMHO >> people is familiar with) rather than a new or not well known such as >> "translucent proxy". >> >> I would suggest to add something like: >> >> "for example by running what is operationally known as a reverse proxy >> [REF] that handles IPv6 customers" >> >> And add the REF to [1] for example. >> >> http://httpd.apache.org/docs/2.2/mod/mod_proxy.html >> >> >> Just my humble 20 cents. >> /as >> >> On 25/10/2012 06:54, Mark Smith wrote: >>> >>> >>> ----- Original Message ----- >>>> From: Brian E Carpenter >>>> To: Erik Nygren >>>> Cc: IPv6 Operations >>>> Sent: Thursday, 25 October 2012 6:04 PM >>>> Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] >>>> >>>> Hi Erik, >>>> >>>> On 24/10/2012 23:00, Erik Nygren wrote: >>>>> On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter >>>>> wrote: >>>>>> [...] >>>>>> >>>>>> Other changes were relatively minor, but there are several new points >>>> from >>>>>> Erik Nygren's extensive review (thanks, Erik!). Here are some >>>> detailed responses >>>>>> to Erik's suggestions: >>>>>> >>>>>> [...] >>>>>> >>>>>> We prefer to refer to RFC2616 where proxy behaviour is actually >>>> specified. >>>>>> RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: >>>> I've also never >>>>>> understood the phrase "reverse proxy"; it's just a proxy >>>> that happens to be near the >>>>>> server instead of near the client, but what it actually does is the >>>> same. Also, >>>>>> "proxy" and "surrogate" mean the same thing in >>>> English.) >>>>> RFC2616 would indicate that what is labelled in the diagram in section >>>>> 7 isn't strictly a proxy >>>>> (for example, proxies receive URLs in absolute form, and in many >>>>> typical contexts, clients >>>>> may be aware that they are communicating with a proxy or are >>>>> configured to use non-transparent >>>>> proxies, which is not the case here). In the common scenario that ICPs >>>>> are likely to deploy >>>>> (where the AAAA record is handed out), the client is unaware that it >>>>> is talking to a surrogate/gateway >>>>> rather than to an origin. A "gateway" as described in RFC2616 >>>> might >>>>> be a better but less frequently used term? >>>> I'm not convinced, because "gateway" is an even more general term >>>> than "proxy". >>>> Personally, I hate the term "transparent proxy", because it's a >>>> lie. >>>> >>> I agree, I use the term "translucent proxy" because I think it is much >>> more accurate. If "transparent proxies" were truly transparent, it wouldn't be possible to >>> find them in the network by comparing the output of traditional traceroute >>> to a host with a tcptraceroute to a service residing on that same host. >>> >>> Regards, >>> Mark. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From philip_matthews@magma.ca Thu Oct 25 10:31:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811821F88AE for ; Thu, 25 Oct 2012 10:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6L+r3vByDmY for ; Thu, 25 Oct 2012 10:31:31 -0700 (PDT) Received: from mail-07.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 33DDA21F889E for ; Thu, 25 Oct 2012 10:31:30 -0700 (PDT) Received: from [74.198.165.97] (helo=[172.20.10.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TRRHC-0004Rk-34; Thu, 25 Oct 2012 13:31:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <006a01cdb20f$47db2450$d7916cf0$@com> Date: Thu, 25 Oct 2012 13:30:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F6270C9-C85D-433E-9C5A-DA34DDDAEFC9@magma.ca> References: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> <006a01cdb20f$47db2450$d7916cf0$@com> To: Ivan Pepelnjak X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.97] Cc: v6ops@ietf.org Subject: Re: [v6ops] New version of Design Guidelines draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:31:32 -0000 Hi Ivan: Thanks very much for your comments. Both comments are very good -- I will add them to the next revision of = the document. - Philip On 2012-10-24, at 13:44 , Ivan Pepelnjak wrote: > Philip, >=20 > Two more gotchas to add to your list: >=20 > Section 2.4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Combined eBGP sessions have inherent next-hop problems.=20 >=20 > With next-hop-self (which is usually what eBGP sessions have to use), = the next hop advertised in a BGP update gets derived from the address = family of the endpoints of the BGP session, which means that if you use = IPv4-only eBGP session, the routers advertise IPv6 prefixes with = IPv4-mapped IPv6 next hops. Junos gracefully recovers by allowing you to = configure ::FFFF:x.y.z.w addresses on interfaces, Cisco IOS doesn't = allow that and thus requires usage of route maps to set IPv6 next hops. >=20 > The reverse situation (IPv4 over IPv6 session - RFC 5549) is even = worse, see https://ripe65.ripe.net/archives/video/49/ for details, don't = think anyone has implemented it yet. >=20 > Section 2.5 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > When using BGP-over-LLA, Cisco IOS makes the interface name part of = BGP neighbor name. If you have to move the cable to another interface = (example: interface failure), you have to reconfigure all the BGP = neighbors (there's no "rename" functionality in Cisco IOS). >=20 > Kind regards, > Ivan >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Philip Matthews >> Sent: Monday, October 22, 2012 8:29 PM >> To: v6ops@ietf.org list >> Subject: [v6ops] New version of Design Guidelines draft >>=20 >> Folks: >>=20 >> I have just posted a new version (-01) of the Design Guidelines = draft: >> https://datatracker.ietf.org/doc/draft-matthews-v6ops-design- >> guidelines/ OR >> = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01 >>=20 >> This version is pretty much a complete rewrite of the document. It >> incorporates all the tremendous feedback that I received by email and >> during the lengthy discussion at IETF-84 in Vancouver. Many thanks to = the >> many, many people who gave me feedback. I spent quite a few hours = going >> through my emails and listening to the audio recording in an effort = to >> capture everyone's feedback. If you feel I somehow forgot or mis- >> interpreted your comment, please let me know. >>=20 >> This version of the document is somewhat more definite in some of its >> recommendations than the previous version. For design choices where I = felt >> that the comments received overwhelming favored one option, the new >> version reflects this sentiment. For example, I felt there was a = strong >> consensus at the last WG meeting that operators should mix IPv4 and = IPv6 >> traffic on a single logical link wherever possible, though I noted = that >> device limitations may require separating them in some cases (e.g. to = get >> good traffic statistics). >>=20 >> Comments on this new version are most welcome. >>=20 >> - Philip >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 From marka@isc.org Thu Oct 25 13:22:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0401521F88DD for ; Thu, 25 Oct 2012 13:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCveNvnxfzfq for ; Thu, 25 Oct 2012 13:22:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1221F879C for ; Thu, 25 Oct 2012 13:22:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4D8AD5F993F; Thu, 25 Oct 2012 20:22:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5A7AB216C3D; Thu, 25 Oct 2012 20:22:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 185852A40C3F; Fri, 26 Oct 2012 07:22:22 +1100 (EST) To: Mark Smith From: Mark Andrews References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> In-reply-to: Your message of "Thu, 25 Oct 2012 01:41:27 PDT." <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Fri, 26 Oct 2012 07:22:22 +1100 Message-Id: <20121025202222.185852A40C3F@drugs.dv.isc.org> Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 20:22:40 -0000 In message <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com>, Mark Sm ith writes: > Hi, > > > > ----- Original Message ----- > > From: Merike Kaeo > > To: Lorenzo Colitti > > Cc: V6 Ops > > Sent: Thursday, 25 October 2012 7:49 AM > > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop > > = > > > = > > > On Oct 23, 2012, at 1:39 AM, Lorenzo Colitti wrote: > > = > > >> On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: > >> So, what do we do?=A0 Do we: > >> = > > >> - ignore the problem > >> - issue generic advice > >> - name and shame > >> - other > >> = > > >> Other. Document that some networks drop fragments, the reasons why they= > do = > > > so, and the impact on applications, but provide no advice. > > = > > > +1 > >=A0 > > I think there should be advice. If the IETF has seen fit to make > > fragmentation a capability of IPv6, then I think that is inherently saying > that the IETF strongly suggests if not requires forwarding rather than > dropping of fragments for successful IPv6 operation. This seems to me to > be an RFC2775 Internet Transparency issue. > > Alternatively, if fragments are more trouble than they're worth, > they should be deprecated.=A0 > > >> It's unlikely that this group, let alone the IETF, would agree on what= > =A0 > > > advice to give (at least this decade), but I think it is the responsibili= > ty of = > > > an operations group to document real operational issues, so the rest of t= > he = > > > community, including application developers and protocol developers, can = > be made = > > > aware of it. > >=A0 > > It seems to me that developing an application that may be used over the > > Internet involves developing for the worst case, not the best. If a small > but significant enough portion of sites on the Internet drop fragments, then > applications will be developed to avoid using fragments. Once applications > avoid using fragments to suit some sites on the Internet, then all sites > on the Internet may as well drop them, because they've been rendered useles= > s. Or they learn to adapt and use fragments where they work. DNS clients do this today. They get stuck behind equipment that: * drops packets > 512 bytes * drops fragments * drops EDNS packets * drops packets with DO set * drops packets where the initial fagment doesn't arrive first The clients adapt the queries they make to get responses back. They work much more efficiently however if they can get fragmented EDNS responses back. > > +1 on documenting known issues to make others aware > > = > > > - merike > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > = > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ayourtch@cisco.com Thu Oct 25 16:12:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29ED21F887A for ; Thu, 25 Oct 2012 16:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.832 X-Spam-Level: X-Spam-Status: No, score=-7.832 tagged_above=-999 required=5 tests=[AWL=2.767, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+NMhwImOYnP for ; Thu, 25 Oct 2012 16:11:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 572C721F8727 for ; Thu, 25 Oct 2012 16:11:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9PMWcsS028078 for ; Fri, 26 Oct 2012 00:32:38 +0200 (CEST) Received: from ams-ayourtch-8718.cisco.com (ams-ayourtch-8718.cisco.com [10.55.144.249]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9PMWa4B008311; Fri, 26 Oct 2012 00:32:36 +0200 (CEST) Date: Fri, 26 Oct 2012 00:32:36 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Mark Andrews In-Reply-To: <20121025202222.185852A40C3F@drugs.dv.isc.org> Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <20121025202222.185852A40C3F@drugs.dv.isc.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 23:12:00 -0000 On Fri, 26 Oct 2012, Mark Andrews wrote: >> Internet involves developing for the worst case, not the best. If a small >> but significant enough portion of sites on the Internet drop fragments, then >> applications will be developed to avoid using fragments. Once applications >> avoid using fragments to suit some sites on the Internet, then all sites >> on the Internet may as well drop them, because they've been rendered useles= >> s. > > Or they learn to adapt and use fragments where they work. DNS clients > do this today. They get stuck behind equipment that: > > * drops packets > 512 bytes > * drops fragments > * drops EDNS packets > * drops packets with DO set > * drops packets where the initial fagment doesn't arrive first > > The clients adapt the queries they make to get responses back. > > They work much more efficiently however if they can get fragmented EDNS > responses back. What about DNSSEC ? Seems like there's a problem if the fragmentation does not work correctly: https://tnc2012.terena.org/getfile/1603 --a From ayourtch@cisco.com Thu Oct 25 16:30:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1923221F86D6 for ; Thu, 25 Oct 2012 16:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.224 X-Spam-Level: X-Spam-Status: No, score=-8.224 tagged_above=-999 required=5 tests=[AWL=1.775, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8laIT9MyF5Lm for ; Thu, 25 Oct 2012 16:30:16 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB721F867C for ; Thu, 25 Oct 2012 16:30:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9PNUEoW003286 for ; Fri, 26 Oct 2012 01:30:14 +0200 (CEST) Received: from ams-ayourtch-8718.cisco.com (ams-ayourtch-8718.cisco.com [10.55.144.249]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9PNUDQx014869; Fri, 26 Oct 2012 01:30:13 +0200 (CEST) Date: Fri, 26 Oct 2012 01:30:12 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Merike Kaeo In-Reply-To: <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 23:30:17 -0000 On Wed, 24 Oct 2012, Merike Kaeo wrote: > > On Oct 23, 2012, at 1:39 AM, Lorenzo Colitti wrote: > >> On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: >> So, what do we do? Do we: >> >> - ignore the problem >> - issue generic advice >> - name and shame >> - other >> >> Other. Document that some networks drop fragments, the reasons why they do so, and the impact on applications, but provide no advice. > > +1 > >> It's unlikely that this group, let alone the IETF, would agree on what advice to give (at least this decade), but I think it is the responsibility of an operations group to document real operational issues, so the rest of the community, including application developers and protocol developers, can be made aware of it. > > +1 on documenting known issues to make others aware +1 on documenting, maybe worth adding to the section 2.2 a few more protocol case studies: http://www.ietf.org/mail-archive/web/ipsec/current/msg07749.html http://www.ietf.org/proceedings/71/slides/radext-4.pdf http://support.microsoft.com/kb/244474 Alongside with that, also probably something like http://tools.ietf.org/html/rfc4347#section-4.2.3 could be also referenced as an example of application protocol's approach to fragmentation, alongside with http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00, http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-03, This might help future app protocol writers' design choices, even if the document does not give the explicit advice (the fact on which I do not have an explicit opinion). --a > > - merike > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From touch@isi.edu Thu Oct 25 16:52:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41021F88CA for ; Thu, 25 Oct 2012 16:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.481 X-Spam-Level: X-Spam-Status: No, score=-105.481 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzAxra8jD3EZ for ; Thu, 25 Oct 2012 16:52:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1C821F887E for ; Thu, 25 Oct 2012 16:52:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q9PNpE3i021311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Oct 2012 16:51:14 -0700 (PDT) Message-ID: <5089D072.8000106@isi.edu> Date: Thu, 25 Oct 2012 16:51:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 23:52:05 -0000 I'm not sure whether noting the issue is critical or not, but tonly one of these examples is useful, IMO, as noted below: On 10/25/2012 4:30 PM, Andrew Yourtchenko wrote: ... > +1 on documenting, maybe worth adding to the section 2.2 a few more > protocol case studies: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg07749.html This one seems useful to the point being discussed (of "drop all" fragment cases in the wild). > http://www.ietf.org/proceedings/71/slides/radext-4.pdf The above is more about trying to avoid fragmentation than any specific reason that fragmentation is a problem. Fragmentation is known to increase probability of drop (opportunity for reassembly overload, increased exposure to the impact of a packet drop). This example isn't directly about "drop all" cases, though. > http://support.microsoft.com/kb/244474 >From that link: "Because UDP is a connectionless protocol, fragmented UDP packets will be dropped if they arrive at the destination out of order. " 1) because UDP is connectionless, UDP packets should be tolerated out of order 2) fragments should already be tolerated out of order So I can't understand why fragmented UDP packets should be dropped if they arrive out of order except as an implementation error. Is this being noted as "bad advice arising from an implementation error"? If not, then it might not be useful to include. > Alongside with that, also probably something like > http://tools.ietf.org/html/rfc4347#section-4.2.3 could be also > referenced as an example of application protocol's approach to > fragmentation, alongside with > http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00, > http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-03, > > This might help future app protocol writers' design choices, even if the > document does not give the explicit advice (the fact on which I do not > have an explicit opinion). That advice presumes that the fragment size can be detected by the application; this is sometimes not the case. If such are being noted, the it might be useful to also at least recommend PLPMTUD (RFC 4821). Joe From marka@isc.org Thu Oct 25 17:18:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE221F88B7 for ; Thu, 25 Oct 2012 17:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, SARE_URI_CONS8=1.036] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJasqXmmRmM2 for ; Thu, 25 Oct 2012 17:18:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2886F21F8830 for ; Thu, 25 Oct 2012 17:18:34 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 88AFE5F99A0; Fri, 26 Oct 2012 00:18:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7AE5E216C7B; Fri, 26 Oct 2012 00:18:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 58B2B2A4409B; Fri, 26 Oct 2012 11:18:18 +1100 (EST) To: Andrew Yourtchenko From: Mark Andrews References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <20121025202222.185852A40C3F@drugs.dv.isc.org > In-reply-to: Your message of "Fri, 26 Oct 2012 00:32:36 +0200." Date: Fri, 26 Oct 2012 11:18:18 +1100 Message-Id: <20121026001818.58B2B2A4409B@drugs.dv.isc.org> Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:18:35 -0000 In message , Andrew Yourtchen ko writes: > > > On Fri, 26 Oct 2012, Mark Andrews wrote: > > >> Internet involves developing for the worst case, not the best. If a small > >> but significant enough portion of sites on the Internet drop fragments, th > en > >> applications will be developed to avoid using fragments. Once applications > >> avoid using fragments to suit some sites on the Internet, then all sites > >> on the Internet may as well drop them, because they've been rendered usele > s= > >> s. > > > > Or they learn to adapt and use fragments where they work. DNS clients > > do this today. They get stuck behind equipment that: > > > > * drops packets > 512 bytes > > * drops fragments > > * drops EDNS packets > > * drops packets with DO set > > * drops packets where the initial fagment doesn't arrive first > > > > The clients adapt the queries they make to get responses back. > > > > They work much more efficiently however if they can get fragmented EDNS > > responses back. > > What about DNSSEC ? Seems like there's a problem if the fragmentation > does not work correctly: https://tnc2012.terena.org/getfile/1603 Which looks at a single query / response rather than a complete system. There are nameservers that do not respond to EDNS packets. There are firewall that do not pass DNS/UDP packets bigger than 512 bytes. These two issues overwhelm any issues due to fragmentation. Nameserver vendors need to deal with these issues as they exist in the real world ever if there isn't a RFC which says how to deal with them. Named sends EDNS@4096, EDNS@512 and plain DNS queries when resolving queries. It does this with sub second retry timeouts. Most referrals do not require fragmentation. If there is not enough space in the UDP response the server falls over to TCP. Named drops the optional parts of DNSKEY/DS responses reducing the likelyhood of fragmentation. Named drops optional parts of responses when it sees a EDNS@512 query reducing the likelyhood of TCP fallback. isc.org referral w/ dnssec is 681 bytes from the root servers isc.org referral w/ dnssec is 514 bytes from the org servers the isc.org dnskey response is 463 bytes from the isc.org servers the org dnskey response is 1334 or 1723 bytes depending apon which nameserver impementatin you hit the root dnskey response is 736 bytes a nxdomain response for sdlkfhadslhasjdhgfjgask is 652 bytes (NSEC) a nxdomain response for sdlkfhadslhasjdhgfjgask.org is 1021 bytes (NSEC3) Both the server and clients sides can limiting the sizes of UDP responses being sent. If you are validating and are stuck behind a firewall that you can't change that blocks fragmented responses you can tell the nameserver to announce a smaller EDNS UDP buffer size that is unlikely to cause fragmentation. Unless you are validating plain DNS responses from signed zones do not cause any issues. In practice you get an occasional slow down due to fragmentation when validating if you havn't fixed your local firewall or tuned your nameserver to account for the firewall. There is code (unreleased) that will do EDNS@4096, EDNS@1432 ([46] in [46]), EDNS@1232 (IPv6 network MTU), EDNS@512 (stupid firewalls) and plain DNS (even stupider firewalls / broken servers). A little bit of extra state per server talked to is used to remember this across multiple queries. Named already tracks response times. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fgont@si6networks.com Thu Oct 25 18:19:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7021F85C0 for ; Thu, 25 Oct 2012 18:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylK2TCbK19TZ for ; Thu, 25 Oct 2012 18:19:30 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0728221F8588 for ; Thu, 25 Oct 2012 18:19:29 -0700 (PDT) Received: from [186.134.20.23] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TRYa3-0006vr-0A; Fri, 26 Oct 2012 03:19:23 +0200 Message-ID: <5089E514.2020208@si6networks.com> Date: Thu, 25 Oct 2012 22:19:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Merike Kaeo References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> In-Reply-To: <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 01:19:30 -0000 On 10/24/2012 05:49 PM, Merike Kaeo wrote: > >> On Mon, Oct 22, 2012 at 8:44 PM, Nick Hilliard wrote: >> So, what do we do? Do we: >> >> - ignore the problem >> - issue generic advice >> - name and shame >> - other >> >> Other. Document that some networks drop fragments, the reasons why they do so, and the impact on applications, but provide no advice. > > +1 If we can converge on some advice, I think it would be appropriate to give it. i.e., as a group, do we have a take on what'd be the most appropriate thing to do wrt fragments? Documenting this issue is good, but not giving any advice looks a bit like hand-washing (or whatever you use in English for referring to the act of not doing anything about something that deserves it :-) ). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From lorenzo@google.com Thu Oct 25 18:53:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D85B21F8583 for ; Thu, 25 Oct 2012 18:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG84EWMXjr7F for ; Thu, 25 Oct 2012 18:53:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3473521F856D for ; Thu, 25 Oct 2012 18:53:47 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2485568obq.31 for ; Thu, 25 Oct 2012 18:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=zZhRbWWHrokEjS1DphwobGcTHkxoV1HEVxP6ng2JgJM=; b=YSFaLwkQqnl7VAufgUcdmOVlYLk0I4oJo+jWO+o9JIeDlQUiqG8Djs3j3KFKgwVmpm 9Gx4sEZVpErnjIUfX4g2itUDinbtBEPy065f6x8BIL/+zWUQZjDug+RAi3QckLqWrEBG /2D0jK16wiYUdeMSfl1Wg+kHhJo93HWK3yqh/gr+zUpbE3nivOUmgkS908uvRiX0uylm 4Be3eU9GnXV+9R9Ipgql/oWWrRuLhBZ1U7Dxu03dcG73+G71JtJNq8LIIx+9x9xw9Kuu P6k3xNhYYwojSEuq7YPtXbPV4Q3p46/uOgIUgnZB8LUgIHNsgwE5CaeXf60ewf3qTjhG Pc7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=zZhRbWWHrokEjS1DphwobGcTHkxoV1HEVxP6ng2JgJM=; b=R6vQIBrJVcBam8HBXrlTN/ZnVWqsyc1/rIQWt4FwCa9kG7s8/A9yhOO+FL4tR7D3Tn TTaJqB6yUx9F0e6AM6GAbN2vQjKCjbsfbA9D9aqGXa6yS5+1EpsG1PAmLLfNSuPKgJQ+ TmOtambqC1z+1vaPvD3T7FgLqoLUw4d0gcDAF4Yu8JT6IZ4HPWR9Wb5s+R7sL622LoAF aJ0RW81wa7Fjl8wrZflPfmsSJmDRprt7LY39BLxd7dlqOFPSIebt0dKyNsoRJGDesMuP oNnDbzpSuzxgwpHlA45jaWu1hRvontGOi/DBXJJJ0fv33GtmgJVxhJtPebTO2dE62pnu 5jsA== Received: by 10.182.38.101 with SMTP id f5mr17543993obk.80.1351216426690; Thu, 25 Oct 2012 18:53:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Thu, 25 Oct 2012 18:53:26 -0700 (PDT) In-Reply-To: <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 10:53:26 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=f46d0446300820a71f04ccec97ca X-System-Of-Record: true X-Gm-Message-State: ALoCoQnt18jIJTTLwuIPKrWbiOyS9P/1ZBYCi8QGXILJiBs6Vm/feLJynZ1d+YLJ4dSM1gPM2313v9YVsDX8Y7dKAMvOvaUQhs1IjtsIyfMHcNJagivAibkPGKhjq/EHcHLyX7n1ChO2lT4lNfzX2fMLFSQPzTBhrESvvdm+d07M8Vl9LA+BOcMFB9MwFkvFNHiWiSMpz+uZ Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 01:53:48 -0000 --f46d0446300820a71f04ccec97ca Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 5:41 PM, Mark Smith wrote: > I think there should be advice. If the IETF has seen fit to > make fragmentation a capability of IPv6, then I think that is inherently > saying > that the IETF strongly suggests if not requires forwarding rather than > dropping of fragments for successful IPv6 operation. This seems to me to > be an RFC2775 Internet Transparency issue. > > Alternatively, if fragments are more trouble than they're worth, > they should be deprecated. > I agree that there should be advice, but unfortunately, I don't see a way to do that. For example, I personally think that fragments are more trouble than they're worth, they don't work in today's Internet (IPv4 *or* IPv6), create security issues (see e.g., Fernando's issues with fragmented RAs, plus an history of security issues in fragment-handling code) and that applications are much better off implementing their own fragmentation above UDP or whatever else they may use. Unfortunately, it doesn't seem likely that this working group will reach consensus on such a recommendation. On the other hand, giving the opposite advice, and saying "fragmentation is required and fragments MUST always be allowed" is out of touch with reality, because current implementations and network designs are not capable of doing this, and is therefore useless because operators can't do what implementations are not capable of. I doubt we'll reach consensus on such a recommendation either. As always, the danger in trying to reach consensus on a controversial topic is that of endlessly discussing the issue, which makes it impossible to make a useful contribution to it. The way I see it, if we can't reach consensus, it's better to punt entirely and at least issue a statement about the issues. At least we will have done something useful. If we get deadlocked forever in trying to decide what the right thing to do is, we will get nothing useful done at all. > It seems to me that developing an application that may be used over > the Internet involves developing for the worst case, not the best. If a > small > but significant enough portion of sites on the Internet drop fragments, > then applications will be developed to avoid using fragments. Once > applications avoid using fragments to suit some sites on the Internet, then > all sites on the Internet may as well drop them, because they've been > rendered useless. > I agree. But on the other hand, the data presented in this draft shows clearly that what you describe ("a small but significant enough portion of sites on the Internet drop fragments") is true today (actually, it's not even "small"). So fragments have already been rendered useless in the general case. But some of the reactions to the draft were, "That's incorrect and it will break things. The operators filtering fragments likely don't know that what they're doing is bad, and once we explain that to them, they will fix it". --f46d0446300820a71f04ccec97ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 5:41 PM, Mark Smith <markzzzsmith@yahoo.= com.au> wrote:
I think there should be advice. If the IETF has seen fit to make=A0fragment= ation a capability of IPv6, then I think that is inherently saying
that the IETF strongly suggests if not requires forwarding rather than
dropping of fragments for successful IPv6 operation. This seems to me to be an RFC2775 Internet Transparency issue.

Alternatively, if fragments are more trouble than they're worth,
they should be deprecated.=A0

I agree t= hat there should be advice, but unfortunately, I don't see a way to do = that.

For example, I personally think that fragmen= ts are more trouble than they're worth, they don't work in today= 9;s Internet (IPv4 *or* IPv6), create security issues (see e.g., Fernando&#= 39;s issues with fragmented RAs, plus an history of security issues in frag= ment-handling code) and that applications are much better off implementing = their own fragmentation above UDP or whatever else they may use.=A0Unfortun= ately, it doesn't seem likely that this working group will reach consen= sus on such a recommendation.

On the other hand, giving the opposite advice, and sayi= ng "fragmentation is required and fragments MUST always be allowed&quo= t; is out of touch with reality, because current implementations and networ= k designs are not capable of doing this, and is therefore useless because o= perators can't do what implementations are not capable of. I doubt we&#= 39;ll reach consensus on such a recommendation either.

As always, the danger in trying to reach consensus on a= controversial topic is that of endlessly discussing the issue, which makes= it impossible to make a useful contribution to it. The way I see it, if we= can't reach consensus, it's better to punt entirely and at least i= ssue a statement about the issues. At least we will have done something use= ful. If we get deadlocked forever in trying to decide what the right thing = to do is, we will get nothing useful done at all.
=A0
It seems to me that developing an application that may be= used over the=A0Internet involves developing for the worst case, not the b= est. If a small
but significant enough portion of sites on the Internet drop fragments, the= n=A0applications will be developed to avoid using fragments. Once applicati= ons=A0avoid using fragments to suit some sites on the Internet, then all si= tes=A0on the Internet may as well drop them, because they've been rende= red useless.

I agree.=A0But on the other hand, the=A0da= ta presented in this draft shows clearly that what you describe ("a sm= all=A0but significant enough portion of sites on the Internet drop fragment= s") is true today (actually, it's not even "small"). So = fragments have already been rendered useless in the general case.=A0But som= e of the reactions to the draft were, "That's incorrect and it wil= l break things. The operators filtering fragments likely don't know tha= t what they're doing is bad, and once we explain that to them, they wil= l fix it".
--f46d0446300820a71f04ccec97ca-- From sm@resistor.net Thu Oct 25 23:05:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A8521F85C2 for ; Thu, 25 Oct 2012 23:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F4XYylOhpaw for ; Thu, 25 Oct 2012 23:05:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B8221F85AF for ; Thu, 25 Oct 2012 23:05:29 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9Q65EIF027593; Thu, 25 Oct 2012 23:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351231521; bh=w1aezYaDTgSLEAAEV+ReK2A4BRfxhNc78YbRqprDSkA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=y5OXiYZWxP9ATQ9NE15WZ8nwvLF4gnwOL2HWRic18op61ku1K5cGILhsE3/fg+0Ev Q4VCMCEzNL1Uo9JN7ipj5A+/bt6OBVT1IUIRWwm0JUFQ9BZoBIXeDX7ic3qoNbKacI jJRwFBtuxc2gMElJKbhreqKJPGQ2yY3kxG21xgOM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351231521; i=@resistor.net; bh=w1aezYaDTgSLEAAEV+ReK2A4BRfxhNc78YbRqprDSkA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sJbNQedVEx29nc5ggxzL0nSDpUtc+oVQnH93yzzJNiuWkPug79iBJu8d7/oJdDOGi apXrdHrGMOEmC4MI6AaLy7meq7oJz9RiVgws5IvHZ7iIzk2jYM2CtFSuCCLsawzKw5 z6HgP7ufjNK/kUpQvh+Fj2g6YfrUy49MLemJuBHQ= Message-Id: <6.2.5.6.2.20121025224452.09492e60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Oct 2012 23:02:27 -0700 To: Brian E Carpenter From: SM In-Reply-To: <50893A75.6070203@gmail.com> References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> <508928CD.4080308@gmail.com> <50893A75.6070203@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:05:31 -0000 Hi Brian, At 06:11 25-10-2012, Brian E Carpenter wrote: >But what is "reverse" about it? As far as I can see it's just >a proxy that happens to be near the server rather than near >the client. draft-ietf-httpbis-p1-messaging-19 discusses about (http) proxies. The "reverse proxy" acts like a http server instead of a http client. Regards, -sm From brian.e.carpenter@gmail.com Fri Oct 26 01:24:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701C821F844C for ; Fri, 26 Oct 2012 01:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.693 X-Spam-Level: X-Spam-Status: No, score=-101.693 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWg6-M5a0ecy for ; Fri, 26 Oct 2012 01:24:19 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1D21F843F for ; Fri, 26 Oct 2012 01:24:18 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1053744eek.31 for ; Fri, 26 Oct 2012 01:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0EhrJ94jo1wF7xraKzXBqVtFhaTv2VFnalL+5d6xaPw=; b=X4/DDv0l8xUbhhTthrW+j6Jr43EHvjE6YPMM20p6NjrV68bkrb7sUg2Prodev5aWNt kvU/nM2oyx0Z6QxMT9aWKQ6852y5nq8LyCbkcqwo6hgST2zNtyfuj8gatS3FXilAL0oR JvBLykLO4hyp103Ze2iEYWg2T4k2+DkyNNZvZtTBsaOb4gibd1C8ledKgCnO8dPdbuih XaPmM0Z/wgCGFMd5lVdjqoDuYnC4B6CGkjRAphG4CfCzj1y7klEVqPqf3sXtOvD5MrJV E04rpWHVUjqFMdAKvXKj/vBmnzOALzpWfIVF5nwR7NKBM0RE/Yv0n//BRBmKD3V6ohjv 44dw== Received: by 10.14.184.2 with SMTP id r2mr29907343eem.43.1351239858058; Fri, 26 Oct 2012 01:24:18 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-184.as13285.net. [2.102.216.184]) by mx.google.com with ESMTPS id f2sm1273582eep.2.2012.10.26.01.24.15 (version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 01:24:17 -0700 (PDT) Message-ID: <508A48B8.7050906@gmail.com> Date: Fri, 26 Oct 2012 09:24:24 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: SM References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> <508928CD.4080308@gmail.com> <50893A75.6070203@gmail.com> <6.2.5.6.2.20121025224452.09492e60@resistor.net> In-Reply-To: <6.2.5.6.2.20121025224452.09492e60@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:24:19 -0000 On 26/10/2012 07:02, SM wrote: > Hi Brian, > At 06:11 25-10-2012, Brian E Carpenter wrote: >> But what is "reverse" about it? As far as I can see it's just >> a proxy that happens to be near the server rather than near >> the client. > > draft-ietf-httpbis-p1-messaging-19 discusses about (http) proxies. The > "reverse proxy" acts like a http server instead of a http client. It behaves like a client on one side and a server on the other side. Brian From sm@resistor.net Fri Oct 26 02:43:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9221F84CA for ; Fri, 26 Oct 2012 02:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3APvLdos1LMy for ; Fri, 26 Oct 2012 02:43:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE6821F84DF for ; Fri, 26 Oct 2012 02:43:28 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9Q9hGlk026788; Fri, 26 Oct 2012 02:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351244606; bh=KMDvbREw28Jmx3vy5NE0QBppeMWZR8LsxqPEn+HZ/RY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X4I+F8JPnaT1WF+VA3ybuyvwK9EjeKcrTfvF0PrKA+i/+b7y6jiwKI6XtVzgPhzEh R7vEr5Eh5Jd3dIMGmZrNG44eISRMfb6Kt79EKxwengCuy2CjzYRZvARFQI6Tkri8DN KaLnh8jIDMHcIPgsmEp3iEa/YwQajQt9hbZ7vF/0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351244606; i=@resistor.net; bh=KMDvbREw28Jmx3vy5NE0QBppeMWZR8LsxqPEn+HZ/RY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3V7Y6P+9Au5rEvVGAVzIrPbr7Gqq98aW8gX5LHI2gadGTrJpUp6KWvIdG1ZdTkog6 AB2JlKN5A5LccEMkAgpgab3BUSHm39San/u6Y49jTFR1vxbX/GIvfigdSVj19ZkJNk vhtlOPMyj7o8Bl7CPbBJim8pLJRgopNiBNLwNKjQ= Message-Id: <6.2.5.6.2.20121026023121.0b46ed88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Oct 2012 02:35:03 -0700 To: Brian E Carpenter From: SM In-Reply-To: <508A48B8.7050906@gmail.com> References: <5040646F.6000103@gmail.com> <5088E475.1000206@gmail.com> <1351155260.68770.YahooMailNeo@web32507.mail.mud.yahoo.com> <508928CD.4080308@gmail.com> <50893A75.6070203@gmail.com> <6.2.5.6.2.20121025224452.09492e60@resistor.net> <508A48B8.7050906@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 09:43:30 -0000 Hi Brian, At 01:24 26-10-2012, Brian E Carpenter wrote: >It behaves like a client on one side and a server on the other side. Yes. The short answer is that it is a well-known term [1]. Regards, -sm 1. http://wiki.squid-cache.org/SquidFaq/ReverseProxy From fgont@si6networks.com Fri Oct 26 05:52:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4A121F8453 for ; Fri, 26 Oct 2012 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAk3aoh0A3pb for ; Fri, 26 Oct 2012 05:52:08 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DF17C21F8450 for ; Fri, 26 Oct 2012 05:52:07 -0700 (PDT) Received: from [186.134.20.23] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TRjON-0000x1-0D; Fri, 26 Oct 2012 14:52:03 +0200 Message-ID: <508A876F.6070503@si6networks.com> Date: Fri, 26 Oct 2012 09:51:59 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 12:52:08 -0000 On 10/25/2012 10:53 PM, Lorenzo Colitti wrote: > For example, I personally think that fragments are more trouble than > they're worth, they don't work in today's Internet (IPv4 *or* IPv6), > create security issues (see e.g., Fernando's issues with fragmented RAs, > plus an history of security issues in fragment-handling code) and that > applications are much better off implementing their own fragmentation > above UDP or whatever else they may use. I'd mostly say "+1" with everything you've said above. > Unfortunately, it doesn't seem > likely that this working group will reach consensus on such a > recommendation. Okay, how about: Plan A: Try to sense whether we can agree on advice Plan B: If we can't, just document the facts Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From wesley.george@twcable.com Fri Oct 26 07:54:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B4321F84EC for ; Fri, 26 Oct 2012 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKLPGPm-+6kp for ; Fri, 26 Oct 2012 07:54:17 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8915E21F84C6 for ; Fri, 26 Oct 2012 07:54:16 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,654,1344225600"; d="scan'208";a="459873289" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 26 Oct 2012 10:53:34 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 26 Oct 2012 10:54:12 -0400 From: "George, Wes" To: "Diego R. Lopez" , IPv6 Ops WG Date: Fri, 26 Oct 2012 10:54:12 -0400 Thread-Topic: New version of draft-lopez-v6ops-dc-ipv6 Thread-Index: AQHNr3M8j4EugeD3fkKjjO1OoT0HCJfLpGbA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336A87C8B@PRVPEXVS15.corp.twcable.com> References: <20121020200652.28676.43201.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [v6ops] New version of draft-lopez-v6ops-dc-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:54:17 -0000 SSd2ZSByZWFkIHRoaXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIGFuZCBJIGhhdmUgYSBmZXcgY29t bWVudHMuDQoNCkkgd291bGQgbm90IHJlZmVyIHRvIHlvdXIgbGFzdCB0cmFuc2l0aW9uIHN0YWdl IGFzICJOZXh0IEdlbmVyYXRpb24iIGFzIHRoYXQgaXMgbm90IGEgcGFydGljdWxhcmx5IGRlc2Ny aXB0aXZlIHRlcm0gZm9yIHRoZSBzdGFnZSB0aGF0IHlvdSBkZXNjcmliZSwgYW5kIGl0IGlzIGFs c28gYSBmYWlybHkgb3ZlcmxvYWRlZCB0ZXJtIC0gbXkgIm5leHQgZ2VuZXJhdGlvbiIgREMgbWF5 IHdlbGwgYmUgdGhlIG9uZSB3aGVyZSBJIGluY3JlYXNlIHRoZSBiYW5kd2lkdGgsIG9yIGJ1aWxk IG91dCBhIGZhYnJpYywgc3RhcnQgdXNpbmcgc29tZSBuZXcgd2lkZ2V0LCBvciB3aGF0ZXZlci4g SSB3b3VsZCBtYXliZSBjYWxsIGl0IElQdjYtb25seSBvciBTaW5nbGUtc3RhY2sgSVB2Niwgc2lu Y2UgdGhhdCBpcyByZWFsbHkgdGhlIGRlc2lyZWQgZW5kIHN0YXRlLCB3aGVyZSBhcyBtdWNoIG9m IHRoZSBEQyBhcyBwb3NzaWJsZSBpcyBydW5uaW5nIElQdjYgZm9yIGFsbCBmdW5jdGlvbnMsIGFu ZCBJUHY0IGNvbm5lY3Rpdml0eSBpcyBoYW5kbGVkIHZpYSB0cmFuc2l0aW9uIGFuZCB0cmFuc2xh dGlvbiB0ZWNobm9sb2dpZXMgYXQgdGhlIGVkZ2VzIG9mIHRoZSBEQyAoZWcgbG9hZGJhbGFuY2Vy cywgZXRjKS4NCg0KU2VjdGlvbiAyLjMgc2hvdWxkIG1lbnRpb24gdGhlIGZhY3QgdGhhdCB0aGlz IHN0YWdlIG1heSBiZSBkcml2ZW4gYnkgZWl0aGVyIGEgbGFjayBvZiBlbm91Z2ggSVB2NCByZXNv dXJjZXMgKHdoZXRoZXIgcHJpdmF0ZSBvciBnbG9iYWxseSB1bmlxdWUpIG9yIGEgbmVlZCB0byBy ZWNsYWltIElQdjQgcmVzb3VyY2VzIGZyb20gcG9ydGlvbnMgb2YgdGhlIG5ldHdvcmsgd2hpY2gg bm8gbG9uZ2VyIG5lZWQgdGhlbS4gVGhlcmUgaXMgYSBwb2ludCBhdCB3aGljaCBkdWFsIHN0YWNr IGlzIHNpbXBseSBub3QgcG9zc2libGUgYW55bW9yZSwgYW5kIG9uY2UgdGhhdCBwb2ludCBoYXMg YmVlbiByZWFjaGVkLCBhIGNhcmVmdWwgZXZhbHVhdGlvbiBvZiB3aGF0IHN0aWxsIG5lZWRzIHRv IHNwZWFrIElQdjQgYW5kIHdoYXQgZG9lcyBub3Qgd2lsbCBuZWVkIHRvIGhhcHBlbiB0byBlbnN1 cmUganVkaWNpb3VzIHVzZSBvZiB0aGUgcmVtYWluaW5nIElQdjQgcmVzb3VyY2VzLg0KDQpJdCBt aWdodCBhbHNvIGJlIGhlbHBmdWwgdG8gZGlzY3VzcyB0aGUgZGlmZmVyZW50IGNsYXNzZXMvY2F0 ZWdvcmllcyBvZiB0aGluZ3MgdGhhdCBhcmUgaW4gYW4gYXZlcmFnZSBkYXRhIGNlbnRlciwgYXMg dGhvc2UgbWF5IGhhdmUgYSBiZWFyaW5nIG9uIGhvdyB0aGUgdHJhbnNpdGlvbiBwcm9jZWVkcywg YW5kIGluZGVlZCBtYXkgYmUgYXQgZGlmZmVyZW50IHBoYXNlcyBvZiB0aGUgdHJhbnNpdGlvbiBh dCBkaWZmZXJlbnQgdGltZXM6DQoNCk1hbmFnZW1lbnQgc3lzdGVtcyAocHJvdmlzaW9uaW5nLCBh bGFybXMvUE1zLCBzb2Z0d2FyZSBkaXN0cm8sIGV0YykNCkZhYnJpYyAoYW5kIHBlcmhhcHMgZXZl biBkaXNjdXNzIHRoZSBkaWZmZXJlbnQgbGF5ZXJzLCBUb1IsIGFnZywgY29yZSwgZXRjKQ0KSHlw ZXJ2aXNvciAodGhvdWdoIHRoaXMgaXMgYWxyZWFkeSBtZW50aW9uZWQgaW4gYSBmZXcgcGxhY2Vz IGluIHRoZSBkcmFmdCkNCk1hY2hpbmUtdG8tbWFjaGluZSBjb21tdW5pY2F0aW9ucyAob25lIGFw cGxpY2F0aW9uIHRhbGtpbmcgdG8gYW5vdGhlciBvdmVyIGFuIEFQSSkNCkVuZC11c2VyIGFwcGxp Y2F0aW9ucy9jb250ZW50DQpFeHRlcm5hbCBzZXJ2aWNlcw0KRXRjDQoNClRoZSBrZXkgaGVyZSBp cyB0byBrZWVwIGl0IGdlbmVyaWMgZW5vdWdoIHNvIHRoYXQgaXQncyB3aWRlbHkgYXBwbGljYWJs ZSwgcmF0aGVyIHRoYW4gZ2V0dGluZyBzbyBzcGVjaWZpYyB0aGF0IHlvdSBoYXZlIHRvIGhhdmUg bXVsdGlwbGUgZGlmZmVyZW50IHNjZW5hcmlvcyB0byByZXByZXNlbnQgZGlmZmVyZW50IHBvdGVu dGlhbCBEQyBhcHBsaWNhdGlvbnMgYW5kIGRlc2lnbnMuDQoNCg0KU2VjdXJpdHkgY29uc2lkZXJh dGlvbnM6IGRyYWZ0LXZ5bmtlLW9wc2VjIGhhcyBiZWVuIHJlcGxhY2VkIGJ5IGRyYWZ0LWlldGYt b3BzZWMuIEhvd2V2ZXIuLi4gVGhlIHJlZmVyZW5jZWQgZHJhZnQgY292ZXJzIGEgbG90IG9mIGdy b3VuZCwgYW5kIHNpbXBseSByZWZlcnJpbmcgdG8gaXQgYnkgaXRzZWxmIG1pZ2h0IGJlIGRhdW50 aW5nIHRvIHBvdGVudGlhbCByZWFkZXJzLiBJdCBtaWdodCBiZSB3b3J0aCBoaWdobGlnaHRpbmcg c3BlY2lmaWMgc2VjdGlvbnMgdGhhdCBhcmUgZXNwZWNpYWxseSBwZXJ0aW5lbnQgdG8gRENzLCBz dWNoIGFzIHRoZSBkaXNjdXNzaW9uIG9mIE5EIGNhY2hlIGV4aGF1c3QsIGV0Yy4NCg0KDQpUaGFu a3MsDQoNCldlcyBHZW9yZ2UNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYNCj4gT2YgRGllZ28gUi4gTG9wZXoNCj4gU2VudDogU3VuZGF5LCBPY3RvYmVy IDIxLCAyMDEyIDY6MDMgQU0NCj4gVG86IElQdjYgT3BzIFdHDQo+IFN1YmplY3Q6IFt2Nm9wc10g TmV3IHZlcnNpb24gb2YgZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ng0KPg0KPiBIaSwNCj4NCj4g VGhpcyBuZXcgdmVyc2lvbiBpbmNvcnBvcmF0ZXMgYWxsIHRoZSBjaGFuZ2VzIGRpc2N1c3NlZCBp biBWYW5jb3V2ZXIsDQo+IGJlaW5nIHRoZSBtb3N0IHNhbGllbnQgYSB0aXRsZSBjaGFuZ2UgYW5k IHRoZSByZW5hbWluZyBvZiB0aGUgIm1hdHVyaXR5DQo+IGxldmVscyIgKGFuZCB0aGVpciBudW1i ZXJzKSBpbnRvIG5hbWVkICJ0cmFuc2l0aW9uIHN0YWdlcyIsIHBsdXMgbW9yZQ0KPiBlbGFib3Jh dGVkIHRleHQgZm9yIGV4YW1wbGVzIGF0IGVhY2ggdHJhbnNpdGlvbiBzdGFnZSwgYW5kIGEgZmly c3QgZnVsbA0KPiBhdHRlbXB0IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQo+DQo+ IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2 Ng0KPg0KPiBEaWZmIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxvcGV6 LXY2b3BzLWRjLWlwdjYtMDMNCj4NCj4gQmUgZ29vZGUsDQo+DQo+IC0tDQo+ICJFc3RhIHZleiBu byBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQo+DQo+IERyIERpZWdvIFIuIExvcGV6DQo+ IFRlbGVmb25pY2EgSStEDQo+IGh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KPg0K PiBlLW1haWw6IGRpZWdvQHRpZC5lcw0KPiBUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KPiBNb2Jp bGU6ICszNCA2ODIgMDUxIDA5MQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBF c3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQ dWVkZSBjb25zdWx0YXINCj4gbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOz biBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZQ0KPiBzaXR1YWRvIG3DoXMgYWJh am8uDQo+IFRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJl c3NlZS4gV2Ugb25seSBzZW5kIGFuZA0KPiByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0 aGUgdGVybXMgc2V0IG91dCBhdDoNCj4gaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNj bGFpbWVyLmFzcHgNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KVGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Ig c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlz IEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From iesg-secretary@ietf.org Fri Oct 26 09:04:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5799621F862A; Fri, 26 Oct 2012 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH0vt4+eBoyT; Fri, 26 Oct 2012 09:04:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E708621F84AF; Fri, 26 Oct 2012 09:04:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121026160427.30056.5891.idtracker@ietfa.amsl.com> Date: Fri, 26 Oct 2012 09:04:27 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:04:28 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ballot/ No IPR declarations have been submitted directly on this I-D. From kk.chittimaneni@gmail.com Sat Oct 27 13:18:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB6821F8644 for ; Sat, 27 Oct 2012 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbROsoyu70g5 for ; Sat, 27 Oct 2012 13:18:52 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08821F84E3 for ; Sat, 27 Oct 2012 13:18:48 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2102998wey.31 for ; Sat, 27 Oct 2012 13:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x2jZyp3AXGZ2cACA3lwoho7tFzVokoDTeNgXDB5MN5E=; b=hTTGrRd+uGlYjuU5piUBgYEZM4kxRh9YUgxTUTcaXZ7ceDkNC+cbV1EtHxKJ8t2UoV 7GlgM3zSXt1YDv7cu+ERvH6Se3eROohRKyHQHxniuHFldVz/XKdtkOra7yVEG7+BlpdT Dz2VVLez4OaTFPETma2zeIkIafjnoDuoLUQ1b7/mp3Eo3iXx9BUguzuCa6Q0OMdFVuZN FOI7Qf0QX0FJGJSMMfNuTDczUqFOngM6PhYC51zqyomWYlwuWIMLXTdrwqNmK0PVeRK4 k1697+RTiKOIByQTMGVv5liNd7hSEzYQgosqMwo7y0e9k6a47ys52h4Nzg0rQdE4e182 P/sg== MIME-Version: 1.0 Received: by 10.180.96.129 with SMTP id ds1mr9498344wib.17.1351369127812; Sat, 27 Oct 2012 13:18:47 -0700 (PDT) Received: by 10.216.231.211 with HTTP; Sat, 27 Oct 2012 13:18:47 -0700 (PDT) In-Reply-To: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Sat, 27 Oct 2012 13:18:47 -0700 Message-ID: From: KK Chittimaneni To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d044282a0d2dc8404cd102420 Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 20:18:53 -0000 --f46d044282a0d2dc8404cd102420 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 6:53 PM, Lorenzo Colitti wrote: > As always, the danger in trying to reach consensus on a controversial > topic is that of endlessly discussing the issue, which makes it impossible > to make a useful contribution to it. The way I see it, if we can't reach > consensus, it's better to punt entirely and at least issue a statement > about the issues. At least we will have done something useful. If we get > deadlocked forever in trying to decide what the right thing to do is, we > will get nothing useful done at all. > > +1 IMHO, it would be naive to ignore operational reality. It is better to document the current state-of-affairs and let the rest of the community make informed decisions based on this information. --f46d044282a0d2dc8404cd102420 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 25, 2012 at 6:53 PM, Lorenzo Colitti= <lorenzo@google.com> wrote:
As always, the danger in trying to reach co= nsensus on a controversial topic is that of endlessly discussing the issue,= which makes it impossible to make a useful contribution to it. The way I s= ee it, if we can't reach consensus, it's better to punt entirely an= d at least issue a statement about the issues. At least we will have done s= omething useful. If we get deadlocked forever in trying to decide what the = right thing to do is, we will get nothing useful done at all.
=A0

+1
IMHO, it would be naive to ignore operational reality. It is better to=20 document the current state-of-affairs and let the rest of the community=20 make informed decisions based on this information.
=A0
--f46d044282a0d2dc8404cd102420-- From kk.chittimaneni@gmail.com Sat Oct 27 13:48:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0821F84C0 for ; Sat, 27 Oct 2012 13:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-0.300, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjqPlwPGsW09 for ; Sat, 27 Oct 2012 13:48:01 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF321F84BF for ; Sat, 27 Oct 2012 13:48:01 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2034016wgb.13 for ; Sat, 27 Oct 2012 13:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ysedAkLHBGOVMhD6pDv4cEULSRZO/tZ/s7R15XqFI6g=; b=hSaLuQQzMaiE7oDN8AHmG3PMFHzsBIFcEmS8CO4gbMCqShtYxmhoumWsJq/KvFSZyZ qRYLfItbZVz81A0ioBpNZ8CIuqDhA6fH/nB1vg9BVo3Grbaqm8zoWaMy+wWVqGhJVMKt HFddaHbfAar7k3lHhAeZr4YM6+En8I0lQTvUwYyGWU6smTfV1k881I2GMyUCRSaTfkCq hc0fKWuvTFqS++wuvZzGNnYYtWc0FxjKz70g4QniJDyGybSeB4oEcLEgHLzdkvNk3TBR FuhsrGjOp1qzJk39dO8hJAoV31V8MmJQuqABQrCgs+GeRJA8WNfsHUxokx8mECKMMBa7 Yelw== MIME-Version: 1.0 Received: by 10.216.227.133 with SMTP id d5mr15418141weq.194.1351370880182; Sat, 27 Oct 2012 13:48:00 -0700 (PDT) Received: by 10.216.231.211 with HTTP; Sat, 27 Oct 2012 13:48:00 -0700 (PDT) In-Reply-To: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> References: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> Date: Sat, 27 Oct 2012 13:48:00 -0700 Message-ID: From: KK Chittimaneni To: Philip Matthews Content-Type: multipart/alternative; boundary=0016e6dd98b745e96504cd108d49 Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] New version of Design Guidelines draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 20:48:02 -0000 --0016e6dd98b745e96504cd108d49 Content-Type: text/plain; charset=ISO-8859-1 Hey Philip, A very nice read, this revision is looking pretty good. Cheers, KK On Mon, Oct 22, 2012 at 11:28 AM, Philip Matthews wrote: > Folks: > > I have just posted a new version (-01) of the Design Guidelines draft: > > https://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines/ OR > http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01 > > This version is pretty much a complete rewrite of the document. It > incorporates all the tremendous feedback that I received by email and > during the lengthy discussion at IETF-84 in Vancouver. Many thanks to the > many, many people who gave me feedback. I spent quite a few hours going > through my emails and listening to the audio recording in an effort to > capture everyone's feedback. If you feel I somehow forgot or > mis-interpreted your comment, please let me know. > > This version of the document is somewhat more definite in some of its > recommendations than the previous version. For design choices where I felt > that the comments received overwhelming favored one option, the new version > reflects this sentiment. For example, I felt there was a strong consensus > at the last WG meeting that operators should mix IPv4 and IPv6 traffic on a > single logical link wherever possible, though I noted that device > limitations may require separating them in some cases (e.g. to get good > traffic statistics). > > Comments on this new version are most welcome. > > - Philip > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0016e6dd98b745e96504cd108d49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Philip,

A very nice read, this revision is looking pretty good. =

Cheers,
KK

On Mon, Oct 22, 201= 2 at 11:28 AM, Philip Matthews <philip_matthews@magma.ca> wrote:
Folks:

I have just posted a new version (-01) of the Design Guidelines draft:
=A0 =A0 =A0https://datatracker.ietf.org/doc/dra= ft-matthews-v6ops-design-guidelines/ =A0OR
=A0 =A0 =A0http://tools.ietf.org/html/draft-matthew= s-v6ops-design-guidelines-01

This version is pretty much a complete rewrite of the document. It incorpor= ates all the tremendous feedback that I received by email and during the le= ngthy discussion at IETF-84 in Vancouver. Many thanks to the many, many peo= ple who gave me feedback. I spent quite a few hours going through my emails= and listening to the audio recording in an effort to capture everyone'= s feedback. If you feel I somehow forgot or mis-interpreted your comment, p= lease let me know.

This version of the document is somewhat more definite in some of its recom= mendations than the previous version. For design choices where I felt that = the comments received overwhelming favored one option, the new version refl= ects this sentiment. For example, I felt there was a strong consensus at th= e last WG meeting that operators should mix IPv4 and IPv6 traffic on a sing= le logical link wherever possible, though I noted that device limitations m= ay require separating them in some cases (e.g. to get good traffic statisti= cs).

Comments on this new version are most welcome.

- Philip


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

--0016e6dd98b745e96504cd108d49-- From nejc@skoberne.net Sat Oct 27 16:22:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C9521F85D6 for ; Sat, 27 Oct 2012 16:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEQ28l5Tbf2U for ; Sat, 27 Oct 2012 16:22:14 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF221F85C1 for ; Sat, 27 Oct 2012 16:22:14 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2064902wgb.13 for ; Sat, 27 Oct 2012 16:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skoberne.net; s=google; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xQ8rHTC03DL4xE0Z6JqoPkkqwyC2IojwQ6eWgX3DEd0=; b=XKelwvj1MtOi8Sqj1S1eUx2ikfSMOktvnpMEXmSXIGY4ASCBxw/5Gkanq5+LUM3oub ZaT1HefY6rdRzIHiygtXOa2nsSXRzZ4P/6dDegvaSyCxm/+ob8JqY3UUhLZNgruxc7pn CK+Y0amc0O2WW70MiGrp42hx0D7DwT3cmaKz8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=xQ8rHTC03DL4xE0Z6JqoPkkqwyC2IojwQ6eWgX3DEd0=; b=hstplkPgI5N96xRjMG3uAIzS4uxGjYbGToNNeLm5uGyuQOtklqhTXVgebw9HS++vgA 6GGTSMeRa3nf7uNfRqxpOwSMNeCa0Nk9cP76GMA62TX02hR//iKj5m6RG/itNH9WXI8L xsM9rsDc3GRjI6oG1hNEXN6uIAbrliDRAN3cTuqIgVjoKO+qtBE7PBRkzP30QaXG4UlC r02jPKgAY95xbZzNP2E1QppV+GaRPIS8t4OmjW7odadugG6cAf3rgvTdb790CWa4l6Ae uBdG5Ye+n3iYXaLQTXQolXxMDOwhkzz8seAetz3aee7EPTKT3+9ZKDaSMTJ1msj2YjPd vSxw== Received: by 10.180.80.104 with SMTP id q8mr9907555wix.6.1351380133533; Sat, 27 Oct 2012 16:22:13 -0700 (PDT) Received: from [192.168.1.25] ([82.153.27.210]) by mx.google.com with ESMTPS id m14sm3968209wie.8.2012.10.27.16.22.12 (version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 16:22:12 -0700 (PDT) Message-ID: <508C6CA5.4090406@skoberne.net> Date: Sun, 28 Oct 2012 00:22:13 +0100 From: =?windows-1252?Q?Nejc_=8Akoberne?= User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <20121002115421.GY13776@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk7YMuRu4AdoRCyx6FDA+fgxn/PmPTMMRpEdlrZAo/uziHqhRTY3rEpN026sl+PJS/ejYuB Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 23:22:15 -0000 Hi, I am reviving this thread, as (AFAIK) nobody mentioned the following issue: "Other aspects of NAT behaviour, notably the NAT binding lifetime and the form of NAT "cone behaviour" for UDP take on the more the more restrictive of the two NATs in sequence. The binding times are potentially problematical in that the two NATs are not synchronised in terms of binding behaviour. If the CGN has a shorter binding time, it is possible for the CGN to misdirect packets and cause application level hang ups. However this is not overly different to a single level NAT environment where aggressively short NAT binding times will also run the risk of causing application level hang ups when the NAT drops the binding for a active session that has been quiet for an extended period of time." (Geoff Huston, http://www.potaroo.net/ispcol/2011-03/transtools-part2.pdf, page 7) So binding lifetime desynch can be quite harmful here? Any real-world experience on this? Thanks, Nejc On 2.10.2012 13:54, Randy Bush wrote: >>> so, is double nat really worse than single nat? is it formally >>> different? except in the case of overlapping spaces, of course. >> One of the problems with "someone else controls your NAT" is that >> you can't add port mappings. This seems to be an inevitable side >> effect of NAT444 (but can happen with single NAT44 as well, of >> course, depending on where it's placed). > i asked *formally*. i am not concerned with all the ops, social, > stuff. and not about issues not directly connected to the nat. > what does double translation do that single does not? > > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Sun Oct 28 13:08:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2638E21F863F for ; Sun, 28 Oct 2012 13:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6tb5XOUAY-6 for ; Sun, 28 Oct 2012 13:08:37 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8121F860C for ; Sun, 28 Oct 2012 13:08:37 -0700 (PDT) Received: from [98.139.91.66] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 28 Oct 2012 20:08:33 -0000 Received: from [98.139.91.36] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 28 Oct 2012 20:08:33 -0000 Received: from [127.0.0.1] by omp1036.mail.sp2.yahoo.com with NNFMP; 28 Oct 2012 20:08:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 462202.86923.bm@omp1036.mail.sp2.yahoo.com Received: (qmail 52649 invoked by uid 60001); 28 Oct 2012 20:08:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351454912; bh=VL5CxffSfIDd1g7wf96dT/c3fuOD1r8iUsgEDChy9uk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EULiN9gxXqz2PWxgkXGgGgnA/L2KwuqE8d7DBK6ncGfG4Ok2HCqECT+7t41Jhqx4/aeiySpBYlRFh5IcCD6KRSokmlQRhNeyIyqEqq3pecydXFI2vAWkvxW8q9sWbCbUuyzMHR2lHhl9P76xNNOqL2OeHVsUOjiawTaQ5SJESns= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NPTeCAk3rLBxjk9YyNYAbzyQ6womFi6XQU3yzCsJlARQ7VUFOWZskWrUJiNTT7KjhDMLzSGktgSRLNym8LWZygQYOXbdouCvyv79+eNNqi19jA2ntTNw2iikLXwKwKoNXWsQdOI1lwiLvvzedoHByea+MMaJ7mzXwInb5AA11LQ=; X-YMail-OSG: hUQdFYAVM1mve3RhQ6UnRZTqPMi29L0bnoE6M8RLOyrcSzj rRaus4d4y.qNXvm_cyBWASqdlgt92_x1UJSlEzKtLactLmSORcTdEVyv2ZtU wVMXHIvM3pYFT3JLsDGMM1B0GPC1fYQJ1RcyuA5K0h2MrCFeLunoyoT63vS7 TCkH3c_ntepJ1RqT3wyRSqJoJQzCZBax5Bttv1UC2.eDiw7pVS_WwRMKyxz9 lgiDzRLhJaFPWSQIxar7mvXuVK98Ic9xvkg1Gqot8iDSK20e_WXaiatUYEzN 8wHSMocboxrs4lZ3YVhq9nuX.EwgWa8gsp0kjPwiKjZeOyH6GD.tM.K5B.v3 FpHoKeuychkiNw9he2ICUZrDlUtNHhWnS3NpKcL.ZeiNTqxwPO2dlAnewdtL wQewr4mWHxgrR4EX4mSWwy056NcQG1MZcbBj.k0pOHk1JBiOTsk4J2nRsF66 YxGlnpp7PeCogT4ClTzg_YvYmup74GeGx4WJnNep6SWt2RuvpijCtIxGUVDg w95_D.hF7Z1eBXRw- Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Sun, 28 Oct 2012 13:08:31 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPgo.VG86IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPiAKPkNjOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PjsgVjYgT3BzIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBGcmlkYXksIDI2IE9jdG9iZXIgMjAxMiAxMTo1MSBQTQo.U3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC10YXlsb3ItdjZvcHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> Message-ID: <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Sun, 28 Oct 2012 13:08:31 -0700 (PDT) From: Mark Smith To: Fernando Gont , Lorenzo Colitti In-Reply-To: <508A876F.6070503@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 20:08:38 -0000 Hi,=0A=0A=0A>________________________________=0A> From: Fernando Gont =0A>To: Lorenzo Colitti =0A>Cc: Mark= Smith ; V6 Ops =0A>Sent: Frida= y, 26 October 2012 11:51 PM=0A>Subject: Re: [v6ops] new draft: draft-taylor= -v6ops-fragdrop=0A> =0A>On 10/25/2012 10:53 PM, Lorenzo Colitti wrote:=0A>>= For example, I personally think that fragments are more trouble than=0A>> = they're worth, they don't work in today's Internet (IPv4 *or* IPv6),=0A>> c= reate security issues (see e.g., Fernando's issues with fragmented RAs,=0A>= > plus an history of security issues in fragment-handling code) and that=0A= >> applications are much better off implementing their own fragmentation=0A= >> above UDP or whatever else they may use. =0A>=0A>I'd mostly say "+1" wit= h everything you've said above.=0A>=0A=0AI don't really disagree with that = either, it's more that fragmentation is a=0A=0Acurrent capability of IPv6, = so I think the IETF's recommendation should be=0Athat it is enabled by defa= ult on the Internet. I think that recommendation=0Afits the robustness prin= ciple too - "..., be liberal in what you accept=0Afrom others".=0A=0AIf the= IETF recommends against forwarding fragments, then I think that=0A=0Acreat= es the obligation to provide advice and methods on what do instead,=0Awhich= might include specifying a standardised UDP fragmentation method,=0Aand pr= ovide alternative methods for protocols that utilise IP layer=0Afragmentati= on.=0A=0AFragments may still be in use, however they may not used much at t= he=0A=0Aapplication layer. OSPFv2 and OSPFv3 uses them instead of implement= ing=0Ait's own fragmentation mechanism (and that may be across multiple hop= s=0Ain the case of a OSPF virtual link), and they are likely to be commonly= =0Aused in IPsec and GRE tunnels (PMTUD across the tunnel path and having= =0Athe tunnel MTU adjusted to it is a more advanced capability). My memory= =0Ais vague, however I also seem to remember seeing them being sent by load= =0Abalancers on the Internet too. At a residential ISP, this was no issue,= =0Aas we didn't perform any stateful firewalling at the edge of our network= .=0A=0A=0AI think another thing to bare in mind is a lot of peoples' common= approach=0A=0Aof taking a shortcut by just doing what the "experts" say. W= hile=0Apeople like us might be interested in the details and pros and cons= =0Aof fragmentation, I think a lot of people just want the experts to say= =0A"enable them" or "disable them", so they can move onto working on someth= ing=0Aelse on their list of things to do. If we don't provide that advice,= =0Athen people will default to what they believe is the safe position, and= =0Atheir safe position is "if in doubt, switch it off". I think this is the= =0Aexplanation as to why people have disabled all ICMPv4, breaking PMTUD -= =0Athey've heard that "ICMP is used by ping, and ping is bad security wise"= =0A(i.e. the topology/host topology argument), so rather than investigating= =0Athe details, just universally disable ICMP. As they themselves rarely se= e=0Athe consequences of PMTUD failing, they think what they've done is fine= -=0Aand give that advice to others if they're asked. That approach has pro= pagated=0Ato the point where MSS hacking on all subscribers is necessary in= a broadband=0Ascenario if you have a dumbell MTUs situation (i.e. PPPoE be= tween cust LAN and=0AInternet)=0A=0A=0A>=0A>> Unfortunately, it doesn't see= m=0A>> likely that this working group will reach consensus on such a=0A>> r= ecommendation.=0A>=0A>Okay, how about:=0A>=0A>Plan A: Try to sense whether = we can agree on advice=0A>Plan B: If we can't, just document the facts=0A>= =0A>Cheers,=0A>-- =0A>Fernando Gont=0A=0A=0A=0ARegards,=0AMark. From lorenzo@google.com Sun Oct 28 23:52:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6413F21F869D for ; Sun, 28 Oct 2012 23:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C19VaF5V3Od for ; Sun, 28 Oct 2012 23:52:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 950C421F868D for ; Sun, 28 Oct 2012 23:52:00 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4830185obq.31 for ; Sun, 28 Oct 2012 23:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=0gHzQwV2K0izrYjy+eCZWaBFvUP9uCfCHv3R7vx413E=; b=mxSjrKzoGy55Xg7qks+NltCyWDnMzXSAhLaJPfHLHa9MzwwVik46robX+6JxPd1u87 z2MhbIE0EWMiIEo+Nf7pbUkDNrU7d/hcIwKVOAVsT7xpV3dafte9vXdbAagM4740cZL0 qu2pU5s1gu3q5sBkmHkBXbErS/a82I67Nn5pI00QGNUluIziAZD+6rl9yEThKtHV6n/+ OqNbxetGVi62z+jDDigWcHUQOi6dSOJKt9S/jRGf95xwTmwEbLIrNuL3veyo2mUtJtdg tiQLkoH30xvWS2S51n3yoGI/46I90l73plcFL3fsM7mijJn5i9V7gxxpcfWksZ2Fb066 +bsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=0gHzQwV2K0izrYjy+eCZWaBFvUP9uCfCHv3R7vx413E=; b=BZInisBwqbrQTX6lfYd9jM2HEta6x6O0glyjha+zIsVW4qyORb0TyQ8vJy1EL7oss6 iCjFSBmyeCRR6BK2pwBDIJB3gKlQdnmPcZ47BH+020xy/NwK2S+1hYhRI9RB+JEhoZ/5 UjgnfFQVUTZ1VUrbslmjnWCeO8b/SZp8NeM1NGR6Smp538mSNlihfcxeFk6wSD5EXizq PJL0CMkUMRFlO2IzKH5KMWeK7X2/rUurvLn57sRzNsaw0RoglyOKTHq6GsfgxeAZ2jcO 089VdEY3stO+9bmkJOfq54C7b0og+7yllc3Bp4eNrak9nUhxFFw8dGg7TF06B5u+CC31 rfyw== Received: by 10.60.5.138 with SMTP id s10mr24735367oes.80.1351493520018; Sun, 28 Oct 2012 23:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Sun, 28 Oct 2012 23:51:39 -0700 (PDT) In-Reply-To: <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> From: Lorenzo Colitti Date: Mon, 29 Oct 2012 15:51:39 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=e89a8ff252ce2d4ef004cd2d1bf3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmn5XcD5hLZYNFk64g/6VFelTmcV1V4I54b2nNydUKAceFxS0w+1WN9oGmtvcJvnApNEBTUczLC94fDgVe3QXM40mEbNq+C6JeeprZzPGQ4/qtsftBp1OqFMxpPV1B6ex4Fs+lHQWMY4MttvWQxY+Q9dmNIRswggYlq1GOLdAv20K0NjyITbE2NogtBy5JrYlCsW+93 Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 06:52:01 -0000 --e89a8ff252ce2d4ef004cd2d1bf3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith wrote: > I don't really disagree with that either, it's more that fragmentation is > a current capability of IPv6, so I think the IETF's recommendation should > be that it is enabled by default on the Internet. I think that > recommendation fits the robustness principle too - "..., be liberal in what > you accept from others". > > If the IETF recommends against forwarding fragments, then I think > that creates the obligation to provide advice and methods on what do > instead, > which might include specifying a standardised UDP fragmentation > method, and provide alternative methods for protocols that utilise IP layer > fragmentation. > > Fragments may still be in use, however they may not used much at the > > application layer. OSPFv2 and OSPFv3 uses them instead of > implementing it's own fragmentation mechanism (and that may be across > multiple hops in the case of a OSPF virtual link), and they are likely to > be commonly used in IPsec and GRE tunnels (PMTUD across the tunnel path and > having the tunnel MTU adjusted to it is a more advanced capability). Ok, so how about stating the following, then? 1. Fragments are unreliable on the Internet today. 2. If you're an application developer and your apps need to run on the Internet, then fragments will likely not work in many cases. If you want your application to work in these cases, you should either use application-layer fragmentation, use path MTU discovery, or limit yourself to small packets instead of sending fragments. 3. If you control the network (e.g., if you're the network operator), and want to use fragments for tunnels or other purposes, go ahead, but note that in other people's networks, they might be filtered. Your suggestion of providing a generic UDP segmentation mechanism is a fine idea, and one that we discussed before this draft was written, but our feeling was that such a solution would be impossible to agree on until we have a problem statement. This draft ("FYI: some operators filter fragments. Keep that in mind.") was supposed to be the problem statement. --e89a8ff252ce2d4ef004cd2d1bf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith <markzzzsmith@yahoo.= com.au> wrote:
I don't really disagree with that either, it's more that fragmentat= ion is a=A0current capability of IPv6, so I think the IETF's recommenda= tion should be=A0that it is enabled by default on the Internet. I think tha= t recommendation=A0fits the robustness principle too - "..., be libera= l in what you accept=A0from others".

If the IETF recommends against forwarding fragments, then I think that=A0cr= eates the obligation to provide advice and methods on what do instead,
which might include specifying a standardised UDP fragmentation method,=A0a= nd provide alternative methods for protocols that utilise IP layer
fragmentation.

Fragments may still be in use, however they may not used much at the

application layer. OSPFv2 and OSPFv3 uses them instead of implementing=A0it= 's own fragmentation mechanism (and that may be across multiple hops=A0= in the case of a OSPF virtual link), and they are likely to be commonly=A0u= sed in IPsec and GRE tunnels (PMTUD across the tunnel path and having=A0the= tunnel MTU adjusted to it is a more advanced capability).

Ok, so how about stating the following, then?

1. Fragments are unreliable on the Internet today.
2. If you're an application developer and your apps need to run on th= e Internet, then fragments will likely not work in many cases. If you want = your application to work in these cases, you should either use application-= layer fragmentation, use path MTU discovery, or limit yourself to small pac= kets instead of sending fragments.
3. If you control the network (e.g., if you're the network operato= r), and want to use fragments for tunnels or other purposes, go ahead, but = note that in other people's networks, they might be filtered.

Your suggestion of providing a generic UDP segmentation= mechanism is a fine idea, and one that we discussed before this draft was = written, but our feeling was that such a solution would be impossible to ag= ree on until we have a problem statement. This draft ("FYI: some opera= tors filter fragments. Keep that in mind.") was supposed to be the pro= blem statement.
--e89a8ff252ce2d4ef004cd2d1bf3-- From brian.e.carpenter@gmail.com Mon Oct 29 00:57:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E80E21F86DC for ; Mon, 29 Oct 2012 00:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6d47waFklqn for ; Mon, 29 Oct 2012 00:57:14 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26E9A21F868B for ; Mon, 29 Oct 2012 00:57:13 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2553211wey.31 for ; Mon, 29 Oct 2012 00:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kFfEOn2kVFsyLtmO+3v8cqk+FzmKXbW+VfedLBNg1QQ=; b=LVXI7z3bUUemZdMmlhTqrc/ip2fCU2KWoO5GtdyGVe7VQQFF461/sw7clTAbEISzky hi0EX9Uev+eo3Ebn2sbmFV7emoTEBEZv4LI50FboQmfBRUbLqfjOVuP3DuhsMa+ag7BZ s5n+3alCI1jpFBkfd0lLxOFrEpx6EPE2twc/ivmU4tedOuJ1l62xiX7NAroc8kZzoEkK i9ywpQDwYKF7QOXpDBnyc8riO/J2Vj9WiuFYKjQWaLBmVccE++hAC624IkuBaJhyebab 7TQ3TUVSjmJdsARpr3zC3dZ3V0tV9LSR3DI/I1SfnRLbGAYhjZbEsB21rXeilCfTg5Ip QzzQ== Received: by 10.180.90.201 with SMTP id by9mr13759710wib.5.1351497433304; Mon, 29 Oct 2012 00:57:13 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-117.as13285.net. [2.102.219.117]) by mx.google.com with ESMTPS id gg4sm10115768wib.6.2012.10.29.00.57.11 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 00:57:12 -0700 (PDT) Message-ID: <508E36DA.5090501@gmail.com> Date: Mon, 29 Oct 2012 07:57:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:57:15 -0000 On 29/10/2012 06:51, Lorenzo Colitti wrote: ... > Your suggestion of providing a generic UDP segmentation mechanism is a fine > idea, and one that we discussed before this draft was written, but our > feeling was that such a solution would be impossible to agree on until we > have a problem statement. This draft ("FYI: some operators filter > fragments. Keep that in mind.") was supposed to be the problem statement. I think the real problem statement is "some operators filter some extension headers, including fragments, and some operators filter ICMP PTB." Brian From lorenzo@google.com Mon Oct 29 01:03:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645E421F849E for ; Mon, 29 Oct 2012 01:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhyKfx6Owaoe for ; Mon, 29 Oct 2012 01:03:16 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E103121F849D for ; Mon, 29 Oct 2012 01:03:15 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so4952316oag.31 for ; Mon, 29 Oct 2012 01:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=q0hbv6AqB1v6EyqVLC4rbfP2l2pRPm1tFqcnl+9+c7w=; b=JGaDswz6QqTqfJr7sj8vzUb8bQ9qpYeULoBBwPuqCQIBfWjCb9efHp6GNW4gxVbcfQ rNBiMfN+qRROWx3Vw36Z2N9+sSr/M2Nyr+VVpPc69pHWoxvnV+GvPzdpJfLjucK0WaXZ rbiCq8WHypeuNOwbxnMCXkNTM21CNf1z6bY4ECbuhYaDCo2yKc80R8UxXem6VBnBU5ni VKnreUwHw7LYMTgeB/HN3XWDgge+dI4WWbdevix300zuG0KInt69ZR7AoEFdv2Uu01cV WTgkq44RHkWhl21bCd0YUAZiR8gDmbMILS339ZZfJ5YiOPsodxZgwBDJqa9vs/6aNPAP udZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=q0hbv6AqB1v6EyqVLC4rbfP2l2pRPm1tFqcnl+9+c7w=; b=kPc8IL5m5fK3XqhjImLD9zEHw7P8TdX3+WAWg+wQxWhrPbBmFQlgs3BMl/6qXPEpYy FVnWKvmdTdLc0k+ONWvHaUTuM71Nz7W4HqwCQjdqNY4Mx1Z37zSgF8y/lqGUQ829o7TY NOci5xY+6pfZ/7YM8BDowLYqmCjSoqEkshCGy+19V7MFrToDK91eLUFyJTYqBjNYV1Gd ZMt10YZILgBROxBIyenotPuRzmgOur+/AMA061XzBh7rSXJRliaDc4An+PD4jLgBh6aZ iLCie8RiX9q3KpbOC01kSyaCN/WFRNlXc+g0sbuikhbW5BIk3U8uylmplCyvwXmpbRBs 116Q== Received: by 10.60.12.99 with SMTP id x3mr9451720oeb.27.1351497795430; Mon, 29 Oct 2012 01:03:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 29 Oct 2012 01:02:55 -0700 (PDT) In-Reply-To: <508E36DA.5090501@gmail.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <508E36DA.5090501@gmail.com> From: Lorenzo Colitti Date: Mon, 29 Oct 2012 17:02:55 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8ff2561002e90004cd2e1a24 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkSsj+/BupAlnnnfuHVG3WWjK9I0tkbJT2Bc6D7TM8l4izpfU4Iy5oe0Z/ca/XClGuYjOdkwV9VaZS6SE8mbHtbEW5yMf6N4uWAwQHf0ZaKsJgDhsQm+crLz5XUpGuEHa1L7RTzwl+RYzoVD7Zuoi7hLIOZda6sZZkqu8jkwaQxKYQNQd79b50tPvFx9Imni38OuBmQ Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:03:16 -0000 --e89a8ff2561002e90004cd2e1a24 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 29, 2012 at 4:57 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I think the real problem statement is "some operators filter some extension > headers, including fragments, and some operators filter ICMP PTB." > I think we can get to consensus as a group that filtering PTB is a bad idea though, right? --e89a8ff2561002e90004cd2e1a24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 29, 2012 at 4:57 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
I think the real problem statement is "some operators filter some exte= nsion
headers, including fragments, and some operators filter ICMP PTB."
=

I think we can get to consensus as a group= that filtering PTB is a bad idea though, right?=A0
--e89a8ff2561002e90004cd2e1a24-- From brian.e.carpenter@gmail.com Mon Oct 29 01:25:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEAE21F8552 for ; Mon, 29 Oct 2012 01:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbvTHO7sjEI5 for ; Mon, 29 Oct 2012 01:25:19 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8866221F854C for ; Mon, 29 Oct 2012 01:25:19 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1690150bkc.31 for ; Mon, 29 Oct 2012 01:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NQGHV7SS2j4GkegPh+T49mcxsUG1tnu/AEsE98XYt2s=; b=ToMca9aHnjWA1ahf/OHtszPkxT2kjeuylVv2jyX8Y2TbBGpOgMSMf7cxr1Y4w1HOfn QhX8mZLnHVHxj+uERwe1GB36i8OBmvrcXF+IyF9Z8ORNW7EobeFIkzz2BrEjQGZnY6XQ BDvXkhXLh6567BmczqSVitk7iRdxc62mnrvJcPUBMB6pNpOFn95bxrLhY/6S0OEogCQG U6EiBilMr1QIjIdPCktiP4xBZjWeOh1nsSXlgYjKtOIhfg2v1x5vOEWx3lji/u0dD9e6 YhSRsqaf1CuSlcdmj5k2S6PBAeWicxmQiRrx/UL8dXz1mE7s5QPzODvWllzVYYo3t2Oj iAiw== Received: by 10.204.11.70 with SMTP id s6mr9206054bks.63.1351499118605; Mon, 29 Oct 2012 01:25:18 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-117.as13285.net. [2.102.219.117]) by mx.google.com with ESMTPS id ht18sm3172670bkc.14.2012.10.29.01.25.15 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 01:25:16 -0700 (PDT) Message-ID: <508E3D6E.60602@gmail.com> Date: Mon, 29 Oct 2012 08:25:18 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <508E36DA.5090501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:25:20 -0000 On 29/10/2012 08:02, Lorenzo Colitti wrote: > On Mon, Oct 29, 2012 at 4:57 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> I think the real problem statement is "some operators filter some extension >> headers, including fragments, and some operators filter ICMP PTB." >> > > I think we can get to consensus as a group that filtering PTB is a bad idea > though, right? I would hope so, and there's already an RFC that covers it, but you did suggest PMTUD as an alternative to fragmentation. We'd better issue a *complete* advisory. Brian From tjc@ecs.soton.ac.uk Mon Oct 29 06:44:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE2D21F8660 for ; Mon, 29 Oct 2012 06:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS4foXVzIIx2 for ; Mon, 29 Oct 2012 06:44:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1921F8646 for ; Mon, 29 Oct 2012 06:44:01 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TDhxQC013296 for ; Mon, 29 Oct 2012 13:44:00 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9TDhxQC013296 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351518240; bh=bfFEZ/afFGfp1tr5GcP0jDdfdMI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=ZGMHtlXj3kIHQrIRPdaFPGG6SxYUA5rxIO3fHZGwamGsCa38llGPqkIixLaZ/S87/ mJRVh/H7C1qfaOoHRj73phgu13ddTJSqmUxkZNyDWaAA24x67aIehu+uhgFRx7trYv 8LAps4JgtVwGxLGnTfPZPv55NHCr8AA3L+A29n0M= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9SDhx0430601441HP ret-id none; Mon, 29 Oct 2012 13:44:00 +0000 Received: from ip-205-081.eduroam.soton.ac.uk (ip-205-081.eduroam.soton.ac.uk [152.78.205.81]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TDhtLx008510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 13:43:55 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <508E3D6E.60602@gmail.com> Date: Mon, 29 Oct 2012 13:44:03 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <508E36DA.5090501@gmail.com> <508E3D6E.6060! 2@gmail.com> <0BA41720-DC11-46A9-93C7-50B8F33EBBD3@ecs.soton.ac.uk> To: V6 Ops X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9SDhx043060144100; tid=o9SDhx0430601441HP; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9TDhxQC013296 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 13:44:03 -0000 On 29 Oct 2012, at 08:25, Brian E Carpenter = wrote: > On 29/10/2012 08:02, Lorenzo Colitti wrote: >> On Mon, Oct 29, 2012 at 4:57 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >>=20 >>> I think the real problem statement is "some operators filter some = extension >>> headers, including fragments, and some operators filter ICMP PTB." >>>=20 >>=20 >> I think we can get to consensus as a group that filtering PTB is a = bad idea >> though, right? >=20 > I would hope so, and there's already an RFC that covers it, but you = did suggest > PMTUD as an alternative to fragmentation. We'd better issue a = *complete* advisory. This, along with Lorenzo's other three points, could be that complete = advisory? The same advisory can target different stakeholders. Tim= From touch@isi.edu Mon Oct 29 08:09:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAA421F8674 for ; Mon, 29 Oct 2012 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRUbYvOSb9Cp for ; Mon, 29 Oct 2012 08:09:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C121F89B2 for ; Mon, 29 Oct 2012 08:09:44 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q9TF8wjj013057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Oct 2012 08:09:07 -0700 (PDT) Message-ID: <508E9C0A.8060004@isi.edu> Date: Mon, 29 Oct 2012 08:08:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:09:45 -0000 How does that differ substantively from RFC 4821's advice? See esp. Sec. 8 of that doc, which seems just as accurate for the current situation. Joe On 10/28/2012 11:51 PM, Lorenzo Colitti wrote: > On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith > wrote: > > I don't really disagree with that either, it's more that > fragmentation is a current capability of IPv6, so I think the IETF's > recommendation should be that it is enabled by default on the > Internet. I think that recommendation fits the robustness principle > too - "..., be liberal in what you accept from others". > > If the IETF recommends against forwarding fragments, then I think > that creates the obligation to provide advice and methods on what do > instead, > which might include specifying a standardised UDP fragmentation > method, and provide alternative methods for protocols that utilise > IP layer > fragmentation. > > Fragments may still be in use, however they may not used much at the > > application layer. OSPFv2 and OSPFv3 uses them instead of > implementing it's own fragmentation mechanism (and that may be > across multiple hops in the case of a OSPF virtual link), and they > are likely to be commonly used in IPsec and GRE tunnels (PMTUD > across the tunnel path and having the tunnel MTU adjusted to it is a > more advanced capability). > > > Ok, so how about stating the following, then? > > 1. Fragments are unreliable on the Internet today. > 2. If you're an application developer and your apps need to run on the > Internet, then fragments will likely not work in many cases. If you want > your application to work in these cases, you should either use > application-layer fragmentation, use path MTU discovery, or limit > yourself to small packets instead of sending fragments. > 3. If you control the network (e.g., if you're the network operator), > and want to use fragments for tunnels or other purposes, go ahead, but > note that in other people's networks, they might be filtered. > > Your suggestion of providing a generic UDP segmentation mechanism is a > fine idea, and one that we discussed before this draft was written, but > our feeling was that such a solution would be impossible to agree on > until we have a problem statement. This draft ("FYI: some operators > filter fragments. Keep that in mind.") was supposed to be the problem > statement. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Internet-Drafts@ietf.org Mon Oct 29 08:21:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6307D21F8711; Mon, 29 Oct 2012 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7pI+mkT3Htg; Mon, 29 Oct 2012 08:21:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2763321F8703; Mon, 29 Oct 2012 08:21:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121029152155.8451.17248.idtracker@ietfa.amsl.com> Date: Mon, 29 Oct 2012 08:21:55 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-ra-guard-implementation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:21:58 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Author(s) : F. Gont Filename : draft-ietf-v6ops-ra-guard-implementation Pages : 19 Date : Oct. 29, 2012 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-05.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-ra-guard-implementation"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-10-29082155.I-D@ietf.org> --NextPart-- From dwing@cisco.com Mon Oct 29 08:49:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFCD21F873A; Mon, 29 Oct 2012 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2jOBM3w49Jn; Mon, 29 Oct 2012 08:49:27 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCBD21F8738; Mon, 29 Oct 2012 08:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3014; q=dns/txt; s=iport; t=1351525767; x=1352735367; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=sldByzodhNhZqC1lWwiAGTmZ3Umj1OqXZmRPg46+BAI=; b=hArMRjVKqVPdsWyIscHAPwkUUoJo39p9Cv1yhjDKMFczY3J8RmkGlUFm wnfkbXvpcsD5gI4b1JQBJBuvOPEo6Iv3xkmZNjkGJSx+vUqtbDSYy4W2M nv0LI9Dfa7f1Ue8OtD130x5+/3pZnHGRbrYCBzEstiNP61HmUNv2ev68M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAKAEOljlCrRDoI/2dsb2JhbABEwVkDgQmBCIIeAQEBAgEBAQEBBQIIAVsLBQcBAwIJEQQBAQEnBxkOHwkIAgQBEgsFEodeBQycMZ9mi3V5hWQDiFmFFYgGjleBa4MP X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208";a="60022835" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 Oct 2012 15:49:10 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9TFn9WX027966; Mon, 29 Oct 2012 15:49:10 GMT From: "Dan Wing" To: "=?iso-8859-2?Q?'Nejc_=A9koberne'?=" , References: <20121002115421.GY13776@Space.Net> <508C6CA5.4090406@skoberne.net> In-Reply-To: <508C6CA5.4090406@skoberne.net> Date: Mon, 29 Oct 2012 08:49:10 -0700 Message-ID: <03c801cdb5ec$efc1feb0$cf45fc10$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJy/YYJ47UjDhaVa+Vz5DmB82cpogEBpR7pAgsKZwYCLRbgr5ZcDkWA Content-Language: en-us Cc: behave@ietf.org Subject: Re: [v6ops] double nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:49:28 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Nejc =A9koberne > Sent: Saturday, October 27, 2012 4:22 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] double nat >=20 > Hi, >=20 > I am reviving this thread, as (AFAIK) nobody mentioned the following > issue: >=20 > "Other aspects of NAT behaviour, notably the NAT binding lifetime and > the form of NAT "cone behaviour" for UDP take on the more the more > restrictive of the two NATs in sequence. > The binding times are potentially problematical in that the two NATs = are > not synchronised in terms of binding behaviour. If the CGN has a = shorter > binding time, it is possible for the CGN to misdirect packets and = cause > application level hang ups. However this is not overly different to a > single level NAT environment where aggressively short NAT binding = times > will also run the risk of causing application level hang ups when the > NAT drops the binding for a active session that has been quiet for an > extended period of time." >=20 > (Geoff Huston, > http://www.potaroo.net/ispcol/2011-03/transtools-part2.pdf, page 7) >=20 > So binding lifetime desynch can be quite harmful here? Any real-world > experience on this? This question is probably better answered in BEHAVE, which I CC'd. Yes, short binding lifetimes can cause applications to fail. Consider, for example, an application lets its connection sit idle and the NAT clobbers the connection, and then re-uses that same IP address and port for another (fresh) connection. Eventually the application using the old connection will send data. Depending on if this was TCP or UDP, and if it was the device behind the NAT or on the Internet, all sorts of things could happen. As Geoff wrote, this occurs with one NAT, if that NAT times out a mapping before the hosts delete their mappings. Yes, this happens in the wild. But it is seldom diagnosed because=20 it is difficult to recreate. -d > Thanks, > Nejc >=20 > On 2.10.2012 13:54, Randy Bush wrote: > >>> so, is double nat really worse than single nat? is it formally > >>> different? except in the case of overlapping spaces, of course. > >> One of the problems with "someone else controls your NAT" is that = you > >> can't add port mappings. This seems to be an inevitable side = effect > >> of NAT444 (but can happen with single NAT44 as well, of course, > >> depending on where it's placed). > > i asked *formally*. i am not concerned with all the ops, social, > > stuff. and not about issues not directly connected to the nat. > > what does double translation do that single does not? > > > > randy > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Mon Oct 29 08:50:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1DF21F8743 for ; Mon, 29 Oct 2012 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6HpzjMdFmqL for ; Mon, 29 Oct 2012 08:50:25 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id A74D121F8742 for ; Mon, 29 Oct 2012 08:50:24 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9TFoNj8032598 for ; Mon, 29 Oct 2012 08:50:24 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9TFoMQs032583 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 29 Oct 2012 08:50:22 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 29 Oct 2012 08:50:22 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Mark Smith Date: Mon, 29 Oct 2012 08:50:21 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac21oezSlSBcvxhLRQuZ9RPhfORhawASm75A Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:50:26 -0000 Hi Lorenzo, > Your suggestion of providing a generic UDP segmentation mechanism > is a fine idea This is exactly what SEAL does for tunnels: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ In this model, the SEAL-enabled ingress tunnel endpoint acts as an "application" that performs segmentation before encapsulation. We have also talked about applying SEAL in a "transport" mode of operation. Thanks - Fred fred.l.templin@boeing.com From brian.e.carpenter@gmail.com Mon Oct 29 09:19:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB59F21F8669 for ; Mon, 29 Oct 2012 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgfK6-mz1nAs for ; Mon, 29 Oct 2012 09:19:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2B21F8661 for ; Mon, 29 Oct 2012 09:19:02 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1949424bkc.31 for ; Mon, 29 Oct 2012 09:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4pqt0ufeGche5XBM6twsHJwPx+bebBhmwbM1aYsVI2U=; b=WUfW/fG4FaxRdatN7Yr0vqSBbmbegzKEqxXKBdH9OvTXuJ+90ZiefSl1dSOJUTLByh QoSfimDGBzP4shegaz2yKq0V32Y31xQAE+0LNa40qIq6T0ARqcVY8yQ+E3C7rpDNAYWn ScBwfyndRKupvCSWa76h24HJIg++UpvssTVlAdjNbIT2L4GCKW0Hjc+9FCq8qBDsiZog WA0Loav02p1IB069RM/eSTam4U95/mCQFsx1nSbpnf8TKeQ3XRHvOcHtf+vroZe8NmrJ lidp/RnW6WPqC5IbsOnvxsvAayRJqWAMrgkgT9CLj7NZvwSr6kwZ8S5vibWkZ6Q+N7JY eVIQ== Received: by 10.204.128.144 with SMTP id k16mr9549051bks.64.1351527541573; Mon, 29 Oct 2012 09:19:01 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-117.as13285.net. [2.102.219.117]) by mx.google.com with ESMTPS id g8sm4497745bkv.6.2012.10.29.09.18.54 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 09:18:55 -0700 (PDT) Message-ID: <508EAC71.2030608@gmail.com> Date: Mon, 29 Oct 2012 16:18:57 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <508E9C0A.8060004@isi.edu> In-Reply-To: <508E9C0A.8060004@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 16:19:08 -0000 On 29/10/2012 15:08, Joe Touch wrote: > How does that differ substantively from RFC 4821's advice? See esp. Sec. > 8 of that doc, which seems just as accurate for the current situation. Joe, I have never thought that 4821 was specific enough, because it leaves quite a bit of the recipe open. The application writer just wants to do open/send/receive/close and have somebody else take care of this stuff. Brian > > Joe > > On 10/28/2012 11:51 PM, Lorenzo Colitti wrote: >> On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith > > wrote: >> >> I don't really disagree with that either, it's more that >> fragmentation is a current capability of IPv6, so I think the IETF's >> recommendation should be that it is enabled by default on the >> Internet. I think that recommendation fits the robustness principle >> too - "..., be liberal in what you accept from others". >> >> If the IETF recommends against forwarding fragments, then I think >> that creates the obligation to provide advice and methods on what do >> instead, >> which might include specifying a standardised UDP fragmentation >> method, and provide alternative methods for protocols that utilise >> IP layer >> fragmentation. >> >> Fragments may still be in use, however they may not used much at the >> >> application layer. OSPFv2 and OSPFv3 uses them instead of >> implementing it's own fragmentation mechanism (and that may be >> across multiple hops in the case of a OSPF virtual link), and they >> are likely to be commonly used in IPsec and GRE tunnels (PMTUD >> across the tunnel path and having the tunnel MTU adjusted to it is a >> more advanced capability). >> >> >> Ok, so how about stating the following, then? >> >> 1. Fragments are unreliable on the Internet today. >> 2. If you're an application developer and your apps need to run on the >> Internet, then fragments will likely not work in many cases. If you want >> your application to work in these cases, you should either use >> application-layer fragmentation, use path MTU discovery, or limit >> yourself to small packets instead of sending fragments. >> 3. If you control the network (e.g., if you're the network operator), >> and want to use fragments for tunnels or other purposes, go ahead, but >> note that in other people's networks, they might be filtered. >> >> Your suggestion of providing a generic UDP segmentation mechanism is a >> fine idea, and one that we discussed before this draft was written, but >> our feeling was that such a solution would be impossible to agree on >> until we have a problem statement. This draft ("FYI: some operators >> filter fragments. Keep that in mind.") was supposed to be the problem >> statement. >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From touch@isi.edu Mon Oct 29 09:24:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D054221F86FB for ; Mon, 29 Oct 2012 09:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aCvaevRnWJ5 for ; Mon, 29 Oct 2012 09:24:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 49D3121F86EB for ; Mon, 29 Oct 2012 09:24:29 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q9TGNt4d010517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Oct 2012 09:24:00 -0700 (PDT) Message-ID: <508EAD9A.4050609@isi.edu> Date: Mon, 29 Oct 2012 09:23:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <508E9C0A.8060004@isi.edu> <508EAC71.2030608@gmail.com> In-Reply-To: <508EAC71.2030608@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 16:24:29 -0000 On 10/29/2012 9:18 AM, Brian E Carpenter wrote: > On 29/10/2012 15:08, Joe Touch wrote: >> How does that differ substantively from RFC 4821's advice? See esp. Sec. >> 8 of that doc, which seems just as accurate for the current situation. > > Joe, > > I have never thought that 4821 was specific enough, because it leaves > quite a bit of the recipe open. The application writer just wants to do > open/send/receive/close and have somebody else take care of this stuff. > > Brian It has very specific advice in Section 8. I don't see much this WG can recommend beyond that until a few standards-track RFCs are revised, and that seems beyond the scope of this WG. Joe From diego@tid.es Tue Oct 30 08:33:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5381521F84D2 for ; Tue, 30 Oct 2012 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOS8-yF8Q4lT for ; Tue, 30 Oct 2012 08:33:49 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3E21F84B5 for ; Tue, 30 Oct 2012 08:33:48 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MCP00172PWB4N@tid.hi.inet> for v6ops@ietf.org; Tue, 30 Oct 2012 16:33:47 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 7C.08.03050.B53FF805; Tue, 30 Oct 2012 16:33:47 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MCP0016YPWB4N@tid.hi.inet> for v6ops@ietf.org; Tue, 30 Oct 2012 16:33:47 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by EX10-HTCAS6-MAD.hi.inet ([fe80::e1e3:e2fc:beda:deb9%15]) with mapi id 14.02.0318.004; Tue, 30 Oct 2012 16:33:47 +0100 Date: Tue, 30 Oct 2012 15:33:47 +0000 From: "Diego R. Lopez" In-reply-to: <2671C6CDFBB59E47B64C10B3E0BD59230336A87C8B@PRVPEXVS15.corp.twcable.com> X-Originating-IP: [10.95.64.115] To: "George, Wes" Message-id: Content-id: <9D7714545FC86D498CDFB6483695CDDB@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: New version of draft-lopez-v6ops-dc-ipv6 Thread-index: AQHNr3M8j4EugeD3fkKjjO1OoT0HCJfLpGbAgAZT1YA= X-AuditID: 0a5f4068-b7f176d000000bea-cb-508ff35b33a6 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsXCFe/ApRv9uT/A4GeHrMXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfP5dMaCH7oV83YfYG1gfKDTxcjBISFgIrFwgnoXIyeQKSZx 4d56NhBbSGADo8SdZzVdjFxA9g9GieYp7ewQzkZGia+TWplAqlgEVCX27FrPCGKzAdmPmn+z g9jCAqYS035OYwVZwCkQLjF9izXEAgWJP+ces4DYIgK6EtseHGQGsZmB4m3v2sHG8Ap4S9za tJ8FIm4mseLYRmaIuKDEj8n3WEBGMguoS0yZkgtRIi7R3HoTqlxRYtqiBrAxjAKyEu/mz2eF WGUmseTKBkaQVhEBK4lFc7IgrhGQWLLnPDOELSrx8vE/VogPzzFKbDvdxziBUWIWkitmIbli FsIVs5BcMQvJFQsYWVcxihUnFWWmZ5TkJmbmpBsY6mVk6mXmpZZsYoTEW8YOxuU7VQ4xCnAw KvHwXjzRFyDEmlhWXJl7iFGSg0lJlDfzVX+AEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe2+eB crwpiZVVqUX5MCkZDg4lCd6WT0ApwaLU9NSKtMwcYFKBSTNxcIK08wC1bwOp4S0uSMwtzkyH yJ9i1OY4+mbuQ0aOxp5FDxmFWPLy81KlxHlngZQKgJRmlObBTXvFKA50tjDvQZAsDzBFws15 BbSCCWiFDl8vyIqSRISUVAPjpuvT2T+d65+W5NPyui5L6fKD7/bqKx74nmoWDy048DLyQV4e R88r2R9x0eK8G3UNblv/K84NcznPmXf71G+lk0ummH7feOi2wjndJbyndUNqTOan3N3c7fTn RvnEYIdPWRPMjSJ3x1c9EzL+e2NDW1IOT96BKp+chDVCoYIWnySPMyyw3daixFKckWioxVxU nAgAqSl6Lk4DAAA= References: <20121020200652.28676.43201.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59230336A87C8B@PRVPEXVS15.corp.twcable.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] New version of draft-lopez-v6ops-dc-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:33:50 -0000 SGkgV2VzLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gQSBmZXcgbW9yZSBkZXRhaWxlZCBy ZXBsaWVzIGlubGluZQ0KDQpPbiAyNiBPY3QgMjAxMiwgYXQgMTY6NTQgLCBHZW9yZ2UsIFdlcyB3 cm90ZToNCj4gSSd2ZSByZWFkIHRoaXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIGFuZCBJIGhhdmUg YSBmZXcgY29tbWVudHMuDQo+DQo+IEkgd291bGQgbm90IHJlZmVyIHRvIHlvdXIgbGFzdCB0cmFu c2l0aW9uIHN0YWdlIGFzICJOZXh0IEdlbmVyYXRpb24iIGFzIHRoYXQgaXMgbm90IGEgcGFydGlj dWxhcmx5IGRlc2NyaXB0aXZlIHRlcm0gZm9yIHRoZSBzdGFnZSB0aGF0IHlvdSBkZXNjcmliZSwg YW5kIGl0IGlzIGFsc28gYSBmYWlybHkgb3ZlcmxvYWRlZCB0ZXJtIC0gbXkgIm5leHQgZ2VuZXJh dGlvbiIgREMgbWF5IHdlbGwgYmUgdGhlIG9uZSB3aGVyZSBJIGluY3JlYXNlIHRoZSBiYW5kd2lk dGgsIG9yIGJ1aWxkIG91dCBhIGZhYnJpYywgc3RhcnQgdXNpbmcgc29tZSBuZXcgd2lkZ2V0LCBv ciB3aGF0ZXZlci4gSSB3b3VsZCBtYXliZSBjYWxsIGl0IElQdjYtb25seSBvciBTaW5nbGUtc3Rh Y2sgSVB2Niwgc2luY2UgdGhhdCBpcyByZWFsbHkgdGhlIGRlc2lyZWQgZW5kIHN0YXRlLCB3aGVy ZSBhcyBtdWNoIG9mIHRoZSBEQyBhcyBwb3NzaWJsZSBpcyBydW5uaW5nIElQdjYgZm9yIGFsbCBm dW5jdGlvbnMsIGFuZCBJUHY0IGNvbm5lY3Rpdml0eSBpcyBoYW5kbGVkIHZpYSB0cmFuc2l0aW9u IGFuZCB0cmFuc2xhdGlvbiB0ZWNobm9sb2dpZXMgYXQgdGhlIGVkZ2VzIG9mIHRoZSBEQyAoZWcg bG9hZGJhbGFuY2VycywgZXRjKS4NCg0KSXQgbWFrZXMgc2Vuc2UsIHRob3VnaCBJIGNhbiB1bmRl cnN0YW5kIHRoYXQgdXNpbmcgc29tZXRoaW5nIHdlIGNvdWxkIGNhbGwNCmFuIGV1cGhvbmljIG5h bWUgd291bGQgaGVscCBpbiBzZW5kaW5nIHRoZSBtZXNzYWdlIHRoYXQncyB0aGUgZGVzaXJhYmxl DQpzdGFnZSB0byBhY2hpZXZlLiBJJ2Qgc3VnZ2VzdCB0byBoYXZlIHNvbWUgbGl2ZSBkaXNjdXNz aW9uIGFib3V0IHRoaXMgaW4NCkF0bGFudGEuLi4NCg0KPiBTZWN0aW9uIDIuMyBzaG91bGQgbWVu dGlvbiB0aGUgZmFjdCB0aGF0IHRoaXMgc3RhZ2UgbWF5IGJlIGRyaXZlbiBieSBlaXRoZXIgYSBs YWNrIG9mIGVub3VnaCBJUHY0IHJlc291cmNlcyAod2hldGhlciBwcml2YXRlIG9yIGdsb2JhbGx5 IHVuaXF1ZSkgb3IgYSBuZWVkIHRvIHJlY2xhaW0gSVB2NCByZXNvdXJjZXMgZnJvbSBwb3J0aW9u cyBvZiB0aGUgbmV0d29yayB3aGljaCBubyBsb25nZXIgbmVlZCB0aGVtLiBUaGVyZSBpcyBhIHBv aW50IGF0IHdoaWNoIGR1YWwgc3RhY2sgaXMgc2ltcGx5IG5vdCBwb3NzaWJsZSBhbnltb3JlLCBh bmQgb25jZSB0aGF0IHBvaW50IGhhcyBiZWVuIHJlYWNoZWQsIGEgY2FyZWZ1bCBldmFsdWF0aW9u IG9mIHdoYXQgc3RpbGwgbmVlZHMgdG8gc3BlYWsgSVB2NCBhbmQgd2hhdCBkb2VzIG5vdCB3aWxs IG5lZWQgdG8gaGFwcGVuIHRvIGVuc3VyZSBqdWRpY2lvdXMgdXNlIG9mIHRoZSByZW1haW5pbmcg SVB2NCByZXNvdXJjZXMuDQoNCkFncmVlZC4gTWVudGlvbmluZyB0aGlzIHdpbGwgYWRkIG1vcmUg d2VpZ2h0IHRvIHRoZSByZWFzb25zIHRvIGFjaGlldmUgdGhpcw0Kc3RhZ2UuIFdpbGwgdXBkYXRl IHRoZSBkb2N1bWVudCBpbiB0aGlzIHJlc3BlY3QuDQoNCj4gSXQgbWlnaHQgYWxzbyBiZSBoZWxw ZnVsIHRvIGRpc2N1c3MgdGhlIGRpZmZlcmVudCBjbGFzc2VzL2NhdGVnb3JpZXMgb2YgdGhpbmdz IHRoYXQgYXJlIGluIGFuIGF2ZXJhZ2UgZGF0YSBjZW50ZXIsIGFzIHRob3NlIG1heSBoYXZlIGEg YmVhcmluZyBvbiBob3cgdGhlIHRyYW5zaXRpb24gcHJvY2VlZHMsIGFuZCBpbmRlZWQgbWF5IGJl IGF0IGRpZmZlcmVudCBwaGFzZXMgb2YgdGhlIHRyYW5zaXRpb24gYXQgZGlmZmVyZW50IHRpbWVz Og0KPg0KPiBNYW5hZ2VtZW50IHN5c3RlbXMgKHByb3Zpc2lvbmluZywgYWxhcm1zL1BNcywgc29m dHdhcmUgZGlzdHJvLCBldGMpDQo+IEZhYnJpYyAoYW5kIHBlcmhhcHMgZXZlbiBkaXNjdXNzIHRo ZSBkaWZmZXJlbnQgbGF5ZXJzLCBUb1IsIGFnZywgY29yZSwgZXRjKQ0KPiBIeXBlcnZpc29yICh0 aG91Z2ggdGhpcyBpcyBhbHJlYWR5IG1lbnRpb25lZCBpbiBhIGZldyBwbGFjZXMgaW4gdGhlIGRy YWZ0KQ0KPiBNYWNoaW5lLXRvLW1hY2hpbmUgY29tbXVuaWNhdGlvbnMgKG9uZSBhcHBsaWNhdGlv biB0YWxraW5nIHRvIGFub3RoZXIgb3ZlciBhbiBBUEkpDQo+IEVuZC11c2VyIGFwcGxpY2F0aW9u cy9jb250ZW50DQo+IEV4dGVybmFsIHNlcnZpY2VzDQo+IEV0Yw0KPg0KPiBUaGUga2V5IGhlcmUg aXMgdG8ga2VlcCBpdCBnZW5lcmljIGVub3VnaCBzbyB0aGF0IGl0J3Mgd2lkZWx5IGFwcGxpY2Fi bGUsIHJhdGhlciB0aGFuIGdldHRpbmcgc28gc3BlY2lmaWMgdGhhdCB5b3UgaGF2ZSB0byBoYXZl IG11bHRpcGxlIGRpZmZlcmVudCBzY2VuYXJpb3MgdG8gcmVwcmVzZW50IGRpZmZlcmVudCBwb3Rl bnRpYWwgREMgYXBwbGljYXRpb25zIGFuZCBkZXNpZ25zLg0KDQpUaGlzIGlzIGEgZ29vZCBwb2lu dCwgdGhvdWdoIEkgdGhpbmsgd2Ugc2hvdWxkIGFncmVlIGluIGxpbWl0aW5nIHRoZSBudW1iZXIN Cm9mIHN1Y2ggaXRlbXMsIGFuZCBjbGVhcmx5IGlkZW50aWZ5IGhvdyB0aGUgYXBwbGljYXRpb24g b2YgdjYgYWZmZWN0IHRoZW0gYW5kDQppbiB3aGljaCByZXNwZWN0IHRoZXkgYXJlIHNwZWNpZmlj IHRvIHRoZSBEQyBlbnZpcm9ubWVudC4gQ2VydGFpbmx5DQptYW5hZ2VtZW50IHN5c3RlbXMgYXJl LCBhcyBjb25zaWRlcmF0aW9ucyBvbiB0aGUgZmFicmljIGFuZCBoeXBlcnZpc29ycy4NCkluIHRo ZSBjYXNlIG9mIGVuZC11c2VyIGFwcGxpY2F0aW9ucyBhbmQgY29udGVudCBJIHRoaW5rIHRoZXkg YXJlIG1vc3RseSBjb25zaWRlcmVkIGluIG90aGVyIG9wZXJhdGlvbmFsIGd1aWRlbGluZTogKGRy YWZ0LWNoa3B2Yy1lbnRlcnByaXNlLWluY3JlbWVudGFsLWlwdjYpIGFuZCB3ZSBjb3VsZCBmb2xs b3cgYW4gYXBwcm9hY2ggc2ltaWxhciB0byB0aGUgdXNlZCBpbg0KdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLg0KDQpXaGVuIGl0IGNvbWVzIHRvIE0yTSBhbmQgZXh0ZXJuYWwgc2VydmljZXMs IEknZCBsaWtlIHRvIGhhdmUgYSBjbGVhcmVyIGlkZWENCm9mIHdoYXQgeW91IGFyZSByZWZlcnJp bmcgdG8uLi4NCg0KPiBTZWN1cml0eSBjb25zaWRlcmF0aW9uczogZHJhZnQtdnlua2Utb3BzZWMg aGFzIGJlZW4gcmVwbGFjZWQgYnkgZHJhZnQtaWV0Zi1vcHNlYy4gSG93ZXZlci4uLg0KDQpSaWdo dC4gV2lsbCBjb3JyZWN0Lg0KDQo+IFRoZSByZWZlcmVuY2VkIGRyYWZ0IGNvdmVycyBhIGxvdCBv ZiBncm91bmQsIGFuZCBzaW1wbHkgcmVmZXJyaW5nIHRvIGl0IGJ5IGl0c2VsZiBtaWdodCBiZSBk YXVudGluZyB0byBwb3RlbnRpYWwgcmVhZGVycy4gSXQgbWlnaHQgYmUgd29ydGggaGlnaGxpZ2h0 aW5nIHNwZWNpZmljIHNlY3Rpb25zIHRoYXQgYXJlIGVzcGVjaWFsbHkgcGVydGluZW50IHRvIERD cywgc3VjaCBhcyB0aGUgZGlzY3Vzc2lvbiBvZiBORCBjYWNoZSBleGhhdXN0LCBldGMuDQoNClRo YXQgY2VydGFpbmx5IG1ha2VzIHNlbnNlLiBXaWxsIHRha2UgY2FyZSBvZiBpdCBmb3IgdGhlIGNv bWluZyB2ZXJzaW9uDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3Ms IERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpo dHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMN ClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUg ZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBz aXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg Zm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJ TkFTL2Rpc2NsYWltZXIuYXNweA0K From Internet-Drafts@ietf.org Tue Oct 30 12:54:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9734721F8629; Tue, 30 Oct 2012 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnkMeBB568c9; Tue, 30 Oct 2012 12:54:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372FB21F85EA; Tue, 30 Oct 2012 12:54:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121030195440.32759.52013.idtracker@ietfa.amsl.com> Date: Tue, 30 Oct 2012 12:54:40 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-6204bis-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:54:40 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : H. Singh, et al Filename : draft-ietf-v6ops-6204bis Pages : 22 Date : Oct. 30, 2012 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-12.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-6204bis"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-10-30125440.I-D@ietf.org> --NextPart-- From markzzzsmith@yahoo.com.au Tue Oct 30 13:14:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EB521F8639 for ; Tue, 30 Oct 2012 13:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGW8tZ3Ja5bd for ; Tue, 30 Oct 2012 13:14:53 -0700 (PDT) Received: from nm1.bullet.mail.ac4.yahoo.com (nm1.bullet.mail.ac4.yahoo.com [98.139.52.198]) by ietfa.amsl.com (Postfix) with ESMTP id 574C521F8624 for ; Tue, 30 Oct 2012 13:14:53 -0700 (PDT) Received: from [98.139.52.196] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 30 Oct 2012 20:14:48 -0000 Received: from [98.139.52.163] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 30 Oct 2012 20:14:48 -0000 Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 30 Oct 2012 20:14:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 414856.16493.bm@omp1046.mail.ac4.yahoo.com Received: (qmail 93024 invoked by uid 60001); 30 Oct 2012 20:14:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351628087; bh=f8tm1F6qY3HyuuGXBOh1wP5N2NEjNBcudPJUSB6a48I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Bgu4QJyJiqAXFgvyyobFqFAo0uF7B4U9SqZeZGQeybVWAM3F34SSOnaGxpt+mUYLhZECxMWHxrnsipXW7cFGcWFDRktThJDarIVBQgkdXqltylkdUE3uvLMcBPKzl2vbt0wtQ2CrBkOiVinJcAf9sx8aR3h4hQSK7F6CSi5fKVc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=08U+0QN3ftstmWiJkG/CsjBDMtXJWlAXSwFkFJ9ofKznNg8TJaDbwRUKCrIaMitnM+X7SxHL4SUFwYNrnIMetdwsAx9sUhPTAUh2RbblFpImvWRfNKgS3dQ6g68zl1iIZ2Jx414KDesNafyJ666/NZ333M+hdgk6B54S/lHf3nA=; X-YMail-OSG: dbdsOj4VM1lMLhamE966U914kBFAzyw3xR_rcxV2dbS1NpK i1.4noeQ.rx62wRIN61BCnuGUFLo_Rf.ADJp.bOdeX.xpyY3S9yclHpRg8cJ BlFJ3D7wCrLnigGJoxQ4_qb9R0jgaPGvGEKcMq6HPJygIFQcXxEHNuWYt.yX JCk9dka_ULpwIDxChDgzcBrtyn86AIu6hMl2VskjrPSihCxcVxrBUI51BI8D IcapdBdBxBJGjWeNzB6J862P6neSrYwe59BAizHAK8iXLxwyZxIgaMhVxK79 nrpOiy2oRpeqh0N077MVnJeSh0Qejb_R9kF85ICm9ilyZNY9l0yxk0P_AdlI QR_R8oX647vgx_k9kxpafzE3A7njjF1u1KMykhqPaJRL3MhFbXDysTfhQMlL 9G3g.WeyxBAcDxYJOOckWVBRMwzqbJfNBdqm69qXS56KKbeKAHRAzmrkbQAY CgXBfx0k7CWkbgB9F5hTpN63CJUzPFWXO_vbB4f45mCEPooTwXBSODOuij_A s3Csn0t8cd4X0kshKvLhFsmPG_QMyMVYP Received: from [150.101.221.237] by web32508.mail.mud.yahoo.com via HTTP; Tue, 30 Oct 2012 13:14:47 PDT X-Rocket-MIMEInfo: 001.001, SGkgTG9yZW56bywKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiAKPkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.OyBWNiBPcHMgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IE1vbmRheSwgMjkgT2N0b2JlciAyMDEyIDU6NTEgUE0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtdGF5bG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.473 61.YahooMailNeo@web32501.mail.mud.yahoo.com> Message-ID: <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> Date: Tue, 30 Oct 2012 13:14:47 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 20:14:54 -0000 Hi Lorenzo,=0A=0A=0A>________________________________=0A> From: Lorenzo Col= itti =0A>To: Mark Smith =0A= >Cc: Fernando Gont ; V6 Ops =0A>Sen= t: Monday, 29 October 2012 5:51 PM=0A>Subject: Re: [v6ops] new draft: draft= -taylor-v6ops-fragdrop=0A> =0A>=0A>On Mon, Oct 29, 2012 at 5:08 AM, Mark Sm= ith wrote:=0A>=0A>I don't really disagree with = that either, it's more that fragmentation is a=A0current capability of IPv6= , so I think the IETF's recommendation should be=A0that it is enabled by de= fault on the Internet. I think that recommendation=A0fits the robustness pr= inciple too - "..., be liberal in what you accept=A0from others".=0A>>=0A>>= If the IETF recommends against forwarding fragments, then I think that=A0cr= eates the obligation to provide advice and methods on what do instead,=0A>>= which might include specifying a standardised UDP fragmentation method,=A0a= nd provide alternative methods for protocols that utilise IP layer=0A>>frag= mentation.=0A>>=0A>>Fragments may still be in use, however they may not use= d much at the=0A>>=0A>>application layer. OSPFv2 and OSPFv3 uses them inste= ad of implementing=A0it's own fragmentation mechanism (and that may be acro= ss multiple hops=A0in the case of a OSPF virtual link), and they are likely= to be commonly=A0used in IPsec and GRE tunnels (PMTUD across the tunnel pa= th and having=A0the tunnel MTU adjusted to it is a more advanced capability= ).=0A>=0A>=0A>Ok, so how about stating the following, then?=0A>=0A>=0A>1. F= ragments are unreliable on the Internet today.=0A=0AThat seems to be what t= he [blackhole] paper is concluding.=0A=0AI haven't read the [blackhole] pap= er, although I've done a few text=0A=0Asearches of it. Thinking about this = issue a bit more, I've started to=0Awonder how this fragmentation filtering= is occurring in IPv6. Is it that=0Apackets with the fragmentation extensio= n header as the first extension=0Aheader are dropped, and all first extensi= on header types are let through=0A(meaning a fragmentation extension header= would pass as long as it isn't=0Athe first), or is it that only TCP and UD= P first extension headers are=0Alet through (and perhaps IPsec ESP) and all= others are dropped? My pure=0Aguess would be the latter is more likely, me= aning that this also breaks=0ADCCP and SCTP. I've been hoping that one of t= he benefits of IPv6 will be=0Athe ability to use more modern transport laye= r protocols like DCCP and=0ASCTP without having to encapsulate them inside = UDP.=0A=0A=0A>2. If you're an application developer and your apps need to r= un on the Internet, then fragments will likely not work in many cases. If y= ou want your application to work in these cases, you should either use appl= ication-layer fragmentation, use path MTU discovery, or limit yourself to s= mall packets instead of sending fragments.=0A=0A=0AICMP based PMTUD is prob= ably not reliable enough either :-(=0A=0A>3. If you control the network (e.= g., if you're the network operator), and want to use fragments for tunnels = or other purposes, go ahead, but note that in other people's networks, they= might be filtered.=0A>=0A=0AThat's ok for e.g. OSPF, however the use case = I was thinking of for IPsec was across the Internet. It's about 10 years si= nce I did a lot of work with IPsec tunnels so I'm wondering how they cope w= ith varying MTUs, broken ICMP PMTUD etc. these days. I'm aware that IPsec h= as become commonly encapsulated inside UDP to avoid NATs, but RFC3948 doesn= 't seem to cover fragmentation issues below UDP.=0A=0A>=0A>Your suggestion = of providing a generic UDP segmentation mechanism is a fine idea, and one t= hat we discussed before this draft was written, but our feeling was that su= ch a solution would be impossible to agree on until we have a problem state= ment. This draft ("FYI: some operators filter fragments. Keep that in mind.= ") was supposed to be the problem statement.=0A>=0A>=0A=0ARegards,=0AMark.= =0A From Fred.L.Templin@boeing.com Tue Oct 30 13:35:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D101921F865C for ; Tue, 30 Oct 2012 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y15qFPmE8qk4 for ; Tue, 30 Oct 2012 13:35:42 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 63DE621F8652 for ; Tue, 30 Oct 2012 13:35:42 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9UKZfHi003589 for ; Tue, 30 Oct 2012 13:35:41 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9UKZdDG003563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 30 Oct 2012 13:35:40 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 30 Oct 2012 13:35:39 -0700 From: "Templin, Fred L" To: Mark Smith , Lorenzo Colitti Date: Tue, 30 Oct 2012 13:35:38 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac2220BEz3pvgwYVSa25S6yPRphV3AAAkrBg Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.473 61.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> In-Reply-To: <1351628087.79801.YahooMailNeo@web32508.mail.mud.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 20:35:42 -0000 Hi Mark, > That's ok for e.g. OSPF, however the use case I was thinking of for IPsec > was across the Internet. It's about 10 years since I did a lot of work > with IPsec tunnels so I'm wondering how they cope with varying MTUs, > broken ICMP PMTUD etc. these days. I'm aware that IPsec has become > commonly encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem > to cover fragmentation issues below UDP. I haven't seen much talk about this, but IPsec tunnels should be able to fragment IPv4 packets that enter the tunnel with DF=3D0, since the IPsec integrity check will detect any IPv4 reassembly errors. But, that's just for IPv4 DF=3D0 packets; IPv6 and IPv4 DF=3D1 packets are subject to PMTUD on entry of the tunnel the same as for any link (unless they use SEAL, of course). Thanks - Fred From lorenzo@google.com Tue Oct 30 17:46:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EF721F867C for ; Tue, 30 Oct 2012 17:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfE74RBPAh7z for ; Tue, 30 Oct 2012 17:46:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 521C421F8654 for ; Tue, 30 Oct 2012 17:46:15 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so965956obq.31 for ; Tue, 30 Oct 2012 17:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cPmxWivAhqBA9oEB0yejaAqyeNzoU76SHASl7xx4bA0=; b=Yf7eiPl+n7v7xR0R0qfYWLXA+4dAXpMzwvSL4sz31Ir45hyMyKMEm1uay+dTS2f9pq Bdc9gzfEEO3V4OjuD4KzMg10TdNCJAJ48W8ii1hRnCEcGu3EHxHoRWPcbA/kwXD9ZP/7 yxLnE6dm+POH+ZNnzjQCa0nrihVx0xZa3JXnJgCwH8nKLzfxmwyJyk43j8XCq+qVvBgU VaENQKUIbPlfCBPbGJ/MIJXM7l/kWWs9zyJ2Giol4qWw4aremhv9k5YkCGUMw5krwSIK d/BgEc20GX4+fPyc9GmUKcF+rjBsvI+eAVyNdhgcyzlDQXUiDa8KwKVwis148sGzwDf3 zmXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cPmxWivAhqBA9oEB0yejaAqyeNzoU76SHASl7xx4bA0=; b=PubE4XPyWZba05QCsT8wXcQhcKauvI4O7i61e+DIHDP1VRAc+d6dE8IDgTuRcvXWdn eu+IZPCSAj0v5GM5b9QSi4mreaJyTFG98PuKbsfz/k0mvrF8b8jAs/ltlY561WSIxPg9 /zx+CGhtLRhfWqC9QXzXf2NaV8Yiye9uECpQIwsjk3HhlaKveUtbQqypnGPSs4RwK9Tz 62nmvMYjbFxkAGy5Q8xxgddOt9+Kzso7K/8XXpTF9KzujS/sY3/KM1i977e31GG5Mg0m 5KBIu127wrff4aAlY4AhBOf908mHCcPdWhpwJqLjbGPahaKFZHtwQU4EPvZ+CPnUH0Ka ZW7g== Received: by 10.182.10.6 with SMTP id e6mr28981464obb.16.1351644374735; Tue, 30 Oct 2012 17:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 30 Oct 2012 17:45:53 -0700 (PDT) In-Reply-To: <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> From: Lorenzo Colitti Date: Wed, 31 Oct 2012 09:45:53 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=f46d04446911d19d0104cd503a8d X-System-Of-Record: true X-Gm-Message-State: ALoCoQmWIR1KYYJ/FoXMnGIl/Yo7vO/PSaAzhhoMWSZ0IAd0XdDHLRk1oX+nHu/l/5+OFmoepr3Po/eAAAKZ1QzkJFWMdQSjVnzPEE6gKt0b5a/xWzu/mcM7xOdSpea4Zxt34ZmwGKriZ39/H1jidoTAkDsnMR+whKi2g0DYP7evgFKf2yNphn6ZTAXPbK3cTF7215whCcOo Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 00:46:16 -0000 --f46d04446911d19d0104cd503a8d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 5:14 AM, Mark Smith wrote: > Is it that packets with the fragmentation extension header as the first > extension header are dropped, and all first extension header types are let > through (meaning a fragmentation extension header would pass as long as it > isn't the first), or is it that only TCP and UDP first extension headers > are let through (and perhaps IPsec ESP) and all others are dropped? My > pure guess would be the latter is more likely, meaning that this also > breaks DCCP and SCTP. I've been hoping that one of the benefits of IPv6 will be the ability to > use more modern transport layer protocols like DCCP and SCTP without having > to encapsulate them inside UDP. > I think DCCP and SCTP are easier than fragments. I think there are two main issues here (in user/enterprise/edge networks; not in backbone networks): 1. Allow through only what you use. 2. Allow through only what your hardware is capable of inspecting/filtering at line rate. #1 equally affects fragment headers and DCCP/SCTP/other protocols. However, #2 specially affects fragment headers and other extension headers in general. As an example: a lot of hardware currently deployed, including, I believe, the totality of one major backbone router vendor's product line, is unable to inspect extension headers beyond the first - at all. On such hardware, saying "allow SCTP from any port to port 53" is no different than saying "allow UDP from this any port to port 53". The hardware has to do the same number of lookups, and even the offsets are the same. It's a simple code fix, if even that. However, saying "allow all UDP packets from any port to port 53, including fragments" requires that the hardware be able to perform a more complex lookup on the same packet - look for a fragment header, and if it's there, skip over it to find the upper-layer protocol header. Things get more expensive if you consider that it's not just fragment headers - it's routing headers, and shim6 headers, and any $header that anyone can dream up and get through the IETF. Doing this at line rate is hard. AIUI many current forwarding architectures work by hashing the first X (e.g., 128) bytes of the packet and turning it into a lookup key that can be processed at high speed (e.g., in TCAM). On such architectures, there is basically no way to process arbitrary extension header chains at line rate without substantially increasing the amount of work that the hardware has to do - and as we know, routers aren't exactly cheap today. If you allow the upper-layer header not to be in the first packet at all (i.e., have the first fragment consist entirely of extension headers). In this case, there is simply no way to filter correctly unless you do full-blown stateful filtering AND ensure that all the packets are processed by the same device. > >2. If you're an application developer and your apps need to run on the > Internet, then fragments will likely not work in many cases. If you want > your application to work in these cases, you should either use > application-layer fragmentation, use path MTU discovery, or limit yourself > to small packets instead of sending fragments. > > > ICMP based PMTUD is probably not reliable enough either :-( > But it needs to be, or as others say, 1280 is the new 1500 and we'll never get ourselves out of this hole. Fortunately I think it's easier than processing arbitrary extension header chains. > >3. If you control the network (e.g., if you're the network operator), and > want to use fragments for tunnels or other purposes, go ahead, but note > that in other people's networks, they might be filtered. > > > > That's ok for e.g. OSPF, however the use case I was thinking of for IPsec > was across the Internet. It's about 10 years since I did a lot of work with > IPsec tunnels so I'm wondering how they cope with varying MTUs, broken ICMP > PMTUD etc. these days. I'm aware that IPsec has become commonly > encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem to cover > fragmentation issues below UDP. > As you say, I think we've given up on running IPsec across the Internet. We use IPsec over UDP instead. --f46d04446911d19d0104cd503a8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 5:14 AM, Mark Smith <markzzzsmith@yahoo.= com.au> wrote:
Is it that=A0packets with the fragmentation extension header as the first e= xtension=A0header are dropped, and all first extension header types are let= through=A0(meaning a fragmentation extension header would pass as long as = it isn't=A0the first), or is it that only TCP and UDP first extension h= eaders are=A0let through (and perhaps IPsec ESP) and all others are dropped= ? My pure=A0guess would be the latter is more likely, meaning that this als= o breaks=A0DCCP and SCTP.=A0
I've been hoping that one of the benefi= ts of IPv6 will be=A0the ability to use more modern transport layer protoco= ls like DCCP and=A0SCTP without having to encapsulate them inside UDP.

I think DCCP and SCTP are easier than= fragments.

I think there are two main issues here= (in user/enterprise/edge networks; not in backbone networks):

1. Allow through only what you use.
2. Allow throu= gh only what your hardware is capable of inspecting/filtering at line rate.=

#1 equally affects fragment headers and DCCP/SCTP= /other protocols. However, #2 specially affects fragment headers and other = extension headers in general.

As an example: a lot of hardware currently deployed, in= cluding, I believe, the totality of one major backbone router vendor's = product line, is unable to inspect extension headers beyond the first - at = all. On such hardware, saying "allow SCTP from any port to port 53&quo= t; is no different than saying "allow UDP from this any port to port 5= 3". The hardware has to do the same number of lookups, and even the of= fsets are the same. It's a simple code fix, if even that. However, sayi= ng "allow all UDP packets from any port to port 53, including fragment= s" requires that the hardware be able to perform a more complex lookup= on the same packet - look for a fragment header, and if it's there, sk= ip over it to find the upper-layer protocol header. Things get more expensi= ve if you consider that it's not just fragment headers - it's routi= ng headers, and shim6 headers, and any $header that anyone can dream up and= get through the IETF.

Doing this at line rate is hard.=A0AIUI many current fo= rwarding architectures work by hashing the first X (e.g., 128) bytes of the= packet and turning it into a lookup key that can be processed at high spee= d (e.g., in TCAM). On such architectures, there is basically no way to proc= ess arbitrary extension header chains at line rate without substantially in= creasing the amount of work that the hardware has to do - and as we know, r= outers aren't exactly cheap today.

If you allow the upper-layer header not to be in the fi= rst packet at all (i.e., have the first fragment consist entirely of extens= ion headers). In this case, there is simply no way to filter correctly unle= ss you do full-blown stateful filtering AND ensure that all the packets are= processed by the same device.
=A0
>2. If you're an application developer and your ap= ps need to run on the Internet, then fragments will likely not work in many= cases. If you want your application to work in these cases, you should eit= her use application-layer fragmentation, use path MTU discovery, or limit y= ourself to small packets instead of sending fragments.


ICMP based PMTUD is probably not reliable enough either :-(

But it needs to be, or as others say, 1280 is th= e new 1500 and we'll never get ourselves out of this hole. Fortunately = I think it's easier than processing arbitrary extension header chains.<= /div>
=A0
>3. If you control the network (e.g., if you're th= e network operator), and want to use fragments for tunnels or other purpose= s, go ahead, but note that in other people's networks, they might be fi= ltered.
>

That's ok for e.g. OSPF, however the use case I was thinking of f= or IPsec was across the Internet. It's about 10 years since I did a lot= of work with IPsec tunnels so I'm wondering how they cope with varying= MTUs, broken ICMP PMTUD etc. these days. I'm aware that IPsec has beco= me commonly encapsulated inside UDP to avoid NATs, but RFC3948 doesn't = seem to cover fragmentation issues below UDP.

As you say, I think we've given up on = running IPsec across the Internet. We use IPsec over UDP instead.
--f46d04446911d19d0104cd503a8d-- From mawatari@jpix.ad.jp Tue Oct 30 22:26:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163A921F86EC for ; Tue, 30 Oct 2012 22:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71by7g-hINn0 for ; Tue, 30 Oct 2012 22:26:08 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8C021F86E6 for ; Tue, 30 Oct 2012 22:26:07 -0700 (PDT) Received: from [192.168.1.3] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 9CB47FC040; Wed, 31 Oct 2012 14:26:06 +0900 (JST) Date: Wed, 31 Oct 2012 14:26:05 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> References: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> Message-Id: <20121031142605.94F5.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: draft-gont-v6ops-slaac-issues-with-duplicate-macs@tools.ietf.org Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 05:26:09 -0000 Greetings, I have read through your document. Layer 2 IXs are dealing with same issues on IPv6 IX segment. In regard to link local address, both manual configuration routers and auto configuration (SLAAC) routers are connecting into one ethernet fabric of IX. Fortunately duplication do not occur so far. This document might be worthwhile subject for IPv6 IX. Kind Regards, Masataka MAWATARI * On Tue, 16 Oct 2012 05:45:00 -0700 (PDT) * wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-gont-v6ops-slaac-issues-with-duplicate-macs. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Wed Oct 31 01:14:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A36721F8629 for ; Wed, 31 Oct 2012 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.616 X-Spam-Level: X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC1CxLwJuYuX for ; Wed, 31 Oct 2012 01:14:43 -0700 (PDT) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5463121F8623 for ; Wed, 31 Oct 2012 01:14:38 -0700 (PDT) Received: from [98.139.52.190] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 31 Oct 2012 08:14:31 -0000 Received: from [98.139.52.167] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 31 Oct 2012 08:14:31 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 31 Oct 2012 08:14:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 222231.8539.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 17901 invoked by uid 60001); 31 Oct 2012 08:14:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351671270; bh=epL3WKUStj+HvHZGo0ZyRWxxaqEoeNaTmCtsP33gAjM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SwbfF1zZy9LdBlQw2xP7uhRl+NSEjhIwooHEudJfUAvnnotlgRDGYQnZ3NSMP5+dyxFZWMMz99sROAJR8rTcsX5IC4JZ8DdxzerESK//Y+F+yYQTN+sYDNxvpKwBiy7wFNF7lqiDA2ioGAxPLFoUzTvjZ7XFU6x2bmlB279+mus= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dSasce2uc1mhoDIIES183yYyEJ8RX/xDcBERBO/iLG3z5hLkgjVDf/5vOfC2+CWoXQj++E3SlCyDdalIdQ/d6zSv2ucrxDkqnyowRixuYdAxgZrQx+fPFto8mbaJVsi6P3+bwEjvLKLI8TgeP9Gj/j51fW6O1WHdJVi99VPw/lM=; X-YMail-OSG: _iRthHoVM1n.Yf3cMKkc04sT3Wk9nvS3A3XmaUCP2XpWrB0 bwFNbgRh0iKAHAQ.N2CXjs6CbFnsaQtpgdlAIUCpFphreDhClq11lPM_fh2f qMJPJwqsxqT3_ucHnpun3oIgphcu5nGqyFBh4116uDkotZlKA1b.0LxEyH_u O5fJOMuWDS4OmA1ASUl4zMDrqmHVEWddsELpgKK7iHbidpLTWtlscP3R9f_S tWzr_lJZI0ije7107428GFjchpdQ5kBxgZvjH2Wm52OfJ7nu_hKx5owBzP3c HKs4pKKVqzGn1JGZiCpjbyQXRfWKnXBjWJo1gRCG3H4hjFg2YHdkHVs319ts wgYTSPJt9qe.LOqog030OR6sv1NIQyBSicVtQtdyN6B5Z3ZsPBWGb7mhvbrA IiMLpM5OK3J5znwh..nAejFekRzDTGvOky0OFy0colPSaPL.Fhsp3__jTw4G 0_vtpCZqqPAk3KG3JlsgAQDBNKoUoIu2jQhTtGN.e0s5YYgyfG7X1WBTJxfh IXkMvmi42 Received: from [150.101.221.237] by web32508.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 01:14:30 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IE1BV0FUQVJJIE1hc2F0YWthIDxtYXdhdGFyaUBqcGl4LmFkLmpwPgo.IFRvOiB2Nm9wc0BpZXRmLm9yZwo.IENjOiBkcmFmdC1nb250LXY2b3BzLXNsYWFjLWlzc3Vlcy13aXRoLWR1cGxpY2F0ZS1tYWNzQHRvb2xzLmlldGYub3JnCj4gU2VudDogV2VkbmVzZGF5LCAzMSBPY3RvYmVyIDIwMTIgNDoyNiBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZ29udC12Nm9wcy1zbGFhYy1pc3N1ZXMtd2l0aC1kdXABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> <20121031142605.94F5.8FE1F57E@jpix.ad.jp> Message-ID: <1351671270.212.YahooMailNeo@web32508.mail.mud.yahoo.com> Date: Wed, 31 Oct 2012 01:14:30 -0700 (PDT) From: Mark Smith To: MAWATARI Masataka , "v6ops@ietf.org" In-Reply-To: <20121031142605.94F5.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-gont-v6ops-slaac-issues-with-duplicate-macs@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 08:14:44 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: MAWATARI Masataka =0A> To: v6ops@ietf.org=0A> Cc: draft-gont-v6ops-slaac-issue= s-with-duplicate-macs@tools.ietf.org=0A> Sent: Wednesday, 31 October 2012 4= :26 PM=0A> Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-wi= th-duplicate-macs=0A> =0A>G reetings,=0A> =0A> =0A> I have read through you= r document.=0A> =0A> Layer 2 IXs are dealing with same issues on IPv6 IX se= gment.=0A> =0A> In regard to link local address, both manual configuration = routers=0A> and auto configuration (SLAAC) routers are connecting into one= =0A> ethernet fabric of IX.=A0 Fortunately duplication do not occur so far.= =0A>=A0=0A=0AHow are the IX going to resolve the layer 2 address duplicatio= n causing=0A=0Alayer 2 unicast to fail? MAC forced forwarding or something = similar?=0A=0A> This document might be worthwhile subject for IPv6 IX.=0A= =0A> =0A> =0A> Kind Regards,=0A> Masataka MAWATARI=0A> =0A> =0A> * On Tue, = 16 Oct 2012 05:45:00 -0700 (PDT)=0A> * wrote:=0A> =0A>> A= new draft has been posted, at =0A> http://tools.ietf.org/html/draft-gont-v= 6ops-slaac-issues-with-duplicate-macs. =0A> Please take a look at it and co= mment.=0A>> _______________________________________________=0A>> v6ops ma= iling list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listinfo= /v6ops=0A> =0A> _______________________________________________=0A> v6ops m= ailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6= ops=0A> From brian.e.carpenter@gmail.com Wed Oct 31 01:18:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FE321F84CD for ; Wed, 31 Oct 2012 01:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnaIszyAssZi for ; Wed, 31 Oct 2012 01:18:21 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D543821F84B2 for ; Wed, 31 Oct 2012 01:18:18 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so544729wgb.13 for ; Wed, 31 Oct 2012 01:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3zS0PvCztECcatTQ2vV7x3QR0JSI0d3zVf5Dtt30eQ8=; b=rgec4dA9NiDhe7phEVrhUAX9mNAJiuerdiZWcp4la3Sb5S0pfReOOYh4XHI9DnmUJ8 eUUUtJdKY+SXfsl5kSMAO1Heck/KfypLQmp2b1LBjheaI6kyEcqryqRfJ5IcuCrGMyit 3oJX04R2u7c4bPcbhgxHICq+D5/JBgN02dvrG2eJ2xkOVyr0Jb7epYmgCIZL7bHTtH55 9ZWVh0B2zh9LhQAbVEqbpq+XoTd1J+4bQHLcRgeVKWciI8JrPIUaUsEoreJF7xI2nuZF esKVAYuwUza8xu8a9SEa48U5NJM5QXja1+LSyBKlQs+4j6omd2GrGnz4fYEeRDcyAhj0 vG6w== Received: by 10.180.89.234 with SMTP id br10mr1176334wib.2.1351671497874; Wed, 31 Oct 2012 01:18:17 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-70.as13285.net. [2.102.217.70]) by mx.google.com with ESMTPS id gm7sm4701969wib.10.2012.10.31.01.18.15 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 01:18:16 -0700 (PDT) Message-ID: <5090DECF.3050100@gmail.com> Date: Wed, 31 Oct 2012 08:18:23 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 08:18:21 -0000 On 31/10/2012 00:45, Lorenzo Colitti wrote: ... > Fortunately I think it's easier than > processing arbitrary extension header chains. Unfortunately the IPv6 architecture requires the network to be transparent to arbitrary extension header chains. This is beyond an operational problem, which is why it is on the 6man agenda. Brian From lorenzo@google.com Wed Oct 31 01:50:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0865721F860F for ; Wed, 31 Oct 2012 01:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INZhosLl1oyF for ; Wed, 31 Oct 2012 01:50:20 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 865C321F84E1 for ; Wed, 31 Oct 2012 01:50:20 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1271328oag.31 for ; Wed, 31 Oct 2012 01:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=OxKMlF/tKIjLSwO0ajA3EMl9N5JmDOMOjiwKrbQXxYQ=; b=AVH2al74t/vUwVS3Yj7ckebIQbr1yuafXyvxR5GV9U4gNJibxA4um1VetMkrR2C492 ph3ORfsznYWMegvhcBe76sScOiGdOth8QQbRYEXnwxp4QtJ7VOhu7mr+NtIb6eroslrT TJK4vonlqyM47GjUIwwik9Ljui8PGYT/F/mzfEAQMM6Y2MYB2dojjdTfsTTizoOHdsm4 bfGv0Q0R4ir5FfPOjBrJgSwXIQc8gfL55NSfSv7A9rm4N+Xw/EF7JLEeTN/mWYTaZ4xO HbPyFtxqdjd5TRb30wUc/6eHrIaNbfXd9vjSinUElPnqPJBDFc2PHVOOOghaDuHlfAcM JLIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=OxKMlF/tKIjLSwO0ajA3EMl9N5JmDOMOjiwKrbQXxYQ=; b=i4B5O0KXTbaijKtwenRsiUwy2I7/vvXVxJbxhxDwXrMhNV+8Rf0f+n7VgyqtCkj58H EIyP9F/2Lv5prpMHFTEGeGu97X2fCA990fCZx/QMsK4J3HBG5kmowP/Mix60Xyx2yG6V l8rtgu6G8cF7CN8Ohg0rfYdUsBsSbSk8NTewOUEY8m0f0sImK9plT2lOzSCQIJIYBonz LrhyDaZ9+if+0t6qU3xkGCYgRtzSSeqK+kbN5qdIlVQ0K+T7wfZQB9XtXxMPuX09ZExF ft+S6NTbkeoAU1olnfrXIYZZGUQMetAK5uSxoFsr4odii4UfdqQjWQjVRAJtozvI6043 mMeg== Received: by 10.60.26.72 with SMTP id j8mr31415666oeg.68.1351673419884; Wed, 31 Oct 2012 01:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Wed, 31 Oct 2012 01:49:59 -0700 (PDT) In-Reply-To: <5090DECF.3050100@gmail.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> From: Lorenzo Colitti Date: Wed, 31 Oct 2012 17:49:59 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8fb1f8d20b690704cd56fec1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn86tTAeelomVK5I4PJTLZr98Sn2+U/bN1mA4gcU2EZMA6VtZu355EsZKKLvEEYqWNY9qLDtl7Hj04YuqeT+iEZMTDEwlxSZTYa8+vechh5u8QWChcdrXQlwC5jXbgsbZHF7p7ODxAoRlTGPl/lnB8ZgSXzKLoDcgxnb1DgtBKFSGzlOnlkACY3hZmR6DDX1CSSeuJY Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 08:50:21 -0000 --e89a8fb1f8d20b690704cd56fec1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 5:18 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Unfortunately the IPv6 architecture requires the network to > be transparent to arbitrary extension header chains. > Good luck with that in real networks. --e89a8fb1f8d20b690704cd56fec1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 5:18 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
Unfortunately the IPv6 architecture requires the network = to
be transparent to arbitrary extension header chains.
<= br>
Good luck with that in real networks.
--e89a8fb1f8d20b690704cd56fec1-- From sthaug@nethelp.no Wed Oct 31 04:21:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279E521F8762 for ; Wed, 31 Oct 2012 04:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5L-1zQLkdXw for ; Wed, 31 Oct 2012 04:21:13 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0D45021F875F for ; Wed, 31 Oct 2012 04:21:12 -0700 (PDT) Received: (qmail 25705 invoked from network); 31 Oct 2012 11:21:10 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 31 Oct 2012 11:21:10 -0000 Date: Wed, 31 Oct 2012 12:21:10 +0100 (CET) Message-Id: <20121031.122110.41655699.sthaug@nethelp.no> To: lorenzo@google.com From: sthaug@nethelp.no In-Reply-To: References: <5090DECF.3050100@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:21:14 -0000 > > Unfortunately the IPv6 architecture requires the network to > > be transparent to arbitrary extension header chains. > > Good luck with that in real networks. Agreed. "Not gonna happen." Steinar Haug, AS 2116 From brian.e.carpenter@gmail.com Wed Oct 31 04:40:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE6A21F875C for ; Wed, 31 Oct 2012 04:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpBmxB1BVcHF for ; Wed, 31 Oct 2012 04:40:44 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6021221F86A6 for ; Wed, 31 Oct 2012 04:40:44 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so666255wey.31 for ; Wed, 31 Oct 2012 04:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=83qPZACLrOABipDRa8TyaJXdt85EGU4/8Ur5HqtugiU=; b=PWdqr9Pn3eFOHLwXygGo7LHmF/V6S6RB2+O2LAgpQ3CLu0qnQftcSPZj68GtEFvUqJ oGw0rBHM+7eOhVwz09+oP6ED8GL6Z9nMEkefNXHE3Mqd77etuycWWUQj3v+6qIl/ExqB 8JHEM6UTmAjq2zelIWiSJZV3ewNUkbWbdkkiXTedZW5jR6Szdw/Pz2ov4IC8fBWeKsEa 9yGd0AzLIpBza+cdRIP53ACaav6ONdMVtDQhOcYgJj0syBzOcVuIFifimJ52r3yZBHrb xrMEau00KG/1FocaJ69M6o76DD2QdPLzbDZoxE21gOFoBTfJiOEf68T2YrdVNZx5PO3T xEgw== Received: by 10.216.145.227 with SMTP id p77mr17439574wej.58.1351683643514; Wed, 31 Oct 2012 04:40:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-70.as13285.net. [2.102.217.70]) by mx.google.com with ESMTPS id v9sm6401910wif.10.2012.10.31.04.40.40 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 04:40:41 -0700 (PDT) Message-ID: <50910E41.2030100@gmail.com> Date: Wed, 31 Oct 2012 11:40:49 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sthaug@nethelp.no References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> In-Reply-To: <20121031.122110.41655699.sthaug@nethelp.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:40:45 -0000 On 31/10/2012 11:21, sthaug@nethelp.no wrote: >>> Unfortunately the IPv6 architecture requires the network to >>> be transparent to arbitrary extension header chains. >> Good luck with that in real networks. > > Agreed. "Not gonna happen." I am not totally unrealistic. However, there are some things that the IETF can do to make the reality a bit better than it is at the moment. Brian From lorenzo@google.com Wed Oct 31 05:52:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310DC21F87B0 for ; Wed, 31 Oct 2012 05:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V82FcotOnAnV for ; Wed, 31 Oct 2012 05:52:00 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9A3821F87AE for ; Wed, 31 Oct 2012 05:52:00 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1492059oag.31 for ; Wed, 31 Oct 2012 05:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Sjl3myuETNjjPiCnoDIfP7utzVC3BAxQUhdlAwzTMhA=; b=lsyvx2mKw0isk33ZpHdcGI2wCzlC67x7rIgT8QchqtRV6XTZ0v5Mbnwc9p5lRUcu6I GyXAUKNawl4EPTKCuVjYeE20ewF/I32Ig1p/hN2CC6CUXgB+zyd9CpdjFdCDlV1UyTex Oi5XwC+urDeC6ynThSEHRQEaieVdJafbAwmT/F5n2hiwwak+l78vk3uGZl8E/bCgw6A7 G/exX1QnmK6iXIuOqDHEsTAB5QjWJNiyWNL81azd3ure8qL6iTqonU35ojxZWOeFFAXc CXQExTZeagWcoEyvZymqZXL2ZfsDldb5/afWTEtEUnijAxiTAdXgcWkUsVkoH5LAt6w2 d6dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Sjl3myuETNjjPiCnoDIfP7utzVC3BAxQUhdlAwzTMhA=; b=Z5DrT5fFFuQ2uT46T+h0Mvnl/QK08nlEnZwQuJIPOSfW7nZARDMVmaxmIUkDIeLJdO fOYikPYCDZdq0u5F9zKJIqZcqy67Ax7AE5QtrrMZg78eHAdZFWCO3Ryp8krpAhVb4jqH Tv/k6/YH5z+dykScEfY/h64WI3NjjsAmVlp7ZrnI2maFRBnHfb6P66A67zjxq4cNYzae 2sSpyYQ77qidxjAy33C/rbUM8KqGHANHBNPyblv50qIkbuux0GAQ5Q7v5TPowQLu2cEF 0U0rI0ub+tDrMhCkb9BYCYSOcbTLcDf2O/6XVvhMEgicThE5aXy9JHppjol1Os24MVD3 opWw== Received: by 10.182.10.6 with SMTP id e6mr30132091obb.16.1351687920109; Wed, 31 Oct 2012 05:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Wed, 31 Oct 2012 05:51:39 -0700 (PDT) In-Reply-To: <50910E41.2030100@gmail.com> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> From: Lorenzo Colitti Date: Wed, 31 Oct 2012 21:51:39 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d044469115347d704cd5a5ec2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQklYdpd/ArYsmsp97rszuS6nbYnWpQFZxHo4/l6GdI2luGeEIEmP7kUS0bPqPOnkyf0fT9Pfj0p3HgVCraiY3vFvnNG45JFWhQqGRx9BFJM1HcSrGIlwvY7ZBcoQq6ix4F7d4fXR5BSBYJA7SC+GcMEMlJdX/4a/3LCfg8YenZvMSrQWjI4RI95XEERLakE6ZhywADs Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 12:52:01 -0000 --f46d044469115347d704cd5a5ec2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 8:40 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > >>> Unfortunately the IPv6 architecture requires the network to > >>> be transparent to arbitrary extension header chains. > > >> Good luck with that in real networks. > > > > Agreed. "Not gonna happen." > > I am not totally unrealistic. However, there are some things that > the IETF can do to make the reality a bit better than it is at > the moment. > But why? If you can't get extension headers to work reliably in the Internet (as opposed to in your own network), then what's the point? You still need a fallback plan for when they get dropped, and users don't like waiting. Why not just use the more reliable plan all the time? --f46d044469115347d704cd5a5ec2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 8:40 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
>>> Unfortunately the IPv6 architecture requires= the network to
>>> be transparent to arbitrary extension header chains.

>> Good luck with that in real networks.
>
> Agreed. "Not gonna happen."

I am not totally unrealistic. However, there are some things that
the IETF can do to make the reality a bit better than it is at
the moment.

But why? If you can't g= et extension headers to work reliably in the Internet (as opposed to in you= r own network), then what's the point? You still need a fallback plan f= or when they get dropped, and users don't like waiting. Why not just us= e the more reliable plan all the time?
--f46d044469115347d704cd5a5ec2-- From mattia.rossi.mailinglists@gmail.com Wed Oct 31 06:11:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AF921F8480 for ; Wed, 31 Oct 2012 06:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFGpp0XVCx6e for ; Wed, 31 Oct 2012 06:11:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EACC21F847F for ; Wed, 31 Oct 2012 06:11:40 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so641294bkc.31 for ; Wed, 31 Oct 2012 06:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7OO4wRKasq2FDp91q3sB09AY+uQLjFOkGcnQhR9qtSc=; b=G86vhQsR/ajWyxr9eT61Jp7MSXJtz5NNOsNVeDhi+vC8nTV+C8/DF1YMNkVJ+T/e9y AbI/0rT3nvOqta4SdLfVPbRElOfWsDYsCUMuvvpKptjEGq1NScRVGRZVB+auDUPdjqRG 1aflyqxKy7td7ttw9WQjy73G46wS5oVDes9COM/Dp/7DVxTN3GglbY5LmpjQanCaKP3N 708mV0kRtPjudpedqulR1CRYaGKZArjTalctm6oLmDvn1P+dTkXnR94y6dosHImW0hWB XATi1GIcJ61QPm6KdfAIsR2foLK37wh7OgTsuU9u+x77xDzZBnHzvjBL1hfTkSdCUWPY JElA== Received: by 10.204.10.74 with SMTP id o10mr11500753bko.9.1351689100178; Wed, 31 Oct 2012 06:11:40 -0700 (PDT) Received: from [192.168.0.121] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id 9sm3270034bkq.13.2012.10.31.06.11.37 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 06:11:38 -0700 (PDT) Message-ID: <50912388.30508@gmail.com> Date: Wed, 31 Oct 2012 14:11:36 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> <1350417296.76189.YahooMailNeo@web32502.mail.mud.yahoo.com> <507EA8CB.40702@houseofzen.org> In-Reply-To: <507EA8CB.40702@houseofzen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 13:11:42 -0000 Am 17.10.2012 14:47, schrieb James M Keller: > On 10/16/2012 3:54 PM, Mark Smith wrote: >> I haven't read it thoroughly, however a few general comments to get >> the ball rolling: - duplicate MAC addresses (by hardware vendors) are >> generally much rarer than the draft suggests. I haven't ever come >> across them in 20 or so years of dealing with ethernet, and I've only >> heard very few first hand accounts of them being encountered. From >> what I've heard, they've been accidents by vendors, e.g. server bios >> installs at the factory that didn't increment MAC addresses on each >> new install. > This has become more of an issue of late with virtual hosting systems > generating MAC addresses for VM NICs and then moving images between > environments and ending up with a collision vs physical hardware > burned-in-addresses. > I can agree on that, MAC duplication happens quite often with duplication of VM's. Although you'd probably experience Ethernet issues before you come to the IPv6 SLAAC issues in most of those situations. Depends on how the network's segmented of course. See section 5.4.5 in RFC 4862: "In this case, the IP address duplication probably means duplicate hardware addresses are in use, and trying to recover from it by configuring another IP address will not result in a usable network. In fact, it probably makes things worse by creating problems that are harder to diagnose than just disabling network operation on the interface; the user will see a partially working network where some things work, and other things do not. " So this is already in contrast with the draft. Additionally I disagree on the point that RFC 4862 doesn't say what to do on DAD, as it states: 5.4 Duplicate Address Detection [snip] If the address is derived from an interface identifier, a new identifier will need to be assigned to the interface, or all IP addresses for the interface will need to be manually configured. [snap] It says that a new identifier needs to be assigned. Doesn't say how, but it does say it has to. So, I think the behaviour of DAD described in this draft is actually correct. If this poses a problem we should think about rewriting section 5.4 of RFC 4862 and update the RFC, otherwise we end up with two quite contrasting standards. Mat From randy@psg.com Wed Oct 31 07:25:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA421F87CE for ; Wed, 31 Oct 2012 07:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXH1VTFetNgG for ; Wed, 31 Oct 2012 07:25:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6A64521F87CC for ; Wed, 31 Oct 2012 07:25:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TTZEL-0009KU-K4; Wed, 31 Oct 2012 14:25:18 +0000 Date: Wed, 31 Oct 2012 23:25:16 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5090DECF.3050100@gmail.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Fernando Gont , V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:25:23 -0000 >> Fortunately I think it's easier than processing arbitrary extension >> header chains. > Unfortunately the IPv6 architecture requires the network to > be transparent to arbitrary extension header chains. it is cheering to see that the ipv6 ivory tower still stands despite years of attack by reality. > This is beyond an operational problem, which is why it is > on the 6man agenda. and how much of good people's time do you plan to waste on this windmill, don? rosenantes From nick@inex.ie Wed Oct 31 07:48:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D4521F8C30 for ; Wed, 31 Oct 2012 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJpC8817uAl2 for ; Wed, 31 Oct 2012 07:48:01 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0521F8BCA for ; Wed, 31 Oct 2012 07:48:00 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9VEl7gE026192 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 14:47:07 GMT (envelope-from nick@inex.ie) Message-ID: <50913A1D.6060806@inex.ie> Date: Wed, 31 Oct 2012 14:47:57 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Randy Bush References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:48:02 -0000 On 31/10/2012 14:25, Randy Bush wrote: > and how much of good people's time do you plan to waste on this > windmill, don? Randy, you're right that we appear to have backed ourselves into a corner where we expect kit to be able to handle TLV processing at wire speed. Rather than stowing thrones, do you have any constructive suggestions on how to deal with the situation? Nick From randy@psg.com Wed Oct 31 08:04:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5A21F87B2 for ; Wed, 31 Oct 2012 08:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q83hfjD+6Q-3 for ; Wed, 31 Oct 2012 08:04:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9131A21F872C for ; Wed, 31 Oct 2012 08:04:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TTZqA-0009RW-Lt; Wed, 31 Oct 2012 15:04:23 +0000 Date: Thu, 01 Nov 2012 00:04:21 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <50913A1D.6060806@inex.ie> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> <50913A1D.6060806@inex.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:04:25 -0000 > you're right that we appear to have backed ourselves into a corner > where we expect kit to be able to handle TLV processing at wire speed. nous? but little sense going through the whole discussion why vendor support for v6 with headers, long masks, ... at wire speed will be another couple of spins away. it will come, but too late to save the overly complex architectural decision. but blame don't move packets. > Rather than stowing thrones, do you have any constructive suggestions > on how to deal with the situation? we have seen the mtu discussions for decades. no pixie dust. all we have ever come up with is big warning signs and pleas for pmtud. rosenantes From lorenzo@google.com Wed Oct 31 08:21:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0517E21F87D3 for ; Wed, 31 Oct 2012 08:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOk5P7vmqTtP for ; Wed, 31 Oct 2012 08:21:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00C4121F874E for ; Wed, 31 Oct 2012 08:21:38 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1661602obq.31 for ; Wed, 31 Oct 2012 08:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=42gNqEl/YOs4wrxg3sJc2PLEv3jWFFlLE9XYBSl4xSY=; b=bpb1aBjdXJTHYA925rilnes0X872p8QgUmYC4YaI94YswLOmYRlu6x1V4wZf1BsvzT Zm0v4tQgEJVTW6BDsVpxxo1xZhlRBCQww7EITvjF0so5BxLewUrfhxNzc/G15fKJTw5t VsZ+jXi+oVdtiFDQFreC9bR6KIz5+l0oSo9c9Wrk0kWS7quvZh88SRNBVT9o1bM+qNDZ 5fYBKJWKBssw1iQJGcgIbeKwLpDAA8if+T4Qd7friljWGQqmzxpuHVRWMz2/vFhaFt6K SyS7j4xWFfRGVBKY1UNKpNnLk8ITApLKlOCO9Ejuxe5i22Q00l9Vb4C0OZrC6VGun/k9 fPJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=42gNqEl/YOs4wrxg3sJc2PLEv3jWFFlLE9XYBSl4xSY=; b=bu+qqQxWwX6BTRBLFXhPWIVw1qi6PdXOFhXPovSw8MvEOOPPnCMmB1LXUOoV6OUMcb lJggMY3xyUBquQGyoCOGHt7oXOBf6ByNa6DmjoYxugJ+bEND4MnTwiSBcXB319emQ6Lf iVEBuPQrJSPZyf1cxf4FH5QCQNGIK5twyQSLUj4ZIACplIooCYiyqBIupa4liACaPJsh gTZ8MjzAmMLhvMamcFs2JPR/8YPtQl9VMzJXhnaNmqCq8ERPwzRzLmKSjAWcZLU6GFhH FoRJ7xYWtucOXCW0f6tG3tpo+oA2ShnL3SQmBf1FyXUlVEc845y4eT7vafKsKPRWO6jS 6yXg== Received: by 10.60.30.100 with SMTP id r4mr32459504oeh.121.1351696898578; Wed, 31 Oct 2012 08:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Wed, 31 Oct 2012 08:21:18 -0700 (PDT) In-Reply-To: <50913A1D.6060806@inex.ie> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> <50913A1D.6060806@inex.ie> From: Lorenzo Colitti Date: Thu, 1 Nov 2012 00:21:18 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=e89a8fb206d47bda2b04cd5c7594 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmXFjN0L6ejqR6/cqujGS4v3iuiEt9Q9RFyRSFk4Jg+tjY+qn/5ZG6b6zeFsfZ6qY6wRqo050p4f+BF/8zXRdbBps952Mn1RlUMu422t0d9TNeKPS39AfyxtLhMSTWz+lFvj5L/laY2E2oHNvnkS6pqBKbGhd8flSjY+Jkv/TSdLjfxCWEx1RqIo22BCsM34D1l7LfD Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:21:40 -0000 --e89a8fb206d47bda2b04cd5c7594 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 11:47 PM, Nick Hilliard wrote: > On 31/10/2012 14:25, Randy Bush wrote: > > and how much of good people's time do you plan to waste on this > > windmill, don? > > Randy, > > you're right that we appear to have backed ourselves into a corner where we > expect kit to be able to handle TLV processing at wire speed. > > Rather than stowing thrones, do you have any constructive suggestions on > how to deal with the situation? > How about deprecate fragmentation at the IP layer and standardize a higher-layer alternative? IPv6 extension headers were standardized in 1995. I'd argue that in 1995 nobody could have foreseen hardware forwarding and that we'd have routers capable of pushing tens of terabits per second. And while other aspects of IPv6 were designed to reduce load on routers,. unfortunately, extension headers were not. Because routers *do* inspect packet contents - for security, QoS classification, accounting, and a thousand other reasons. From the point of view of reducing load on routers, extension headers were a mistake. Yes, it's possible to put arbitrary length TLV processing in silicon so it can forward at line rate packets with 8 extension headers - but we're not suggesting that router vendors do that, are we? Because silicon is expensive. And if that's not what we are suggesting, then what is it that we really want? Up to one extension header? Up to two? --e89a8fb206d47bda2b04cd5c7594 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 11:47 PM, Nick Hilliard <nick@inex.ie> wr= ote:
On 31/10/2012 14:25, Randy Bush wrote:
> and how much of good people's time do you plan to waste on this > windmill, don?

Randy,

you're right that we appear to have backed ourselves into a corner wher= e we
expect kit to be able to handle TLV processing at wire speed.

Rather than stowing thrones, do you have any constructive suggestions on how to deal with the situation?

How abo= ut deprecate fragmentation at the IP layer and standardize a higher-layer a= lternative?

IPv6 extension headers were standardiz= ed in 1995. I'd argue that in 1995 nobody could have foreseen hardware = forwarding and that we'd have routers capable of pushing tens of terabi= ts per second. And while other aspects of IPv6 were designed to reduce load= on routers,. unfortunately, extension headers were not. Because routers *d= o* inspect packet contents - for security, QoS classification, accounting, = and a thousand other reasons.=A0From the point of view of reducing load on = routers,=A0extension headers were a mistake.

Yes, it's possible to put arbitrary length TLV proc= essing in silicon so it can forward at line rate packets with 8 extension h= eaders - but we're not suggesting that router vendors do that, are we? = Because silicon is expensive. And if that's not what we are suggesting,= then what is it that we really want? Up to one extension header? Up to two= ?
--e89a8fb206d47bda2b04cd5c7594-- From Fred.L.Templin@boeing.com Wed Oct 31 08:43:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF56B21F855A for ; Wed, 31 Oct 2012 08:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAy7dy16XYP9 for ; Wed, 31 Oct 2012 08:43:24 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 686C021F8479 for ; Wed, 31 Oct 2012 08:43:24 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9VFhNdx012405 for ; Wed, 31 Oct 2012 10:43:23 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9VFhL3Q012210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 31 Oct 2012 10:43:22 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 31 Oct 2012 08:43:21 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Nick Hilliard Date: Wed, 31 Oct 2012 08:43:20 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac23e3fmAvdI8WA3TBm+mZKjZXeVSAAAJdoQ Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> <50913A1D.6060806@inex.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: V6 Ops Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:43:25 -0000 > How about deprecate fragmentation at the IP layer Why? So that routers in the middle of the network can more quickly do something that they shouldn't be doing in the first place? > and standardize a higher-layer alternative? For that, we have SEAL. RFC5320 is an experimental earlier version that specifies both tunnel and transport modes of operation. SEAL(bis) ('draft-templin-intarea-seal') currently only specifies tunnel mode operation, but we can bring back transport mode if there is sufficient interest. It is currently in the RFC Editor queue as an Informational submission, but maybe we should reclassify it as standards track? Thanks - Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Wed Oct 31 08:45:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7CC21F8793 for ; Wed, 31 Oct 2012 08:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sserVLdOAc-R for ; Wed, 31 Oct 2012 08:45:08 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id CB22121F8521 for ; Wed, 31 Oct 2012 08:45:08 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9VFj8e3007964 for ; Wed, 31 Oct 2012 08:45:08 -0700 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9VFj7Px007958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 31 Oct 2012 08:45:08 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 31 Oct 2012 08:45:07 -0700 From: "Templin, Fred L" To: Randy Bush , Nick Hilliard Date: Wed, 31 Oct 2012 08:45:07 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac23eRJPs2iTKQ30SUaUjiyTOm0YWgABW3QQ Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <5085319B.60707@inex.ie> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <5090DECF.3050100@gmail.com> <50913A1D.6060806@inex.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:45:09 -0000 > we have seen the mtu discussions for decades. no pixie dust. all we > have ever come up with is big warning signs and pleas for pmtud. You forgot about SEAL. Thanks - Fred fred.l.templin@boeing.com From wesley.george@twcable.com Wed Oct 31 09:14:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9A21F87CA for ; Wed, 31 Oct 2012 09:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53U+Witns7kP for ; Wed, 31 Oct 2012 09:14:00 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 94C5121F868E for ; Wed, 31 Oct 2012 09:14:00 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,687,1344225600"; d="scan'208";a="443588879" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 31 Oct 2012 12:10:47 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 31 Oct 2012 12:10:50 -0400 From: "George, Wes" To: "Diego R. Lopez" Date: Wed, 31 Oct 2012 12:10:58 -0400 Thread-Topic: New version of draft-lopez-v6ops-dc-ipv6 Thread-Index: AQHNr3M8j4EugeD3fkKjjO1OoT0HCJfLpGbAgAZT1YCAAaq+sA== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336CAEB6B@PRVPEXVS15.corp.twcable.com> References: <20121020200652.28676.43201.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59230336A87C8B@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] New version of draft-lopez-v6ops-dc-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:14:01 -0000 DQo+IEZyb206IERpZWdvIFIuIExvcGV6IFttYWlsdG86ZGllZ29AdGlkLmVzXQ0KPg0KPiBUaGlz IGlzIGEgZ29vZCBwb2ludCwgdGhvdWdoIEkgdGhpbmsgd2Ugc2hvdWxkIGFncmVlIGluIGxpbWl0 aW5nIHRoZQ0KPiBudW1iZXIgb2Ygc3VjaCBpdGVtcywgYW5kIGNsZWFybHkgaWRlbnRpZnkgaG93 IHRoZSBhcHBsaWNhdGlvbiBvZiB2Ng0KPiBhZmZlY3QgdGhlbSBhbmQgaW4gd2hpY2ggcmVzcGVj dCB0aGV5IGFyZSBzcGVjaWZpYyB0byB0aGUgREMNCj4gZW52aXJvbm1lbnQuIENlcnRhaW5seSBt YW5hZ2VtZW50IHN5c3RlbXMgYXJlLCBhcyBjb25zaWRlcmF0aW9ucyBvbiB0aGUNCj4gZmFicmlj IGFuZCBoeXBlcnZpc29ycy4NCltXRUddIFllcy4gVGhhdCdzIGEgZ29vZCB0ZXN0IHRvIHVzZS4g VGhlcmUncyBhIGxvdCBvZiByaXNrIGluIGdldHRpbmcgdG9vIHNwZWNpZmljIGFuZCB0byBzcGVj aWFsaXplZCBoZXJlLCBzbyBmZWVkYmFjayBmcm9tIERDIG9wZXJhdG9ycyBvbiBhIHNldCBvZiBj YXRlZ29yaWVzIHRoYXQgbWFrZSBzZW5zZSB3aWxsIGJlIHZlcnkgaGVscGZ1bC4NCg0KPiBJbiB0 aGUgY2FzZSBvZiBlbmQtdXNlciBhcHBsaWNhdGlvbnMgYW5kIGNvbnRlbnQgSSB0aGluayB0aGV5 IGFyZSBtb3N0bHkNCj4gY29uc2lkZXJlZCBpbiBvdGhlciBvcGVyYXRpb25hbCBndWlkZWxpbmU6 IChkcmFmdC1jaGtwdmMtZW50ZXJwcmlzZS0NCj4gaW5jcmVtZW50YWwtaXB2NikgYW5kIHdlIGNv dWxkIGZvbGxvdyBhbiBhcHByb2FjaCBzaW1pbGFyIHRvIHRoZSB1c2VkIGluDQo+IHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucy4NCj4NCj4gV2hlbiBpdCBjb21lcyB0byBNMk0gYW5kIGV4dGVy bmFsIHNlcnZpY2VzLCBJJ2QgbGlrZSB0byBoYXZlIGEgY2xlYXJlcg0KPiBpZGVhIG9mIHdoYXQg eW91IGFyZSByZWZlcnJpbmcgdG8uLi4NCj4NCltXRUddIEkgY2FuIHRyeSB0byBjbGFyaWZ5IGEg Yml0IC0NCk0yTSAtIEF0IGxlYXN0IGluIG15IGNvbXBhbnkncyBzeXN0ZW1zLCBoYXZlIGEgZmFp cmx5IG1vZHVsYXIgZGVzaWduIHRvIHRoZSBhcHBsaWNhdGlvbnMgdGhhdCB3ZSB1c2UsIHNvIHdl IGVuZCB1cCB3aXRoIGEgbG90IG9mIGFwcGxpY2F0aW9ucyB0aGF0IGhhdmUgb25lIHNldCBvZiBm dW5jdGlvbnMsIGJ1dCBtYWtlIEFQSSBjYWxscyB0byBvdGhlciBhcHBsaWNhdGlvbnMgd2l0aGlu IHRoZSBkYXRhIGNlbnRlciBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aGF0IHRoZXkgcmVx dWlyZSB0byBjb21wbGV0ZSB0aGVpciBpbnRlbmRlZCBmdW5jdGlvbi4gVGhlc2UgbWFjaGluZS10 by1tYWNoaW5lIGNvbW11bmljYXRpb25zIGFyZSBhIGdvb2QgcGxhY2UgdG8gZXhwZXJpbWVudCB3 aXRoIG1vdmluZyB0byBJUHY2LCBlc3BlY2lhbGx5IHdoZW4geW91IGhhdmUgY29udHJvbCBvdmVy IGJvdGggb2YgdGhlIGFwcGxpY2F0aW9ucyAodnMgb25lIHdoZXJlIHlvdSdyZSBtYWtpbmcgY2Fs bHMgdG8gYW4gQVBJIG9uIGFuIGV4dGVybmFsbHkgbWFuYWdlZCBzeXN0ZW0gZm9yIGV4YW1wbGUp LiBUaGlzIGlzIGJlY2F1c2UgYXNzdW1pbmcgeW91IGhhdmUgYW4gSVB2Ni1jYXBhYmxlIGZhYnJp YyBpbiBwbGFjZSwgYW5kIHRoZSB1bmRlcmx5aW5nIFZNIGluZnJhc3RydWN0dXJlIHN1cHBvcnRz IElQdjYsIGl0IG1heSBiZSBhcyBzaW1wbGUgYXMgY2hhbmdpbmcgYSBmZXcgRE5TIGVudHJpZXMg dG8gYWRkIEFBQUEgcmVjb3JkcywgYW5kIHRoZSB0cmFmZmljIGdvaW5nIGJldHdlZW4gdGhlc2Ug YXBwbGljYXRpb25zIHdpbGwgYmVnaW4gdXNpbmcgSVB2NiBpbiBhIHdheSB0aGF0IGlzIHJlbGF0 aXZlbHkgc3RyYWlnaHRmb3J3YXJkIGZyb20gYSBjb250cm9sIGFuZCByb2xsb3V0IHBlcnNwZWN0 aXZlIGJlY2F1c2UgeW91IGFyZSBub3QgZGVhbGluZyB3aXRoIHRoZSB2YXJpYWJsZSB0aGF0IGFu eSBzb3J0IG9mIGh1bWFuIHVzZXIgbWlnaHQgaW50cm9kdWNlIC0gaXQncyB0d28gYXBwbGljYXRp b25zIHRhbGtpbmcgdG8gb25lIGFub3RoZXIgZGlyZWN0bHkuIEl0IGlzIHdvcnRoIG5vdGluZyB0 aGF0IGluIHNvbWUgY2FzZXMgdGhlc2UgYXJlIG5vdCBuZWNlc3NhcmlseSBjb250YWluZWQgY29t cGxldGVseSB3aXRoaW4gb25lIGRhdGFjZW50ZXIsIHNvIHlvdSBjb3VsZCBtYWtlIGEgZGlzdGlu Y3Rpb24gYmV0d2VlbiB0aG9zZSB0aGF0IHN0YXkgd2l0aGluIGEgc2luZ2xlIGRhdGEgY2VudGVy IHZzIHRob3NlIHRoYXQgbXVzdCBjb21tdW5pY2F0ZSBiZXR3ZWVuIGRhdGFjZW50ZXJzLg0KRXh0 ZXJuYWwgc2VydmljZXMgcmVmZXJzIHRvIGFueSBzb3J0IG9mIGFwcGxpY2F0aW9ucyB0aGF0IGFy ZSBwcm92aWRpbmcgc2VydmljZXMgY29uc3VtZWQgb3V0c2lkZSBvZiB0aGUgZGF0YWNlbnRlciAo dnMgdGhvc2UgbGlrZSBJIG91dGxpbmVkIGFib3ZlKS4NCkhvcGVmdWxseSB0aGF0IGhlbHBzLiBJ IGtub3cgdGhhdCBNMk0gaXMgYWxzbyBhbiBvdmVybG9hZGVkIHRlcm0sIGFuZCBJIGRpZG4ndCBl eGFjdGx5IHVzZSBpdCBpbiB0aGUgdHJhZGl0aW9uYWwgc2Vuc2UsIHNvIEkgYXBvbG9naXplIGZv ciBhbnkgY29uZnVzaW9uIEkgbWF5IGhhdmUgY2F1c2VkLg0KDQpXZXMgR2VvcmdlDQoNCg0KVGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5 aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBh dHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRv dXQuDQo= From brian.e.carpenter@gmail.com Wed Oct 31 10:27:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4721F84D3 for ; Wed, 31 Oct 2012 10:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.635 X-Spam-Level: X-Spam-Status: No, score=-101.635 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGXNXKw+Wrk9 for ; Wed, 31 Oct 2012 10:27:27 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8547421F863F for ; Wed, 31 Oct 2012 10:27:27 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so848175wey.31 for ; Wed, 31 Oct 2012 10:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2FodnJGu3ct6mLbL6fJe9oCjD3DMc2dPNBj95upXeMM=; b=nNTiCN7CQySz5MIWCMX8pAFXBTeG97+uOUU4Arz5Bs6X2G+vZzyr6+/ec2AjkScHQA H7wxF2Lmrrtzg5iwx+68S8FoTyt2djTzMdgTDn7E9P/XR9/Ky3XSAEOhf3Wn4+k8FVg1 Kt+UnjQjP5pdfi+BiLk1WKCr0qtBkr2mE7wV2Pq+YpNf1z1ERMzaqadPuW9F5ubIomjg VlM0uybjSW61juzroSP8pQN/h2sOOvn1ZPbJzc/WuVUJPqmYbEE6NfC31n/zYYuUv5cs htM4c9RjJwTJLtvkvCGkyuM3G1EkwJ6Uwq66rGsXPiHSLj0QPuMxZPozMCqr0hpx3+pm yOvA== Received: by 10.181.13.239 with SMTP id fb15mr3919261wid.22.1351704446728; Wed, 31 Oct 2012 10:27:26 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-70.as13285.net. [2.102.217.70]) by mx.google.com with ESMTPS id a10sm6686922wiz.4.2012.10.31.10.27.24 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 10:27:25 -0700 (PDT) Message-ID: <50915F86.7050304@gmail.com> Date: Wed, 31 Oct 2012 17:27:34 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: fgont@si6networks.com, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:27:28 -0000 On 31/10/2012 12:51, Lorenzo Colitti wrote: > On Wed, Oct 31, 2012 at 8:40 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>>>> Unfortunately the IPv6 architecture requires the network to >>>>> be transparent to arbitrary extension header chains. >>>> Good luck with that in real networks. >>> Agreed. "Not gonna happen." >> I am not totally unrealistic. However, there are some things that >> the IETF can do to make the reality a bit better than it is at >> the moment. >> > > But why? If you can't get extension headers to work reliably in the > Internet (as opposed to in your own network), then what's the point? You > still need a fallback plan for when they get dropped, and users don't like > waiting. Why not just use the more reliable plan all the time? For MTU/fragmentation issues, there may be such a plan. There are other extension headers for which there is no such plan. Come to 6man. Brian From fgont@si6networks.com Wed Oct 31 10:54:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97D521F886A for ; Wed, 31 Oct 2012 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5fO6y0cGmr8 for ; Wed, 31 Oct 2012 10:54:27 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45521F8855 for ; Wed, 31 Oct 2012 10:54:27 -0700 (PDT) Received: from r186-52-22-47.dialup.adsl.anteldata.net.uy ([186.52.22.47] helo=[192.168.51.104]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TTcUf-0002Er-AG; Wed, 31 Oct 2012 18:54:21 +0100 Message-ID: <509165B8.404@si6networks.com> Date: Wed, 31 Oct 2012 15:54:00 -0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> In-Reply-To: <50915F86.7050304@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:54:27 -0000 On 10/31/2012 03:27 PM, Brian E Carpenter wrote: >> But why? If you can't get extension headers to work reliably in the >> Internet (as opposed to in your own network), then what's the point? You >> still need a fallback plan for when they get dropped, and users don't like >> waiting. Why not just use the more reliable plan all the time? > > For MTU/fragmentation issues, there may be such a plan. > > There are other extension headers for which there is no such plan. The end-result is/is going to be that sine extension headers are not reliable, no mechanism will be able to rely on them. SO, in practice, you better put your "options"/fragmentation somewhere else, or prepare to be dropped. It happened with IPv4 options already.... Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Wed Oct 31 11:11:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C2921F8596 for ; Wed, 31 Oct 2012 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtwKxApiid1w for ; Wed, 31 Oct 2012 11:11:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA421F85EB for ; Wed, 31 Oct 2012 11:11:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q9VIBEw4026592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 11:11:14 -0700 (PDT) Message-ID: <509169C2.9040208@isi.edu> Date: Wed, 31 Oct 2012 11:11:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Fernando Gont References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> In-Reply-To: <509165B8.404@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:11:37 -0000 On 10/31/2012 10:54 AM, Fernando Gont wrote: > On 10/31/2012 03:27 PM, Brian E Carpenter wrote: >>> But why? If you can't get extension headers to work reliably in the >>> Internet (as opposed to in your own network), then what's the point? You >>> still need a fallback plan for when they get dropped, and users don't like >>> waiting. Why not just use the more reliable plan all the time? >> >> For MTU/fragmentation issues, there may be such a plan. >> >> There are other extension headers for which there is no such plan. > > The end-result is/is going to be that sine extension headers are not > reliable, no mechanism will be able to rely on them. SO, in practice, > you better put your "options"/fragmentation somewhere else, or prepare > to be dropped. > > It happened with IPv4 options already.... Yes, but the whole point of the IPv6 option architecture was to avoid the issues seen with IPv4 options. Consider that: - routers don't like fragments because they can't inspect them - so we tunnel and fragment in a higher level protocol the router now needs to implement the higher protocol and still fragment or else we cannot have tunnels the routers on the path still cannot inspect the higher-level fragments So we're back to the reason this all breaks - routers doing something that we simply cannot support in the architecture. Joe From fgont@si6networks.com Wed Oct 31 11:34:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3583B21F8865 for ; Wed, 31 Oct 2012 11:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+St1zf56HmI for ; Wed, 31 Oct 2012 11:34:43 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 93F1B21F881F for ; Wed, 31 Oct 2012 11:34:43 -0700 (PDT) Received: from r186-52-22-47.dialup.adsl.anteldata.net.uy ([186.52.22.47] helo=[192.168.51.104]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TTd7X-0003Ey-Jo; Wed, 31 Oct 2012 19:34:32 +0100 Message-ID: <50916F21.6030303@si6networks.com> Date: Wed, 31 Oct 2012 16:34:09 -0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> In-Reply-To: <509169C2.9040208@isi.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:34:44 -0000 On 10/31/2012 04:11 PM, Joe Touch wrote: > Yes, but the whole point of the IPv6 option architecture was to avoid > the issues seen with IPv4 options. The only thing in that IPv6 would avoid is requiring routers to parse *all* options, just to find the ones that need to be processed by routers. While the IPv6 extension header syntax is good in terms of extensibility (in principle, you can include as many options as you want9, it also allows for pathological cases in which the header chain is split among multiple fragments (we're working on fixing that one), and also requires any box that wants to find the upper-layer header to parse the entire IPv6 header chain -- something that a large number of devices cannot do at wire speed. For filtering purposes, it'd been interesting to have a pointer to the upper-layer header -- although with the original specs, it might simply not be there. With IPv4, at the very least it's trivial to find the upper layer protocol: just skip the first IHL of the packet, and you're there. With IPv6, at leasts in theory, it might be impossible (unless you reassemble-filter-and-refragment). > Consider that: > > - routers don't like fragments because they can't inspect them > > - so we tunnel and fragment in a higher level protocol > > the router now needs to implement the higher protocol > and still fragment or else we cannot have tunnels > > the routers on the path still cannot inspect the > higher-level fragments > > So we're back to the reason this all breaks - routers doing something > that we simply cannot support in the architecture. It's probably time to accept that firewalls and routers implementing ACLs are part of the architecture. One might argue that the use of firewalls couldn't be foreseen with IPv4. But at the time IPv6 was designed, it was already a reality. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Wed Oct 31 11:59:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDBE21F8720 for ; Wed, 31 Oct 2012 11:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raL4eNVugCPb for ; Wed, 31 Oct 2012 11:59:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55421F85CD for ; Wed, 31 Oct 2012 11:59:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q9VIwvo3022133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 11:58:57 -0700 (PDT) Message-ID: <509174F1.8080809@isi.edu> Date: Wed, 31 Oct 2012 11:58:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Fernando Gont References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> In-Reply-To: <50916F21.6030303@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:59:42 -0000 On 10/31/2012 11:34 AM, Fernando Gont wrote: > On 10/31/2012 04:11 PM, Joe Touch wrote: >> Yes, but the whole point of the IPv6 option architecture was to avoid >> the issues seen with IPv4 options. > > The only thing in that IPv6 would avoid is requiring routers to parse > *all* options, just to find the ones that need to be processed by routers. Yes. However, since fragmentation is near the end of the set of possible options, that means that ANY recommendations about how IPv6 routers handle options will require deep option parsing. How does that help? > While the IPv6 extension header syntax is good in terms of extensibility > (in principle, you can include as many options as you want, it also > allows for pathological cases in which the header chain is split among > multiple fragments (we're working on fixing that one), and also requires > any box that wants to find the upper-layer header to parse the entire > IPv6 header chain -- something that a large number of devices cannot do > at wire speed. I thought we were talking more about fragmentation - which defeats filtering on upper layer info anyway. The non-HBH options can be split across fragments, but not the HBH ones. > For filtering purposes, it'd been interesting to have a pointer to the > upper-layer header -- although with the original specs, it might simply > not be there. With IPv4, at the very least it's trivial to find the > upper layer protocol: just skip the first IHL of the packet, and you're > there. With IPv6, at leasts in theory, it might be impossible (unless > you reassemble-filter-and-refragment). In both cases fragmentation defeats DPI. But then so does IPsec. Yes, IPv6's chained header structure is not DPI-friendly. But this isn't news, is it? >> Consider that: >> >> - routers don't like fragments because they can't inspect them >> >> - so we tunnel and fragment in a higher level protocol >> >> the router now needs to implement the higher protocol >> and still fragment or else we cannot have tunnels >> >> the routers on the path still cannot inspect the >> higher-level fragments >> >> So we're back to the reason this all breaks - routers doing something >> that we simply cannot support in the architecture. > > It's probably time to accept that firewalls and routers implementing > ACLs are part of the architecture. We need to accept one of three things: DPI is part of the architecture either don't use IPv6 options or don't use IPv6 IPv6 options are part of the architecture DPI isn't meaningful anymore > One might argue that the use of > firewalls couldn't be foreseen with IPv4. But at the time IPv6 was > designed, it was already a reality. So that means IPv6 was designed to inhibit the use of options, or designed to inhibit its own deployment. Seems like the latter is coming to fruition. Joe From fgont@si6networks.com Wed Oct 31 12:52:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9330121F8815 for ; Wed, 31 Oct 2012 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqLbYLc88hZA for ; Wed, 31 Oct 2012 12:52:00 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A625421F8A53 for ; Wed, 31 Oct 2012 12:51:59 -0700 (PDT) Received: from [2001:13c7:7003:2:5b1:279a:848c:bf07] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TTeKP-0005Hb-Vb; Wed, 31 Oct 2012 20:51:54 +0100 Message-ID: <50918153.7070509@si6networks.com> Date: Wed, 31 Oct 2012 17:51:47 -0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> In-Reply-To: <509174F1.8080809@isi.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 19:52:05 -0000 On 10/31/2012 04:58 PM, Joe Touch wrote: >> The only thing in that IPv6 would avoid is requiring routers to parse >> *all* options, just to find the ones that need to be processed by >> routers. > > Yes. > > However, since fragmentation is near the end of the set of possible > options, that means that ANY recommendations about how IPv6 routers > handle options will require deep option parsing. How does that help? mm.. not sure what you mean. Could you elaborate a bit more? >> While the IPv6 extension header syntax is good in terms of extensibility >> (in principle, you can include as many options as you want, it also >> allows for pathological cases in which the header chain is split among >> multiple fragments (we're working on fixing that one), and also requires >> any box that wants to find the upper-layer header to parse the entire >> IPv6 header chain -- something that a large number of devices cannot do >> at wire speed. > > I thought we were talking more about fragmentation - which defeats > filtering on upper layer info anyway. It *currently* does in v6, but not in v4: in v4 the first fragment always has, at the very least, the IP addresses, upper-layer protocol, and transport ports. In v6 (with the current specs), that might not be the case. > The non-HBH options can be split across fragments, but not the HBH ones. And...? >> For filtering purposes, it'd been interesting to have a pointer to the >> upper-layer header -- although with the original specs, it might simply >> not be there. With IPv4, at the very least it's trivial to find the >> upper layer protocol: just skip the first IHL of the packet, and you're >> there. With IPv6, at leasts in theory, it might be impossible (unless >> you reassemble-filter-and-refragment). > > In both cases fragmentation defeats DPI. Please see above (the situation in v6 is different from the v4 one9. >> It's probably time to accept that firewalls and routers implementing >> ACLs are part of the architecture. > > We need to accept one of three things: > > DPI is part of the architecture > either don't use IPv6 options > or don't use IPv6 I'd put it as "DPI is part of the architecture. Beware that IPv6 packets carrying options are not reliable. Use them at your own risk.". >> One might argue that the use of >> firewalls couldn't be foreseen with IPv4. But at the time IPv6 was >> designed, it was already a reality. > > So that means IPv6 was designed to inhibit the use of options, or > designed to inhibit its own deployment. > > Seems like the latter is coming to fruition. I'd argue that the problems with v6 deployment have more to do with what's noted in RFC 1669 than with DPI. But that train has already left. So we better try to improve v6 to the best of our possibilities, where necessary. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Wed Oct 31 13:00:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB58821F8825 for ; Wed, 31 Oct 2012 13:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+ijHic-LtBL for ; Wed, 31 Oct 2012 13:00:23 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7E80821F8823 for ; Wed, 31 Oct 2012 13:00:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q9VK09xQ019125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 13:00:09 -0700 (PDT) Message-ID: <50918349.9020205@isi.edu> Date: Wed, 31 Oct 2012 13:00:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Fernando Gont References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50918153.7070509@si6networks.com> In-Reply-To: <50918153.7070509@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:00:24 -0000 On 10/31/2012 12:51 PM, Fernando Gont wrote: > On 10/31/2012 04:58 PM, Joe Touch wrote: >>> The only thing in that IPv6 would avoid is requiring routers to parse >>> *all* options, just to find the ones that need to be processed by >>> routers. >> >> Yes. >> >> However, since fragmentation is near the end of the set of possible >> options, that means that ANY recommendations about how IPv6 routers >> handle options will require deep option parsing. How does that help? > > mm.. not sure what you mean. Could you elaborate a bit more? The fragment header is not required to be the first header; it's required to come after the HBH and before the E2E ones. So "must drop IPv6 fragments" implies parsing ALL HBH headers that come before the frag header (or you'd never know the frag header was there). >>> While the IPv6 extension header syntax is good in terms of extensibility >>> (in principle, you can include as many options as you want, it also >>> allows for pathological cases in which the header chain is split among >>> multiple fragments (we're working on fixing that one), and also requires >>> any box that wants to find the upper-layer header to parse the entire >>> IPv6 header chain -- something that a large number of devices cannot do >>> at wire speed. >> >> I thought we were talking more about fragmentation - which defeats >> filtering on upper layer info anyway. > > It *currently* does in v6, but not in v4: in v4 the first fragment > always has, at the very least, the IP addresses, upper-layer protocol, > and transport ports. In v6 (with the current specs), that might not be > the case. > > >> The non-HBH options can be split across fragments, but not the HBH ones. > > And...? I'm not sure what bug you're implying above ("we're working on fixing that one"), but it's not that the entire chain is split among the fragments. Joe From markzzzsmith@yahoo.com.au Wed Oct 31 13:03:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C976321F85DF for ; Wed, 31 Oct 2012 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w-pkk-ylH5A for ; Wed, 31 Oct 2012 13:03:54 -0700 (PDT) Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id C04C321F85B6 for ; Wed, 31 Oct 2012 13:03:53 -0700 (PDT) Received: from [98.139.215.141] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 20:03:49 -0000 Received: from [98.139.215.249] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 20:03:49 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 31 Oct 2012 20:03:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 862140.28852.bm@omp1062.mail.bf1.yahoo.com Received: (qmail 18533 invoked by uid 60001); 31 Oct 2012 20:03:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351713829; bh=mmxg+LOeNR2CGXIAFNS9zaTNYR898IGw0IT8vrvfDK4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WRUYfvnM/w5FHTYn9cnSsGXnrM+q3t8zhr0MlhtNXzv1sHvfs+xBBYCil6fU0h8TUPfqT0T1YvxYhT6PQBSASdDirvlid3dgLMWE1T9Rv/hxnMpw0hXU5ULX9ypBBIXyo+wlO3m/K0DnCnFOcoM2gailR4c1B6IMUoKs/SB0554= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Av9qDclR9+2mOq4c20XS+8JB9lSOW928cjNwGo6KpM8xUCpLKzk6PV6y+mP9E+xKjVxcdD7GDzU/gqGYXKeL8KKe0bzYZNnPK52pxB2G7QnNaq3pU50cOjLJ3RFjJlnXA7c0PCqhr9tM1Lr5dMN/8Ks6GprfeYHV8lFsuNqiGXA=; X-YMail-OSG: goSfUigVM1lVSaS5pcvHZF0tkdYZVRp22or808SQgas2Iva B.ZW4UCy2f6.qeTcF8QYnNZKAgzTw4ZIVjhQPGLWp5kD7TI8TmLCi9xWVI1s .H1XNhmllt9XQVrPNip9FUHYAbABz_y7Onuh70LCxw8MkYjmHdXmmOYsk21x rYTSFtckVlyAeysixl9YxRW7_nGDx4fauH72OqT7rIyDsdeWZov0misMuNiK wOngeVuT3k8oCL4ECHAHUKX6qXz1QhxGVrqDqMa36Y5rBPB5U3s6dsfY4tVp 0c04UJxB0O.Lk2DzJ_4Jj0wPfGp16oBr3hMKn1lUY5dI_9I7uAa90ldhBmOs dGUKh9Zjv2w.ibNmhk8gO7ZK7mZOz7dF5ahgocg5IhZ2Gv0Zqs4PdeCA1u0j U13YMWcO_xeJBq6jYhaCCcM2ABkSHHj2W5yRQLSpO6hjYATCLEtwm9x..Fwf vgFhVbesxHInGE_Oh_Tkkkq.t27K_qghz0J5PmTE1fnzwd2032BCiAcshazx YHCESVoCPRPXG Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 13:03:48 PDT X-Rocket-MIMEInfo: 001.001, SGksCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiAKPkNjOiBmZ29udEBzaTZuZXR3b3Jrcy5jb207IHY2b3BzQGlldGYub3JnIAo.U2VudDogV2VkbmVzZGF5LCAzMSBPY3RvYmVyIDIwMTIgMTE6NTEgUE0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtdGF5bG9yLXY2b3BzLWZyYWdkcm9wCj4gCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> Message-ID: <1351713828.99139.YahooMailNeo@web32505.mail.mud.yahoo.com> Date: Wed, 31 Oct 2012 13:03:48 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti , Brian E Carpenter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "fgont@si6networks.com" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:03:54 -0000 Hi,=0A=0A>________________________________=0A> From: Lorenzo Colitti =0A>To: Brian E Carpenter =0A>C= c: fgont@si6networks.com; v6ops@ietf.org =0A>Sent: Wednesday, 31 October 20= 12 11:51 PM=0A>Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop= =0A> =0A>=0A>On Wed, Oct 31, 2012 at 8:40 PM, Brian E Carpenter wrote:=0A>=0A>>>> Unfortunately the IPv6 architecture re= quires the network to=0A>>>>> be transparent to arbitrary extension header = chains.=0A>>=0A>>>> Good luck with that in real networks.=0A>>>=0A>>> Agree= d. "Not gonna happen."=0A>>=0A>>I am not totally unrealistic. However, ther= e are some things that=0A>>the IETF can do to make the reality a bit better= than it is at=0A>>the moment.=0A>>=0A>=0A>=0A>But why? If you can't get ex= tension headers to work reliably in the Internet (as opposed to in your own= network), then what's the point? You still need a fallback plan for when t= hey get dropped, and users don't like waiting. Why not just use the more re= liable plan all the time?=0A>_=0A=0ASo I think, using the "dumb network, sm= art hosts" model, these measures=0A=0A(dropping fragments, dropping extensi= on headers, and dropping ICMP) are=0Amaking the Internet dumber, and that m= eans the hosts will need to become=0Asmarter. Smarter hosts will either cho= ose to use the simple base capability=0Aof the network (e.g. 1280 MTU), or = need to measure the availability of the=0Afeatures they want to use (PMTUD)= , without relying on the the network to=0Aindicate which features are and a= re not currently available (ie. ICMP PTB).=0A=0AThere are already examples = of hosts doing this active measuring - packet=0Aloss indicating to TCP that= congestion is occurring, measuring PMTU without=0Arelying on ICMP (RFC4821= ), NAT presence determination using STUN.=0A=0ABefore and unrelated to this= thread, I've recently been thinking about=0A=0Awhat the impact of the rapi= d adoption of wireless, mobile multihomed hosts=0A(a.k.a. smartphones and t= ables) will be to enterprise and carrier networks,=0Aand what would happen = to network QoS and network located security if these=0Ahosts started using = Multipath TCP. As these hosts' point of attachment=0Awill never be consiste= nt, and even the performance of the links they're=0Acommonly attached can c= hange over time (i.e. wifi), they'll never be able=0Ato assume a consistent= network layer service (throughput, MTU, extension=0Aheader support etc., N= AT presence, IPv4 and/or IPv6), and therefore will=0Aneed to actively measu= re it if they want to utilise more than just the base=0Afunctionality. They= 'll also need to be responsible for their own security.=0A=0AThe Happy eyeb= alls technique is another example of a host dynamically=0Acoping with the a= vailability or unreliability of a feature it wants to use.=0A=0ASo perhaps = the topic of this draft needs to be encompassed into something=0A=0Alarger,= discussing the "dumbing down" of the Internet, and what hosts,=0Aboth fixe= d and rapidly growing numbers of multihomed mobile ones, need to=0Ado to co= pe when the only reliable indicator from the network layer that=0Asomething= has gone wrong is packet loss, and that there is no reliable=0Aindicator o= f what went wrong.=0A=0A=0A______________________________________________= =0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/v6ops=0A>=0A>=0A> From markzzzsmith@yahoo.com.au Wed Oct 31 13:13:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E3021F8233 for ; Wed, 31 Oct 2012 13:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.158 X-Spam-Level: X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zHdF3ffK9XG for ; Wed, 31 Oct 2012 13:13:03 -0700 (PDT) Received: from nm12-vm0.bullet.mail.sp2.yahoo.com (nm12-vm0.bullet.mail.sp2.yahoo.com [98.139.91.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21D21F8232 for ; Wed, 31 Oct 2012 13:13:03 -0700 (PDT) Received: from [98.139.91.66] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 31 Oct 2012 20:12:58 -0000 Received: from [98.139.91.28] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 31 Oct 2012 20:12:58 -0000 Received: from [127.0.0.1] by omp1028.mail.sp2.yahoo.com with NNFMP; 31 Oct 2012 20:12:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 75590.82062.bm@omp1028.mail.sp2.yahoo.com Received: (qmail 25330 invoked by uid 60001); 31 Oct 2012 20:12:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351714377; bh=9T2ploWhrU0AVycXyYiCsZ2BrZOJ26ZRN0RG47C/H9c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3e1EiWpLNP+8zUDPgA+k+b0uFrmzUOACuuzFIIYVP4sqmybLFuaPIH3yVOQuQn6zOBkXRsFTmawQZQvFprbrQjO1uaA/DPG6aTOww4q+UK0ReD/cQVHUkMZDitX18bkoYtSyaKLGpsvA95nG00dbWImv4EDX0u+qzCLTz1QMk+A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lG26feN2o9moVzvTQYsEB95n2zkloKbwdMH7m8G4RQDfYueUff4gISiv0Gm05XeeI+eoCvbxXp/CCBRKJLTcFOeIT9oGxvK14RmjFJMRJHhaiqMTRVet0Vci7aIfXsrYpQZ6r4eomUwONa8tjofTkVtiB/PIWltEznSD+/bibaU=; X-YMail-OSG: jv8IvYkVM1kkBCw5Ws8NppcchgZxBUNzF4jFNQ2br_dZ1_X RKlizVQH7bkXBx5ulGvcY3mY4oAWeMdHUg9WC4TmEOFwIuH0gxsnXwXG.uAX u.DySHTVs6OWZjkA4I3vRFlD_ljumi0MKz88f.bznK8hWfxz2JUA4p2TkiDQ J4MI1QJ_lfSlJDOzvrefgfL0Rk.Feclu5I3f1ljatYo_1Kq2kRaoyB0zlY6v PFv0HWiH7oiV7VMsU4N3KEX9HkayX1aOWYIcJHIO7gwGiCY6Cm2Lj0bnOw4I oAR_hYgcCv5VbXeEp0BCs.oRt5yykqfmOcqCoFAjKcp4rM5P6JAJUn_nFz__ 6Dntw1XjvJ4D.aH8f.smARy3KlYhkcxloCiF34Y7iI6_PT6sow0WEhv1BwbX .uuEpk2v5n7jtrku6xSfYQjf4jNREVxZtidCWr9EnTyrd6pjVzGLke1mbwrl 37NoVynANhi4I.pugbWadfY7291G5TSyqFk2GHd6.nidY9l6QUdtqG2uA0KF CINlS5_dBUvS4p7uHzuTkOhaEzogVA2H.dl4V Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 13:12:57 PDT X-Rocket-MIMEInfo: 001.001, CgoKClw.IAo.IEJlZm9yZSBhbmQgdW5yZWxhdGVkIHRvIHRoaXMgdGhyZWFkLCBJJ3ZlIHJlY2VudGx5IGJlZW4gdGhpbmtpbmcgYWJvdXQKPiAKPiB3aGF0IHRoZSBpbXBhY3Qgb2YgdGhlIHJhcGlkIGFkb3B0aW9uIG9mIHdpcmVsZXNzLCBtb2JpbGUgbXVsdGlob21lZCBob3N0cwo.IChhLmsuYS4gc21hcnRwaG9uZXMgYW5kIHRhYmxlcynCoAoKVGhhdCBzaG91bGQgYmUgInRhYmxldHMiLiBSYXBpZCBhZG9wdGlvbiBvZiBtb2JpbGUgdGFibGVzIHdpbGwgbWFrZSBteSB0cmFpbiByaWRlIHRvIHdvcmsgbXUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <1351713828.99139.YahooMailNeo@web32505.mail.mud.yahoo.com> Message-ID: <1351714377.3736.YahooMailNeo@web32505.mail.mud.yahoo.com> Date: Wed, 31 Oct 2012 13:12:57 -0700 (PDT) From: Mark Smith To: Mark Smith , Lorenzo Colitti , Brian E Carpenter In-Reply-To: <1351713828.99139.YahooMailNeo@web32505.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "fgont@si6networks.com" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:13:03 -0000 =0A=0A=0A=0A\> =0A> Before and unrelated to this thread, I've recently been= thinking about=0A> =0A> what the impact of the rapid adoption of wireless,= mobile multihomed hosts=0A> (a.k.a. smartphones and tables)=A0=0A=0AThat s= hould be "tablets". Rapid adoption of mobile tables will make my train ride= to work much more uncomfortable. From fred@cisco.com Wed Oct 31 13:33:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FA921F878B for ; Wed, 31 Oct 2012 13:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G5oo6yJ3ltG for ; Wed, 31 Oct 2012 13:33:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6994621F8787 for ; Wed, 31 Oct 2012 13:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=800; q=dns/txt; s=iport; t=1351715613; x=1352925213; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EIoTlYZqaWTl5WtQ6fUiyM01AWo2MbHF/8IEpbB4Eaw=; b=UJq+lCR8p27egeIUsGkk9woTFBfH3Of/YOZpsgpqttcN8zafDBA2h1rx h8eyuw0yEzu4PlQJDlie5+qrFqByXYFe9G0s2cxAjAtXNkcVF6Lh26TOX t4hbcBEzFkwHvlZWw2YkVsMR8/GMzeHQTAMEaQZqwjcjiNYWknR/Dy28f I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGuKkVCtJV2Z/2dsb2JhbABEw12BCIIeAQEBAwESASc/BQsCAQgiFBAyJQIEDg0ah14GmxmgKYt4hVphA6RNgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="137267790" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2012 20:33:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9VKXWax028773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 20:33:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 15:33:32 -0500 From: "Fred Baker (fred)" To: "Templin, Fred L" Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: AQHNt6b9g92I1qLh5kW3Jy3oBAzr9A== Date: Wed, 31 Oct 2012 20:33:31 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--35.252300-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-ID: <364B8EBE5C73E04A919B78245CA06EE9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:33:34 -0000 On Oct 18, 2012, at 10:48 AM, Templin, Fred L wrote: > Once again, tunnels are an important class of "application" > that cannot do without some form of fragmentation capability > for the tunneled packets, since they have no way of reducing > the size of the packets they send down to 1280. They are also an obvious place to use a subnetwork-dependent protocol. RFC = 1990, for example, builds a segment/reassembly protocol that runs atop a (s= et of) PPP link(s). If the advice of the operators is that they would like = the fragment header to go away, which is the net effect of fragdrop, one co= uld imagine a tunneling protocol that was in essence GRE plus a fragmentati= on field (packet id plus sequence number), intended to be exchanged by tunn= el/encapsulation endpoints.= From Fred.L.Templin@boeing.com Wed Oct 31 13:47:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC74B21F8842 for ; Wed, 31 Oct 2012 13:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-IPHkUJyjXb for ; Wed, 31 Oct 2012 13:47:24 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 546D021F871D for ; Wed, 31 Oct 2012 13:47:24 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9VKlMXb024457 for ; Wed, 31 Oct 2012 13:47:23 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9VKlLTx024418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 31 Oct 2012 13:47:22 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Wed, 31 Oct 2012 13:47:21 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Date: Wed, 31 Oct 2012 13:47:17 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: AQHNt6b9g92I1qLh5kW3Jy3oBAzr9JfT4Dqw Message-ID: References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:47:25 -0000 Hi Fred, > one could imagine a tunneling protocol that was in essence GRE plus a > fragmentation field (packet id plus sequence number), intended to be > exchanged by tunnel/encapsulation endpoints. SEAL can be used either along with or instead of GRE, based on the use case. SEAL has the fragmentation field you've mentioned which is used to accommodate "medium-sized" packets (between 1280-1500) but it also holds the gate open for smaller and larger packets to go through. The SEAL MTU philosophy is: "Take care of the smalls and let the bigs take care of themselves" Thanks - Fred fred.l.templin@boeing.com From touch@isi.edu Wed Oct 31 13:56:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CFF21F8842 for ; Wed, 31 Oct 2012 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtnQ9MfoMn-4 for ; Wed, 31 Oct 2012 13:56:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7C21F8832 for ; Wed, 31 Oct 2012 13:56:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q9VKuUrI028331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 13:56:30 -0700 (PDT) Message-ID: <5091907E.3090206@isi.edu> Date: Wed, 31 Oct 2012 13:56:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:56:39 -0000 Hi, all, As per my recent post, the claim that "we cannot parse the entire IP option chain at line rate" doesn't fit with "so we should drop IP fragments", since the fragment option need not appear at the head of the option chain. I'm wondering whether routers that drop fragments do so only when that's the first option, or do they just drop packets with *any* options? If just fragments, a quick fix might be to create a new null HBH option that is silently ignored, solely to bury the fragment option away from the primary IPv6 next-header field. Can anyone with such a router comment as to what might happen? Thanks, Joe From lorenzo@google.com Wed Oct 31 17:35:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90F21F8871 for ; Wed, 31 Oct 2012 17:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFqOHJ+myccW for ; Wed, 31 Oct 2012 17:35:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBBE21F85E7 for ; Wed, 31 Oct 2012 17:35:29 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2206899obq.31 for ; Wed, 31 Oct 2012 17:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=R94w6TDSpuubBfO0il0XFuryBPJsYmbzoZdB3hdYh6o=; b=pa4kMgBeFZYCNBczQQ3kVejRUYkPFuyu5b2Ke7HJJIHT08TSiX0j7Gvaox7uvDApW1 I9CHHHBa/wXwbNz0vjEgMSp//EocBQJW3+oTbpcpKkGTfAQoY43B6nwvKdWb/jtLRtoc F/6h6XyBWqPafcVJfyUWVNMgMaMvdKWZA5MvNWsl2Z1o2TTDlaIBMJOI4ZpQBqv+dv2J T86ucrz+By2YRxjoH4CX2/mGOmFdb95FcPxwuotZD3IKyy+blSUgMYAEsFNvTqWWME2I PwMgJZY/HBII98s9QRrKEFUxkmZ0rrQbh+EH5fS6fbB8p3jI6h1y9XV5VWN+OYnZ9bhI SEmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=R94w6TDSpuubBfO0il0XFuryBPJsYmbzoZdB3hdYh6o=; b=X719AbKJsO/IJGxCfSIgwKnJPX8+kpNcRC6y/Nbl1fPlNq0S7R31mLZLJ1a/9V4060 r6n3Pxtv/ADCHt436qUjr6D10s1ATyCnVw6uGU1i5jTC17c8yOC9dQA0OBmmyPKrZAk9 E285B9T9V5Wp7fiu34vqkbkl0MosIbftfFZAR5DGgbsa0vopwmmhE+nOJh+dJQaDoHXw xMcsOD3TLxviXgVkJB9aVptczt+//C/gJ0NLoTpAMVWeTd5IXbH4iE+a8DxtrMJa4ZKu Sq7fB0zxFk0Ai3Fd7Ch3hqB3qdtWnG34alomnVooMZfvg9BXzAcu5bHUHdYlyRwUPges PizQ== Received: by 10.60.12.99 with SMTP id x3mr17480467oeb.27.1351730128892; Wed, 31 Oct 2012 17:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Wed, 31 Oct 2012 17:35:07 -0700 (PDT) In-Reply-To: <5091907E.3090206@isi.edu> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> From: Lorenzo Colitti Date: Thu, 1 Nov 2012 09:35:07 +0900 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=e89a8ff256102a31a804cd643219 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnZVmbvzvH1TUC/t+xAdkqDsjZK+0kO3w7/fvUAIXi07BJhZULQixb5hS3YR6A/BAQFn1aIMkylQwAZBYWMvWYQ8AgXvNitvRC08Gwl49kN5yh98CL4PfbzyE3yjKkUKF2+y8GkYT4hDnKvaAdvWORi4vkfXXgML0J4oTZ6KtoDz88fi1fxW6LkwwF0f0C86Vp25iXu Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:35:30 -0000 --e89a8ff256102a31a804cd643219 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 1, 2012 at 5:56 AM, Joe Touch wrote: > I'm wondering whether routers that drop fragments do so only when that's > the first option, or do they just drop packets with *any* options? > Routers just do what operators configure them to do. Operators who want to have their routers do things like: - Attack (e.g., SYN flood) rate-limiting - Stateless ACL processing for security purposes - QoS classification - ... and so on configure their routers to look at upper-layer headers. If the routers cannot parse the extension header chain but only look at the next header value in the IPv6 header, then the operators have a choice: 1. Give up the above functionality. 2. Drop all packets with extension headers. It's not just the fragment header, it's all extension headers. The fragment header is just the most important one. In general: I'm not an expert, but I think the situation where processing an IPv6 packet may require 8 or 10 lookups, arbitrarily spaced within a 1500-byte packet, is not easy to implement in hardware. It doesn't work on today's architectures, and I suspect supporting it might increase the cost of forwarding hardware Supporting extension header chain parsing at anything other than wire speed exposes operators to a resource exhaustion attacks where attackers can increase load on routers (e.g., force packets to be software switched) simply by sending legitimate packets with lots of extension headers. So really it's not practical to say that you can simply provision / build for partial load since "packets with lots of extension headers are rare". --e89a8ff256102a31a804cd643219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu= , Nov 1, 2012 at 5:56 AM, Joe Touch <touch@isi.edu> wrote:
I'm wondering whether routers that drop = fragments do so only when that's the first option, or do they just drop= packets with *any* options?

Routers just do what operators configure t= hem to do.

Operators who want to have their router= s do things like:

- Attack (e.g., SYN flood) rate-= limiting
- Stateless ACL processing for security purposes
- QoS = classification
- ... and so on

con= figure their routers to look at upper-layer headers. If the routers cannot = parse the extension header chain but only look at the next header value in = the IPv6 header, then the operators have a choice:

1. Give up the above functionality.
2. Drop a= ll packets with extension headers.

It's not ju= st the fragment header, it's all extension headers. The fragment header= is just the most important one.

In general: I'm not an expert, but I think the situ= ation where processing an IPv6 packet may require 8 or 10 lookups, arbitrar= ily spaced within a 1500-byte packet, is not easy to implement in hardware.= It doesn't work on today's architectures, and I suspect supporting= it might increase the cost of forwarding hardware

Supporting extension header chain parsing at anything o= ther than wire speed exposes operators to a resource exhaustion attacks whe= re attackers can increase load on routers (e.g., force packets to be softwa= re switched) simply by sending legitimate packets with lots of extension he= aders. So really it's not practical to say that you can simply provisio= n / build for partial load since "packets with lots of extension heade= rs are rare".
--e89a8ff256102a31a804cd643219-- From touch@isi.edu Wed Oct 31 17:54:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946B021F8858 for ; Wed, 31 Oct 2012 17:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UETxdgFQ1zM8 for ; Wed, 31 Oct 2012 17:54:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1576021F867C for ; Wed, 31 Oct 2012 17:54:24 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qA10pJcb007782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 17:51:19 -0700 (PDT) Message-ID: <5091C787.6060403@isi.edu> Date: Wed, 31 Oct 2012 17:51:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:54:24 -0000 On 10/31/2012 5:35 PM, Lorenzo Colitti wrote: > On Thu, Nov 1, 2012 at 5:56 AM, Joe Touch > wrote: > > I'm wondering whether routers that drop fragments do so only when > that's the first option, or do they just drop packets with *any* > options? > > > Routers just do what operators configure them to do. Not everything; as you note below, some aspects of the configuration are limited by capability. However, you've answered the key issue - this is not about fragments, but rather about two things: a) DPI DPI cannot be done on packets with any options so this either means operators need to ignore DPI on such packets or drop them There are certainly places where DPI is expected (e.g., by a government), and so only DPI-capable packets are permitted, but this doesn't seem tenable anywhere except at the boundaries of customer networks (otherwise all encrypted traffic would be dropped all over the place, and that doesn't appear to be happening) b) support for ANY HBH options unfortunately, this is very difficult to determine unless fragmentation or a known destination option occurs I.e., there's no structure to the option numbers that makes it easy to say "there are no more HBH options", so the best that can be done here is, as you note, "drop all packets with any options". Again, however, that doesn't necessarily mean all remaining packets can be DPI processed. Joe From lorenzo@google.com Wed Oct 31 17:59:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BCF21F889B for ; Wed, 31 Oct 2012 17:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNlNy7E7MD0n for ; Wed, 31 Oct 2012 17:59:09 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF81721F86BE for ; Wed, 31 Oct 2012 17:59:08 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2223256oag.31 for ; Wed, 31 Oct 2012 17:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=I85GN4madcMhoKiO+NsI6JGTGVfdni1ijpbIqDJ/gjI=; b=EkOS4ApIP5U54NopZrq3dbmz0r1HSG3Y9TcuD163q2G8U5lv/vgRLtHXRs8TYBxRhV wyVtKJsWyykymHn8cI4QIuTupv/aYnTslFj14guOl0ZJt2R4nvCHrH4zPEfZSsdIwHbF M6bWdE+KvyyfZQoLTCUt/thAkx8JuspdAGuiRvJXz7mMpO8ODOymEJhoaY/E6ALA4mgo /gfZmFicVoWaHcN1H8rXbs8BMul/VLJwcHkTzRJDW0YdmAptF6CU9Zeje5cudDjaWpLz Je043Gv6mbIJd12YMiJ9wsUXDIkUnq5NSs6Gmhxo2jUDUG+L6oA+sb8WKH/Ov8LluR9r ubww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=I85GN4madcMhoKiO+NsI6JGTGVfdni1ijpbIqDJ/gjI=; b=IffJyuvqMUwErLlljeJvY/1BS2NuU49wO4B0tOpRJnY5yX0d91xDH5qUcbELFzm/5U WbPXsTvDYDr5+mZJ8Nts1E4Ys5MJlmbNorSphhi5bBQabzBjgU0DVFnf+6ZSRJkMVQkx zGgZxUfz7DovVw4oYA+n6gLL8KqKOYBJZmGtTW25kC+fJywpYmfm452KhPo2N2J8w8+l EhMeMmVBLCyko5qNCd3+JTwhVGAi0xN/YcwWLPB2AyZK00CwAR6TBk6UFsUyo8kYgBC/ cLydSBu0QzCnMsZCHKbxLH8LL7F7F2Z2ZdYv2rKHfjroa2sgI+3GS7nmPI1zGhZbjwT0 2njg== Received: by 10.182.188.36 with SMTP id fx4mr7749475obc.6.1351731548466; Wed, 31 Oct 2012 17:59:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Wed, 31 Oct 2012 17:58:48 -0700 (PDT) In-Reply-To: <5091C787.6060403@isi.edu> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DA6A3.20807@inex.ie> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> <5091C787.6060403@isi.edu> From: Lorenzo Colitti Date: Thu, 1 Nov 2012 09:58:48 +0900 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=f46d04463168c72fdc04cd648615 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkGgEBEktzyf4hDZI45RvXsUcFoQ0EOzYtHqwiCm8jcVdXfHLOjAscqxeRE8TgB04RTmUG+lk/pNzE5dZDn6e9kOL6elV+wj7kUF/8oaEQPEPolqfl53gPL2x0dYWtpbkYJohiZdfdRa1XegjeD9+WxSZsvKuFPpxTVTbl0k95cYnCwzT9PJYvYmA3CgGZiQx7DwfDl Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:59:09 -0000 --f46d04463168c72fdc04cd648615 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 1, 2012 at 9:51 AM, Joe Touch wrote: > However, you've answered the key issue - this is not about fragments, but > rather about two things: > > a) DPI > DPI cannot be done on packets with any options > so this either means operators need to ignore DPI > on such packets or drop them > I don't think we should use the term DPI, because we don't really have consensus on what it means. I suspect some would assert that just looking at layer 4 headers is not DPI and that it's only DPI if you look into layer 4 payloads as well. > There are certainly places where DPI is expected (e.g., by a government), > and so only DPI-capable packets are permitted, but this doesn't seem > tenable anywhere except at the boundaries of customer networks (otherwise > all encrypted traffic would be dropped all over the place, and that doesn't > appear to be happening) > ... and saying that looking at layer 4 headers is "DPI" will also lead to this kind of confusion. --f46d04463168c72fdc04cd648615 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu= , Nov 1, 2012 at 9:51 AM, Joe Touch <touch@isi.edu> wrote:
However, you've answer= ed the key issue - this is not about fragments, but rather about two things= :

a) DPI
=A0 =A0 =A0 =A0 DPI cannot be done on packets with any options
=A0 =A0 =A0 =A0 so this either means operators need to ignore DPI
=A0 =A0 =A0 =A0 on such packets or drop them

I don't think we should use the term DPI, because we don't re= ally have consensus on what it means. I suspect some would assert that just= looking at layer 4 headers is not DPI and that it's only DPI if you lo= ok into layer 4 payloads as well.
=A0
There are certainly places whe= re DPI is expected (e.g., by a government), and so only DPI-capable packets= are permitted, but this doesn't seem tenable anywhere except at the bo= undaries of customer networks (otherwise all encrypted traffic would be dro= pped all over the place, and that doesn't appear to be happening)

... and saying that looking at layer 4 hea= ders is "DPI" will also lead to this kind of confusion.
--f46d04463168c72fdc04cd648615-- From mawatari@jpix.ad.jp Wed Oct 31 18:26:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024A21F88E6 for ; Wed, 31 Oct 2012 18:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mclJ+QID8m7n for ; Wed, 31 Oct 2012 18:26:03 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0820121F86BE for ; Wed, 31 Oct 2012 18:26:02 -0700 (PDT) Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 33B38FC040; Thu, 1 Nov 2012 10:26:01 +0900 (JST) Date: Thu, 01 Nov 2012 10:26:01 +0900 From: MAWATARI Masataka To: markzzzsmith@yahoo.com.au In-Reply-To: <1351671270.212.YahooMailNeo@web32508.mail.mud.yahoo.com> References: <20121031142605.94F5.8FE1F57E@jpix.ad.jp> <1351671270.212.YahooMailNeo@web32508.mail.mud.yahoo.com> Message-Id: <20121101102600.8DF1.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: draft-gont-v6ops-slaac-issues-with-duplicate-macs@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 01:26:03 -0000 Hi Mark-san, If MAC address duplication occured on IX segment, both of IPv4 and IPv6 would been destroyed. I think that IX people do not have the definitive solution when it happens. First of all they will inquire of router vendors. It will not be technical solution depending on the cause. Kind Regards, Masataka MAWATARI * On Wed, 31 Oct 2012 01:14:30 -0700 (PDT) * Mark Smith wrote: > Hi, > > > ----- Original Message ----- > > From: MAWATARI Masataka > > To: v6ops@ietf.org > > Cc: draft-gont-v6ops-slaac-issues-with-duplicate-macs@tools.ietf.org > > Sent: Wednesday, 31 October 2012 4:26 PM > > Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs > > > >G reetings, > > > > > > I have read through your document. > > > > Layer 2 IXs are dealing with same issues on IPv6 IX segment. > > > > In regard to link local address, both manual configuration routers > > and auto configuration (SLAAC) routers are connecting into one > > ethernet fabric of IX.? Fortunately duplication do not occur so far. > >? > > How are the IX going to resolve the layer 2 address duplication causing > > layer 2 unicast to fail? MAC forced forwarding or something similar? > > > This document might be worthwhile subject for IPv6 IX. > > > > > > > Kind Regards, > > Masataka MAWATARI