From carlosm3011@gmail.com Fri Apr 1 00:57:01 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEE328C103 for ; Fri, 1 Apr 2011 00:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePZVEAHtHGsD for ; Fri, 1 Apr 2011 00:56:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8247528C0EE for ; Fri, 1 Apr 2011 00:56:43 -0700 (PDT) Received: by iwn39 with SMTP id 39so3740523iwn.31 for ; Fri, 01 Apr 2011 00:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=skRADLSo1ZjaUj89j/MJa1HTzaXggDDJtXydf0HK720=; b=QoWkbXorizik+dZYJlIQYObfaWhnJyJMLrTzjL3vr6P/78y2GAb2u+bTGKOPF6ygo/ Q+fOSciWbCAlfSAA+OYVcempeYq0opOOCI5nwMcb+6AIJLb9CylbeesKzXo8IAX/QUIw KCQR+vYBfF226v7QBgrcgaQdvPdkB7dzGYoSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=VBUmBoSwZZzHB47QDpOwoOTmZ5yU3+IygRiRPBv3O8mqPvDI+TPdvI9j7Scw6idmFn MSzk+yWzPNn4fE6vyaq1P1ibzxJFUzzvY1PMiF+mYBF5G3x7CtTKB0RWSkQHMJTe+8Vn uTPwNBiT2gzOZVAocLG4+8T594IgpsnNLaTbE= MIME-Version: 1.0 Received: by 10.43.53.133 with SMTP id vq5mr4262753icb.527.1301644703410; Fri, 01 Apr 2011 00:58:23 -0700 (PDT) Received: by 10.42.211.10 with HTTP; Fri, 1 Apr 2011 00:58:23 -0700 (PDT) In-Reply-To: <4D9361F8.60203@gont.com.ar> References: <4D9361F8.60203@gont.com.ar> Date: Fri, 1 Apr 2011 07:58:23 +0000 Message-ID: Subject: Re: draft-gont-6man-managing-privacy-extensions From: Carlos Martinez-Cagnazzo To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlos@lacnic.net List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:57:01 -0000 Hi all, I do agree with Fernando that we need to be more clear on the trust models that we apply ( I don't think this is an issue only on 6man, it's a general thing ). If we distrust some network element, then we distrust it for *any* purpose, not just for this or that bit. In this particular case, if we distrust the router we need to consider that a rogue router could do well, almost anything, including just capturing all your packets and uploading them to some place. I'm not saying that concerns on trust boundaries should then be dismissed, but rather than we need to be more strict about them. We trust the network element or we don't, we can't trust it for some features but not for others. regards Carlos On Wed, Mar 30, 2011 at 5:01 PM, Fernando Gont wrote: > Folks, > > At the 6man wg meeting, the aforementioned I-D was deemed "as a very bad > idea", because of its privacy implications. > > My question is: what's the trust model that leads to that conclusion? > > I mean, a host doing SLAAC trusts the router about the prefix to be > configured, default route, various network parameters (Hop Count, MTU, > etc.), recursive DNS resolver, etc. > > Why do folks consider that for some of this information, the router is > to be trusted, while for other (the SAG bits that our I-D specifies) > shouldn't? > > That aside, if a router is deemed as possibly malicious, even without > the SAG bits it could claim that DHCPv6 is needed, and then have the > DHCP server lease an address that embeds the source link-layer address > of the DHCPv6 request... > > *And*, as noted in the upcoming version that I had posted, the final > decision on which policy to apply is on de hands of the host (and not > the router). > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From alexandru.petrescu@gmail.com Fri Apr 1 03:16:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6513A67E9 for ; Fri, 1 Apr 2011 03:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9awzyl7xlsw for ; Fri, 1 Apr 2011 03:16:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0C8653A67CF for ; Fri, 1 Apr 2011 03:16:07 -0700 (PDT) Received: by bwz13 with SMTP id 13so2610191bwz.31 for ; Fri, 01 Apr 2011 03:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uZj+F4N3k+C+isS5ffRdY65lqNLMymaVF5hRyiOCw/w=; b=Fj9j4TNH9oSVLDjASkIC/oGu/zYFeGHq8rYu6/77v4Fe0tSnEyWOaSVxFdJx4BoMFv BcqtPt+vRhw8g9f6CEBVc/2ET/jug790fdTrEahy4URJOMGuvUQFlCzPRpMzm1AI1U63 BSb9euuTWs6isy2WhtU3JCUxtXowUOfHIKWu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iNscavVbvQDaRLgLuKoGi2gu7TjzNmLoVFiMgtVl9iobAtyDW9NkEmkUihxl6Om1X9 VCT15/ONjCUf74A+3GHN6gF1V7Eo0KXP/H1Xqx5r7Hth5aDDXolRmtxnU6b6ZBq92r+4 AFiDc4dYxxPUM+XxGGSIF9BiJSZe5Itu7J18c= Received: by 10.204.134.207 with SMTP id k15mr706673bkt.135.1301653067012; Fri, 01 Apr 2011 03:17:47 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id l1sm1291137bkl.13.2011.04.01.03.17.44 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 03:17:45 -0700 (PDT) Message-ID: <4D95A646.1050105@gmail.com> Date: Fri, 01 Apr 2011 12:17:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hesham Soliman Subject: Re: Vehicle's VIN in IPv6. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Scott Brim , George Michaelson , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:16:09 -0000 Le 01/04/2011 01:29, Hesham Soliman a écrit : >> >> >> >> I don't think "go away" is the right answer. I think "your model >> has flaws" is closer. >> >> The key message is that if they apply for patents in it (BMW) they >> clearly see dollar-signs and its very hard to trump money. > > => I don't think it's as organised as you might think. People apply > for patents all the time for a wide range of reasons and they don't > necessarily reflect dollar signs. > > We've seen people from ITU suggest we embed IPv6 addresses in phone > numbers ....etc before. The same type of education about > locator/application identifier separation is needed here. Right... makes me think upper layer suggestions can be made too. E.g. if VIN is something like a service (like uCode microcode like barcodes EPC), or like a printer name, then there may exist ways to map VIN into a DNS record(?), and let the resolver map that service into an appropriate IPv6 address. Or an URI(?). I am not quite sure about my terminology here. Is a car seen more like something providing web services. I need to understand the problem better before discarding this VIN request. Alex > > Hesham > >> >> >> -G >> -------------------------------------------------------------------- >> >> >> IETF >> IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > > >> -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From huitema@microsoft.com Fri Apr 1 14:51:18 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9023A6991 for ; Fri, 1 Apr 2011 14:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQPPeI74nNbx for ; Fri, 1 Apr 2011 14:51:16 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D97963A6981 for ; Fri, 1 Apr 2011 14:51:16 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Apr 2011 14:52:51 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 1 Apr 2011 14:52:51 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.185]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 14:52:50 -0700 From: Christian Huitema To: "carlos@lacnic.net" , Fernando Gont Subject: RE: draft-gont-6man-managing-privacy-extensions Thread-Topic: draft-gont-6man-managing-privacy-extensions Thread-Index: AQHL7v4pNFfXosTXMEm4VX/hGfn7FpRJHIGAgAByliA= Date: Fri, 1 Apr 2011 21:52:50 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F0EE600@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <4D9361F8.60203@gont.com.ar> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:51:19 -0000 We trust the router to transmit packets. We have to, otherwise we would not= get connectivity. We can actually verify that by observing that packets ar= e received by peers on the other side of the network. Depending on our leve= l of paranoia, we can use various levels of end-to-end encryption to verify= that we are indeed speaking to the right peer. We can elect to stop attemp= ting to send packets through a particular router if we are not getting the = forwarding service. Configuring the prefixes is very linked to the routing function, so we can = trust a router when it tells us that he will serve a particular prefix. Aga= in, we can verify that using that prefix provides end-to-end connectivity. Trusting the router to transmit packets does not mean trusting the router f= orm something else, like configuring my security posture.=20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Car= los Martinez-Cagnazzo Sent: Friday, April 01, 2011 12:58 AM To: Fernando Gont Cc: ipv6@ietf.org Subject: Re: draft-gont-6man-managing-privacy-extensions Hi all, I do agree with Fernando that we need to be more clear on the trust models = that we apply ( I don't think this is an issue only on 6man, it's a general= thing ). If we distrust some network element, then we distrust it for *any* purpose,= not just for this or that bit. In this particular case, if we distrust the= router we need to consider that a rogue router could do well, almost anyth= ing, including just capturing all your packets and uploading them to some p= lace. I'm not saying that concerns on trust boundaries should then be dismissed, = but rather than we need to be more strict about them. We trust the network = element or we don't, we can't trust it for some features but not for others= . regards Carlos On Wed, Mar 30, 2011 at 5:01 PM, Fernando Gont wrote= : > Folks, > > At the 6man wg meeting, the aforementioned I-D was deemed "as a very=20 > bad idea", because of its privacy implications. > > My question is: what's the trust model that leads to that conclusion? > > I mean, a host doing SLAAC trusts the router about the prefix to be=20 > configured, default route, various network parameters (Hop Count, MTU,=20 > etc.), recursive DNS resolver, etc. > > Why do folks consider that for some of this information, the router is=20 > to be trusted, while for other (the SAG bits that our I-D specifies)=20 > shouldn't? > > That aside, if a router is deemed as possibly malicious, even without=20 > the SAG bits it could claim that DHCPv6 is needed, and then have the=20 > DHCP server lease an address that embeds the source link-layer address=20 > of the DHCPv6 request... > > *And*, as noted in the upcoming version that I had posted, the final=20 > decision on which policy to apply is on de hands of the host (and not=20 > the router). > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809=20 > 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From alexandru.petrescu@gmail.com Sat Apr 2 07:10:19 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17A13A6821; Sat, 2 Apr 2011 07:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeTZPV3Svq3u; Sat, 2 Apr 2011 07:10:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id AEAFB3A681F; Sat, 2 Apr 2011 07:10:13 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id DB93A9400D0; Sat, 2 Apr 2011 16:11:46 +0200 (CEST) Message-ID: <4D972EA0.8030401@gmail.com> Date: Sat, 02 Apr 2011 16:11:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Haberman Subject: Re: Request To Advance: References: <4D934844.1090106@innovationslab.net> In-Reply-To: <4D934844.1090106@innovationslab.net> Content-Type: multipart/mixed; boundary="------------030508030604010700040401" X-Antivirus: avast! (VPS 110402-0, 02/04/2011), Outbound message X-Antivirus-Status: Clean Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man-ads@tools.ietf.org, IPv6 WG Mailing List , ROLL WG , Robert Cragie , iesg-secretary@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 14:10:19 -0000 This is a multi-part message in MIME format. --------------030508030604010700040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit [if needed I can trim the To/Cc, I just dont know] Hello Brian, Chairs, ADs, 6man, roll, This draft-ietf-6man-rpl-routing-header-03 is way too brief about the security risks of RPL RH. It basically states that this RPL RH is not risky when looked at from the outside, and does not seem to talk about risks from within RPL network. This perspective contradicts the RPL draft which says "[RPL networks] are vulnerable to passive eavesdropping attacks [and more]". This RPL RH is intended to be used with RPL protocol. RPL's draft security text states that AH and message auth code should be used over the entire IPv6 headers; hence over this RPL RH as well. However, there is no example of how to do it. Whereas it is known how to apply AH over Routing Header Type 0 (some advice in RFC4302). For RPL RH, we had an agreeing discussion on the RoLL WG email list September 10th, 2010, about a step-by-step description of using AH over RPL RH. See the first attached email and url: http://www.ietf.org/mail-archive/web/roll/current/msg05418.html My agreement to that discussion is ok, but does not show in these archives I dont know why, but I attached it as well to this email. I suggest inserting that example of using AH over RPL RH into the RPL RH draft. Maybe as an appendix, as an example. I find it very useful to implementer. (note: I do not know whether Robert Cragie who wrote that proposal on the mailing list agrees or even needs to insert it in the draft). Thank you for considering this issue, and I will follow this issue, Alex Le 30/03/2011 17:12, Brian Haberman a écrit : > Jari& Ralph, On behalf of the 6MAN WG, the chairs request the > advancement of: > > Title : An IPv6 Routing Header for Source Routes with RPL > Author(s) : J. Hui, et al. Filename : > draft-ietf-6man-rpl-routing-header-03.txt Pages : 19 Date : > 2011-03-29 > > as a Proposed Standard. A 6MAN WG Last Call ended on December 6, > 2010 and this version addresses all comments raised. > > Regards, Brian& Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --------------030508030604010700040401 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com Received: from zimbra31-e6.priv.proxad.net (LHLO zimbra31-e6.priv.proxad.net) (172.20.243.181) by zimbra31-e6.priv.proxad.net with LMTP; Fri, 10 Sep 2010 18:51:27 +0200 (CEST) Received: from relay4-v.mail.gandi.net (mx23-g26.priv.proxad.net [172.20.243.93]) by zimbra31-e6.priv.proxad.net (Postfix) with ESMTP id 247651255D7 for ; Fri, 10 Sep 2010 18:48:15 +0200 (CEST) Received: from relay4-v.mail.gandi.net ([217.70.178.78]) by mx1-g20.free.fr (MXproxy) for alexandru.petrescu@free.fr ; Fri, 10 Sep 2010 18:48:15 +0200 (CEST) X-ProXaD-SC: state=HAM score=0 X-Originating-IP: 10.0.21.73 Received: from spool.mail.gandi.net (mspool3-v.mgt.gandi.net [10.0.21.73]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id 010D2BA7F; Fri, 10 Sep 2010 18:48:15 +0200 (CEST) Received: from mfilter4-v.gandi.net (mfilter4-v.gandi.net [217.70.178.38]) by spool.mail.gandi.net (Postfix) with ESMTP id AA47B1B4068; Fri, 10 Sep 2010 18:48:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter4-v.gandi.net Received: from spool.mail.gandi.net ([10.0.21.73]) by mfilter4-v.gandi.net (mfilter4-v.gandi.net [217.70.178.38]) (amavisd-new, port 10024) with ESMTP id G7BztIKZ9ffv; Fri, 10 Sep 2010 18:48:11 +0200 (CEST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by spool.mail.gandi.net (Postfix) with ESMTP id 32BAF1B4060 for ; Fri, 10 Sep 2010 18:48:10 +0200 (CEST) Received: by bwz20 with SMTP id 20so3317779bwz.27 for ; Fri, 10 Sep 2010 09:48:10 -0700 (PDT) Received: by 10.204.48.75 with SMTP id q11mr750192bkf.0.1284137290444; Fri, 10 Sep 2010 09:48:10 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.204.51.82 with SMTP id c18cs21786bkg; Fri, 10 Sep 2010 09:48:10 -0700 (PDT) Received: by 10.227.147.211 with SMTP id m19mr83585wbv.200.1284137286743; Fri, 10 Sep 2010 09:48:06 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by mx.google.com with ESMTP id k29si3455389wbb.65.2010.09.10.09.48.06; Fri, 10 Sep 2010 09:48:06 -0700 (PDT) Received-SPF: neutral (google.com: 79.170.40.78 is neither permitted nor denied by best guess record for domain of robert.cragie@gridmerge.com) client-ip=79.170.40.78; Authentication-Results: mx.google.com; spf=neutral (google.com: 79.170.40.78 is neither permitted nor denied by best guess record for domain of robert.cragie@gridmerge.com) smtp.mail=robert.cragie@gridmerge.com Received: from client-86-23-76-166.brhm.adsl.virginmedia.com ([86.23.76.166] helo=[192.168.1.72]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Ou6lh-0005Oe-0K; Fri, 10 Sep 2010 17:48:06 +0100 Message-ID: <4C8A6144.1070401@gridmerge.com> Date: Fri, 10 Sep 2010 17:48:04 +0100 From: Robert Cragie Reply-To: robert.cragie@gridmerge.com Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexandru Petrescu CC: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit References: <13773.1282327971@marajade.sandelman.ca> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> In-Reply-To: <4C8A4D19.40202@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040403030608070304050109" X-Antivirus: avast! (VPS 100910-1, 10/09/2010), Inbound message X-Antivirus-Status: Clean This is a cryptographically signed message in MIME format. --------------ms040403030608070304050109 Content-Type: multipart/alternative; boundary="------------070303040201040809040700" This is a multi-part message in MIME format. --------------070303040201040809040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alex, Thank you for focusing on a pertinent issue. You are right to highlight=20 what we do with a RH4 header as I believe secured DAO ACK is the (only)=20 RPL control message which requires RH4 in non-storing mode. So, to follow the rules for mutable and predictable fields (see RFC=20 4302), we can resubstitute at the end: Consider the following: A -> B -> C -> D -> E A -> B: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | B | 3 | C | D | E | B -> C: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | C | 2 | B | D | E | C -> D: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | D | 1 | B | C | E | D -> E: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | E | 0 | B | C | D | When the packet arrives at E, recreate the original RH4 header for MAC=20 computation: n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp) tmp =3D Dst Dst =3D RH4.A[0] RH4.Seq =3D n for (k =3D 1; k < n; k++) { RH4.A[k-1] =3D RH4.A[k] } RH4.A[k] =3D tmp |Src|Dst|RH4 | | | |Seq|L0 |L1 |L2 | ------------------------- | A | B | 3 | C | D | E | Is that acceptable? Now, just because I refer to IPSec AH, it doesn't mean I am suggesting=20 we use it. I am suggesting we can use the fundamental principles from=20 IPSec for an equivalent operation. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: > Le 10/09/2010 11:55, Robert Cragie a =E9crit : >> David, >> >> I totally agree with what you say. Thank you for restating generally >> that IPSec has already been extensively considered - I use the term >> 'paraphernalia' as a general term for the overheads. >> >> Alex - can we please drop the IPSec discussion and move on and >> concentrate on the things which do need to sorted out? > > Ok... let me try to avoid dissent and do what you ask. > > Let's come back to RPL-11 text: >> 3. If the packet header specifies a source route by including a RH4 >> header as specified in [I-D.ietf-6man-rpl-routing-header] > > then draft-ietf-6man-rpl-routing-header-00 says: >> else { swap the IPv6 Destination Address and Address[i] > > That means that there is a mutable but predictable field (IPv6 > Destination Addess) in RH of RPL. But RPL Security doesn't understand > mutable but predictable fields (only mutable as per recent discussion).= > RPL Security covers "entire IPv6 packet", which changes enroute despit= e > RPL Security's expectation it won't change. > > So the question is: does RPL Security secure the RH4 header? I think i= t > does not, because its MAC computation does not say how are the mutable > but predictable fields covered. > > For example, a sender builds a packet with Dst address1, computes MAC, > inserts MAC. Then intermediary routers process that packet and replace= > that Dst address1 with address2 from the Routing Header. Now the packe= t > is received at address1. The MAC can't be meaningfully computed on the= > receiver, because the "IPv6 entire packet" has changed, it is not the > same as at emission. > > I think this example is correct. > > It can't be solved in the same way we solved the mutability of "Hop > Limit" (we said to make HopLimit set to 0 for MAC calculation), because= > if we do so then we have a higher risk of attack than when left HopLimi= t > unsecure. If we set to 0 de Dst for MAC calculation then the risk of > implication of forged IP dst addresses is higher than forged HopLimit. > Forging an IP dst address is stronger security attack than forging > HopLimit, intuitively speaking. > > Besides, whereas the receiver has really no idea about what could the > original HopLimit be, it knows precisely what the original Dst address > was (it's in the RH4, swapped). Thus the securing solution should be > different - it should be as smart as RH4 is. > > Knowing the previous discussion, it may be possible that people will > request we refer to that Authentication Header RFC which tells how > mutable, mutable but predictable fields are dealt with. At that point > we come back to IPsec, but I will abstain from saying so if you wish. > There is also the fact that previous IPsec talk says RH0 whereas here w= e > have RH4 and things may be different. > > That's too long for anyone to read, but you get the point. > > Alex > > > > > You are of course >> entitled to your opinion but progress is only made in the IETF >> through rough consensus. Consensus does not mean unanimous agreement; >> if we can all at least consent to a solution then the process will >> run a lot more smoothly and we will all benefit. Continual dissent >> will only serve to hinder this progress. >> >> I think the consensus is clear: >> >> * We do not mention IPSec in RPL security * The mutable field >> discussion is entirely independent from IPSec >> >> Robert >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >> >> >> >> On 09/09/2010 9:33 PM, David Culler wrote: >>> Dear Alex, Thank you for focusing on the question of routing >>> security, rather than internet security in general. Yes, IPSec has >>> been utilized to secure routing protocols. Now please take the >>> next step and focus on routing for low power and lossy networks. >>> Obviously, IPSec has to be the first thing considered. And it was. >>> Dating back to the earliest security framework discussions it was >>> considered many times. We returned to the IPSec issue extensively >>> back in June on the mailing list. I won't reiterate the >>> discussion on the storage and time complexity, nor the message >>> overhead implications that were in those prior postings. But I >>> will observe that no one suggested that they saw their way to a >>> full IPSec implementation within the constraints articulated in the >>> Routing Requirements documents. The WG group has long since >>> reached a rough consensus on this matter and moved on. That is the >>> nature of a group process and specifically the role of WG LC. At >>> some point, we commit to certain things and stop revisiting them >>> from first principles. That allows us to focus more sharply on >>> the selected approach and refine it more completely. For example, >>> in security, we have specifics to resolve, such as which header >>> fields need to be skipped. It is not a matter of "but I imagine >>> that there may be alternatives". There might be. But we don't >>> just turn the same rocks over and over again. We carve the rough >>> stone, we chisel the details, we sand, we polish. >>> >>> So I assume that the point of your posting is that you want to be >>> sure that the justification for the choices that the WG made are >>> properly documented in the WG documents. If you feel that they are >>> not, perhaps you could point to the document and section that you >>> feel should contain this material more substantially. >>> >>> D. >>> >>> For reference,http://www.ietf.org/tao.html section 7.4 >>> >>> >>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>> >>>> Le 09/09/2010 16:59, David Culler a=E9crit : >>>>> The RPL charter calls for us to address routing security >>>>> considerations. Not security in general. Not application >>>>> security. Not link level. Routing security. It is focused for >>>>> good reason. >>>> Routing security like OSPF using IPsec? "Authentication has been >>>> removed from the OSPF protocol and instead relies on IPv6's >>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>> says rfc5340... why does RPL need to be different in this >>>> respect? >>>> >>>> Alex >>>> >>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 08/09/2010 18:15, Philip Levis a=E9crit : >>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>> >>>>>>>> Le 03/09/2010 13:48, Robert Cragie a=E9crit : [skipped >>>>>>>> agreed opinions about IPsec] >>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>> ok so why avoid using it. >>>>>>>>> I don't think the specification of RPL security >>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>> specification? >>>>>>>> YEs, the RPL specification must say something about >>>>>>>> security in its Security Considerations section. That >>>>>>>> something has to mention something about IPsec. >>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>> entirely independent of IPSec. There have already been >>>>>>> numerous discussions about why simply relying on IPSec >>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>> these points every few weeks and rehash the same >>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>> time. >>>>>> Phil - if RPL says "security" then it must understand that >>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>> the design (mutable fields, etc.) >>>>>> >>>>>> Have you checked the mutable field discussion? Do you agree >>>>>> that mutable fields must be taken into account? >>>>>> >>>>>> Please read that around 3 people agreed on a list of items >>>>>> which are worth discussion of security and IPsec - mutable >>>>>> fields is one such item. >>>>>> >>>>>> As such this discussion is not a waste of everyone's time. >>>>>> >>>>>> Alex >>>>>> >>>>>>> Phil >>>>>> >>>>>> _______________________________________________ Roll mailing >>>>>> list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>> Associate Chair EECS >>>>> >>>>> >>>>> >>>>> >>>> >>> David Culler culler@cs.berkeley.edu Chair Computer Science >>> Associate Chair EECS >>> >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------070303040201040809040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight what we do with a RH4 header as I believe secured DAO ACK is the (only) RPL control message which requires RH4 in non-storing mode.

So, to follow the rules for mutable and predictable fields (see RFC 4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | B | 3 | C | D | E |
B -> C:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | C | 2 | B | D | E |
C -> D:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | D | 1 | B | C | E |
D -> E:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | E | 0 | B | C | D |
When the packet arrives at E, recreate the original RH4 header for MAC computation:

n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp =3D Dst
Dst =3D RH4.A[0]
RH4.Seq =3D n
for (k =3D 1; k < n; k++)
{
  RH4.A[k-1] =3D RH4.A[k]
}
RH4.A[k] =3D tmp

|Src|Dst|RH4         = ;   |
|   |   |Seq|L0 |L1 |L2 |
-------------------------
 | A | B | 3 | C | D | E |
Is that acceptable?

Now, just because I refer to IPSec AH, it doesn't mean I am suggesting we use it. I am suggesting we can use the fundamental principles from IPSec for an equivalent operation.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
Le 10/09/2010 11:55, Robert Cragie a écrit :
David,

I totally agree with what you say. Thank you for restating generally
 that IPSec has already been extensively considered - I use = the term
 'paraphernalia' as a general term for the overheads.

Alex - can we please drop the IPSec discussion and move on and
concentrate on the things which do need to sorted out?

Ok... let me try to avoid dissent and do what you ask.

Let's come back to RPL-11 text:
3.  If the packet header specifies a= source route by including a RH4
header as specified in [I-D.ietf-6man-rpl-routing-header]

then draft-ietf-6man-rpl-routing-header-00 says:
else { swap the IPv6 Destination Address and Address[i]

That means that there is a mutable but predictable field (IPv6
Destination Addess) in RH of RPL.  But RPL Security doesn't understand
mutable but predictable fields (only mutable as per recent discussion).
 RPL Security covers "entire IPv6 packet", which changes enrou= te despite
RPL Security's expectation it won't change.

So the question is: does RPL Security secure the RH4 header?  = I think it
does not, because its MAC computation does not say how are the mutable
but predictable fields covered.

For example, a sender builds a packet with Dst address1, computes MAC,
inserts MAC.  Then intermediary routers process that packet an= d replace
that Dst address1 with address2 from the Routing Header.  Now = the packet
is received at address1.  The MAC can't be meaningfully comput= ed on the
receiver, because the "IPv6 entire packet" has changed, it is not the
same as at emission.

I think this example is correct.

It can't be solved in the same way we solved the mutability of "Hop
Limit" (we said to make HopLimit set to 0 for MAC calculation), because
if we do so then we have a higher risk of attack than when left HopLimit
unsecure.  If we set to 0 de Dst for MAC calculation then the = risk of
implication of forged IP dst addresses is higher than forged HopLimit.
Forging an IP dst address is stronger security attack than forging
HopLimit, intuitively speaking.

Besides, whereas the receiver has really no idea about what could the
original HopLimit be, it knows precisely what the original Dst address
was (it's in the RH4, swapped).  Thus the securing solution sh= ould be
different - it should be as smart as RH4 is.

Knowing the previous discussion, it may be possible that people will
request we refer to that Authentication Header RFC which tells how
mutable, mutable but predictable fields are dealt with.  At th= at point
we come back to IPsec, but I will abstain from saying so if you wish.
There is also the fact that previous IPsec talk says RH0 whereas here we
have RH4 and things may be different.

That's too long for anyone to read, but you get the point.

Alex




 You are of course
entitled to your opinion but progress is only made in the IETF
through rough consensus. Consensus does not mean unanimous agreement;
if we can all at least consent to a solution then the process will
run a lot more smoothly and we will all benefit. Continual dissent
will only serve to hinder this progress.

I think the consensus is clear:

* We do not mention IPSec in RPL security * The mutable field
discussion is entirely independent from IPSec

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44
1924 910888 +1 415 513 0064 http://www.gridmerge.com
<http://www.gridmerge.com/>


On 09/09/2010 9:33 PM, David Culler wrote:
Dear Alex, Thank you for focusing on th= e question of routing
security, rather than internet security in general.  Yes, IPSec has
been utilized to secure routing protocols.  Now please tak= e the
next step and focus on routing for low power and lossy networks.
Obviously, IPSec has to be the first thing considered.  An= d it was.
Dating back to the earliest security framework discussions it was
considered many times.   We returned to the IPSec iss= ue extensively
back in June on the mailing list.   I won't reiterate= the
discussion on the storage and time complexity, nor the message
overhead implications that were in those prior postings.  = But I
will observe that no one suggested that they saw their way to a
full IPSec implementation within the constraints articulated in the
Routing Requirements documents.   The WG group has lo= ng since
reached a rough consensus on this matter and moved on.  Th= at is the
nature of a group process and specifically the role of WG LC.&n= bsp; At
some point, we commit to certain things and stop revisiting them
from first principles.   That allows us to focus more= sharply on
the selected approach and refine it more completely.  For example,
in security, we have specifics to resolve, such as which header
fields need to be skipped.  It is not a matter of "but I imagine
that there may be alternatives".  There might be.  Bu= t we don't
just turn the same rocks over and over again.  We carve th= e rough
stone, we chisel the details, we sand, we polish.

So I assume that the point of your posting is that you want to be
sure that the justification for the choices that the WG made are
properly documented in the WG documents.  If you feel that= they are
not, perhaps you could point to the document and section that you
feel should contain this material more substantially.

D.

For reference,http://www.ietf.org/tao.html  section 7.= 4


On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:

Le 09/09/2010 16:59, David Culler aécrit :
The RPL charter calls for us to address routing security
considerations.  Not security in general.  Not ap= plication
security. Not link level.  Routing security.  It = is focused for
good reason.
Routing security like OSPF using IPsec? "Authentication has been
removed from the OSPF protocol and instead relies on IPv6's
Authentication Header and Encapsulating Security Payload (ESP)."
says rfc5340... why does RPL need to be different in this
respect?

Alex

On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:

Le 08/09/2010 18:15, Philip Levis= aécrit :
On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:

Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
agreed opinions about IPsec]
Reusing the IPsec module ensures a secure system -
it's proven by earlier experience. We know it worked
ok so why avoid using it.
<RCC>I don't think the specification of RPL security
precludes the use of IPSec instead. Does the use of
IPSec need to be specified in the RPL
specification?</RCC>
YEs, the RPL specification must say something about
security in its Security Considerations section. = ; That
something has to mention something about IPsec.
Why does it have to do so? In theory, RPL should be
entirely independent of IPSec. There have already been
numerous discussions about why simply relying on IPSec
would be problematic. Unfortunately you seem to forget
these points every few weeks and rehash the same
discussion. At some point it becomes a waste of everyone's
time.
Phil - if RPL says "security" then it must understand that
Internet security is usually IPsec.  This is truer w= ith IPv6
(as opposed to IPv4) where IPsec is very much integrated in
the design (mutable fields, etc.)

Have you checked the mutable field discussion?  Do y= ou agree
that mutable fields must be taken into account?

Please read that around 3 people agreed on a list of items
which are worth discussion of security and IPsec - mutable
fields is one such item.

As such this discussion is not a waste of everyone's time.

Alex

Phil

_______________________________________________ Roll mailing
list Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= /a>
David Cullerculler@cs.berkeley.edu  Chai= r Computer Science
Associate Chair EECS





David Culler culler@cs.berkeley.edu Chair Computer Scie= nce
Associate Chair EECS



_______________________________________________ Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listinf= o/roll



_______________________________________________ Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listinfo/= roll


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--------------070303040201040809040700-- --------------ms040403030608070304050109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTEwMTY0ODA0WjAjBgkqhkiG9w0BCQQxFgQUTdtE PCVAAP81UIbq1+ioPsG25dwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAC0QjFHwszqO8++MWHvM1P+zw9EMMnMNiCyMR OSx0AXP7EhwkjsNKwAe9EoSbGqlYCEZNpMx4SnThqikSmVQM72OoaBPA/TA+ShC9rxs7z0zN NOhwyRevhOoh0K6KCz0FUj9MCyTi/MmkuDW8AlvRh6YxMxCuhoewNmISEgTuQtH9R9lAvHK0 YpxEzK7ITdg/kY7AuQlYwlsVFeFhSHUCfSSUsB/tCJ5GPwrMJR+l3wJRlOMhJ+G7dWfzUd85 LrrKOItOujSooErd7BDdvTPN1fQzs41h+3JBD+Ian6IRmkL7LDg2/fA0N5X5Dh0dPo3UQphO 7HqIocjFFkQNQNnnmAAAAAAAAA== --------------ms040403030608070304050109-- --------------030508030604010700040401 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com Received: from zimbra31-e6.priv.proxad.net (LHLO zimbra31-e6.priv.proxad.net) (172.20.243.181) by zimbra31-e6.priv.proxad.net with LMTP; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) Received: from relay2-v.mail.gandi.net (mx15-g26.priv.proxad.net [172.20.243.85]) by zimbra31-e6.priv.proxad.net (Postfix) with ESMTP id 7027811FCB5 for ; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) Received: from relay2-v.mail.gandi.net ([217.70.178.76]) by mx1-g20.free.fr (MXproxy) for alexandru.petrescu@free.fr ; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) X-ProXaD-SC: state=HAM score=0 X-Originating-IP: 10.0.21.74 Received: from spool.mail.gandi.net (mspool4-v.mgt.gandi.net [10.0.21.74]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 2453D135D8; Fri, 10 Sep 2010 19:55:25 +0200 (CEST) Received: from mfilter1-v.gandi.net (mfilter1-v.gandi.net [217.70.178.35]) by spool.mail.gandi.net (Postfix) with ESMTP id 4AB762DC051; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter1-v.gandi.net Received: from spool.mail.gandi.net ([10.0.21.74]) by mfilter1-v.gandi.net (mfilter1-v.gandi.net [217.70.178.35]) (amavisd-new, port 10024) with ESMTP id HuhmBYnH-CSC; Fri, 10 Sep 2010 19:55:19 +0200 (CEST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by spool.mail.gandi.net (Postfix) with ESMTP id 6D3292DC052 for ; Fri, 10 Sep 2010 19:55:19 +0200 (CEST) Received: by bwz20 with SMTP id 20so3404710bwz.27 for ; Fri, 10 Sep 2010 10:55:19 -0700 (PDT) Received: by 10.204.112.129 with SMTP id w1mr672062bkp.204.1284141318683; Fri, 10 Sep 2010 10:55:18 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.204.51.82 with SMTP id c18cs23924bkg; Fri, 10 Sep 2010 10:55:18 -0700 (PDT) Received: by 10.100.174.8 with SMTP id w8mr1076648ane.12.1284141316616; Fri, 10 Sep 2010 10:55:16 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id f15si7265617ibb.27.2010.09.10.10.55.15; Fri, 10 Sep 2010 10:55:16 -0700 (PDT) Received-SPF: pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=roll-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411C3A6866; Fri, 10 Sep 2010 10:54:47 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847E53A685C for ; Fri, 10 Sep 2010 10:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M2olbT+kkRU for ; Fri, 10 Sep 2010 10:54:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8BD923A67EB for ; Fri, 10 Sep 2010 10:54:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8AHstZI017005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Sep 2010 19:54:55 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o8AHst3l025570; Fri, 10 Sep 2010 19:54:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8AHss2r011600; Fri, 10 Sep 2010 19:54:55 +0200 Message-ID: <4C8A70EE.1050301@gmail.com> Date: Fri, 10 Sep 2010 19:54:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com> In-Reply-To: <4C8A6144.1070401@gridmerge.com> Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org X-Antivirus: avast! (VPS 100910-1, 10/09/2010), Inbound message X-Antivirus-Status: Clean Le 10/09/2010 18:48, Robert Cragie a =E9crit : > Hi Alex, > > Thank you for focusing on a pertinent issue. You are right to highlight > what we do with a RH4 header as I believe secured DAO ACK is the (only) > RPL control message which requires RH4 in non-storing mode. Sounds reassuring to know RH4 is only for DAO ACK and only for non-storing mode. And in storing mode? Is RH4 present in other than DAO ACK? Just to make sure I understand you. > So, to follow the rules for mutable and predictable fields (see RFC > 4302), we can resubstitute at the end: > > Consider the following: > > A -> B -> C -> D -> E > > A -> B: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | B | 3 | C | D | E | > > B -> C: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | C | 2 | B | D | E | > > C -> D: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | D | 1 | B | C | E | > > D -> E: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | E | 0 | B | C | D | > > When the packet arrives at E, recreate the original RH4 header for MAC > computation: > > n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp) > tmp =3D Dst > Dst =3D RH4.A[0] > RH4.Seq =3D n > for (k =3D 1; k < n; k++) > { > RH4.A[k-1] =3D RH4.A[k] > } > RH4.A[k] =3D tmp > > |Src|Dst|RH4 | > | | |Seq|L0 |L1 |L2 | > ------------------------- > | A | B | 3 | C | D | E | > > Is that acceptable? Thanks for the method - it reads reasonable. It is a good way (one way? = are there others? are there little bugs in that code?) to specify MAC = over RH4 coherently - reconstruct the RH at reception. This solution is = different than solving the mutability of the Hop Limit field. Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be = used sometime, together with RH4. This raises the obvious question = about: is the header of the encapsulating packet also protected by the = MAC of RPL? Or not? RPL spec currently says the "entire IPv6 packet" is covered by its MAC. = But does that cover the IPv6 base header of the encapsulating header? = Or not? And in which order? > Now, just because I refer to IPSec AH, it doesn't mean I am suggesting > we use it. I am suggesting we can use the fundamental principles from > IPSec for an equivalent operation. I understand. I am just afraid sometimes we try to rewrite much parts = of it. For example, I wonder how to you plan to refer to that RFC document? = Just wondering. Alex > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: >> Le 10/09/2010 11:55, Robert Cragie a =E9crit : >>> David, >>> >>> I totally agree with what you say. Thank you for restating generally >>> that IPSec has already been extensively considered - I use the term >>> 'paraphernalia' as a general term for the overheads. >>> >>> Alex - can we please drop the IPSec discussion and move on and >>> concentrate on the things which do need to sorted out? >> >> Ok... let me try to avoid dissent and do what you ask. >> >> Let's come back to RPL-11 text: >>> 3. If the packet header specifies a source route by including a RH4 >>> header as specified in [I-D.ietf-6man-rpl-routing-header] >> >> then draft-ietf-6man-rpl-routing-header-00 says: >>> else { swap the IPv6 Destination Address and Address[i] >> >> That means that there is a mutable but predictable field (IPv6 >> Destination Addess) in RH of RPL. But RPL Security doesn't understand >> mutable but predictable fields (only mutable as per recent discussion). >> RPL Security covers "entire IPv6 packet", which changes enroute despite >> RPL Security's expectation it won't change. >> >> So the question is: does RPL Security secure the RH4 header? I think it >> does not, because its MAC computation does not say how are the mutable >> but predictable fields covered. >> >> For example, a sender builds a packet with Dst address1, computes MAC, >> inserts MAC. Then intermediary routers process that packet and replace >> that Dst address1 with address2 from the Routing Header. Now the packet >> is received at address1. The MAC can't be meaningfully computed on the >> receiver, because the "IPv6 entire packet" has changed, it is not the >> same as at emission. >> >> I think this example is correct. >> >> It can't be solved in the same way we solved the mutability of "Hop >> Limit" (we said to make HopLimit set to 0 for MAC calculation), because >> if we do so then we have a higher risk of attack than when left HopLimit >> unsecure. If we set to 0 de Dst for MAC calculation then the risk of >> implication of forged IP dst addresses is higher than forged HopLimit. >> Forging an IP dst address is stronger security attack than forging >> HopLimit, intuitively speaking. >> >> Besides, whereas the receiver has really no idea about what could the >> original HopLimit be, it knows precisely what the original Dst address >> was (it's in the RH4, swapped). Thus the securing solution should be >> different - it should be as smart as RH4 is. >> >> Knowing the previous discussion, it may be possible that people will >> request we refer to that Authentication Header RFC which tells how >> mutable, mutable but predictable fields are dealt with. At that point >> we come back to IPsec, but I will abstain from saying so if you wish. >> There is also the fact that previous IPsec talk says RH0 whereas here we >> have RH4 and things may be different. >> >> That's too long for anyone to read, but you get the point. >> >> Alex >> >> >> >> >> You are of course >>> entitled to your opinion but progress is only made in the IETF >>> through rough consensus. Consensus does not mean unanimous agreement; >>> if we can all at least consent to a solution then the process will >>> run a lot more smoothly and we will all benefit. Continual dissent >>> will only serve to hinder this progress. >>> >>> I think the consensus is clear: >>> >>> * We do not mention IPSec in RPL security * The mutable field >>> discussion is entirely independent from IPSec >>> >>> Robert >>> >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >>> >>> >>> >>> On 09/09/2010 9:33 PM, David Culler wrote: >>>> Dear Alex, Thank you for focusing on the question of routing >>>> security, rather than internet security in general. Yes, IPSec has >>>> been utilized to secure routing protocols. Now please take the >>>> next step and focus on routing for low power and lossy networks. >>>> Obviously, IPSec has to be the first thing considered. And it was. >>>> Dating back to the earliest security framework discussions it was >>>> considered many times. We returned to the IPSec issue extensively >>>> back in June on the mailing list. I won't reiterate the >>>> discussion on the storage and time complexity, nor the message >>>> overhead implications that were in those prior postings. But I >>>> will observe that no one suggested that they saw their way to a >>>> full IPSec implementation within the constraints articulated in the >>>> Routing Requirements documents. The WG group has long since >>>> reached a rough consensus on this matter and moved on. That is the >>>> nature of a group process and specifically the role of WG LC. At >>>> some point, we commit to certain things and stop revisiting them >>>> from first principles. That allows us to focus more sharply on >>>> the selected approach and refine it more completely. For example, >>>> in security, we have specifics to resolve, such as which header >>>> fields need to be skipped. It is not a matter of "but I imagine >>>> that there may be alternatives". There might be. But we don't >>>> just turn the same rocks over and over again. We carve the rough >>>> stone, we chisel the details, we sand, we polish. >>>> >>>> So I assume that the point of your posting is that you want to be >>>> sure that the justification for the choices that the WG made are >>>> properly documented in the WG documents. If you feel that they are >>>> not, perhaps you could point to the document and section that you >>>> feel should contain this material more substantially. >>>> >>>> D. >>>> >>>> For reference,http://www.ietf.org/tao.html section 7.4 >>>> >>>> >>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>>> >>>>> Le 09/09/2010 16:59, David Culler a=E9crit : >>>>>> The RPL charter calls for us to address routing security >>>>>> considerations. Not security in general. Not application >>>>>> security. Not link level. Routing security. It is focused for >>>>>> good reason. >>>>> Routing security like OSPF using IPsec? "Authentication has been >>>>> removed from the OSPF protocol and instead relies on IPv6's >>>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>>> says rfc5340... why does RPL need to be different in this >>>>> respect? >>>>> >>>>> Alex >>>>> >>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>>> >>>>>>> Le 08/09/2010 18:15, Philip Levis a=E9crit : >>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>>> Le 03/09/2010 13:48, Robert Cragie a=E9crit : [skipped >>>>>>>>> agreed opinions about IPsec] >>>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>>> ok so why avoid using it. >>>>>>>>>> I don't think the specification of RPL security >>>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>>> specification? >>>>>>>>> YEs, the RPL specification must say something about >>>>>>>>> security in its Security Considerations section. That >>>>>>>>> something has to mention something about IPsec. >>>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>>> entirely independent of IPSec. There have already been >>>>>>>> numerous discussions about why simply relying on IPSec >>>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>>> these points every few weeks and rehash the same >>>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>>> time. >>>>>>> Phil - if RPL says "security" then it must understand that >>>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>>> the design (mutable fields, etc.) >>>>>>> >>>>>>> Have you checked the mutable field discussion? Do you agree >>>>>>> that mutable fields must be taken into account? >>>>>>> >>>>>>> Please read that around 3 people agreed on a list of items >>>>>>> which are worth discussion of security and IPsec - mutable >>>>>>> fields is one such item. >>>>>>> >>>>>>> As such this discussion is not a waste of everyone's time. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> Phil >>>>>>> >>>>>>> _______________________________________________ Roll mailing >>>>>>> list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>>> Associate Chair EECS >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> David Culler culler@cs.berkeley.edu Chair Computer Science >>>> Associate Chair EECS >>>> >>>> >>>> >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --------------030508030604010700040401-- From narten@us.ibm.com Tue Apr 5 10:39:22 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EAF28C12C for ; Tue, 5 Apr 2011 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.724 X-Spam-Level: X-Spam-Status: No, score=-106.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlYBjM7LCz9u for ; Tue, 5 Apr 2011 10:39:17 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 07CDC28C12B for ; Tue, 5 Apr 2011 10:39:15 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35HYB86009472 for ; Tue, 5 Apr 2011 11:34:11 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p35Hes9A103676 for ; Tue, 5 Apr 2011 11:40:54 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35Hers6024217 for ; Tue, 5 Apr 2011 11:40:54 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35HeqsP024121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 11:40:52 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35HeoU9018197; Tue, 5 Apr 2011 13:40:50 -0400 Message-Id: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: 6MAN WG Last Call: In-reply-to: References: Comments: In-reply-to Bob Hinden message dated "Fri, 18 Mar 2011 15:54:22 -0700." Date: Tue, 05 Apr 2011 13:40:50 -0400 From: Thomas Narten Cc: Brian Haberman , 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 17:39:22 -0000 Here are my detailed comments on the document. I did chat with Brian directly in Prague about these points as well. Overall, I support this document. But I think the wording in places needs another round of revision. A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that a node desires to label as a flow. A flow could consist of all packets in a This is a circular definition. I think it would be useful to give two definitions, something like the following: A Flow is a sequence of packets originating from a particular application that should be treated "the same" by the network as they are forwarded along to their ultimate destination. Packets within a flow should not be reordered, should not be given dissimilar QOS treatment, etc. What constitutes a Flow can only be defined by the application itself. At the network level, routers need to be able to identify packets belonging to the same Flow in order to process them consistently. At the same time, it may be beneficial to process packets between the same src/destination pairs (but from different application flows) differently, e.g., to support ECMP or other types of load splitting. Then: Traditionally, flow classifiers have been based on the 5-tuple of the source and destination addresses, ports, and the transport protocol add "flow classifiers at the network layer" The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a node to label packets of a flow. A Flow Label of zero is used to indicate packets not part of any flow. Packet classifiers can use reword to say "that have not been labeled" (Packets will almost always be part of some Flow). specification. However, any node that sets flow label values according to a stateful scheme MUST ensure that packets conform to Section 3 of the present specification if they are sent outside the network domain using the stateful scheme. The above wording regarding "sent outside the network domain" is problematic. It hints that maybe you can do things with the Flow Label within a domain so long as you don't send such packets outside the domain. We shouldn't even hint that that is acceptable. I'd suggest removing all references to the "stateful" flow label scheme to one section. And that section could be very short. 1. Implementers are advised that forwarding nodes, especially those acting as domain border devices, might nevertheless be configured to change the flow label value in packets. This is undetectable, unless some future version of IPsec authentication [RFC4302] protects the flow label value. Remove this. Again, the Flow Label is not allowed to be modified accept when zero. That is all that needs to be said. if the packet will leave their domain. If it is known to a border router that flow labels originated within the domain are not uniformly distributed, it will need to set outgoing flow labels in the same manner as described for forwarding nodes in Section 3. Remove this. It agains suggests border routers will be resetting Flow Label values. o Implementers should be aware that the flow label is an unprotected field that could have been accidentally or intentionally changed en route. Implementations MUST take appropriate steps to protect themselves from being vulnerable to denial of service and other types of attack that could result (see Section 6.1). Can we just move this advice to the Security Considerations section? IMO, we are giving it too much weight by having it in the main text. o Forwarding nodes such as routers and load balancers MUST NOT depend only on Flow Label values being uniformly distributed. In any usage such as a hash key for load distribution, the Flow Label bits MUST be combined at least with bits from other sources within the packet, so as to produce a constant hash value for each flow and a suitable distribution of hash values across flows. Can't we just come out and say that routers should: 1) use the src/dest/flow/port numbers? this is the most prefered. 2) if you can't use the port numbers, hash on the 3 tuple. 3) you could also say hash on teh src/dest alone as a last resort, but why the Flow Label RFC would suggest that isn't immediately obvious to me. :-) The use of the Flow Label field does not necessarily signal any requirement on packet reordering. Especially, the zero label does not imply that significant reordering is acceptable. The first sentence above isn't right. One SHOULD NOT reorder packets from the same flow. Period. An IPv6 node that does not set the flow label to a non-zero value, or make use of it in any way, MUST ignore it when receiving or forwarding a packet. I don't understand why this wording is in here. For the stateless case, nodes should simply ignore the received Flow Label value. We should probably just say that. It is desirable that flow label values should be uniformly distributed to assist load distribution. It is therefore RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a given flow to the same uniformly distributed pseudo-random value. Both stateful and stateless methods of assigning a pseudo-random value could be used, but it is outside the scope of this specification to mandate an algorithm. In a stateless mechanism, the algorithm SHOULD ensure that the resulting flow label values are unique with high probability. I think we need to specify some recommended algorithms. They can be SHOULDs (rather than MUST), but saying nothing leaves things too unclear. In particular, if we think just doing a simple hash based on the port numbers (or something) is good enough, we should recommend that. Also, this document should not be requiring (or even use SHOULD) to say pseudo randomness is necessary. This document has not made the case for that. An OPTIONAL algorithm for generating such a pseudo-random value is described in [I-D.gont-6man-flowlabel-security]. [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and the reference should be changed to Informative, if the cited draft is not on the standards track at the time of publication. ]] I'd prefer that this document provide a suggested algorithm. A source node which does not otherwise set the flow label MUST set its value to zero. Better: just say that the default value should be zero, unless set explicitely. A node that forwards a flow whose flow label value in arriving packets is zero MAY set the flow label value. In that case, it is s/MAY set/MAY change/ A node that sets the flow label MAY also take part in a flow state establishment method that results in assigning specific treatments to specific flows, possibly including signaling. Any such method MUST NOT disturb nodes taking part in the stateless model just described. Further details are not discussed in this document. I don't understand what does this is really intended to mean. IMO, just say the first sentence, and then say the details of stateful are out of scope for this document. would cause a stateful mechanism to behave incorrectly. For this reason, stateless mechanisms should not use the flow label alone to control load distribution, and stateful mechanisms should include s/stateless mechanisms/stateless classifiers/ Thomas From narten@us.ibm.com Tue Apr 5 10:43:57 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1457A3A6952 for ; Tue, 5 Apr 2011 10:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.71 X-Spam-Level: X-Spam-Status: No, score=-106.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGwgi8gyL+ni for ; Tue, 5 Apr 2011 10:43:56 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 3BBEE3A68DF for ; Tue, 5 Apr 2011 10:43:56 -0700 (PDT) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35HZHeH022843 for ; Tue, 5 Apr 2011 13:35:17 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 629A36E803F for ; Tue, 5 Apr 2011 13:45:39 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35Hjd0f382220 for ; Tue, 5 Apr 2011 13:45:39 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35HjcaE027493 for ; Tue, 5 Apr 2011 13:45:39 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35HjbMM027340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 13:45:38 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35Hjacn018215; Tue, 5 Apr 2011 13:45:36 -0400 Message-Id: <201104051745.p35Hjacn018215@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-ecmp-01.txt] In-reply-to: <4D52FC43.90203@gmail.com> References: <4D52FC43.90203@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 10 Feb 2011 09:42:43 +1300." Date: Tue, 05 Apr 2011 13:45:36 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 17:43:57 -0000 Looking at the revised document, here are some additional comments. One lightweight approach to ECMP or LAG is this: if there are N equally good paths to choose from, then form a modulo(N) hash [RFC2991] from a consistent set of fields in each packet header that are certain to have the same values throughout the duration of a flow, and use the resulting output hash value to select a particular would be nice to have a term better than "consistent". The point is, you want to use fields that stay constant for a given flow. distribution, due to the pseudo-random nature of ephemeral ports. Ephemeral port numbers are quite well distributed [Lee10] and will is "pseudo-random" right here? IN fact, do we even need that last part of the sentence? o The flow label in the outer packet SHOULD be set by the sending TEP to a pseudo-random 20-bit value in accordance with [RFC3697] or its replacement. The same flow label value MUST be used for Don't like this psuedo-random requirement here. And, the TEP should be setting the Flow Label in *exactly* the same way as 3697bis recommends. Tunnels are no different... * Note that this rule is a recommendation, to permit individual implementers to take an alternative approach if they wish to do so. For example, a simpler solution than a pseudo-random value might be adopted if it was known that the load balancer would Carpenter & Amante Expires August 14, 2011 [Page 6] Internet-Draft Flow Label for tunnel ECMP/LAG February 2011 continue to provide uniform distribution of flows with it. Such an alternative MUST conform to [RFC3697] or its replacement. This is too wishy washy. It also suggests that the TEP setting the Flow Label knows about the algorithm used by the load balancer. That will rarely (never?) be the case and this document shouldn't suggest this. the relevant flow label into the outer IPv6 header. A user flow could be identified by the ingress TEP most simply by its {destination, source} address 2-tuple (coarse) or by its 5-tuple {dest addr, source addr, protocol, dest port, source port} (fine). At present, ironically, there would be little advantage for IPv6 packets in using the {dest addr, source addr, flow label} 3-tuple. Ambiguous. Advantages compared to what? Also, the Flow classification should simply follow the recommendation in 3697bis, which says use the 5 tuple, or, at a minimum, the 3 tuple. The The choice of n-tuple is an implementation detail in the sending TEP. No it's not. What may be a detail is the actual algorithm used. But which fields to use should be a clear recommendation (e.g., taken from 3697bis). * This stateless method creates a small probability of two different user flows hashing to the same flow label. Since RFC 3697 allows a source (the TEP in this case) to define any set of packets that it wishes as a single flow, occasionally labeling two user flows as a single flow through the tunnel is acceptable. This should be fine. There is no problem with treating packets from 2 different flows the same way. The problem occurs if packets from within one flow are treated differently. o At intermediate router(s) that perform load distribution, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next-hop MUST minimally include the 3-tuple {dest addr, source addr, flow label}. This applies whether the traffic is tunneled traffic only, or a mixture of normal traffic and tunneled traffic. Be more clear: should be 5 tuple, next best is 3. Defer to 3697bis. Thomas From narten@us.ibm.com Tue Apr 5 11:07:35 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACF03A67DA for ; Tue, 5 Apr 2011 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.699 X-Spam-Level: X-Spam-Status: No, score=-106.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pANcxD2oV30 for ; Tue, 5 Apr 2011 11:07:34 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id B50FF3A67B6 for ; Tue, 5 Apr 2011 11:07:34 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35Hv7NE018902 for ; Tue, 5 Apr 2011 11:57:07 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p35I97xJ120220 for ; Tue, 5 Apr 2011 12:09:07 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35IE25X007402 for ; Tue, 5 Apr 2011 12:14:02 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35IE1I7007355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 12:14:02 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35I94HL018340; Tue, 5 Apr 2011 14:09:04 -0400 Message-Id: <201104051809.p35I94HL018340@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: 6MAN WG Last Call: In-reply-to: <2F8FF78F-24CF-4895-A5BC-EA4167D92C6D@gmail.com> References: <2F8FF78F-24CF-4895-A5BC-EA4167D92C6D@gmail.com> Comments: In-reply-to Bob Hinden message dated "Mon, 21 Mar 2011 10:15:42 -0700." Date: Tue, 05 Apr 2011 14:09:04 -0400 From: Thomas Narten Cc: Brian Haberman , 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 18:07:35 -0000 Here are my comments on this document. My main issue is that it continues to assert that flow labels are required to be pseudo random. I am not convinced that is necessary and I think it makes things more complex than necessary. Detailed comments: Review of -04 Also, it could be used as a covert data channel, since apparently pseudo-random flow label values could in fact consist of covert data. drop "pseudo-random" as that is not relevant to the point. As a result, some security specialists believe that flow labels should be cleared for safety. If you don't have a reference to this, please delete. However, it is recommended that sources should set a pseudo-random flow label value in all flows, replacing the less precise recommendation made in Section 3 of RFC 3697. Both stateful and Again, I don't think we have agreement on this "recommendation". mathematically on immutable flow labels. The new rules require that flow labels exported to the Internet should always be either zero or pseudo-random, but even this cannot be relied on mathematically. Use Pseudo random requirement again... Thomas From shane@castlepoint.net Tue Apr 5 12:20:35 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50353A6407 for ; Tue, 5 Apr 2011 12:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCnKoMXnCsyE for ; Tue, 5 Apr 2011 12:20:34 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 28FE53A63CA for ; Tue, 5 Apr 2011 12:20:34 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 39FB2268676; Tue, 5 Apr 2011 13:22:17 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 05 Apr 2011 13:22:17 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=59821; data-bytes=0 From: Shane Amante Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Pseudorandom Flow Labels Date: Tue, 5 Apr 2011 13:22:16 -0600 Message-Id: To: Thomas Narten Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:20:36 -0000 Thomas, With respect to your comments on, both at the mic at the 6MAN WG and on = the list: draft-ietf-6man-flow-3697bis-02 draft-ietf-6man-flow-ecmp-01 draft-ietf-6man-flow-update-04 You seem to take issue with a recommendation for creating/selecting a = flow-label that is "pseudo-random". Can you clarify the reason(s) you = take issue with creating/selecting a flow-label that is "pseudo-random"? = (IMO, the current 'SHOULD' in the draft provides enough leeway that if = implementations have good reason(s) to not select pseudo-random values = for flow-labels they can choose to do so, but would hopefully have good = reasons for that). The reason I ask is as follows: 1) RFC 6056: Recommendations for Transport Protocol Randomization, in = particular Appendix A. In short, a lot of [deployed] implementations = are already computing a pseudo-random value for a transport protocol = port (within the ephemeral port range), today, so IMHO the = implementation "burden" of choosing a pseudo-random value must be quite = low and, in theory, there should be good re-use of that code/logic for = selecting flow-labels. 2) If we expect that if a intermediate router or switch is using *just* = the 3-tuple of {src_ip, dst_ip + flow_label} as input-keys to compute a = load-balancing hash algorithm, then the more random the flow-label, the = better load-distribution of /all/ traffic will be across the LAG and/or = ECMP paths. Here's a few cases in point: a) As a network operator I have no control over the number of IP = addresses used by content farms or residential networks. Furthermore, = it's not clear that as more & more machines (and, smartphones!) ship = that support multiple CPU's and/or multiple cores that each of those = discrete computing units will (or, should?) receive their own IP = address. With IPv6 that's at least a possibly, but perhaps due to "ease = of development", that won't happen often, or at all. If we strongly = recommend a pseudo-random flow-label and a device is only capable of = load-balancing using a 3-tuple, then I've at least got a [relatively] = unique flow-label in the packet header to provide load distribution. b) The reason that we observe in today's production networks very = good load-distribution over LAG and/or ECMP paths is most likely the = result of, first, hosts selecting a pseudo-random value for their = ephemeral ports (based on RFC 6056) and, second, the ability for = intermediate routers/switches to use the traditional 5-tuple for = input-keys for load-distribution on those paths. Since we would like to = move in a direction of LAG/ECMP load-balancing based on just the 3-tuple = of {src_ip, dst_ip, flow_label}, then we should not take a step = backwards from where we are today wrt pseudorandom-ness of individual = flows. 3) Finally, if we expect that the flow-label may (or, hopefully will) = get used as a lightweight method of detecting and, possibly, preventing = 3rd-party DoS or traffic injection attacks, (i.e.: = draft-gont-6man-flowlabel-security), then it depends on generation of = pseudo-random values for flow-labels in order that off-path attackers = have a reasonably low chance of guessing a valid flow-label. Thanks, -shane= From narten@us.ibm.com Tue Apr 5 12:57:05 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91FE3A67A2 for ; Tue, 5 Apr 2011 12:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.69 X-Spam-Level: X-Spam-Status: No, score=-106.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88aTLixObWCh for ; Tue, 5 Apr 2011 12:57:03 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id BA4A23A6407 for ; Tue, 5 Apr 2011 12:57:02 -0700 (PDT) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35Jbmkm027350 for ; Tue, 5 Apr 2011 15:37:48 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8E03338C8039 for ; Tue, 5 Apr 2011 15:58:31 -0400 (EDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35JwdHF438926 for ; Tue, 5 Apr 2011 15:58:39 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35JwcUm027848 for ; Tue, 5 Apr 2011 13:58:38 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35Jwb7Q027805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 13:58:38 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35JwaJP019044; Tue, 5 Apr 2011 15:58:36 -0400 Message-Id: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> To: Shane Amante Subject: Re: Pseudorandom Flow Labels In-reply-to: References: Comments: In-reply-to Shane Amante message dated "Tue, 05 Apr 2011 13:22:16 -0600." Date: Tue, 05 Apr 2011 15:58:36 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:57:05 -0000 At the core, my concern with "pseudo random" is that I (as an implementor) do not know what I have to do do satisfy that requirement and I think in some cases that cost is higher than justified by the benefit. The current documents do not provide enough concrete guidance, IMO. If we want folk to actually set the Flow Label to a good value, tell them what to do. Don't make them think too hard. Provide them with a suggested algorithm. Don't just say "make it psuedo random". > 1) RFC 6056: Recommendations for Transport Protocol Randomization, > in particular Appendix A. In short, a lot of [deployed] > implementations are already computing a pseudo-random value for a > transport protocol port (within the ephemeral port range), today, > so IMHO the implementation "burden" of choosing a pseudo-random > value must be quite low and, in theory, there should be good > re-use of that code/logic for selecting flow-labels. This is good stuff. For originating hosts (not TEPs) then, the documents should reference RFC 6056 (they currently do not), point out that ports following the recommendation have the necessary property already, and suggest a way of mapping the port numbers (and whatever other info would be good) into the Flow Label to be used. More to the point, if this could be done in a "stateless" manner, e.g., by the routine that sends IP datagrams, that would be nice. I.e., if the IP "send" routine could easily set the Flow Label whenever it was zero, in a "stateless" manner, that would almost guarantee we'd get wide spread implementation. The problem I have with "pseudo random" is that it has properties that I am not convinced the Flow Label necessarily needs to have. And the complexity of getting real pseudo randomness in a simple implementation may be too high. I take it as a given that doing ECMP on the src/dst address gets you 80% of what you need today. Adding in the Flow Label (if set) will take you much further. I am not convinced you need real "pseudo randomness" in the Flow Label to get the benefits being called for. > 2) If we expect that if a intermediate router or switch is using > *just* the 3-tuple of {src_ip, dst_ip + flow_label} as input-keys to > compute a load-balancing hash algorithm, then the more random the > flow-label, the better load-distribution of /all/ traffic will be > across the LAG and/or ECMP paths. Understood. But what you need for this is not (necessarily) pseudo randomness. Just sufficient variability (when combined with the src/dst) to get good distribution on the output side of the hash. > a) As a network operator I have no control over the number of IP > addresses used by content farms or residential networks. > Furthermore, it's not clear that as more & more machines (and, > smartphones!) ship that support multiple CPU's and/or multiple > cores that each of those discrete computing units will (or, > should?) receive their own IP address. With IPv6 that's at > least a possibly, but perhaps due to "ease of development", > that won't happen often, or at all. If we strongly recommend a > pseudo-random flow-label and a device is only capable of > load-balancing using a 3-tuple, then I've at least got a > [relatively] unique flow-label in the packet header to provide > load distribution. I think we can assume that if we use both the src/dst, we will get a good degree of distribution in the values. Adding the Flow Label gives more. I am just not convinced that to get good distribution we need to *require* (or strongly suggest) psuedo randomness in the Flow Lable. We know that by simply incrementing the Flow Label by 1 for each flow, we get sufficient distribution. That is *way* easier to implement than something else. > b) The reason that we observe in today's production networks very > good load-distribution over LAG and/or ECMP paths is most > likely the result of, first, hosts selecting a pseudo-random > value for their ephemeral ports (based on RFC 6056) and, > second, the ability for intermediate routers/switches to use > the traditional 5-tuple for input-keys for load-distribution on > those paths. Since we would like to move in a direction of > LAG/ECMP load-balancing based on just the 3-tuple of {src_ip, > dst_ip, flow_label}, then we should not take a step backwards > from where we are today wrt pseudorandom-ness of individual > flows. This takes me back to an earlier point. Then suggest that if the port numbers are pseudo random, provide me with a simple algorithm for mapping that into a good Flow Label value. > 3) Finally, if we expect that the flow-label may (or, hopefully > will) get used as a lightweight method of detecting and, possibly, > preventing 3rd-party DoS or traffic injection attacks, (i.e.: > draft-gont-6man-flowlabel-security), then it depends on generation > of pseudo-random values for flow-labels in order that off-path > attackers have a reasonably low chance of guessing a valid > flow-label. I'm less convinced that there are real significant DOS attacks that using a pseudo-random flow label can address. Now. What about TEPs? They have no way of knowing whether the port numbers being used provide proper randomness. That implies if they are going to generate pseudo-random Flow Labels, they have a *lot* more work to do. And to be sure that all packets from a given "flow" are given the same Flow Label, they may have to maintain state. i.e., so that subsequent packets from the same flow get assigned the same Flow Label value. I doubt you are suggesting that. But the current documents leave this all to the reader. Again, I think some concrete recommendations are in order. If you think TEPs will, in fact, just produce a Flow Label value based on whatever ports the packets being tunneled contain, then just say so and be done with it. But don't require that they produce "pseudo random" values if in fact, we are pretty sure TEPs won't actually implement this. Thomas From narten@us.ibm.com Tue Apr 5 13:35:18 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4193428B797 for ; Tue, 5 Apr 2011 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.682 X-Spam-Level: X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpwu+Nts2UlP for ; Tue, 5 Apr 2011 13:35:17 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 8FA9028C0E9 for ; Tue, 5 Apr 2011 13:35:17 -0700 (PDT) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35KBC6v005309 for ; Tue, 5 Apr 2011 16:11:12 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 7E6626E803E for ; Tue, 5 Apr 2011 16:36:54 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35KarwT2252998 for ; Tue, 5 Apr 2011 16:36:53 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35Kaq5x029998 for ; Tue, 5 Apr 2011 16:36:53 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35KapSj029918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 16:36:52 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35KaoHV019253; Tue, 5 Apr 2011 16:36:51 -0400 Message-Id: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> To: Shane Amante Subject: Re: Pseudorandom Flow Labels In-reply-to: References: Comments: In-reply-to Shane Amante message dated "Tue, 05 Apr 2011 13:22:16 -0600." Date: Tue, 05 Apr 2011 16:36:50 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:35:18 -0000 Case in point about how we are being *extremely* loose in using the term "pseudo random". If you look at draft-gont-6man-flowlabel-security-01, it proposes two different algorithms for generating Flow Label values. Unless I'm missing something, neither of them actually provides "pseudo randomness". Both have subsequent Flow Label values simply increment a counter to get to the next value. What these algorithms do do is make it very hard for an off-site attacker to guess what Flow Label values are being used. That is probably a good thing. But that is not the same thing as saying that the Flow Labels that are generated are "pseudo random", which is what the current Flow Label documents are saying we need. Part of my objection to the term "pseudo random" is that the term has not been defined within the context of the Flow Label. RFC 4086 "Randomness Requirements for Security" talks quite a bit about pseudo randomness. I don't think we need that for the Flow Label. But without carefully defining terms, that is what is presumably being required... Thomas From shane@castlepoint.net Tue Apr 5 14:21:59 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF7B28C0E2 for ; Tue, 5 Apr 2011 14:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN92Ns6IkRfA for ; Tue, 5 Apr 2011 14:21:58 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4B2813A67C1 for ; Tue, 5 Apr 2011 14:21:58 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 83B1F268676; Tue, 5 Apr 2011 15:23:41 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 05 Apr 2011 15:23:41 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60710; data-bytes=0 Subject: Re: Pseudorandom Flow Labels Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> Date: Tue, 5 Apr 2011 15:23:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92DAE8F3-471F-4331-8882-3788631959F5@castlepoint.net> References: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:21:59 -0000 Thomas, On Apr 5, 2011, at 13:58 MDT, Thomas Narten wrote: [--snip--] > I take it as a given that doing ECMP on the src/dst address gets you > 80% of what you need today. Adding in the Flow Label (if set) will > take you much further. I am not convinced you need real "pseudo > randomness" in the Flow Label to get the benefits being called for. As I pointed out below, we already have pseudorandom distribution of = flows today, given that most host implementations use RFC 6056 and = (IPv4) load-balancing routers/switches use the 5-tuple as input-keys ... = included in those input-keys is a "pseudorandom ephemeral port". In = short, if you remove the pseudo-random requirement from flow-labels, = (and I can only load-balance on just the 3-tuple), I guarantee I will = end up with less efficient load-balancing. Second, the economic results of what you suggest would be bad. IOW, = operators need to pack all links, in a LAG and/or ECMP group, as = _efficiently_ as (reasonably) possible, particularly over Inter-City and = especially over Inter-Continental links where costs are substantial. In = summary, "good enough" is not adequate, hence the reqm't for = pseudorandom-ness in flow-labels (originated by hosts!) to provide the a = very, very high probability that flows will be "uniformly distributed". >> 2) If we expect that if a intermediate router or switch is using >> *just* the 3-tuple of {src_ip, dst_ip + flow_label} as input-keys to >> compute a load-balancing hash algorithm, then the more random the >> flow-label, the better load-distribution of /all/ traffic will be >> across the LAG and/or ECMP paths. >=20 > Understood. But what you need for this is not (necessarily) pseudo > randomness. Just sufficient variability (when combined with the > src/dst) to get good distribution on the output side of the hash. I'll state it a bit differently: I need flow-labels as close to the = [pseudo-random] properties provided by RFC 6056. >> a) As a network operator I have no control over the number of IP >> addresses used by content farms or residential networks. >> Furthermore, it's not clear that as more & more machines (and, >> smartphones!) ship that support multiple CPU's and/or multiple >> cores that each of those discrete computing units will (or, >> should?) receive their own IP address. With IPv6 that's at >> least a possibly, but perhaps due to "ease of development", >> that won't happen often, or at all. If we strongly recommend a >> pseudo-random flow-label and a device is only capable of >> load-balancing using a 3-tuple, then I've at least got a >> [relatively] unique flow-label in the packet header to provide >> load distribution. >=20 > I think we can assume that if we use both the src/dst, we will get a > good degree of distribution in the values. Adding the Flow Label gives > more. I am just not convinced that to get good distribution we need to > *require* (or strongly suggest) psuedo randomness in the Flow > Lable. We know that by simply incrementing the Flow Label by 1 for > each flow, we get sufficient distribution. That is *way* easier to > implement than something else. Unfortunately, if: a) All hosts at a site start off selecting "1" for their flow-labels; = or, b) Don't cycle through the full-range of flow-label values; or, c) a [large] set of hosts experience synchronization of flow-label = values; or, d) Reset back to flow-label "1" after some short time period ... then you nullify the claim of having "sufficient distribution" of = flow-labels and, consequently, flows. Instead, if we tell implementers = to select a pseudorandom value, using an O/S and/or API's random() = function, we're much more likely to get "sufficient distribution". >> b) The reason that we observe in today's production networks very >> good load-distribution over LAG and/or ECMP paths is most >> likely the result of, first, hosts selecting a pseudo-random >> value for their ephemeral ports (based on RFC 6056) and, >> second, the ability for intermediate routers/switches to use >> the traditional 5-tuple for input-keys for load-distribution on >> those paths. Since we would like to move in a direction of >> LAG/ECMP load-balancing based on just the 3-tuple of {src_ip, >> dst_ip, flow_label}, then we should not take a step backwards >> from where we are today wrt pseudorandom-ness of individual >> flows. >=20 > This takes me back to an earlier point. Then suggest that if the port > numbers are pseudo random, provide me with a simple algorithm for > mapping that into a good Flow Label value. draft-gont-6man-flowlabel-security-01? Which is already referenced from = draft-ietf-6man-flow-3697bis-02. >> 3) Finally, if we expect that the flow-label may (or, hopefully >> will) get used as a lightweight method of detecting and, possibly, >> preventing 3rd-party DoS or traffic injection attacks, (i.e.: >> draft-gont-6man-flowlabel-security), then it depends on generation >> of pseudo-random values for flow-labels in order that off-path >> attackers have a reasonably low chance of guessing a valid >> flow-label. >=20 > I'm less convinced that there are real significant DOS attacks that > using a pseudo-random flow label can address. >=20 > Now. What about TEPs? They have no way of knowing whether the port > numbers being used provide proper randomness. That implies if they are > going to generate pseudo-random Flow Labels, they have a *lot* more > work to do. And to be sure that all packets from a given "flow" are > given the same Flow Label, they may have to maintain state. i.e., so > that subsequent packets from the same flow get assigned the same Flow > Label value. I doubt you are suggesting that. You are correct. > But the current > documents leave this all to the reader. Again, I think some concrete > recommendations are in order. If you think TEPs will, in fact, just > produce a Flow Label value based on whatever ports the packets being > tunneled contain, then just say so and be done with it. OK. I think I understand where you are coming from with respect to = draft-ietf-6man-flow-ecmp-01. Hopefully the above comment(s) will allow = us to craft text that will resolve your concerns with that draft once = and for all. However, that still leaves draft-ietf-6man-flow-3697bis-02 = open for discussion. > But don't > require that they produce "pseudo random" values if in fact, we are > pretty sure TEPs won't actually implement this. Understood. -shane= From jhw@apple.com Tue Apr 5 14:42:44 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46E23A67F1 for ; Tue, 5 Apr 2011 14:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.328 X-Spam-Level: X-Spam-Status: No, score=-106.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJKNhIfMsa7w for ; Tue, 5 Apr 2011 14:42:42 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by core3.amsl.com (Postfix) with ESMTP id CB3FC3A67EB for ; Tue, 5 Apr 2011 14:42:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ7009FY8ARG4C1@localhost.apple.com> for ipv6@ietf.org; Tue, 05 Apr 2011 14:44:26 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-0a-4d9b8d3a269c Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 85.D1.23242.A3D8B9D4; Tue, 05 Apr 2011 14:44:26 -0700 (PDT) Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ700BNS8E1Q640@et.apple.com> for ipv6@ietf.org; Tue, 05 Apr 2011 14:44:26 -0700 (PDT) Subject: Re: Pseudorandom Flow Labels From: james woodyatt In-reply-to: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> Date: Tue, 05 Apr 2011 14:44:25 -0700 Message-id: <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:42:44 -0000 On Apr 5, 2011, at 13:36 , Thomas Narten wrote: > > Case in point about how we are being *extremely* loose in using the term "pseudo random". I share your concern. Would replacing "pseudo-random" with "low discrepancy" address your concerns? -- james woodyatt member of technical staff, core os networking From narten@us.ibm.com Tue Apr 5 14:46:43 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7183A67EB for ; Tue, 5 Apr 2011 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.676 X-Spam-Level: X-Spam-Status: No, score=-106.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcw4FdIK+pq4 for ; Tue, 5 Apr 2011 14:46:42 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id B31D63A67D8 for ; Tue, 5 Apr 2011 14:46:42 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35LWsrf022488 for ; Tue, 5 Apr 2011 15:32:54 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35LmPwr084914 for ; Tue, 5 Apr 2011 15:48:25 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35LmPJf027769 for ; Tue, 5 Apr 2011 15:48:25 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35LmNtZ027689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 15:48:24 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35LmM9g019765; Tue, 5 Apr 2011 17:48:22 -0400 Message-Id: <201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> To: james woodyatt Subject: Re: Pseudorandom Flow Labels In-reply-to: <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> Comments: In-reply-to james woodyatt message dated "Tue, 05 Apr 2011 14:44:25 -0700." Date: Tue, 05 Apr 2011 17:48:22 -0400 From: Thomas Narten Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:46:43 -0000 > I share your concern. Would replacing "pseudo-random" with "low > discrepancy" address your concerns? Replacing the term with another would be fine. That said, the real issue is we need to define what we mean by whatever term we use. Thomas From jhw@apple.com Tue Apr 5 15:47:42 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9FB3A6810 for ; Tue, 5 Apr 2011 15:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-ii6DnBfMqj for ; Tue, 5 Apr 2011 15:47:41 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by core3.amsl.com (Postfix) with ESMTP id A52C73A67F3 for ; Tue, 5 Apr 2011 15:47:41 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ7000USBAXAPA0@localhost.apple.com> for ipv6@ietf.org; Tue, 05 Apr 2011 15:49:25 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-ad-4d9b9c75050e Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with SMTP id D1.E8.29082.57C9B9D4; Tue, 05 Apr 2011 15:49:25 -0700 (PDT) Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ700BGTBECQ660@et.apple.com> for ipv6@ietf.org; Tue, 05 Apr 2011 15:49:25 -0700 (PDT) Subject: Re: Pseudorandom Flow Labels From: james woodyatt In-reply-to: <201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> Date: Tue, 05 Apr 2011 15:49:24 -0700 Message-id: <9ED6022F-6863-4267-A268-C73240098539@apple.com> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> <201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:47:42 -0000 On Apr 5, 2011, at 14:48 , Thomas Narten wrote: > [I wrote:] >> >> I share your concern. Would replacing "pseudo-random" with "low discrepancy" address your concerns? > > Replacing the term with another would be fine. That said, the real issue is we need to define what we mean by whatever term we use. Discrepancy is a measure of the deviation of a point set from a uniform distribution. Or, so Wolfram MathWorld tells me. A low discrepancy sequence would be one that has *approximately* uniform distribution [though, not necessarily *exactly* uniform], which is what seems to be the object of the game here. There are many excellent well-known low discrepancy sequences to choose from, and I'm not sure IETF needs to specify a standard one, but it's possible one could be found if we really tried hard. If you want to get hideously pedantic, you could specify a maximum discrepancy; I'm sure Timothy Winters and his crew would just melt if you did that. Note: another term for "low discrepancy" is "quasi-random" but I'm not sure we want to go there. -- james woodyatt member of technical staff, core os networking From narten@us.ibm.com Tue Apr 5 17:06:54 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDD33A684D for ; Tue, 5 Apr 2011 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.67 X-Spam-Level: X-Spam-Status: No, score=-106.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxtl902I72Gd for ; Tue, 5 Apr 2011 17:06:53 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id C450D3A6844 for ; Tue, 5 Apr 2011 17:06:53 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35NqsYR025031 for ; Tue, 5 Apr 2011 17:52:54 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3608RkB103930 for ; Tue, 5 Apr 2011 18:08:27 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3608RYD025328 for ; Tue, 5 Apr 2011 18:08:27 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3608QEl025300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 18:08:27 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3608OlC022133; Tue, 5 Apr 2011 20:08:25 -0400 Message-Id: <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> To: james woodyatt Subject: Re: Pseudorandom Flow Labels In-reply-to: <9ED6022F-6863-4267-A268-C73240098539@apple.com> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> <201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> <9ED6022F-6863-4267-A268-C73240098539@apple.com> Comments: In-reply-to james woodyatt message dated "Tue, 05 Apr 2011 15:49:24 -0700." Date: Tue, 05 Apr 2011 20:08:24 -0400 From: Thomas Narten Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:06:54 -0000 > Discrepancy is a measure of the deviation of a point set from a > uniform distribution. Actually, the core issue is that we do not need the Flow Label to be uniformly distributed. In an ideal world, that would be a nice property to have. And all things equal, better to have that propert than not. But for ECMP and other types of things being discussed, such a property is simply *not* required to get perfectly fine results. What is *required* is that the hash function (or whatever function that is used) on the router maps the tuples in a *uniform* way across the range of possible outputs. If you have 10 links, and all your Flow Labels are clustered around low ten values, but in an approximately uniform way, a simple modulo hash will get you the kind of distribution you need. The range of values of the flow label itself does not need to be uniformly distributed. That is why incrementing a counter for each new flow provides adequate properties. I remain unconvinced that we need to require that they exhibit pseudo randomness, or even be uniform. If that is a requirement, I'd like to see the justification, not just hand waiving. Thomas From john@jlc.net Tue Apr 5 17:30:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188243A6844 for ; Tue, 5 Apr 2011 17:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXiKidh6aN3O for ; Tue, 5 Apr 2011 17:30:08 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 5EE8D3A681A for ; Tue, 5 Apr 2011 17:30:08 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 447C033C21; Tue, 5 Apr 2011 20:31:52 -0400 (EDT) Date: Tue, 5 Apr 2011 20:31:52 -0400 From: John Leslie To: Thomas Narten Subject: Re: Pseudorandom Flow Labels Message-ID: <20110406003152.GA24474@verdi> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> <201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> <9ED6022F-6863-4267-A268-C73240098539@apple.com> <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.4.1i Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:30:09 -0000 Thomas Narten wrote: > > What is *required* is that the hash function (or whatever function > that is used) on the router maps the tuples in a *uniform* way across > the range of possible outputs. > > If you have 10 links, and all your Flow Labels are clustered around > low ten values, but in an approximately uniform way, a simple modulo > hash will get you the kind of distribution you need. > > The range of values of the flow label itself does not need to be > uniformly distributed. I'm strongly in favor of stating the requirement this way (though perhaps more wordsmithing can make it even better). AFAICT, this is our actual concern -- that an Equal Cost Multipath router can do a simple hash function to distribute flows across multiple links without endangering in-order delivery of the individual flows identified in the Flow Label. (I'd also like a statement to that effect, or whatever it is we actually mean to accomplish.) > If that is a requirement, I'd like to see the justification, not just > hand waiving. Me too. -- John Leslie From jhw@apple.com Tue Apr 5 17:42:42 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6103A682D for ; Tue, 5 Apr 2011 17:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRGRf8aC1AcO for ; Tue, 5 Apr 2011 17:42:42 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id 2CFEB3A682A for ; Tue, 5 Apr 2011 17:42:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ7006OPGPZPOC1@localhost.apple.com> for ipv6@ietf.org; Tue, 05 Apr 2011 17:44:25 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-10-4d9bb7697df2 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id E5.D1.23242.967BB9D4; Tue, 05 Apr 2011 17:44:25 -0700 (PDT) Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ7002CIGQ1EP30@gertie.apple.com> for ipv6@ietf.org; Tue, 05 Apr 2011 17:44:25 -0700 (PDT) Subject: Re: Pseudorandom Flow Labels From: james woodyatt In-reply-to: <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> Date: Tue, 05 Apr 2011 17:44:25 -0700 Message-id: References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com> <201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> <9ED6022F-6863-4267-A268-C73240098539@apple.com> <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> To: 6MAN Working Group X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:42:42 -0000 On Apr 5, 2011, at 17:08 , Thomas Narten wrote: > > What is *required* is that the hash function (or whatever function > that is used) on the router maps the tuples in a *uniform* way across > the range of possible outputs. Then it seems like "Equidistributed Sequence" is the precise term you want. I too would like to see the case for Low Discrepancy vs. Equidistributed made more clear. One of the arguments I suppose could be made for Low Discrepancy is that it would provide a guarantee that *any* substring of the full 20-bit flow label could be taken as an input to a function that maps with low discrepancy to a particular load-sharing element. Equidistributed does not provide any such guarantee and requires A) that the domain of the function be the full label, and B) the function to map an equidistributed domain to a low discrepancy codomain. Are those functions any cheaper? I doubt it. -- james woodyatt member of technical staff, core os networking From shemant@cisco.com Tue Apr 5 18:13:44 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFB93A6828 for ; Tue, 5 Apr 2011 18:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.641 X-Spam-Level: X-Spam-Status: No, score=-9.641 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLb7z1p8IGaS for ; Tue, 5 Apr 2011 18:13:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CE47D3A69A0 for ; Tue, 5 Apr 2011 18:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2527; q=dns/txt; s=iport; t=1302052527; x=1303262127; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7GkL/pAvcWz+DNCyuYAWywkpwSyrFe/+9vdThny2kHg=; b=XNIMV8X4vB2wEsdCa/KLPxz7a3tQrIlMADJSXvbWxRyztJ3pwW0zQlyV 3mXWLXhLfkSU3qh6OYANBobdUOtFYjidWavO2BYNIdH9NWXW/uGuOJaiC UQv07/M0QfgiDnYtUld13AsvMbJ0/iPNoKOpUvi3ZtlqEnHGQSYanh7oc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAAW+m02tJV2a/2dsb2JhbACYLY1Id6Y5nDKFbASFR4s/ X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="424530003" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2011 01:15:27 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p361FQY6012191; Wed, 6 Apr 2011 01:15:26 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 20:15:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BkPE CxQW DHrT HQO5 HnBr ICWe IGts Ngw5 O5YX P4av UhMS Z9cd ck/3 c6wE gFuF h4b/; 3; aQBwAHYANgBAAGkAZQB0AGYALgBvAHIAZwA7AGoAaAB3AEAAYQBwAHAAbABlAC4AYwBvAG0AOwBuAGEAcgB0AGUAbgBAAHUAcwAuAGkAYgBtAC4AYwBvAG0A; Sosha1_v1; 7; {A1F521D2-8C7C-44C1-8762-29615019E0D2}; cwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 06 Apr 2011 01:15:18 GMT; UgBFADoAIABQAHMAZQB1AGQAbwByAGEAbgBkAG8AbQAgAEYAbABvAHcAIABMAGEAYgBlAGwAcwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {A1F521D2-8C7C-44C1-8762-29615019E0D2} Content-class: urn:content-classes:message Subject: RE: Pseudorandom Flow Labels Date: Tue, 5 Apr 2011 20:15:18 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301391452@XMB-RCD-109.cisco.com> In-Reply-To: <9ED6022F-6863-4267-A268-C73240098539@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pseudorandom Flow Labels Thread-Index: Acvz47412DPAEn1tRTKUvqXWrmc+jAAEnYUw References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com><19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com><201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> <9ED6022F-6863-4267-A268-C73240098539@apple.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , X-OriginalArrivalTime: 06 Apr 2011 01:15:27.0045 (UTC) FILETIME=[1CC73F50:01CBF3F8] Cc: Thomas Narten X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:13:45 -0000 Snipped from RFC 4193 is this text. "pseudo-randomly allocated global ID". If pseudo-random was accepted in this RFC, why are we discussing pseudo-random again? One reason is acceptable to me that over the years we learn to be more precise or more audience read the documents and thus more folks can ask for a better choice for a term. I agree with Thomas that we can pick a term but then the term has to be defined clearly. Here is some text from RFC 4193 one could use. This way we avoid the IETF specifying what pseudo-random algorithm to use but still get a as precise as possible definition that has been accepted in other RFCs such as RFC 4193. [Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM].] =20 Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, April 05, 2011 6:49 PM To: Thomas Narten Cc: 6MAN Working Group Subject: Re: Pseudorandom Flow Labels On Apr 5, 2011, at 14:48 , Thomas Narten wrote: > [I wrote:] >>=20 >> I share your concern. Would replacing "pseudo-random" with "low discrepancy" address your concerns? >=20 > Replacing the term with another would be fine. That said, the real issue is we need to define what we mean by whatever term we use. Discrepancy is a measure of the deviation of a point set from a uniform distribution. Or, so Wolfram MathWorld tells me. A low discrepancy sequence would be one that has *approximately* uniform distribution [though, not necessarily *exactly* uniform], which is what seems to be the object of the game here. There are many excellent well-known low discrepancy sequences to choose from, and I'm not sure IETF needs to specify a standard one, but it's possible one could be found if we really tried hard. If you want to get hideously pedantic, you could specify a maximum discrepancy; I'm sure Timothy Winters and his crew would just melt if you did that. Note: another term for "low discrepancy" is "quasi-random" but I'm not sure we want to go there. -- james woodyatt member of technical staff, core os networking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From shemant@cisco.com Tue Apr 5 18:33:16 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3F73A69A9 for ; Tue, 5 Apr 2011 18:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.625 X-Spam-Level: X-Spam-Status: No, score=-10.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26EGry8-QduD for ; Tue, 5 Apr 2011 18:33:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D8C5D3A69A7 for ; Tue, 5 Apr 2011 18:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1331; q=dns/txt; s=iport; t=1302053699; x=1303263299; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6TEm1XXEfd9Z6LT5zq6CyW1wWZXn8PFbjB4kZj8vWTA=; b=ib1bmsw4bjd1jPsGXyzgQVLeZKDQB/h8C++jMVww3rOzpH1BFLa4fPB7 6/suXMoD6O5Jaf1WPTGOi72K0OoFNq1zKIeILbBXZit5BsP+28gxQC3hZ fYG1axgICkFvW5/GWvzh42rMwJw//R1ZDtc6kai3B+wT1KjuBMwedEpxo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAKLCm02tJXG+/2dsb2JhbACYLI1Id6YhnDGFbASFR4s/ X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="424535978" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2011 01:34:59 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p361YwwV005125; Wed, 6 Apr 2011 01:34:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 20:34:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Af4j DoXm Dz7A KHW2 MGgZ OfYp P2Ir UK+K Vomj WwzW W5Rb XjiP YpOI ZFUD ZH7c Z0M8; 3; aQBwAHYANgBAAGkAZQB0AGYALgBvAHIAZwA7AGoAaAB3AEAAYQBwAHAAbABlAC4AYwBvAG0AOwBuAGEAcgB0AGUAbgBAAHUAcwAuAGkAYgBtAC4AYwBvAG0A; Sosha1_v1; 7; {DEA874CB-172B-4D41-99C3-08449837DDCE}; cwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 06 Apr 2011 01:34:53 GMT; UgBFADoAIABQAHMAZQB1AGQAbwByAGEAbgBkAG8AbQAgAEYAbABvAHcAIABMAGEAYgBlAGwAcwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {DEA874CB-172B-4D41-99C3-08449837DDCE} Content-class: urn:content-classes:message Subject: RE: Pseudorandom Flow Labels Date: Tue, 5 Apr 2011 20:34:53 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301391466@XMB-RCD-109.cisco.com> In-Reply-To: <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pseudorandom Flow Labels Thread-Index: Acvz7s7pyTFFmQOPRvu1/IvWT9Er5AACos2A References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com><19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com><201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com><9ED6022F-6863-4267-A268-C73240098539@apple.com> <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> From: "Hemant Singh (shemant)" To: "Thomas Narten" , "james woodyatt" X-OriginalArrivalTime: 06 Apr 2011 01:34:58.0810 (UTC) FILETIME=[D73465A0:01CBF3FA] Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:33:17 -0000 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Tuesday, April 05, 2011 8:08 PM To: james woodyatt Cc: 6MAN Working Group Subject: Re: Pseudorandom Flow Labels >What is *required* is that the hash function (or whatever function >that is used) on the router maps the tuples in a *uniform* way across >the range of possible outputs. >If you have 10 links, and all your Flow Labels are clustered around >low ten values, but in an approximately uniform way, a simple modulo >hash will get you the kind of distribution you need. >The range of values of the flow label itself does not need to be >uniformly distributed. >That is why incrementing a counter for each new flow provides adequate >properties. I remain unconvinced that we need to require that they >exhibit pseudo randomness, or even be uniform. >If that is a requirement, I'd like to see the justification, not just >hand waiving. How about something like the text below: A property of the flow label is that when the flow label is used a key to a hash function the function produces a uniform distribution of hash values. Thus, incrementing a counter for each new flow is one means to achieve the property described in the previous sentence.=20 Hemant=20 From brian.e.carpenter@gmail.com Wed Apr 6 00:17:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357ED3A68C7 for ; Wed, 6 Apr 2011 00:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60KIMjxb-JMT for ; Wed, 6 Apr 2011 00:17:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 181963A68BB for ; Wed, 6 Apr 2011 00:17:07 -0700 (PDT) Received: by wyb29 with SMTP id 29so1107331wyb.31 for ; Wed, 06 Apr 2011 00:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mjf8j48GEttt1dBKkFer/5W6/LudbcgYvfuq2npBZoo=; b=oCC6MFVEmkdYTbG4zedJYqUDKY7n7Hwzn5ucyvYLytQ5b0PAuBnfKHalM883c+UUsL U70LaNwn8mBXt7uxmTK+AZv6fiGc0Si592QWGuH6Y5rBy7iovrIPTa2MfblzbhmXfxv0 QhAqyaj3cMKbb0zc9C6B3JCj2L388XkKMtcvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ZX1C/yEnYsD9ZF/svu2sCBRr9u+SPNociLo42NVVSjS6hbwQgyaRUpS0cOz1MvTh1z IJgrt1AH+FACz2y+UFTrpbxdrcaUI8VDaJXYUlAsloy9rTSOw+aeTSj9sVlZgrYPjyU7 xrB8deW3N+eNywa4rkpODXLBp7jYfUbKWMkFA= Received: by 10.216.171.133 with SMTP id r5mr6069219wel.91.1302074330634; Wed, 06 Apr 2011 00:18:50 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id bs4sm155115wbb.52.2011.04.06.00.18.48 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 00:18:49 -0700 (PDT) Message-ID: <4D9C13D5.1030800@gmail.com> Date: Wed, 06 Apr 2011 19:18:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com><19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com><201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com><9ED6022F-6863-4267-A268-C73240098539@apple.com> <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391466@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301391466@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 07:17:09 -0000 I have a quite strongly held belief that trying to be mathematically precise (not to say pedantic) has never worked well in IETF protocols. (OK, there is one possible exception, namely NTP.) Our implementors are not going to understand subtleties such as 'low discrepancy'. IMHO, arguing about the correct mathematical formulation is not quite the point. We do seem to agree that the important point is that the final output of the hash function used to select between alternate routes is uniformly distributed. Asking for flow label values that are reasonably well distributed as input to that hash function is enough. Any stateless method that provides this will do. Frankly I don't care whether we all it pseudo-random, quasi-random, or mashed potato. (Counting from 1 will not do, because it's stateful.) Regards Brian Carpenter On 2011-04-06 13:34, Hemant Singh (shemant) wrote: > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Tuesday, April 05, 2011 8:08 PM > To: james woodyatt > Cc: 6MAN Working Group > Subject: Re: Pseudorandom Flow Labels > > >> What is *required* is that the hash function (or whatever function >> that is used) on the router maps the tuples in a *uniform* way across >> the range of possible outputs. > >> If you have 10 links, and all your Flow Labels are clustered around >> low ten values, but in an approximately uniform way, a simple modulo >> hash will get you the kind of distribution you need. > >> The range of values of the flow label itself does not need to be >> uniformly distributed. > >> That is why incrementing a counter for each new flow provides adequate >> properties. I remain unconvinced that we need to require that they >> exhibit pseudo randomness, or even be uniform. > >> If that is a requirement, I'd like to see the justification, not just >> hand waiving. > > How about something like the text below: > > A property of the flow label is that when the flow label is used a key > to a hash function the function produces a uniform distribution of hash > values. Thus, incrementing a counter for each new flow is one means to > achieve the property described in the previous sentence. > > Hemant > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Wed Apr 6 01:56:13 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11F028C105 for ; Wed, 6 Apr 2011 01:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8ejh+9gIyww for ; Wed, 6 Apr 2011 01:56:13 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 36B0528C0E7 for ; Wed, 6 Apr 2011 01:56:13 -0700 (PDT) Received: by wwk4 with SMTP id 4so3669136wwk.1 for ; Wed, 06 Apr 2011 01:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/dIFM7wjQcLHKfTzSKT2p9gy27A3Cgx7yWqjCDgrQ4M=; b=aw9Kt+LImXjtmytd4lEKI+K2xGFwP7+U33tgjmPvo1me3WafXXQZSS3Cy9q3f6krG/ maW5rp5Oht091zhM8Qxy9TY7wtpfVIF6LCKO20FORkf0/3vO+vIn9si7CFdwP952zD50 R1VGSzN604tQldfFrfUVMOTKNBh5kuZAC2Awg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=woR0fG0uR5m2Zn9zdFa9uIooJ2yOU6cckQPlz7s4Ijn8M/bFxFKPjB9WsKVWcUjIUb djx8J9z01jkjiA+JE97oz4cdLU9CvXPlzaQhiWlhagfSII3KDCacyvpSGLKya77vO9sg Si2FjTTy0vkD7d1X9gOZ54u44IPmk7K+SYACk= Received: by 10.216.140.219 with SMTP id e69mr515298wej.45.1302080276390; Wed, 06 Apr 2011 01:57:56 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id d59sm147822wed.21.2011.04.06.01.57.54 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 01:57:55 -0700 (PDT) Message-ID: <4D9C2B10.8080500@gmail.com> Date: Wed, 06 Apr 2011 20:57:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: 6MAN WG Last Call: References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> In-Reply-To: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:56:14 -0000 Thomas, Thanks for your three sets of comments. The authors will work on new versions to respond to them. That will take two or three weeks, I think. Regards Brian On 2011-04-06 05:40, Thomas Narten wrote: > Here are my detailed comments on the document. ... From narten@us.ibm.com Wed Apr 6 06:23:14 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9C128C122 for ; Wed, 6 Apr 2011 06:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.666 X-Spam-Level: X-Spam-Status: No, score=-106.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WctO9169-Do0 for ; Wed, 6 Apr 2011 06:23:14 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id DBBC63A69A6 for ; Wed, 6 Apr 2011 06:23:13 -0700 (PDT) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p36D3vqb023573 for ; Wed, 6 Apr 2011 09:03:57 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 01B7B38C803C for ; Wed, 6 Apr 2011 09:24:41 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p36DOmI8177434 for ; Wed, 6 Apr 2011 09:24:49 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p36DOmag007799 for ; Wed, 6 Apr 2011 10:24:48 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-245-36.mts.ibm.com [9.65.245.36]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p36DOkaw007407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 10:24:47 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p36DOiRY026957; Wed, 6 Apr 2011 09:24:44 -0400 Message-Id: <201104061324.p36DOiRY026957@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: Pseudorandom Flow Labels In-reply-to: <4D9C13D5.1030800@gmail.com> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com><19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com><201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com><9ED6022F-6863-4267-A268-C73240098539@apple.com> <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391466@XMB-RCD-109.cisco.com> <4D9C13D5.1030800@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Wed, 06 Apr 2011 19:18:45 +1200." Date: Wed, 06 Apr 2011 09:24:44 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6MAN Working Group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:23:14 -0000 > I have a quite strongly held belief that trying to be mathematically > precise (not to say pedantic) has never worked well in IETF > protocols. Agree completely. :-) > We do seem to agree that the important point is that the final output > of the hash function used to select between alternate routes is > uniformly distributed. Asking for flow label values that are reasonably > well distributed as input to that hash function is enough. Right. But now let me flip-flop a bit. In order to understand what "reasonably well distributed as input" actually means, we need to understand what algorithms are being used by routers when doing ECMP and the like. If we had data about what algorithms are actually used (or are reasonable to implement) we can talk about the distribution properties that are needed on the input side of the hash. Is there any such data? What do the router implementor say to this? I feel like much of the discussion so far about what kind of distribution is needed has been handwaving. To be clear, what I'd like is simple rules on how to set the Flow Label, but no simpler than is necessary to make the ECMP stuff work well in practice. Thomas From scott.brim@gmail.com Wed Apr 6 08:47:34 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF34E28C13D for ; Wed, 6 Apr 2011 08:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC3JRCRsjWUi for ; Wed, 6 Apr 2011 08:47:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7DD4D28C122 for ; Wed, 6 Apr 2011 08:47:33 -0700 (PDT) Received: by iye19 with SMTP id 19so1949576iye.31 for ; Wed, 06 Apr 2011 08:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AQCPhkLnS72RUzUlXf1GcuiYujuQJAWhwHssgr1ACgY=; b=TvXDaI8x+xN1D01YiH73nIfRHjDmf8Mi0F+DkWCdX8xlsoYUyBnNSt4k999BlackCZ m4bKkUQ9UhrHgil/TQtvmLJo7dMcn1RoFSW4SWtx9Bt1HTexg33vz5EawuTUOqmMvJGs xyX81BeRbuwS+r9YMB0SETO+DCG8PEBZmJsuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PiktEt/JLK2HAG4GMFbMzzen+B/A/3RxdQyHl+l/iBvhSW5ZEBZjOKP4BYmmC9mRIU cWAPYhBpUHCvNO7goe4EwMpZooBATB5Rg16GO1uBZCMMisx3an2tJnPZzxsSbt3vVGx8 9jEMjNSFL1/wknE+9Zpr3AbYN1RRcVJCJSasQ= Received: by 10.231.62.72 with SMTP id w8mr1143477ibh.80.1302104957136; Wed, 06 Apr 2011 08:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.208.14 with HTTP; Wed, 6 Apr 2011 08:48:57 -0700 (PDT) In-Reply-To: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> From: Scott Brim Date: Wed, 6 Apr 2011 11:48:57 -0400 Message-ID: Subject: Re: 6MAN WG Last Call: To: Thomas Narten Content-Type: multipart/alternative; boundary=000e0cd56c546e332a04a041efc2 Cc: 6man Mailing List , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:47:34 -0000 --000e0cd56c546e332a04a041efc2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 5, 2011 at 13:40, Thomas Narten wrote: > Here are my detailed comments on the document. I did chat with Brian > directly in Prague about these points as well. Overall, I support this > document. But I think the wording in places needs another round of > revision. > > A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast, or multicast destination that a node > desires to label as a flow. A flow could consist of all packets in a > > This is a circular definition. I think it would be useful to give two > definitions, something like the following: > > A Flow is a sequence of packets originating from a particular > application that should be treated "the same" by the network as > they are forwarded along to their ultimate destination. Packets > within a flow should not be reordered, should not be given > dissimilar QOS treatment, etc. What constitutes a Flow can only be > defined by the application itself. > Sorry, Thomas, I don't think this will work. First, I don't think we can define a "flow" by what the network should do with it, whatever it is. If something is definable, then it has attributes independent of how other things behave toward it. It seems that a flow is anything the node labels with the same flow label. If so (as in your last sentence), then that's the only definition you have. Also, a flow doesn't necessarily originate from a single application. It could be multiple. Some environments don't even have applications. My inclination would be to decline this definition change. The rest looks good. Thanks ... Scot --000e0cd56c546e332a04a041efc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 5, 2011 at 13:40, Thomas Narten <narten@us.ibm.com> wrote:
Here are my detailed comments on the document. I did chat with Brian
directly in Prague about these points as well. Overall, I support this
document. But I think the wording in places needs another round of
revision.

=A0 A flow is a sequence of packets sent from a particular source to a
=A0 particular unicast, anycast, or multicast destination that a node
=A0 desires to label as a flow. =A0A flow could consist of all packets in = a

This is a circular definition. I think it would be useful to give two
definitions, something like the following:

=A0 =A0A Flow is a sequence of packets originating from a particular
=A0 =A0application that should be treated "the same" by the netw= ork as
=A0 =A0they are forwarded along to their ultimate destination. Packets
=A0 =A0within a flow should not be reordered, should not be given
=A0 =A0dissimilar QOS treatment, etc. What constitutes a Flow can only be<= br> =A0 =A0defined by the application itself.

<= div>Sorry, Thomas, I don't think this will work. =A0First, I don't = think we can define a "flow" by what the network should do with i= t, whatever it is. =A0If something is definable, then it has attributes ind= ependent of how other things behave toward it. =A0It seems that a flow is a= nything the node labels with the same flow label. =A0If so (as in your last= sentence), then that's the only definition you have. =A0Also, a flow d= oesn't necessarily originate from a single application. =A0It could be = multiple. =A0Some environments don't even have applications. =A0My incl= ination would be to decline this definition change.

The rest looks good.

Thanks ..= . Scot

--000e0cd56c546e332a04a041efc2-- From fernando.gont.netbook.win@gmail.com Wed Apr 6 10:34:10 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914E43A68EA for ; Wed, 6 Apr 2011 10:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MUx7d3GYej6 for ; Wed, 6 Apr 2011 10:34:09 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 9E06B3A68CE for ; Wed, 6 Apr 2011 10:34:09 -0700 (PDT) Received: by gxk19 with SMTP id 19so789131gxk.31 for ; Wed, 06 Apr 2011 10:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=mC//GIHVdKHtis3s8Ikgx00J3j3G4tvmMon6wGrfj6k=; b=oZvaC7vMTIMWKGwbE8IDCq4+nCKIjGySc2PL5xvP6qOCp4qmZenRUZgIgOh2ZD/df3 GlcsvcSiVpIIa/EMBya/u4m051KUtoppLEcAN/2Klkqv73Vcw/X2DXcyD5e2yQuF4Ida Ei5n1e0HKUVcruSZ/huUPpsYuEv2I4Yo71UOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Mn3ViHzmW3qlrPvSHP6tHiU7ApaHg7q/VD4nG8yA3STV/wzHP91gNypgKT2jiuW58r 4gBy84bIY9DtrOUrGymGlrM9Us1A3pTgnFGs5L6lRQgqsadhQw4QYM+yPTOXlaA/eadF UQjnes6//MLDfmHiRcXN5iI9AZVzz9rGNyt40= Received: by 10.101.174.3 with SMTP id b3mr957577anp.114.1302111353396; Wed, 06 Apr 2011 10:35:53 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id e24sm880572ana.28.2011.04.06.10.35.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 10:35:52 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CA46C.6040404@gont.com.ar> Date: Wed, 06 Apr 2011 14:35:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Shane Amante Subject: Re: Pseudorandom Flow Labels References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:34:10 -0000 Hi, Shane, On 05/04/2011 04:22 p.m., Shane Amante wrote: > With respect to your comments on, both at the mic at the 6MAN WG and > on the list: draft-ietf-6man-flow-3697bis-02 > draft-ietf-6man-flow-ecmp-01 draft-ietf-6man-flow-update-04 > > You seem to take issue with a recommendation for creating/selecting a > flow-label that is "pseudo-random". Can you clarify the reason(s) > you take issue with creating/selecting a flow-label that is > "pseudo-random"? (IMO, the current 'SHOULD' in the draft provides > enough leeway that if implementations have good reason(s) to not > select pseudo-random values for flow-labels they can choose to do so, > but would hopefully have good reasons for that). > > The reason I ask is as follows: 1) RFC 6056: Recommendations for > Transport Protocol Randomization, in particular Appendix A. In > short, a lot of [deployed] implementations are already computing a > pseudo-random value for a transport protocol port (within the > ephemeral port range), today, so IMHO the implementation "burden" of > choosing a pseudo-random value must be quite low and, in theory, > there should be good re-use of that code/logic for selecting > flow-labels. And even if they had to implement this support "from scratch", the code would be very small -- see e.g. the recent patch for port randomization that was posted to freebsd-net. > 2) If we expect that if a intermediate router or switch > is using *just* the 3-tuple of {src_ip, dst_ip + flow_label} as > input-keys to compute a load-balancing hash algorithm, then the more [...] +1 for pseudo-random Flow Labels :-) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Apr 6 10:59:35 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429453A696D for ; Wed, 6 Apr 2011 10:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-GBojOE9z+V for ; Wed, 6 Apr 2011 10:59:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0F2043A696C for ; Wed, 6 Apr 2011 10:59:33 -0700 (PDT) Received: by ywi6 with SMTP id 6so799109ywi.31 for ; Wed, 06 Apr 2011 11:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=8/tGWN75FcGtYhU5LWZvWjmqNYXV8pnBeHLX5a6i/kY=; b=lI2LK0IbqnPHEiEygLZgf58WrhN1dmFd58/D48GqSAcrgkBYGcB2OUu4DqhbbhCPen LETTEQhXB8w3lG74ep0VTo+PhtAZoT+jnTr/lbi17dcqI0/7eUCtPEo/px09b0aDeAo0 VB0ayh+UTEdDwzITIafmlHBSGnt3W8Ze1eDjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=uMp3QTDZYymLRiabAuNc6Adq4LFQoDpmOZx8TcItXAL/MVkHB7LV7Tyo/tqxf6Fr4V WeGKRD1ZsVgVvt1rEEdMIstA1uKc9owJMVco0zItBCIUGzvY981mNNbDtREP9oLysPbW 54n+y+sbrI3knQ6HMM1Mx42kAYeUFcz9s9OVw= Received: by 10.236.78.33 with SMTP id f21mr1511835yhe.123.1302112877563; Wed, 06 Apr 2011 11:01:17 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id l73sm270559yhn.77.2011.04.06.11.01.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:01:16 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CAA66.9090402@gont.com.ar> Date: Wed, 06 Apr 2011 15:01:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Pseudorandom Flow Labels References: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> In-Reply-To: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:59:35 -0000 On 05/04/2011 04:58 p.m., Thomas Narten wrote: > At the core, my concern with "pseudo random" is that I (as an > implementor) do not know what I have to do do satisfy that requirement > and I think in some cases that cost is higher than justified by the > benefit. The current documents do not provide enough concrete > guidance, IMO. If we want folk to actually set the Flow Label to a > good value, tell them what to do. Don't make them think too > hard. Provide them with a suggested algorithm. Don't just say "make it > psuedo random". draft-gont-6man-flowlabel-security aims at addressing this issue. > More to the point, if this could be done in a "stateless" manner, > e.g., by the routine that sends IP datagrams, that would be > nice. I.e., if the IP "send" routine could easily set the Flow Label > whenever it was zero, in a "stateless" manner, that would almost > guarantee we'd get wide spread implementation. FWIW, all of the algorithms in the port randomization RFC (including the hash-based ones) are stateless. > I take it as a given that doing ECMP on the src/dst address gets you > 80% of what you need today. Adding in the Flow Label (if set) will > take you much further. I am not convinced you need real "pseudo > randomness" in the Flow Label to get the benefits being called for. I think that for this sort of ting, "pseudo-random numbers" are your friend. There have been a variety of cases in recent history in which predictable values have been used (TCP ISNs, IP IDs, TCP port numbers, etc.), and only later we realized that there were implications to that. -- which then lead to patches such that pseudo-random values were used, instead. >> 2) If we expect that if a intermediate router or switch is using >> *just* the 3-tuple of {src_ip, dst_ip + flow_label} as input-keys to >> compute a load-balancing hash algorithm, then the more random the >> flow-label, the better load-distribution of /all/ traffic will be >> across the LAG and/or ECMP paths. > > Understood. But what you need for this is not (necessarily) pseudo > randomness. Just sufficient variability (when combined with the > src/dst) to get good distribution on the output side of the hash. Agreed. For instance, the hash-based algorithm recommended in draft-gont-6man-flowlabel-security results in a linear function for each (src IP, dst IP) (that has a random offset...) >> a) As a network operator I have no control over the number of IP >> addresses used by content farms or residential networks. >> Furthermore, it's not clear that as more & more machines (and, >> smartphones!) ship that support multiple CPU's and/or multiple >> cores that each of those discrete computing units will (or, >> should?) receive their own IP address. With IPv6 that's at >> least a possibly, but perhaps due to "ease of development", >> that won't happen often, or at all. If we strongly recommend a >> pseudo-random flow-label and a device is only capable of >> load-balancing using a 3-tuple, then I've at least got a >> [relatively] unique flow-label in the packet header to provide >> load distribution. > > I think we can assume that if we use both the src/dst, we will get a > good degree of distribution in the values. Adding the Flow Label gives > more. I am just not convinced that to get good distribution we need to > *require* (or strongly suggest) psuedo randomness in the Flow > Lable. We know that by simply incrementing the Flow Label by 1 for > each flow, we get sufficient distribution. That is *way* easier to > implement than something else. What we want is unpredictable flow numbers, with a low frequency of FL reuse. A typical call to random() would be just *one*¨way to do it. But, as noted, there are others. For hash-based algorithms, you only compute the hash once for each flow. Then you simply increment the FL for each packet you send for that flow. > Now. What about TEPs? They have no way of knowing whether the port > numbers being used provide proper randomness. That implies if they are > going to generate pseudo-random Flow Labels, they have a *lot* more > work to do. And to be sure that all packets from a given "flow" are > given the same Flow Label, they may have to maintain state. i.e., so > that subsequent packets from the same flow get assigned the same Flow > Label value. Not necessarily: hash functions are your friend (whether you might or might not want to implement this (e.g., for performance reasons) is a different issue) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Apr 6 11:20:33 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C0C28C101 for ; Wed, 6 Apr 2011 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGs8PP6KFH9G for ; Wed, 6 Apr 2011 11:20:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 4AACD28C106 for ; Wed, 6 Apr 2011 11:20:32 -0700 (PDT) Received: by ywi6 with SMTP id 6so807442ywi.31 for ; Wed, 06 Apr 2011 11:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=6HsPU3d3c3KYDPEEqIPNCX2ykG0FQQFEkzrvtUlOjcM=; b=GgrWch572fvdQybcRRz5k4JZhq5fA6AEknetU7wLEJbWwP+LAjbSBUvzTrQIJvcvQw TDi+TN3u8s6GuhtYlPAhg+7tr50gyqXRrEHG8B5XbTa0ZNqM0+HaqHk2ypljcp44ztIv sVgePnEfxBRPQcRLNbVNq/RnIuYp+AjOtEYqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=OnJNuevieOOW0fOKQhjf8DY/MJwU3VgMIWG3BkVx1prBY5U4/N1Qm6iDlqQYBZo+K6 D0waOGTKYSFniPAKX8/wf3mjM2wqCV1kkILIZGgNUkbqpayjo0FWuFZkou0McxiY73X6 76S8JBkYD37KSApwT4eHGvJfo4PGbapqlc9Sk= Received: by 10.150.193.10 with SMTP id q10mr2092890ybf.413.1302114136038; Wed, 06 Apr 2011 11:22:16 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id p33sm803648ybk.2.2011.04.06.11.22.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:22:15 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CAF52.9050805@gont.com.ar> Date: Wed, 06 Apr 2011 15:22:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> In-Reply-To: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:20:33 -0000 Thomas, On 05/04/2011 05:36 p.m., Thomas Narten wrote: > Case in point about how we are being *extremely* loose in using the > term "pseudo random". [....] > Part of my objection to the term "pseudo random" is that the term has > not been defined within the context of the Flow Label. You raise a very good point, indeed. For instance, when we talk about e.g. "port randomization", we're really talking about "producing port numbers that are unpredictable by off-path attackers". To make this terminology issue worse, it has been argued a few times (by some mathematician IETFers) that the properties that we need for the "hash" functions in the hash-based algorithms are really that of PRFs (Pseudo Random Functions) (i.e., hash functions being a specific example). In summary, I agree with the terminology issue that you've raised. I'd probably argue that the best way to go is to specify which properties we want for Flow Labels, such as they have been specified for port numbers in RFC 6056. Namely: * We want Flow Labels that unpredictable by off-path attackers (history has taught us that this is a good proactive measure) * We want an algorithm for generating FL that produces FLs that do not repeat with a high frequency (i.e., they are distributed normally) One possible algorithm for achieving these properties is calling a random()-like function. But there are others, such as the hash-based algorithms specified in draft-gont-6man-flowlabel-security. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Apr 6 11:32:42 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0FF3A690A for ; Wed, 6 Apr 2011 11:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M11ZT10tqzS for ; Wed, 6 Apr 2011 11:32:41 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 8DE733A68B9 for ; Wed, 6 Apr 2011 11:32:41 -0700 (PDT) Received: by yxk30 with SMTP id 30so811758yxk.31 for ; Wed, 06 Apr 2011 11:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=EMIPNH3b7sRoWoA0zen0Zs0MtHXfXgZNMvAVwUIJwv8=; b=XzZGz1lMiXch+jSZ9jYfSXDCKeQ81RbQQdTbjhGskgI3AQ5O4B99xvAP0k6siczPIZ uDtAREQbJhRoHAUkaW/lOIpV6j2qOhE/pOR+0KgcLsLZ46b/wpwJLrP79HotcE3bsfnn nUa7aDQNPTaqIZ2y+4M686jSCDS1CMjrrPsmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=CGKmOG5KkA/M+ih3aQRPvMejHhqpHiE6OyHsE8SmaXUiYXHzojOQffi5FwQp23nGIT RZTJ8tvsfhq8BX5S5d1ZCQ2fbetYaHhgpdCT/mpnbxJuaJZ0ZsROYgUaePurnnv2fzSX W5an62ZstrEElpYuScTnj74f2TgUKDVZPmG5I= Received: by 10.236.103.72 with SMTP id e48mr839086yhg.458.1302114865387; Wed, 06 Apr 2011 11:34:25 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id h63sm287457yhm.86.2011.04.06.11.34.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:34:24 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CB22B.8010707@gont.com.ar> Date: Wed, 06 Apr 2011 15:34:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Shane Amante Subject: Re: Pseudorandom Flow Labels References: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> <92DAE8F3-471F-4331-8882-3788631959F5@castlepoint.net> In-Reply-To: <92DAE8F3-471F-4331-8882-3788631959F5@castlepoint.net> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:32:42 -0000 Shane, On 05/04/2011 06:23 p.m., Shane Amante wrote: > As I pointed out below, we already have pseudorandom distribution of > flows today, given that most host implementations use RFC 6056 and > (IPv4) load-balancing routers/switches use the 5-tuple as input-keys > ... included in those input-keys is a "pseudorandom ephemeral port". Note that e.g. Linux implements the hash-based algorithm in RFC 6056, rather than the random()-based algorithms. -- FWIW, see my response to Thomas wrt the terminology that we are using. >> I think we can assume that if we use both the src/dst, we will get >> a good degree of distribution in the values. Adding the Flow Label >> gives more. I am just not convinced that to get good distribution >> we need to *require* (or strongly suggest) psuedo randomness in the >> Flow Lable. We know that by simply incrementing the Flow Label by 1 >> for each flow, we get sufficient distribution. That is *way* easier >> to implement than something else. > > Unfortunately, if: a) All hosts at a site start off selecting "1" > for their flow-labels; We should have already learned the lesson that this is a really bad choice. > or, b) Don't cycle through the full-range of > flow-label values; This would be an implementation bug. > or, c) a [large] set of hosts experience > synchronization of flow-label values; Given that the FL field is large enough, and that the offset itself is random, I deem this as *very* unlikely. Also, for synchronization to occur, all those hosts would need to have the same frequency of flows/time. -- and since the src IP would be also used for ECMP/LAG, then I don't think that this would be a big deal, either. > or, d) Reset back to > flow-label "1" after some short time period ... This would be a really dumb thing to do, btw. Note: I'm not arguing that a random()-based algorithm would be a bad idea. I'm arguing that such an algorithm is not necessarily the only possible one, and not necessarily the best possible option, either. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Apr 6 11:45:55 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CFE28C0D6 for ; Wed, 6 Apr 2011 11:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-lBKVvW+w-T for ; Wed, 6 Apr 2011 11:45:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 8795C28B23E for ; Wed, 6 Apr 2011 11:45:54 -0700 (PDT) Received: by ywi6 with SMTP id 6so817437ywi.31 for ; Wed, 06 Apr 2011 11:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Nd1rjkUOUjku7jHs6LKVoJXxc5J+0nVyetju2bY1E44=; b=lG9RgZv8R3ksGrhnydSpfv2PXdj1DjI9FY7enVy3nRgKqAu3ujkCtrquJm0jtD5TAY PqDX9yDULPVwuADi5Y1te+MZ04S+JBLOo8J76f2AM+Oe1XAg1XJIb2tj+63mjq8PI+37 vcHpLdv44aNelcoxE2d6a/H9lIiDraOycgkrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=YQ0gIQNq4CJFMkA6I7RkubaDxGWVABJvlNz4YLdJJsqjBeljmn/i5WzlCGJTNekiYw hmDLLzBsD2MplAOje4Ngvf47X62EkkqYqAQHvsDeFQ6N2grYIsClrKGJtgllsz7u1Fk8 1ShOq071KHo5vPrY5fwqZSDeUpSIMz5zUz5cI= Received: by 10.150.147.15 with SMTP id u15mr2379801ybd.327.1302115658389; Wed, 06 Apr 2011 11:47:38 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id w1sm497467ybl.24.2011.04.06.11.47.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 11:47:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CB542.6010807@gont.com.ar> Date: Wed, 06 Apr 2011 15:47:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com><19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com><201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com> <9ED6022F-6863-4267-A268-C73240098539@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391452@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301391452@XMB-RCD-109.cisco.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:45:55 -0000 Hi, Hermant, On 05/04/2011 10:15 p.m., Hemant Singh (shemant) wrote: > Snipped from RFC 4193 is this text. "pseudo-randomly allocated global > ID". If pseudo-random was accepted in this RFC, why are we discussing > pseudo-random again? Because the requirements are different. For RFC 4193, the IIDs must be unpredictable to any host in the Internet. For FLs, they only need to be unpredictable by off-path attackers. For RFC4193, it wouldn't make sense to select them with a hash-based approach such as the one in draft-gont-6man-flolabel-security, as while you get incremental addresses, you could still be tracked. But this does not apply to FLs -- see the et of requirements in one of my other posts. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From narten@us.ibm.com Wed Apr 6 11:48:57 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3463128C104 for ; Wed, 6 Apr 2011 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.662 X-Spam-Level: X-Spam-Status: No, score=-106.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxvIfyN4cnWD for ; Wed, 6 Apr 2011 11:48:56 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 4B7313A690A for ; Wed, 6 Apr 2011 11:48:56 -0700 (PDT) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p36IMw3X003338 for ; Wed, 6 Apr 2011 14:22:58 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 276D438C803C for ; Wed, 6 Apr 2011 14:50:25 -0400 (EDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p36Inxoa135716 for ; Wed, 6 Apr 2011 14:50:00 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p36InxMD001634 for ; Wed, 6 Apr 2011 12:49:59 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-245-36.mts.ibm.com [9.65.245.36]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p36InvD9001572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 12:49:58 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p36InujN029813; Wed, 6 Apr 2011 14:49:56 -0400 Message-Id: <201104061849.p36InujN029813@cichlid.raleigh.ibm.com> To: Scott Brim Subject: Re: 6MAN WG Last Call: In-reply-to: References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> Comments: In-reply-to Scott Brim message dated "Wed, 06 Apr 2011 11:48:57 -0400." Date: Wed, 06 Apr 2011 14:49:56 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: 6man Mailing List , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:48:57 -0000 Hi Scott. Scott Brim writes: > > A Flow is a sequence of packets originating from a particular > > application that should be treated "the same" by the network as > > they are forwarded along to their ultimate destination. Packets > > within a flow should not be reordered, should not be given > > dissimilar QOS treatment, etc. What constitutes a Flow can only be > > defined by the application itself. > > > Sorry, Thomas, I don't think this will work. First, I don't think we can > define a "flow" by what the network should do with it, whatever it > is. Well, we are defining a flow by what the network SHOULD NOT do with packets belonging to the same flow. I.e., packets within a Flow should not be reordered. That seems to be the key requirement/principle. (Are there other attributes?) > If something is definable, then it has attributes independent of how > other things behave toward it. It seems that a flow is anything the > node labels with the same flow label. Right. > If so (as in your last sentence), then that's the only definition > you have. Also, a flow doesn't necessarily originate from a single > application. It could be multiple. Agreed. > Some environments don't even have applications. My inclination > would be to decline this definition change. What I think is worth highlighting is that what constitutes a flow can only be defined by the source of the traffic (i.e., the application(s) or whatever is at the higher layer). The source node may be using heuristics to label flows that don't completely match up with what the application thinks. That is not necessarily a problem (it's reality), but I think its useful to make that distinction. I.e., ideally, the higher layers are what label individual flows. But if that doesn't happen, the sending node can use heuristics (like looking at port numbers to fill in the Flow Label) and do pretty well. Thomas From scott.brim@gmail.com Wed Apr 6 13:20:39 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C563A69B9 for ; Wed, 6 Apr 2011 13:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqC5PT7ilRbg for ; Wed, 6 Apr 2011 13:20:38 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 383E03A6994 for ; Wed, 6 Apr 2011 13:20:38 -0700 (PDT) Received: by iwn39 with SMTP id 39so2235250iwn.31 for ; Wed, 06 Apr 2011 13:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9IBKXXDXRJJmQWeRjnknGgqJ90FAS8Ln4lfV7MGZ5SU=; b=HtRJIuh+tg0LaW+Yr8NemsqBQFIsPVR4RtqqaERZlpZZMZ1rGmEB4ialjssiPv7Fj0 O4S3OiTTTMOQmb6GXh1l7eOoPVTY6GjIZCkTB/0LsxzC0PJuX8JUodLsxE00E0P4grZW 5SRuDeHx+RvMPv0tvR/zhW9478B2roPyQbTf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xl1uAUoNuhKwMR0nV/Stz1H7ruVmQul2JFhwsrgEYKUaHAkzDeCOBQ34SqD5umMwaB GWgB5jLM+ei3vPz1BLzQuPhTdkKtCCpix8/+6DpTxN7GAhHi6lJT8IEH3KcgAeVwSiPf lm/a9IrMKTWLIG7wDqTPXFkK7vBX1nw1lsVes= Received: by 10.231.188.167 with SMTP id da39mr59376ibb.30.1302121342122; Wed, 06 Apr 2011 13:22:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.208.14 with HTTP; Wed, 6 Apr 2011 13:22:02 -0700 (PDT) In-Reply-To: <201104061849.p36InujN029813@cichlid.raleigh.ibm.com> References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> <201104061849.p36InujN029813@cichlid.raleigh.ibm.com> From: Scott Brim Date: Wed, 6 Apr 2011 16:22:02 -0400 Message-ID: Subject: Re: 6MAN WG Last Call: To: Thomas Narten Content-Type: multipart/alternative; boundary=001636c92bc80d3b7404a045c033 Cc: 6man Mailing List , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:20:39 -0000 --001636c92bc80d3b7404a045c033 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 14:49, Thomas Narten wrote: > Scott Brim writes: > > > > A Flow is a sequence of packets originating from a particular > > > application that should be treated "the same" by the network as > > > they are forwarded along to their ultimate destination. Packets > > > within a flow should not be reordered, should not be given > > > dissimilar QOS treatment, etc. What constitutes a Flow can only be > > > defined by the application itself. > > > > > > Sorry, Thomas, I don't think this will work. First, I don't think we can > > define a "flow" by what the network should do with it, whatever it > > is. > > Well, we are defining a flow by what the network SHOULD NOT do with > packets belonging to the same flow. I.e., packets within a Flow should > not be reordered. That seems to be the key requirement/principle. (Are > there other attributes?) > Last sentence first: Yes and the text that was there was "A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that a node desires to label as a flow." ... but what the network should/should not do SHOULD be farther down in the draft where such things are already discussed, not in the (very small, simple) definition of a flow at the beginning, no? But let's not spend a lot of time on it. Completely agree on the rest. > What I think is worth highlighting is that what constitutes a flow can > only be defined by the source of the traffic (i.e., the application(s) > or whatever is at the higher layer). The source node may be using > heuristics to label flows that don't completely match up with what the > application thinks. That is not necessarily a problem (it's reality), > but I think its useful to make that distinction. > > I.e., ideally, the higher layers are what label individual flows. But > if that doesn't happen, the sending node can use heuristics (like > looking at port numbers to fill in the Flow Label) and do pretty well. > --001636c92bc80d3b7404a045c033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 6, 2011 at 14:49, Thomas Narten <narten@us.ibm.com> wrote:
Scott Brim <sc= ott.brim@gmail.com> writes:

> > =A0 =A0A Flow is a sequence of packets originating from a particu= lar
> > =A0 =A0application that should be treated "the same" by= the network as
> > =A0 =A0they are forwarded along to their ultimate destination. Pa= ckets
> > =A0 =A0within a flow should not be reordered, should not be given=
> > =A0 =A0dissimilar QOS treatment, etc. What constitutes a Flow can= only be
> > =A0 =A0defined by the application itself.
> >

> Sorry, Thomas, I don't think this will work. =A0First, I don't= think we can
> define a "flow" by what the network should do with it, whate= ver it
> is.

Well, we are defining a flow by what the network SHOULD NOT do with packets belonging to the same flow. I.e., packets within a Flow should
not be reordered. That seems to be the key requirement/principle. (Are
there other attributes?)

Last sentence = first: Yes and the text that was there was

=A0 &qu= ot;A flow is a sequence of pac= kets sent from a particular source to a
=A0 pa= rticular unicast, anycast, or multicast destination that a node
=A0 desi= res to label as a flow."

... but what the network should/shoul= d not do SHOULD be farther down in the draft where such things are already = discussed, not in the (very small, simple) definition of a flow at the begi= nning, no?

But let's not spend a lot of time= on it.

Completely agree on the rest.
=A0
What I think is worth highlighting is that what constitut= es a flow can
only be defined by the source of the traffic (i.e., the application(s)
or whatever is at the higher layer). The source node may be using
heuristics to label flows that don't completely match up with what the<= br> application thinks. =A0That is not necessarily a problem (it's reality)= ,
but I think its useful to make that distinction.

I.e., ideally, the higher layers are what label individual flows. But
if that doesn't happen, the sending node can use heuristics (like
looking at port numbers to fill in the Flow Label) and do pretty well.
--001636c92bc80d3b7404a045c033-- From john@jlc.net Wed Apr 6 13:42:40 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18683A69B9 for ; Wed, 6 Apr 2011 13:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trOC5zMnZN9q for ; Wed, 6 Apr 2011 13:42:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 575CC3A67A3 for ; Wed, 6 Apr 2011 13:42:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3B0DD33C23; Wed, 6 Apr 2011 16:44:24 -0400 (EDT) Date: Wed, 6 Apr 2011 16:44:24 -0400 From: John Leslie To: Fernando Gont Subject: Re: Pseudorandom Flow Labels Message-ID: <20110406204424.GG24474@verdi> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9CAF52.9050805@gont.com.ar> User-Agent: Mutt/1.4.1i Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:42:41 -0000 Fernando Gont wrote: > > * We want Flow Labels that unpredictable by off-path attackers (history > has taught us that this is a good proactive measure) I'm afraid I don't follow: what sort of attack could an off-path attacker mount by correctly guessing the Flow Label? -- John Leslie From fernando.gont.netbook.win@gmail.com Wed Apr 6 14:20:28 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AF43A6956 for ; Wed, 6 Apr 2011 14:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVz+CEi-oNLP for ; Wed, 6 Apr 2011 14:20:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 9460A3A67D3 for ; Wed, 6 Apr 2011 14:20:27 -0700 (PDT) Received: by gwb20 with SMTP id 20so670437gwb.31 for ; Wed, 06 Apr 2011 14:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=iGVwclmMeZ7ntcabJXTfND1KUD7wKA43Aae353+UI7U=; b=SmdRDwAwypESQzQ2SIAIEnrKzCMryPY4a3OE3XmTLuMdh/LUiX2rIWNXK9/tvGwBxN uiTTKYb5oxaQhaYzfIq/UEGEQVXzOZk7ITN/veMOAFvUuHzg9e0JBgfBahDZF/VPQ/ds iW7PVJ5b6HSEsqxbxVGt5f9scwDuejoC4nNMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=DmhBLelL7qvcr7U+5lusHX03hgkI/TK/Dq0YlpY3JGbph3U8STQ8OuEPxyil2eqKZV lYruWSHuhpvO/eDCcITbdiY3UA9Ng+uIZGP4J2oRshivFL9E2Q4KKsNyrhois3ZBQNu1 TyKORVfVl6paDf2ZZrSq9qLLAETCsgCOKj2mU= Received: by 10.236.77.97 with SMTP id c61mr122401yhe.297.1302124931094; Wed, 06 Apr 2011 14:22:11 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id c17sm1065743anc.41.2011.04.06.14.22.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 14:22:10 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CD97D.1060208@gont.com.ar> Date: Wed, 06 Apr 2011 18:22:05 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Leslie Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> <20110406204424.GG24474@verdi> In-Reply-To: <20110406204424.GG24474@verdi> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:20:28 -0000 John, On 06/04/2011 05:44 p.m., John Leslie wrote: > Fernando Gont wrote: >> * We want Flow Labels that unpredictable by off-path attackers (history >> has taught us that this is a good proactive measure) > > I'm afraid I don't follow: what sort of attack could an off-path > attacker mount by correctly guessing the Flow Label? Play with ECMP/LAG. And, it's clear you could never implement something like draft-blake-ipv6-flow-label-nonce-02 if FLs are predictable. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From shane@castlepoint.net Wed Apr 6 14:43:08 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8560528B797 for ; Wed, 6 Apr 2011 14:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLEpVTELKJCC for ; Wed, 6 Apr 2011 14:42:50 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 489803A67E3 for ; Wed, 6 Apr 2011 14:42:50 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 13EAF26803D; Wed, 6 Apr 2011 15:44:34 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 06 Apr 2011 15:44:34 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=51228; data-bytes=0 Subject: Re: Pseudorandom Flow Labels Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4D9CAF52.9050805@gont.com.ar> Date: Wed, 6 Apr 2011 15:44:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <87F2B923-3FC6-4879-8C81-B9C283AC5EA0@castlepoint.net> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:43:08 -0000 Fernando, Thomas, On Apr 6, 2011, at 12:22 MDT, Fernando Gont wrote: > Thomas, >=20 > On 05/04/2011 05:36 p.m., Thomas Narten wrote: >> Case in point about how we are being *extremely* loose in using the >> term "pseudo random". > [....] >> Part of my objection to the term "pseudo random" is that the term has >> not been defined within the context of the Flow Label. >=20 > You raise a very good point, indeed. For instance, when we talk about > e.g. "port randomization", we're really talking about "producing port > numbers that are unpredictable by off-path attackers". >=20 > To make this terminology issue worse, it has been argued a few times = (by > some mathematician IETFers) that the properties that we need for the > "hash" functions in the hash-based algorithms are really that of PRFs > (Pseudo Random Functions) (i.e., hash functions being a specific = example). >=20 > In summary, I agree with the terminology issue that you've raised. I'd > probably argue that the best way to go is to specify which properties = we > want for Flow Labels, such as they have been specified for port = numbers > in RFC 6056. Namely: >=20 > * We want Flow Labels that unpredictable by off-path attackers = (history > has taught us that this is a good proactive measure) > * We want an algorithm for generating FL that produces FLs that do not > repeat with a high frequency (i.e., they are distributed normally) I like your (attempt at) a more precise definition that Thomas has been = asking for. I would think another desirable property of (host-generated?) = flow-labels might be that, by default, they strive to preserve privacy = of the transmitter. IOW, flow-labels cannot be used to track = individuals (over time), because they are traceable back to a particular = implementation or, worse, a specific device. > One possible algorithm for achieving these properties is calling a > random()-like function. But there are others, such as the hash-based > algorithms specified in draft-gont-6man-flowlabel-security. Right. -shane > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 From fernando.gont.netbook.win@gmail.com Wed Apr 6 15:14:37 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DE83A692F for ; Wed, 6 Apr 2011 15:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgm3JFuto3CE for ; Wed, 6 Apr 2011 15:14:36 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 4B5E63A67E9 for ; Wed, 6 Apr 2011 15:14:36 -0700 (PDT) Received: by yic13 with SMTP id 13so902850yic.31 for ; Wed, 06 Apr 2011 15:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=nX+9GbpI+FZdo33lPy/zotI5DZA6+WnQ9ouZjvVQjGw=; b=OHdlBBzS19NeSJrm4x788ce1JtXo+euZ6WvRFIa50Q23UmsKT2eBvVpTf/nyoDYAiz T57nNhLlT921vBtAarbwAiGFis/csbe/ODPOF2RHv4m8iUBZRST0qT/1bu+xJb6pJK3E 8Wq07y3p1cqMAWWS0jpW48C9FLuTpiAFsku/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=qXjExgVLXrWAe1UGC9uLY+5bR1JfuIEundnV9UhBw2R9Pvh26K2RgLX6tZf0yQleEl WKrCtjj0A6tnUGZYFK43QSA47i+Wsh2PBiMhy1vl5ly9G0QoQ1B0zfdrGNBx1y3nBmGY bE8xXYakaeVw0ScTLuf7/7iVeazCzaqxr6V74= Received: by 10.150.165.12 with SMTP id n12mr175954ybe.16.1302128180144; Wed, 06 Apr 2011 15:16:20 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id t5sm590849ybe.14.2011.04.06.15.16.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 15:16:18 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CE62C.4070804@gont.com.ar> Date: Wed, 06 Apr 2011 19:16:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Shane Amante Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> <87F2B923-3FC6-4879-8C81-B9C283AC5EA0@castlepoint.net> In-Reply-To: <87F2B923-3FC6-4879-8C81-B9C283AC5EA0@castlepoint.net> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:14:37 -0000 Hi, Shane, On 06/04/2011 06:44 p.m., Shane Amante wrote: >> * We want Flow Labels that unpredictable by off-path attackers >> (history has taught us that this is a good proactive measure) * We >> want an algorithm for generating FL that produces FLs that do not >> repeat with a high frequency (i.e., they are distributed normally) > > I like your (attempt at) a more precise definition that Thomas has > been asking for. > > I would think another desirable property of (host-generated?) > flow-labels might be that, by default, they strive to preserve > privacy of the transmitter. IOW, flow-labels cannot be used to track > individuals (over time), because they are traceable back to a > particular implementation or, worse, a specific device. While I agree with this, this seems to be like a requirement for psedu-randomness. That is, if all hosts in my local network set the FL with random(), and only my hosts implements the hash based scheme in e.g. draft-gont-flowlabel-security, then you might argue that the FL could be exploited to track me (or well, actually identify my host in my local network, even if I'm using privacy addresses). But this is already the case for virtually all protocol parameters on which there's some room for choice. (From TCP's initial window to IPv6 Hop Limit value, etc.) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter@gmail.com Thu Apr 7 00:31:02 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AEA3A688C for ; Thu, 7 Apr 2011 00:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AesNYeE3k2Ig for ; Thu, 7 Apr 2011 00:31:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2177C3A6814 for ; Thu, 7 Apr 2011 00:31:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so2155701wyb.31 for ; Thu, 07 Apr 2011 00:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gGS+2HWn0Wp+/RyLPD7zON52BvRL+q4CKi/SsBsPG6I=; b=dl/mhUWzCx2pkAxuh+9Ag/OwhiTt8N1Qq8qVFCLTGoBSHDYJ/bNZCZVCIKp1qlsI2i 7m6sZ4tb7GpFOGSOk6VxekOMPFlpEjk3n555xkLc6GOVglvkEkBoz9VO2cCBHGq2uGsP HHf6G+qAoWoEVtTmQw73QTmo3668kWr3G/7MU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=G3pe8qsi7p1yzoL7oF/SkBL0doxJmidxtf8o7aPmKNwCmOQMCYmX6+Ls2T5aLfa+LM UFAQFBlDGAT3ATxPAmBlBQgZF66cDhur1hXZBp19EmZZbnDvipgAc5PwMSmHXIHupL4H VFq0hlj8MVQHz14LMvGXx6e3pEHudr6E7P2Tw= Received: by 10.227.206.78 with SMTP id ft14mr509412wbb.136.1302161564726; Thu, 07 Apr 2011 00:32:44 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id z13sm848030wbd.46.2011.04.07.00.32.43 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:32:43 -0700 (PDT) Message-ID: <4D9D6898.4090502@gmail.com> Date: Thu, 07 Apr 2011 19:32:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> <87F2B923-3FC6-4879-8C81-B9C283AC5EA0@castlepoint.net> <4D9CE62C.4070804@gont.com.ar> In-Reply-To: <4D9CE62C.4070804@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:31:02 -0000 Setting the flow label by calling random() cannot be a stateless method - it would mean storing the value for use on future packets of the same flow. We need a stateless method. Brian On 2011-04-07 10:16, Fernando Gont wrote: > Hi, Shane, > > On 06/04/2011 06:44 p.m., Shane Amante wrote: > >>> * We want Flow Labels that unpredictable by off-path attackers >>> (history has taught us that this is a good proactive measure) * We >>> want an algorithm for generating FL that produces FLs that do not >>> repeat with a high frequency (i.e., they are distributed normally) >> I like your (attempt at) a more precise definition that Thomas has >> been asking for. >> >> I would think another desirable property of (host-generated?) >> flow-labels might be that, by default, they strive to preserve >> privacy of the transmitter. IOW, flow-labels cannot be used to track >> individuals (over time), because they are traceable back to a >> particular implementation or, worse, a specific device. > > While I agree with this, this seems to be like a requirement for > psedu-randomness. > > That is, if all hosts in my local network set the FL with random(), and > only my hosts implements the hash based scheme in e.g. > draft-gont-flowlabel-security, then you might argue that the FL could be > exploited to track me (or well, actually identify my host in my local > network, even if I'm using privacy addresses). > > But this is already the case for virtually all protocol parameters on > which there's some room for choice. (From TCP's initial window to IPv6 > Hop Limit value, etc.) > > Thanks, From brian.e.carpenter@gmail.com Thu Apr 7 00:36:19 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3CB28C118 for ; Thu, 7 Apr 2011 00:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WWdL3Z+JZlX for ; Thu, 7 Apr 2011 00:36:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5D0DD28C117 for ; Thu, 7 Apr 2011 00:36:18 -0700 (PDT) Received: by wyb29 with SMTP id 29so2159313wyb.31 for ; Thu, 07 Apr 2011 00:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CoUcQy6G11ngq0PRFLIoyAtkOV0Ujh+cgy1djyZMB1w=; b=nEKofKMRqEEBVrjraIPKqiJf/mTyY1+b4hq3LQljqohTEFTir092yKdGJwLsOH1043 Uk/vYxNlZtVMFza6Qt7MHJGMug2myXNCPvaSlymHWPcaORfjEdr7tpcp2+lq+8ZXyrcx UM10jaIwzrrct5KmvZJ/yDeU5AW995t7yC2SQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=rl/C5KFZqdp2N7edgIPiY1Z08QGdYL5jRCJhkd/bDX04Bx2SZPeTN8BRo7BV9OAp5A 8RyZ1FOMZVITtOuZTSaDVn8iOkil9UtZSQNUHBqJ7j2311HO9a7CYVJpADL/EtoQt1MI dF24NGKyVQM9MVHlsqZsKupn8NIAbcxlVpJhY= Received: by 10.227.208.212 with SMTP id gd20mr506293wbb.210.1302161882156; Thu, 07 Apr 2011 00:38:02 -0700 (PDT) Received: from [192.168.1.65] (host86-162-222-107.range86-162.btcentralplus.com [86.162.222.107]) by mx.google.com with ESMTPS id y29sm853961wbd.4.2011.04.07.00.37.48 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:38:00 -0700 (PDT) Message-ID: <4D9D69C9.5020509@gmail.com> Date: Thu, 07 Apr 2011 19:37:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim Subject: Re: 6MAN WG Last Call: References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> <201104061849.p36InujN029813@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Bob Hinden , Brian Haberman , 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:36:19 -0000 On 2011-04-07 08:22, Scott Brim wrote: > On Wed, Apr 6, 2011 at 14:49, Thomas Narten wrote: > >> Scott Brim writes: >> >>>> A Flow is a sequence of packets originating from a particular >>>> application that should be treated "the same" by the network as >>>> they are forwarded along to their ultimate destination. Packets >>>> within a flow should not be reordered, should not be given >>>> dissimilar QOS treatment, etc. What constitutes a Flow can only be >>>> defined by the application itself. >>>> >>> Sorry, Thomas, I don't think this will work. First, I don't think we can >>> define a "flow" by what the network should do with it, whatever it >>> is. >> Well, we are defining a flow by what the network SHOULD NOT do with >> packets belonging to the same flow. I.e., packets within a Flow should >> not be reordered. That seems to be the key requirement/principle. (Are >> there other attributes?) >> > > Last sentence first: Yes and the text that was there was > > "A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast, or multicast destination that a node > desires to label as a flow." > > ... but what the network should/should not do SHOULD be farther down in the > draft where such things are already discussed, not in the (very small, > simple) definition of a flow at the beginning, no? > > But let's not spend a lot of time on it. > > Completely agree on the rest. > > >> What I think is worth highlighting is that what constitutes a flow can >> only be defined by the source of the traffic (i.e., the application(s) >> or whatever is at the higher layer). The source node may be using >> heuristics to label flows that don't completely match up with what the >> application thinks. That is not necessarily a problem (it's reality), >> but I think its useful to make that distinction. >> >> I.e., ideally, the higher layers are what label individual flows. But >> if that doesn't happen, the sending node can use heuristics (like >> looking at port numbers to fill in the Flow Label) and do pretty well. We got a pretty clear message a few discussions ago to drop the speculative text in RFC 3697 about how hosts would support the ability of applications to do this. So the idea is to be silent on this. Brian From fernando.gont.netbook.win@gmail.com Thu Apr 7 01:18:46 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C2328C123 for ; Thu, 7 Apr 2011 01:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOvTKfagUyiC for ; Thu, 7 Apr 2011 01:18:45 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id B2B2328C122 for ; Thu, 7 Apr 2011 01:18:45 -0700 (PDT) Received: by yic13 with SMTP id 13so1072036yic.31 for ; Thu, 07 Apr 2011 01:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=BDdVmai8IlKmOK0m5kNvqo8TZqgwMeMYKP0WFjURbC8=; b=tLFUqz8IVMkpg5h4Cy7S3Bsnnck+yprvX98TMBbed1J56gHwEE9GAPuU+YycLoA9RL JkBSbso1SxBKDaA8bV/+wlARUe/t78JUZNfnmOoxz3owhau63riDqqVPGuHH66ySP7Zq Ljf7Ck7n0KaTPKbNS+KTAMxALCUUVDV3hJdPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=vz6TAB5omqyX1sU7UAcW62jKt0BnZ1VNURaAgps7+DKvfitHEXhsoca4LDg1DrrJNx FraUlfBnOc5fqPsE51OP4TzXMLSs+IxGCB0bUb8Knl3+hshGcEURP5a/yrmMA/+uwzjC kRV6lsPPvCNSlUuwTAnB/bXiaXRghAHya1RPQ= Received: by 10.236.105.172 with SMTP id k32mr760863yhg.83.1302164429743; Thu, 07 Apr 2011 01:20:29 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id u40sm620850yhn.74.2011.04.07.01.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 01:20:28 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9D73C3.7060500@gont.com.ar> Date: Thu, 07 Apr 2011 05:20:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Pseudorandom Flow Labels References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> <87F2B923-3FC6-4879-8C81-B9C283AC5EA0@castlepoint.net> <4D9CE62C.4070804@gont.com.ar> <4D9D6898.4090502@gmail.com> In-Reply-To: <4D9D6898.4090502@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:18:46 -0000 On 07/04/2011 04:32 a.m., Brian E Carpenter wrote: > Setting the flow label by calling random() cannot be a stateless > method - it would mean storing the value for use on future packets > of the same flow. We need a stateless method. Oops, you're right. (Although for FLs set by end nodes this shouldn't matter much) Anyway, you have two stateless methods in draft-gont-6man-flowlabel-security.... :-) Which raises the question ;-) about whether we should work on this I-D. FWIW, IIRC the wg had been polled about adoption of this document as a wg item, but I think only one folk (you?) responded. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From john@jlc.net Thu Apr 7 05:08:41 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753573A6A03 for ; Thu, 7 Apr 2011 05:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Bp6owcroGxR for ; Thu, 7 Apr 2011 05:08:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id C9EE93A68AC for ; Thu, 7 Apr 2011 05:08:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 494F833C24; Thu, 7 Apr 2011 08:10:25 -0400 (EDT) Date: Thu, 7 Apr 2011 08:10:25 -0400 From: John Leslie To: Fernando Gont Subject: Re: Pseudorandom Flow Labels Message-ID: <20110407121025.GH24474@verdi> References: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com> <4D9CAF52.9050805@gont.com.ar> <20110406204424.GG24474@verdi> <4D9CD97D.1060208@gont.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9CD97D.1060208@gont.com.ar> User-Agent: Mutt/1.4.1i Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:08:41 -0000 Fernando Gont wrote: > On 06/04/2011 05:44 p.m., John Leslie wrote: >> Fernando Gont wrote: >>> * We want Flow Labels that unpredictable by off-path attackers (history >>> has taught us that this is a good proactive measure) >> >> I'm afraid I don't follow: what sort of attack could an off-path >> attacker mount by correctly guessing the Flow Label? > > Play with ECMP/LAG. I'm afraid you'll need to be more specific: I still don't see an attack against the sender here. > And, it's clear you could never implement something like > draft-blake-ipv6-flow-label-nonce-02 if FLs are predictable. I did think of that, but decided I'd never want to use such a thing. There are quite a few better ways to accomplish the goal, and far too many opportunities for middleboxes to screw it up. -- John Leslie From fernando.gont.netbook.win@gmail.com Thu Apr 7 10:11:51 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBCF28C164 for ; Thu, 7 Apr 2011 10:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnGQbq+G5eg9 for ; Thu, 7 Apr 2011 10:11:51 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id DE27828C168 for ; Thu, 7 Apr 2011 10:11:50 -0700 (PDT) Received: by yic13 with SMTP id 13so1326140yic.31 for ; Thu, 07 Apr 2011 10:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=2JsVspisUKu4qUAD8QAoBkTW3/ovkQAlO7Cz3rEEIPc=; b=AE50A5+06WEgKW3joUeLA5/MJ1o1RcXFlbuve5WBvTjqe+jjisbdHHggyUP0zzf/Dj C6mZfENEj/V9M4pc7cT/7jEDradnXLC2y99e0DsRsrUwuXLe7a7rHaG6NlcLKRIfIuXm G1BJKPGXwItl0P+5KxQa9UJnp4TjyFzJix+i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=nC7IB0YMOLNPuS7a7cJ0dhYEH9QSeMxM/ILgT1rWcFttWcYJgAPL0Ag4UoFBn1Wccf UVUZaRSe1Qjw5csJi5f9rDVvh3vr1HtyUwPYtpFGjO9BQouDaRv1uHKXT8FGSkLC9VBn /5AJsT3xKTZclrb0IPmK5RIpn/WaMxGgo+4xU= Received: by 10.101.145.37 with SMTP id x37mr898589ann.22.1302196415398; Thu, 07 Apr 2011 10:13:35 -0700 (PDT) Received: from [192.168.123.102] ([190.48.227.167]) by mx.google.com with ESMTPS id k16sm2010638anb.11.2011.04.07.10.13.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 10:13:34 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9DF0B9.6070209@gont.com.ar> Date: Thu, 07 Apr 2011 14:13:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Pseudorandom Flow Labels References: <201104051958.p35JwaJP019044@cichlid.raleigh.ibm.com> <4D9CAA66.9090402@gont.com.ar> In-Reply-To: <4D9CAA66.9090402@gont.com.ar> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Thomas Narten , 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:11:52 -0000 On 06/04/2011 03:01 p.m., Fernando Gont wrote: >> I think we can assume that if we use both the src/dst, we will get a >> good degree of distribution in the values. Adding the Flow Label gives >> more. I am just not convinced that to get good distribution we need to >> *require* (or strongly suggest) psuedo randomness in the Flow >> Lable. We know that by simply incrementing the Flow Label by 1 for >> each flow, we get sufficient distribution. That is *way* easier to >> implement than something else. > > What we want is unpredictable flow numbers, with a low frequency of FL > reuse. A typical call to random() would be just *one*¨way to do it. But, > as noted, there are others. > > For hash-based algorithms, you only compute the hash once for each flow. > Then you simply increment the FL for each packet you send for that flow. Sorry. Please let me correct myself: The hash is computed only once for each flow. And every time a new flow is created, a global counter is incremented. When a new flow is created, the FL is selected by the expresion: FL = hash(src ip, dst ip) + counter and the counter is incremented So, the FL of successive Flow Labels between the same set of IPv6 addresses will have monotonically-increasing FLs. The table in http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-01 illustrates this much better. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From richih.mailinglist@gmail.com Thu Apr 7 13:05:47 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD043A6980 for ; Thu, 7 Apr 2011 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXpnCH9oIOF2 for ; Thu, 7 Apr 2011 13:05:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 88CEA3A690A for ; Thu, 7 Apr 2011 13:05:46 -0700 (PDT) Received: by iwn39 with SMTP id 39so3487391iwn.31 for ; Thu, 07 Apr 2011 13:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=S0Xt4cUxlYbyezl/rlaXkEGjQhgrUQSEgMFtgwFEizI=; b=aZ0ilNgXCgYB9L/AZ2BsmNvnvLMF+BNeqlcyz4yrgfqcB0AS6ugr0YpDv1sIYrxvDa bd6Dnz+d+KkxrE9Z3V2sX9xSQN8kHeCYnPhA2HlRRZnQSQho727EBVIRRkHt61lFXNNJ 5NYKxWA+7XoPK0n1777DeuWwcpXk6Ar4Y35eE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=BBffi6kfH1DVG/et88+WjPUMcbheO280JKDG7d5xoBDBK0nbupTvb5uWMPs6jsr21R 714leaIyfwqFrHZuZ5t6+bAo/zDH0IKSA3OimhBriTwaeBaCojfXTCogeLEiFT/g2nR2 oxz0DH2vJYmEvtvxirPuDS8Ps2YF0D7ae4Meg= Received: by 10.231.18.220 with SMTP id x28mr1254319iba.185.1302206851125; Thu, 07 Apr 2011 13:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.92.16 with HTTP; Thu, 7 Apr 2011 13:07:11 -0700 (PDT) From: Richard Hartmann Date: Thu, 7 Apr 2011 22:07:11 +0200 Message-ID: Subject: Introducing draft-6man-addresspartnaming To: 6man List Content-Type: text/plain; charset=UTF-8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:05:47 -0000 Dear all, Fred Baker asked me to move draft-denog-v6ops-addresspartnaming-04 [1] to 6man. Thus, we are reintroducing it as draft-6man-addresspartnaming-00 without changing anything in the actual text. The DENOG reference has been removed for internal and political reasons but this ID still stems from within part of the community calling itself DENOG and enjoys broad support. draft-6man-addresspartnaming-00 has been uploaded, but it's not released yet as the secretary still needs to make manual changes to document the transition properly. Anyway, after a long time of gathering feedback, we have boiled down the options to hextet and quibble. quibble remains in there mostly for historic reasons and to gather additional feedback. I do not think suggesting two separate terms is useful in the least and we hope to get input on this. The main problem with it is that quibble is overloaded in English and in a negative way. My money is on consensus evolving to drop it in -01. The second question on my mind is if using MUST for hextet is appropriate. Using SHOULD is fine as well though I personally think MUST is better to avoid any and all potential confusion. We are really looking forward to any and all feedback, this issue might not seem to be important at first, but many/most people tend to reconsider after some thinking, thanks, Richard Hartmann [1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming-04 From bob.hinden@gmail.com Thu Apr 7 14:51:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CCF28C0D8 for ; Thu, 7 Apr 2011 14:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.494 X-Spam-Level: X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXlyvwji02jn for ; Thu, 7 Apr 2011 14:51:08 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 5E1343A6943 for ; Thu, 7 Apr 2011 14:51:08 -0700 (PDT) Received: by pxi20 with SMTP id 20so1667958pxi.27 for ; Thu, 07 Apr 2011 14:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=ZX/d2Q1putnJgri1VnSzs1zjt5CZNBjjzWQ1i1R7dvE=; b=NB8hY80P8yIb3nnGIyfPVoVWod65lAzofl09PMtoOkkEj6KuJ+hm+t+3G5trZe1TBq U5tPJPXtIPnazgHFj9FJWDNZQQzy8kLnTEAmOyuK0VfzNVgOFJbei3ENVCchz18EYFkI ALui5li4cswBMO2bhasUctEaSOw74airIX/gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=quKICw2FknIzfjS0oUlij5RX110C5pThjIgn/xOVGwXtRJomRYC3bH/N9pRDX/hWfc a+0UQoXoAAp3At5qdCxGJNhXo4qYbnyiPJTi5mKzkKEMh16jqvGFuy5ax0/Qwp1Ds2D0 e3qTrkQ0vgq/gwMwJjGEtfCdDEV5uVBIU0y4U= Received: by 10.142.150.16 with SMTP id x16mr1117122wfd.173.1302213169879; Thu, 07 Apr 2011 14:52:49 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id x11sm2718204wfd.13.2011.04.07.14.52.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 14:52:47 -0700 (PDT) Subject: Re: Introducing draft-6man-addresspartnaming Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Thu, 7 Apr 2011 14:52:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0433A074-A784-483A-86D0-083878A5377E@gmail.com> References: To: Richard Hartmann X-Mailer: Apple Mail (2.1082) Cc: 6man List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:51:09 -0000 Richard, It is good to discuss this in 6man on the IPv6 list, but if you are = going to resubmit the draft it should be named something like: draft-hartmann-6man-addresspartnaming-00 as it is an individual draft, not a 6man working group document. Thanks, Bob On Apr 7, 2011, at 1:07 PM, Richard Hartmann wrote: > Dear all, >=20 > Fred Baker asked me to move draft-denog-v6ops-addresspartnaming-04 [1] > to 6man. Thus, we are reintroducing it as > draft-6man-addresspartnaming-00 without changing anything in the > actual text. >=20 > The DENOG reference has been removed for internal and political > reasons but this ID still stems from within part of the community > calling itself DENOG and enjoys broad support. >=20 > draft-6man-addresspartnaming-00 has been uploaded, but it's not > released yet as the secretary still needs to make manual changes to > document the transition properly. >=20 >=20 > Anyway, after a long time of gathering feedback, we have boiled down > the options to hextet and quibble. quibble remains in there mostly for > historic reasons and to gather additional feedback. I do not think > suggesting two separate terms is useful in the least and we hope to > get input on this. The main problem with it is that quibble is > overloaded in English and in a negative way. My money is on consensus > evolving to drop it in -01. >=20 > The second question on my mind is if using MUST for hextet is > appropriate. Using SHOULD is fine as well though I personally think > MUST is better to avoid any and all potential confusion. >=20 >=20 > We are really looking forward to any and all feedback, > this issue might not seem to be important at first, but many/most > people tend to reconsider after some thinking, > thanks, >=20 > Richard Hartmann >=20 >=20 > [1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming-04 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From richih.mailinglist@gmail.com Thu Apr 7 17:25:19 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724203A6820 for ; Thu, 7 Apr 2011 17:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz2A1y+nh-EU for ; Thu, 7 Apr 2011 17:25:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D271E3A6808 for ; Thu, 7 Apr 2011 17:25:18 -0700 (PDT) Received: by iye19 with SMTP id 19so3679697iye.31 for ; Thu, 07 Apr 2011 17:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=2MbVT67QYDZL8+NZhMwLr/EJ8qasIBNS8KLOMZVSu+Q=; b=QjN+aNcvX5ocesUMzhZtACaHIM+bF8ne8QTeh8avb0QpqLMNFgcTnOrNeZWtqbMWXG LkynFef4df6R3LvPVYnrxaief3FOYi8EI1bWK52q7thf/3hgOWHM+KIFBDjiwKxuilZM hGJHvYQ0nPoLswkufIc/OplHKaC5+TSyJM+yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=uNvckwQT/qq2feeuQAAu0KVL+G8JEcNYpQcfcap/5gNFo2h9Jg6rr8YXkZFqwKk9pD dnY50Q15+31Wg48RpxAXEToQWyV0gzlmYVu9zCYNb19HJDuvK7RQuLAgy5/MSBLbvpOi t848uersBjY4VXN4Sgz8uIFU6QRcZe/6rVGh0= Received: by 10.43.58.148 with SMTP id wk20mr2500118icb.242.1302222423106; Thu, 07 Apr 2011 17:27:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.92.16 with HTTP; Thu, 7 Apr 2011 17:26:43 -0700 (PDT) In-Reply-To: <0433A074-A784-483A-86D0-083878A5377E@gmail.com> References: <0433A074-A784-483A-86D0-083878A5377E@gmail.com> From: Richard Hartmann Date: Fri, 8 Apr 2011 02:26:43 +0200 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:25:19 -0000 On Thu, Apr 7, 2011 at 23:52, Bob Hinden wrote: > =C2=A0draft-hartmann-6man-addresspartnaming-00 The main work is shared between two editors listed alphabetically so I am unsure how to name this fairly. Suggestions? draft-donnerhackehartmann-6man-addresspartnaming-00 is a tad too long ;) Thanks, Richard From kauer@biplane.com.au Thu Apr 7 18:52:33 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342B13A69AD for ; Thu, 7 Apr 2011 18:52:33 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXNOjORPRYtk for ; Thu, 7 Apr 2011 18:52:31 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by core3.amsl.com (Postfix) with ESMTP id A955E3A69A0 for ; Thu, 7 Apr 2011 18:52:29 -0700 (PDT) Received: from igw.biplane.com.au ([203.26.128.2] helo=[192.168.1.202]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q80to-0000IC-Hh for ipv6@ietf.org; Thu, 07 Apr 2011 21:54:12 -0400 Subject: Re: Introducing draft-6man-addresspartnaming From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-lx676jq2Thm1mxkMU+IN" Date: Fri, 08 Apr 2011 11:54:09 +1000 Message-ID: <1302227649.31306.221.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 01:52:33 -0000 --=-lx676jq2Thm1mxkMU+IN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2011-04-07 at 22:07 +0200, Richard Hartmann wrote: > The second question on my mind is if using MUST for hextet is > appropriate. Using SHOULD is fine as well though I personally think > MUST is better to avoid any and all potential confusion. "hextet" - oh dear. Were there really no better suggestions than quibble and hextet? Sorry for missing the earlier discussions, an I'll pull my head in if it's really gone that far down the track, but "hextet" is wrong on o many levels. It implies that it consists of six things - like a quintet (5), septet(7) or triplet(3). The idea that a hextet is four hex digits is very counter-intuitive. What about "quad"? IPv4 has "dotted quad", but I've never heard that notation referred to as "quad" without the "dotted". I doubt there would be confusion regardless, and certainly not in context. "Quad" accurately conveys the sense of "four", there are four hex digits in each section of an uncompressed IPv6 address etc - seems like a good word. However, "field" is even better. It's straightforward and gets around the fact that the chunk between two colons in an IPv6 address is often *not* actually four hex digits. It may represent any number of hex digits from zero to 32! For such a thing, "hextet"and "quad" are both very wrong. "Field" would remain correct, however. An invented word, unless it has the same quirky, geeky humor of "byte" and "nibble", is most unlikely to be generally adopted. Definitely "SHOULD", not "MUST". People will say what they say. =20 > this issue might not seem to be important at first, but many/most > people tend to reconsider after some thinking, I confess I thought at first you might be joking.... Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-lx676jq2Thm1mxkMU+IN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk2easEACgkQMAcU7Vc29ocZFgCgmcj5JTkFi6U05L4d48ONaKsX n2QAoNAc5KumHi6k4ICEnQ8f690fX27Y =tjOD -----END PGP SIGNATURE----- --=-lx676jq2Thm1mxkMU+IN-- From richih.mailinglist@gmail.com Thu Apr 7 19:02:07 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C4B3A69A2 for ; Thu, 7 Apr 2011 19:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hApnMpNryTR for ; Thu, 7 Apr 2011 19:02:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 294033A69CF for ; Thu, 7 Apr 2011 19:02:06 -0700 (PDT) Received: by iye19 with SMTP id 19so3744791iye.31 for ; Thu, 07 Apr 2011 19:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ysbOoVkriFMhOUGL+CuKiAkM+U3Xa2hp64MUnSqe5Zw=; b=NVLXMDuQVMEW/d0VDdTSoO3WGS/zuCAaN5Og26eoi8vV35t5XwIDap+jMq2gibaOyW rx0e0fIkWv+okhFnlgbwoBmdfdctM0DLjm+gs1D+vXCcM3RtMbVkRDr3qJBQ/ECX2goD 2jtF4BDHASZJjNispvH+h+9EESlWY3m1zSQjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=gOOrbNxFtP8irVL3ty/p7SI1gZwoOASvs8x7JJsY9IncC5xYqn4tvsG75j8TLdBmV0 i7hwL+iOELnI9BeTAyNcD+quRkJkAglUBzzj16Ma1CyUlLMkc4Cpc3O1kjhven5xxFmA ohKZMr35ZQlX/1rRgaEZ1Sa5EbN0kuPN7a94g= Received: by 10.231.61.198 with SMTP id u6mr1537546ibh.160.1302228231119; Thu, 07 Apr 2011 19:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.92.16 with HTTP; Thu, 7 Apr 2011 19:03:31 -0700 (PDT) In-Reply-To: <1302227649.31306.221.camel@karl> References: <1302227649.31306.221.camel@karl> From: Richard Hartmann Date: Fri, 8 Apr 2011 04:03:31 +0200 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming To: Karl Auer Content-Type: text/plain; charset=UTF-8 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 02:02:07 -0000 On Fri, Apr 8, 2011 at 03:54, Karl Auer wrote: > "hextet" - oh dear. Were there really no better suggestions than quibble > and hextet? If you look at -02 of the initial draft, you will find a full list. Googling for the name of the ID will bring up a lot of discussions on various related lists. Finally, hextet and quibble came out _far_ ahead of all other options. FWIW, hextet is the short form of hexadectet. > However, "field" is even better. Field is overloaded and not unique. If anything you would have to say "IPv6 field" which is bulky and context-sensitive. > An invented word, unless it has the same quirky, geeky humor of "byte" > and "nibble", is most unlikely to be generally adopted. Why? It's a unique identifier without pre-existing meaning in the relevant context. > Definitely "SHOULD", not "MUST". People will say what they say. The MUST refers to written documentation. This might or might not change depending on feedback. > I confess I thought at first you might be joking.... I assure you I am not. In somewhat unrelated news, "Karl Auer" is a famous persona of a German comedian. I doubt you named yourself after him, but I always wondered and context is fitting, atm. Thanks for your feedback, Richard From kauer@biplane.com.au Fri Apr 8 01:03:36 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3653E28C106 for ; Fri, 8 Apr 2011 01:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlmzZxkALkUf for ; Fri, 8 Apr 2011 01:03:34 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by core3.amsl.com (Postfix) with ESMTP id EF58228C0E9 for ; Fri, 8 Apr 2011 01:03:33 -0700 (PDT) Received: from igw.biplane.com.au ([203.26.128.2] helo=[192.168.1.202]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Q86gu-00042I-7k for ipv6@ietf.org; Fri, 08 Apr 2011 04:05:16 -0400 Subject: Re: Introducing draft-6man-addresspartnaming From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: <1302227649.31306.221.camel@karl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-u5kChWMbwjdMqMY2fZzJ" Date: Fri, 08 Apr 2011 18:05:15 +1000 Message-ID: <1302249915.31306.332.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 08:03:36 -0000 --=-u5kChWMbwjdMqMY2fZzJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-04-08 at 04:03 +0200, Richard Hartmann wrote: > On Fri, Apr 8, 2011 at 03:54, Karl Auer wrote: > If you look at -02 of the initial draft, you will find a full list. OK. I've read it and find many of the arguments to be generally unconvincing. Right with you on "chazwazza" though :-) If the draft is to document what amounts to a popularity contest for a word, then that's fine, but it would be more honest if it said so, rather than presenting such thin arguments. If there are going to be arguments for and against, they need to be considerably stronger and more relevant than most of those offered in -02. My argument against "hextet" is simple. It is not a legitimate abbreviation of "hexadectet" for two reasons. Firstly, you can't abbreviate "hexadec-" because to do so changes it's meaning from "16-" to "because, along the model of "quintet", "septet" and "octet" (and to a lesser extent triplet), the word "hextet" strongly suggests a set of six things. In contrast to blander options like "chunk" "field" and "segment", it is misleading - there may be zero to four hex digits between two colons, and there are three to eight colon-delimited parts in an IPv6 address. There is no "sixness" in what the word is trying to describe. The argument about uniqueness and context is covered below. > ahead of all other options. FWIW, hextet is the short form of > hexadectet. Well, thanks be! :-) It's still bad though. > Field is overloaded and not unique. If anything you would have to say > "IPv6 field" which is bulky and context-sensitive. Not at all. There are literally tens of thousands of words in English alone that are not unique in meaning and require context to be properly understood. "Field" is one of them - so are "address", "bit" and "colon", for that matter. In the context of IPv6 addresses, there would be no more ambiguity with "field" than there would be for, say, "bit", which could mean "a binary digit" or "a small piece" unless qualified by context: "Er, which bit of the address are we talking about, Marvin?" "The interface ID, Trevor; the bit after the prefix." "Oh, right, you mean the bit starting at bit 65?" "Yeah, though we could move back a couple of bits to give us a bit more room in the subnet, I suppose." "That'd be a bit pointless though, wouldn't it?" "Well, yeah, a bit." "Hextet" is jargon for the sake of jargon. IMHO. > > An invented word, [...] is most unlikely to be generally adopted. >=20 > Why? It's a unique identifier without pre-existing meaning in the > relevant context. No point arguing about whether it will or will not be adopted. Let's see if anyone is calling them hextets five years from now. My money is on "nope". > In somewhat unrelated news, "Karl Auer" is a famous persona of a > German comedian. I doubt you named yourself after him, but I always > wondered and context is fitting, atm. I'm named Karl after my father. Auer is a pretty common Austrian surname. Apart from the comedian, there's a quite famous furniture designer called Karl Auer, a chemist/physicist who was Baron von Welsbach (sadly no relation), and a Waffen-SS Sturmbannfuehrer and recipient of the Iron Cross (happily no relation). And if you say my name quickly, you get "kalauer", which is the German word for a stale joke :-) Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-u5kChWMbwjdMqMY2fZzJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk2ewbQACgkQMAcU7Vc29odC9QCgxbF1p81N8p6d35h81VpKJ+l8 p+QAniMjA2TFuEHuPN9gVfHSyn5HGBWG =kIsB -----END PGP SIGNATURE----- --=-u5kChWMbwjdMqMY2fZzJ-- From richih.mailinglist@gmail.com Fri Apr 8 02:59:39 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470F83A69BC for ; Fri, 8 Apr 2011 02:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-eQbsOuTWWn for ; Fri, 8 Apr 2011 02:59:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 0FBC83A69B8 for ; Fri, 8 Apr 2011 02:59:38 -0700 (PDT) Received: by iye19 with SMTP id 19so4099454iye.31 for ; Fri, 08 Apr 2011 03:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Oa8SGcaHefVOl20SxexeWCvqs3EWE2jRYdcUOfLVhmc=; b=ZmQ8Et3sc75NpOfA6gszEfyjKhGkF9ZNofpIwB0PfyQrFJgxtLLovopSQNbxk52Wec u+Fm0enOy7RK5xXP1Tc2zFXpH+42X/TsaPOYG4hh0T6e7cdzptOtm1145KA1/8spJrxg kL1C49+id8Pu/daLlPfVZSpzu1VbLWeJMpq4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uh6gZoZ9s4WtvtBnUiA62NsurzOoHTRg0x7UlqO1Ula55vkYroS385iMp6tfIt0gNk L9b9mwgmLW7qaUpsv5Uuq+O8eJVqgtfaz7ZAOFGtPwVORcwxLGD1Gzk5qj8m/+Ae4Gbi HaXmM5Y6AC3p0Vqc/joou6sm+YZDR0U8EYYfM= Received: by 10.231.130.153 with SMTP id t25mr1963895ibs.135.1302256883087; Fri, 08 Apr 2011 03:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.92.16 with HTTP; Fri, 8 Apr 2011 03:01:03 -0700 (PDT) In-Reply-To: <1302249915.31306.332.camel@karl> References: <1302227649.31306.221.camel@karl> <1302249915.31306.332.camel@karl> From: Richard Hartmann Date: Fri, 8 Apr 2011 12:01:03 +0200 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming To: Karl Auer Content-Type: text/plain; charset=UTF-8 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:59:39 -0000 On Fri, Apr 8, 2011 at 10:05, Karl Auer wrote: > OK. I've read it and find many of the arguments to be generally > unconvincing. Right with you on "chazwazza" though :-) That's fine. This is why we are here :) > If the draft is to document what amounts to a popularity contest for a > word, then that's fine, but it would be more honest if it said so, > rather than presenting such thin arguments. I am not sure why or how you see this as a popularity contest. We solicited feedback from everywhere and went with the results that showed the most promise of broad and general consensus across both the IETF lists and actual operators around the world. > My argument against "hextet" is simple. It is not a legitimate > abbreviation of "hexadectet" for two reasons. That as may be, it's a nice, short, precise, unique term. It's not unheard of that terms are not 100% correct but widely accepted and in general use. This may not be perfect, but it shows signs of consensus. As you will certainly agree, a commonly term that is in wide an accepted use is better than the current confusion. As you said it's very late in the game, but you are more than welcome to make an alternate suggestion. > there may be zero to four hex digits > between two colons, and there are three to eight colon-delimited parts > in an IPv6 address. This point is half moot as I am agreeing that hextet is not a perfect, "merely" the best, option. Still, no matter how you represent those 16 bits, they are 16 bits. Either way, if anything, this representation issue makes the argument for a not-quite-technically-perfect stronger, imo. > Not at all. There are literally tens of thousands of words in English > alone that are not unique in meaning and require context to be properly > understood. "Field" is one of them - so are "address", "bit" and > "colon", for that matter. In the context of IPv6 addresses, there would > be no more ambiguity with "field" than there would be for, say, "bit", > which could mean "a binary digit" or "a small piece" unless qualified by > context: In technical context, "bit" is reasonably unique to determine that you are referring to a single boolean value. As soon as you are talking about an IPv6 bit, an IPv4 bit or a Mibibytes' bit, you need to add context, though. This is something we would like to avoid for IPv6 "fields". "Field" is perfect inasmuch as it describes pretty much anything. Point in case, the IPv6 RFCs refer to fields (while _not_ specifying this as a definite term, merely as a placeholder as they had to use some name). "Field" is horrible inasmuch as it describes pretty much anything. Bit vector is another technically correct choice which is horribly overloaded with context-sensitive meanings. The goal is to say "look at the fourth hextet" and not "look at the fourth thing, that IPv6 field. Yes, you know what I mean. Yes, it's nice that you call it chazwazza. Would you stop this and look at it, please?" > And if you say my > name quickly, you get "kalauer", which is the German word for a stale > joke :-) Which is why the Comedian chose it. He says it quickly and slurs it. Enough off topic chatter though, the com.au threw me off, last I checked it did not mean .austria ;) Richard From tjc@ecs.soton.ac.uk Fri Apr 8 03:58:57 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025263A69F8 for ; Fri, 8 Apr 2011 03:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7KKSelh+-rQ for ; Fri, 8 Apr 2011 03:58:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 928103A69B8 for ; Fri, 8 Apr 2011 03:58:54 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p38B0Xqn004214 for ; Fri, 8 Apr 2011 12:00:33 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p38B0Xqn004214 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1302260433; bh=BIX0J1XChpps5cz2QlprML1gdNU=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=KX5Z4JrOLthiTUomdkGNX+JHjxB/l0x42eDWZAVSdXYvmS7hyD9beW+9V4swk7pcT iCOngwKKxfwYJ3gDeJsj/fZVHjXhocETMX5+eKis8EATmpqrbqrPzdE6k0YgnEzZdW SGUnOaux5BUumHiC1f8OFDRzG5/SZVW1u8GX73xU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n37C0X00356107436O ret-id none; Fri, 08 Apr 2011 12:00:33 +0100 Received: from dhcp-152-78-94-192.ecs.soton.ac.uk (dhcp-152-78-94-192.ecs.soton.ac.uk [152.78.94.192]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p38B0QkH023300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Apr 2011 12:00:26 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-149--316804490 Subject: Re: Introducing draft-6man-addresspartnaming Date: Fri, 8 Apr 2011 12:00:26 +0100 In-Reply-To: To: 6man References: <29518319-54A8-4477-B245-8BC171128F53@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1082) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n37C0X003561074300; tid=n37C0X00356107436O; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p38B0Xqn004214 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:58:57 -0000 --Apple-Mail-149--316804490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Apr 2011, at 21:07, Richard Hartmann wrote: >=20 > Anyway, after a long time of gathering feedback, we have boiled down > the options to hextet and quibble. quibble remains in there mostly for > historic reasons and to gather additional feedback. I do not think > suggesting two separate terms is useful in the least and we hope to > get input on this. The main problem with it is that quibble is > overloaded in English and in a negative way. My money is on consensus > evolving to drop it in -01. >=20 > The second question on my mind is if using MUST for hextet is > appropriate. Using SHOULD is fine as well though I personally think > MUST is better to avoid any and all potential confusion. Maybe hextet will grow on me. I'll start using it and see what funny = looks or comments I get :) I also wouldn't object to people saying that an IPv6 address consists of = eight hexadecimal quads (given quad is used elsewhere for groups of 4 = things). I would say SHOULD though not MUST. If it catches on, people will just = use it. Tim= --Apple-Mail-149--316804490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Anyway, after a = long time of gathering feedback, we have boiled down
the options to = hextet and quibble. quibble remains in there mostly for
historic = reasons and to gather additional feedback. I do not think
suggesting = two separate terms is useful in the least and we hope to
get input on = this. The main problem with it is that quibble is
overloaded in = English and in a negative way. My money is on consensus
evolving to = drop it in -01.

The second question on my mind is if using MUST = for hextet is
appropriate. Using SHOULD is fine as well though I = personally think
MUST is better to avoid any and all potential = confusion.

Maybe hextet will grow = on me.   I'll start using it and see what funny looks or comments I = get :)

I also wouldn't object to people saying = that an IPv6 address consists of eight hexadecimal quads (given quad is = used elsewhere for groups of 4 things).

I would = say SHOULD though not MUST.   If it catches on, people will just = use it.

Tim
= --Apple-Mail-149--316804490-- From i.grok@comcast.net Fri Apr 8 04:22:59 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093183A69FB for ; Fri, 8 Apr 2011 04:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgKE3xScWekJ for ; Fri, 8 Apr 2011 04:22:58 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 7F88A3A69F8 for ; Fri, 8 Apr 2011 04:22:58 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id UzPY1g0011ZMdJ4A1zQkmj; Fri, 08 Apr 2011 11:24:44 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id UzQi1g00G00PQ6U8czQjRv; Fri, 08 Apr 2011 11:24:43 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p38BOfkH020771 for ; Fri, 8 Apr 2011 07:24:41 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p38BOfQP020769 for ipv6@ietf.org; Fri, 8 Apr 2011 07:24:41 -0400 Date: Fri, 8 Apr 2011 07:24:41 -0400 From: Scott Schmit To: ipv6@ietf.org Subject: Re: Introducing draft-6man-addresspartnaming Message-ID: <20110408112441.GA14605@odin.ulthar.us> Mail-Followup-To: ipv6@ietf.org References: <1302227649.31306.221.camel@karl> <1302249915.31306.332.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1302249915.31306.332.camel@karl> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 11:22:59 -0000 On Fri, Apr 08, 2011 at 06:05:15PM +1000, Karl Auer wrote: > On Fri, 2011-04-08 at 04:03 +0200, Richard Hartmann wrote: > > On Fri, Apr 8, 2011 at 03:54, Karl Auer wrote: > My argument against "hextet" is simple. It is not a legitimate > abbreviation of "hexadectet" for two reasons. Firstly, you can't > abbreviate "hexadec-" because to do so changes it's meaning from "16-" > to "because, along the model of "quintet", "septet" and "octet" (and to > a lesser extent triplet), the word "hextet" strongly suggests a set of > six things. In contrast to blander options like "chunk" "field" and > "segment", it is misleading - there may be zero to four hex digits ^^^^^^^^^^ > between two colons, and there are three to eight colon-delimited parts > in an IPv6 address. There is no "sixness" in what the word is trying to > describe. So, you're talking about base-6 digits when you say "hex digits", right? I wasn't aware that anybody used base-6 notation in computing... In other words, there is precedent here. :-) -- Scott Schmit From jhw@apple.com Fri Apr 8 09:19:46 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EDD3A694F for ; Fri, 8 Apr 2011 09:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofBHTcBOmOIM for ; Fri, 8 Apr 2011 09:19:45 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id DC4B63A6959 for ; Fri, 8 Apr 2011 09:19:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJC00C4CDFAM570@mail-out.apple.com> for ipv6@ietf.org; Fri, 08 Apr 2011 09:21:31 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-84-4d9f360b72ae Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 0C.21.18996.B063F9D4; Fri, 08 Apr 2011 09:21:31 -0700 (PDT) Received: from [66.109.105.84] by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJC00DICDFPAI20@cardamom.apple.com> for ipv6@ietf.org; Fri, 08 Apr 2011 09:21:31 -0700 (PDT) Subject: Re: Introducing draft-6man-addresspartnaming From: james woodyatt In-reply-to: Date: Fri, 08 Apr 2011 09:21:24 -0700 Message-id: References: <29518319-54A8-4477-B245-8BC171128F53@ecs.soton.ac.uk> To: 6MAN X-Mailer: Apple Mail (2.1213) X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:19:46 -0000 On Apr 8, 2011, at 4:00 AM, Tim Chown wrote: > > Maybe hextet will grow on me. I'll start using it and see what funny looks or comments I get I would have preferred "hexquad" but nobody ever listens to me. -- james woodyatt member of technical staff, core os networking From scott.brim@gmail.com Fri Apr 8 16:00:09 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73E428C0CE for ; Fri, 8 Apr 2011 16:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.633 X-Spam-Level: X-Spam-Status: No, score=-103.633 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3pZ2l2aGILF for ; Fri, 8 Apr 2011 16:00:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 647BE3A6A49 for ; Fri, 8 Apr 2011 16:00:07 -0700 (PDT) Received: by vws12 with SMTP id 12so3746586vws.31 for ; Fri, 08 Apr 2011 16:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=ktkAfW5tMD3kc6+jDYZLAPUtPWH/cx7wlnN2DFLqEZU=; b=fUuYgOPid+vGdrisX9b0CgctaBifiyGw4Z0kWO07xi8bsggfPz0vaT+nr2LcJ0aIgX yLdATlsw4IINkzEW/lqTX1IHJBGMv72NIaPHe8E+8ZYf2ukMwRfRAv6d8yDS3QcwzG7N fQJWkmk89Z5wOvhJE2GVfH9fy6U9y2KMkZrg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=CLFEWTuiQfaD1aDEBRbm3iYfXiWSvnZBL1+9BZW86iLUelPyUla0fdlw/7ALKjYYYG 8il18NVUBYCiBpnNbGvmbgcgNaMHYRXBlGooyv2yKQIukYd/i00hfyfIUvUuPmYnBMbh HnlDzdM4KJtWybFOsZZz3PKrO+emAcBzHpvwQ= MIME-Version: 1.0 Received: by 10.52.98.97 with SMTP id eh1mr4030505vdb.148.1302303712679; Fri, 08 Apr 2011 16:01:52 -0700 (PDT) Received: by 10.52.159.100 with HTTP; Fri, 8 Apr 2011 16:01:52 -0700 (PDT) Received: by 10.52.159.100 with HTTP; Fri, 8 Apr 2011 16:01:52 -0700 (PDT) Date: Fri, 8 Apr 2011 19:01:52 -0400 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming From: Scott Brim To: Richard Hartmann Content-Type: multipart/alternative; boundary=20cf307d046c2f163f04a0703656 Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 23:00:10 -0000 --20cf307d046c2f163f04a0703656 Content-Type: text/plain; charset=ISO-8859-1 If enough people express support we can make this a BCP, but whatever is done here, "the market" will decide on its own. . [Sent from my Vibrant.] --20cf307d046c2f163f04a0703656 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If enough people express support we can make this a BCP,=A0 but whatever= is done here, "the market" will decide on its own. .

[Sent from my Vibrant.]

--20cf307d046c2f163f04a0703656-- From richih.mailinglist@gmail.com Fri Apr 8 17:08:38 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86213A69B1 for ; Fri, 8 Apr 2011 17:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seqyQqvgwq0R for ; Fri, 8 Apr 2011 17:08:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id AD2983A6905 for ; Fri, 8 Apr 2011 17:08:37 -0700 (PDT) Received: by iye19 with SMTP id 19so4791377iye.31 for ; Fri, 08 Apr 2011 17:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=IqdDhdYMCAp89YXZqIHwOD3qfdP1oNl2GKhbMnEh2jI=; b=HW0Nd8mC6UFIXVUl4tYkkTJoM1LmMmu0F54NxYObe43cWQeBUST0lyTZawwFdbBqyh /+ChuLG7IfpBRFaSeT9T6DDQQ7aJLiaA9G1as2DXk5lzz+STYCkEmQy9ee1WGcBD+Hu0 o+s+7z63Owu6KYGjbEqnYbiORur1BqBNnj+c0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=asAS66CLskEV66SOv/YA/Uzo1zycO/F465WIRBR37VxnCJvmZSSDYbouoyPsviw1Ic OCiWnXHl0Y4o+dcrlScdN/ET/ATnQ29k+BfXTaM34scpu07QJxQ4PMKABmld4jI+E1Vd KasaNG7+UAfJWanogNIYV88YTJtjGpYns0wR4= Received: by 10.231.61.198 with SMTP id u6mr2768198ibh.160.1302307823154; Fri, 08 Apr 2011 17:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.92.16 with HTTP; Fri, 8 Apr 2011 17:10:03 -0700 (PDT) In-Reply-To: References: From: Richard Hartmann Date: Sat, 9 Apr 2011 02:10:03 +0200 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming To: Scott Brim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:08:38 -0000 On Sat, Apr 9, 2011 at 01:01, Scott Brim wrote: > If enough people express support we can make this a BCP That would be very welcome indeed. >,=C2=A0 but whatever is > done here, "the market" will decide on its own. . If this poll [1] and the various feedback by operators is a reliable metric, the market may have decided for hextet, already. And yes, I should have used Condorcet [2] possibly modified for NotA. Richard [1] http://doodle.com/5q9gfvk4qe6zmzc6 [2] http://en.wikipedia.org/wiki/Condorcet_method From albert.e.manfredi@boeing.com Fri Apr 8 17:32:56 2011 Return-Path: X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA373A6820 for ; Fri, 8 Apr 2011 17:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc4utoj-OD8W for ; Fri, 8 Apr 2011 17:32:55 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 342D13A681E for ; Fri, 8 Apr 2011 17:32:55 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p390Ydba004423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Apr 2011 19:34:40 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p390Yd5L006026 for ; Fri, 8 Apr 2011 17:34:39 -0700 (PDT) Received: from XCH-MWHT-06.mw.nos.boeing.com (xch-mwht-06.mw.nos.boeing.com [134.57.113.166]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p390YaOP005996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 8 Apr 2011 17:34:37 -0700 (PDT) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-06.mw.nos.boeing.com (134.57.113.166) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 8 Apr 2011 19:34:36 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Fri, 8 Apr 2011 19:34:36 -0500 From: "Manfredi, Albert E" To: Richard Hartmann Date: Fri, 8 Apr 2011 19:34:32 -0500 Subject: RE: Introducing draft-6man-addresspartnaming Thread-Topic: Introducing draft-6man-addresspartnaming Thread-Index: Acv2SoykydqEIqlxSp2nlzrpJ1bFbAAAwQsQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18062.000 x-tm-as-result: No--57.772100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:32:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBSaWNoYXJk IEhhcnRtYW5uDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMDgsIDIwMTEgODoxMCBQTQ0KPiBUbzog U2NvdHQgQnJpbQ0KPiBDYzogNm1hbiBMaXN0DQo+IFN1YmplY3Q6IFJlOiBJbnRyb2R1Y2luZyBk cmFmdC02bWFuLWFkZHJlc3NwYXJ0bmFtaW5nDQo+IA0KPiBPbiBTYXQsIEFwciA5LCAyMDExIGF0 IDAxOjAxLCBTY290dCBCcmltIDxzY290dC5icmltQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4gSWYg ZW5vdWdoIHBlb3BsZSBleHByZXNzIHN1cHBvcnQgd2UgY2FuIG1ha2UgdGhpcyBhIEJDUA0KPiAN Cj4gVGhhdCB3b3VsZCBiZSB2ZXJ5IHdlbGNvbWUgaW5kZWVkLg0KPiANCj4gDQo+ID4swqAgYnV0 IHdoYXRldmVyIGlzDQo+ID4gZG9uZSBoZXJlLCAidGhlIG1hcmtldCIgd2lsbCBkZWNpZGUgb24g aXRzIG93bi4gLg0KPiANCj4gSWYgdGhpcyBwb2xsIFsxXSBhbmQgdGhlIHZhcmlvdXMgZmVlZGJh Y2sgYnkgb3BlcmF0b3JzIGlzIGEgcmVsaWFibGUNCj4gbWV0cmljLCB0aGUgbWFya2V0IG1heSBo YXZlIGRlY2lkZWQgZm9yIGhleHRldCwgYWxyZWFkeS4gQW5kIHllcywgSQ0KPiBzaG91bGQgaGF2 ZSB1c2VkIENvbmRvcmNldCBbMl0gcG9zc2libHkgbW9kaWZpZWQgZm9yIE5vdEEuDQoNCkkgdGhp bmsgc29tZXRoaW5nIGlzIG5lZWRlZCwgYW5kIGhleHRldCBpcyBwcm9iYWJseSBnb29kLWlzaC4N Cg0KQW55b25lIGNvbnNpZGVyZWQgaGV4ZGVjdGV0PyBFYXNpZXIgdG8gc2F5IHRoYXQgaGV4YWRl Y3RldCwgSSB0aGluaywgYW5kIGZhciBtb3JlIGFjY3VyYXRlIHRoYW4gaGV4dGV0IQ0KDQpRdWli YmxlPyBOYXcuIEZvciBvbmUgdGhpbmcsIGl0IGhhcyBuZWdhdGl2ZSBjb25ub3RhdGlvbnMuIFdo byB3YW50cyB0byBiZSBxdWliYmxpbmcgb3ZlciBJUHY2IGFkZHJlc3NlcyBmb3IgYWxsIHRpbWUg YW55d2F5PyBXZSBoYXZlIG1vcmUgaW1wb3J0YW50IHRoaW5ncyB0byBkbz8gKEkgdGhpbmsgd2Ug ZG8/KQ0KDQpCZXJ0DQoNCg== From bob.hinden@gmail.com Tue Apr 12 15:46:47 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 844E2E0859 for ; Tue, 12 Apr 2011 15:46:47 -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, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9x4SH8bjGRo for ; Tue, 12 Apr 2011 15:46:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 36270E07F4 for ; Tue, 12 Apr 2011 15:46:46 -0700 (PDT) Received: by iwn39 with SMTP id 39so55075iwn.31 for ; Tue, 12 Apr 2011 15:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=fbIZUT8+/Cvhef52oe2CiW598hGCmBF3D3flIgyG170=; b=h08Bv/sOk+IbDYGdu/i/xVpFu4HMKeZvEKpqMuMF5NbIxlLjBDGHfWhUHwG1VV1VKb dFpKkRGMrtuUcgQZ2LJHcrFvRUg38Z1woSK8KduXHh+lsK1xA8Swn2KVxkPxA+46+ysT xYSty78BGTW5y/OJkKkajVXcjtx1KagJZ4quE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fU3BLaznbyvScEZnjqR/+RKk5ujaMOTVs0vEOzXW2yvEg3M+hR95Siuct4Jh5Dna58 83Jgyta8Moe/z5X88SCWttRp+qXtOq+QP1qjZoPXyUU2oWTT7hdKICPld2ASiBRsg+Yf YJ3VsiLTfnHpJMMd16QxpIB8pFWKAvF0oCQ68= Received: by 10.42.154.131 with SMTP id q3mr694576icw.465.1302648404054; Tue, 12 Apr 2011 15:46:44 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id d9sm5217329ibb.19.2011.04.12.15.46.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 15:46:43 -0700 (PDT) Subject: Re: 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> Date: Tue, 12 Apr 2011 15:46:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46218705-942F-4483-8C2D-3E5AA1D97B25@gmail.com> References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) Cc: 6man Mailing List , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 22:46:47 -0000 Thomas, Finally catching up on email after IETF. On Apr 5, 2011, at 10:40 AM, Thomas Narten wrote: > Here are my detailed comments on the document. I did chat with Brian > directly in Prague about these points as well. Overall, I support this > document. But I think the wording in places needs another round of > revision. >=20 > A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast, or multicast destination that a node > desires to label as a flow. A flow could consist of all packets in = a >=20 > This is a circular definition. I think it would be useful to give two > definitions, something like the following: Like Scott, I don't have any difficulty with the current text, nor find = it circular. My preference is to leave it as is. I agree with the rest of your proposed changes. Thanks for taking a = another close look. Bob >=20 > A Flow is a sequence of packets originating from a particular > application that should be treated "the same" by the network as > they are forwarded along to their ultimate destination. Packets > within a flow should not be reordered, should not be given > dissimilar QOS treatment, etc. What constitutes a Flow can only be > defined by the application itself. >=20 > At the network level, routers need to be able to identify packets > belonging to the same Flow in order to process them > consistently. At the same time, it may be beneficial to process > packets between the same src/destination pairs (but from different > application flows) differently, e.g., to support ECMP or other > types of load splitting. >=20 > Then: =20 >=20 > Traditionally, flow classifiers have been based on the 5-tuple of = the > source and destination addresses, ports, and the transport > protocol >=20 > add "flow classifiers at the network layer" >=20 > The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by = a > node to label packets of a flow. A Flow Label of zero is used to > indicate packets not part of any flow. Packet classifiers can use >=20 > reword to say "that have not been labeled" (Packets will almost always > be part of some Flow). >=20 > specification. However, any node that sets flow label values > according to a stateful scheme MUST ensure that packets conform to > Section 3 of the present specification if they are sent outside the > network domain using the stateful scheme. >=20 > The above wording regarding "sent outside the network domain" is > problematic. It hints that maybe you can do things with the Flow Label > within a domain so long as you don't send such packets outside the > domain. We shouldn't even hint that that is acceptable. I'd suggest > removing all references to the "stateful" flow label scheme to one > section. And that section could be very short. >=20 > 1. Implementers are advised that forwarding nodes, especially those > acting as domain border devices, might nevertheless be = configured > to change the flow label value in packets. This is = undetectable, > unless some future version of IPsec authentication [RFC4302] > protects the flow label value. >=20 > Remove this. Again, the Flow Label is not allowed to be modified > accept when zero. That is all that needs to be said. >=20 > if the packet will leave their domain. If it is known to a > border router that flow labels originated within the domain are > not uniformly distributed, it will need to set outgoing flow > labels in the same manner as described for forwarding nodes in > Section 3. >=20 > Remove this. It agains suggests border routers will be resetting Flow > Label values. >=20 > o Implementers should be aware that the flow label is an = unprotected > field that could have been accidentally or intentionally changed > en route. Implementations MUST take appropriate steps to protect > themselves from being vulnerable to denial of service and other > types of attack that could result (see Section 6.1). >=20 > Can we just move this advice to the Security Considerations section? > IMO, we are giving it too much weight by having it in the main text. >=20 > o Forwarding nodes such as routers and load balancers MUST NOT > depend only on Flow Label values being uniformly distributed. In > any usage such as a hash key for load distribution, the Flow = Label > bits MUST be combined at least with bits from other sources = within > the packet, so as to produce a constant hash value for each flow > and a suitable distribution of hash values across flows. >=20 >=20 > Can't we just come out and say that routers should: >=20 > 1) use the src/dest/flow/port numbers? this is the most prefered. >=20 > 2) if you can't use the port numbers, hash on the 3 tuple. >=20 > 3) you could also say hash on teh src/dest alone as a last resort, but > why the Flow Label RFC would suggest that isn't immediately obvious to > me. :-) >=20 > The use of the Flow Label field does not necessarily signal any > requirement on packet reordering. Especially, the zero label does > not imply that significant reordering is acceptable. >=20 > The first sentence above isn't right. One SHOULD NOT reorder packets > from the same flow. Period.=20 >=20 > An IPv6 node that does not set the flow label to a non-zero value, = or > make use of it in any way, MUST ignore it when receiving or > forwarding a packet. >=20 > I don't understand why this wording is in here. For the stateless > case, nodes should simply ignore the received Flow Label value. We > should probably just say that. >=20 > It is desirable that flow label values should be uniformly > distributed to assist load distribution. It is therefore = RECOMMENDED > that source hosts support the flow label by setting the flow label > field for all packets of a given flow to the same uniformly > distributed pseudo-random value. Both stateful and stateless = methods > of assigning a pseudo-random value could be used, but it is outside > the scope of this specification to mandate an algorithm. In a > stateless mechanism, the algorithm SHOULD ensure that the resulting > flow label values are unique with high probability. >=20 > I think we need to specify some recommended algorithms. They can be > SHOULDs (rather than MUST), but saying nothing leaves things too > unclear. In particular, if we think just doing a simple hash based on > the port numbers (or something) is good enough, we should recommend > that. >=20 > Also, this document should not be requiring (or even use SHOULD) to > say pseudo randomness is necessary. This document has not made the > case for that. >=20 > An OPTIONAL algorithm for generating such a pseudo-random value is > described in [I-D.gont-6man-flowlabel-security]. >=20 > [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and > the reference should be changed to Informative, if the cited draft = is > not on the standards track at the time of publication. ]] >=20 > I'd prefer that this document provide a suggested algorithm. >=20 > A source node which does not otherwise set the flow label MUST set > its value to zero. >=20 > Better: just say that the default value should be zero, unless set > explicitely. >=20 > A node that forwards a flow whose flow label value in arriving > packets is zero MAY set the flow label value. In that case, it is >=20 > s/MAY set/MAY change/ >=20 > A node that sets the flow label MAY also take part in a flow state > establishment method that results in assigning specific treatments = to > specific flows, possibly including signaling. Any such method MUST > NOT disturb nodes taking part in the stateless model just described. > Further details are not discussed in this document. >=20 > I don't understand what does this is really intended to mean. IMO, > just say the first sentence, and then say the details of stateful are > out of scope for this document. >=20 > would cause a stateful mechanism to behave incorrectly. For this > reason, stateless mechanisms should not use the flow label alone to > control load distribution, and stateful mechanisms should include >=20 > s/stateless mechanisms/stateless classifiers/ >=20 > Thomas From magnus.westerlund@ericsson.com Thu Apr 14 05:00:04 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 277DFE074A for ; Thu, 14 Apr 2011 05:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCcmJdvQIMmt for ; Thu, 14 Apr 2011 05:00:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 209A1E069F for ; Thu, 14 Apr 2011 05:00:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-82-4da6e1c2d824 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.B8.11171.2C1E6AD4; Thu, 14 Apr 2011 14:00:02 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 14:00:02 +0200 Message-ID: <4DA6E1C1.6060602@ericsson.com> Date: Thu, 14 Apr 2011 14:00:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-6man-udpchecksims@tools.ietf.org, "ipv6@ietf.org" Subject: Comments on draft-ietf-6man-udpchecksums-00 X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:00:04 -0000 Hi, I have made a review of the draft and have some comments on it. 1. Needs to indicate that it updates RFC2460 (when approved). This usually goes into the header of the front page. The abstract and as part of the introduction. 2. The abstract is way to meager. It needs to make clear, what it does, that there are limitations and that it updates RFC 2460. 3. Style of writing. This is a document that updates and will be the specification of a change of the IPv6 specification. Currently it still reads like a change proposal. From my perspective it needs to be more authoritative. This is something we have decided to do. Thus the document should be written like: 1. Introduction: We are changing the UDP zero checksum rule in IPv6. 2. Short motivation why. 3. Change to specification. Old text that is replaced. New text. Some places where this is evident: - Section 1, last paragraph on page 3: Not long term relevant and using terms that make less sense in an RFC. - Section 1.4 "Recommend Solution": Wrong title. Should be its own main section. First paragraph. 4. Section 1.4: In cases, where the encapsulating protocol uses a zero checksum for UDP, the receiver of packets in the allowed port range MUST NOT discard packets with a UDP checksum of zero. "in the allowed port range" seems wrong, isn't "to a port that has been enabled to receive zero checksum" so that the full sentence reads: In cases, where the encapsulating protocol uses a zero checksum for UDP, the receiver of packets to a port that has been enabled to receive zero checksum MUST NOT discard packets with a UDP checksum of zero. 5. Section 1.4 bullet 1: 1. IPv6 protocol stack implementations SHOULD NOT by default allow the new method. The default node receiver behaviour MUST discard all IPv6 packets carrying UDP packets with a zero checksum. I think "new method" is unclear in this sentence. Yes, I know it is from my draft. However, in the context of actually doing the change it needs to be more crisp and clear. 6. Section 1.4, bullet 3: 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with a zero-checksum. This should remain the case for any datagram received on a port that does not explicitly enable zero-checksum processing. A port for which zero-checksum has been enabled MUST NOT log the datagram. Should we clarify that it MUST NOT log for the reason of it having a zero checksum. It may still be logged but for other reasons. The simplest change appears to say: A port for which zero-checksum has been enabled MUST NOT log the datagram for that reason. 7. Section 1.4, bullet 5: 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, then the tunnel MUST provide an additional integrity verification mechanism. An integrity mechanism is always recommended at the tunnel layer to ensure that corruption rates of the inner most packet are not increased. I think the first "MUST" is actually not correct. I think "MAY" is actually more correct. If you transport IP as inner packet, then you MAY rely on that being corruption verified by itself, the outer header doesn't need to take that responsibility providing that the corruption rate will not be increase. However disallowing additional checks was not the intention here. 8. Section 1.5 should have its own main section. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Apr 14 05:01:27 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B2310E088E for ; Thu, 14 Apr 2011 05:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gdxr+vOojqz for ; Thu, 14 Apr 2011 05:01:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id BA947E088A for ; Thu, 14 Apr 2011 05:01:26 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-67-4da6e21595a1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.06.09202.512E6AD4; Thu, 14 Apr 2011 14:01:26 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 14:01:25 +0200 Message-ID: <4DA6E215.10306@ericsson.com> Date: Thu, 14 Apr 2011 14:01:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-6man-udpchecksums@tools.ietf.org, "ipv6@ietf.org" Subject: Comments on draft-ietf-6man-udpchecksums-00 X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:01:27 -0000 (resend due to bad author alias address) Hi, I have made a review of the draft and have some comments on it. 1. Needs to indicate that it updates RFC2460 (when approved). This usually goes into the header of the front page. The abstract and as part of the introduction. 2. The abstract is way to meager. It needs to make clear, what it does, that there are limitations and that it updates RFC 2460. 3. Style of writing. This is a document that updates and will be the specification of a change of the IPv6 specification. Currently it still reads like a change proposal. From my perspective it needs to be more authoritative. This is something we have decided to do. Thus the document should be written like: 1. Introduction: We are changing the UDP zero checksum rule in IPv6. 2. Short motivation why. 3. Change to specification. Old text that is replaced. New text. Some places where this is evident: - Section 1, last paragraph on page 3: Not long term relevant and using terms that make less sense in an RFC. - Section 1.4 "Recommend Solution": Wrong title. Should be its own main section. First paragraph. 4. Section 1.4: In cases, where the encapsulating protocol uses a zero checksum for UDP, the receiver of packets in the allowed port range MUST NOT discard packets with a UDP checksum of zero. "in the allowed port range" seems wrong, isn't "to a port that has been enabled to receive zero checksum" so that the full sentence reads: In cases, where the encapsulating protocol uses a zero checksum for UDP, the receiver of packets to a port that has been enabled to receive zero checksum MUST NOT discard packets with a UDP checksum of zero. 5. Section 1.4 bullet 1: 1. IPv6 protocol stack implementations SHOULD NOT by default allow the new method. The default node receiver behaviour MUST discard all IPv6 packets carrying UDP packets with a zero checksum. I think "new method" is unclear in this sentence. Yes, I know it is from my draft. However, in the context of actually doing the change it needs to be more crisp and clear. 6. Section 1.4, bullet 3: 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with a zero-checksum. This should remain the case for any datagram received on a port that does not explicitly enable zero-checksum processing. A port for which zero-checksum has been enabled MUST NOT log the datagram. Should we clarify that it MUST NOT log for the reason of it having a zero checksum. It may still be logged but for other reasons. The simplest change appears to say: A port for which zero-checksum has been enabled MUST NOT log the datagram for that reason. 7. Section 1.4, bullet 5: 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, then the tunnel MUST provide an additional integrity verification mechanism. An integrity mechanism is always recommended at the tunnel layer to ensure that corruption rates of the inner most packet are not increased. I think the first "MUST" is actually not correct. I think "MAY" is actually more correct. If you transport IP as inner packet, then you MAY rely on that being corruption verified by itself, the outer header doesn't need to take that responsibility providing that the corruption rate will not be increase. However disallowing additional checks was not the intention here. 8. Section 1.5 should have its own main section. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From philip.chimento@jhuapl.edu Thu Apr 14 05:09:28 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 397E8E076D for ; Thu, 14 Apr 2011 05:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv5zgRHquHKX for ; Thu, 14 Apr 2011 05:09:27 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfc.amsl.com (Postfix) with ESMTP id E701CE072F for ; Thu, 14 Apr 2011 05:09:26 -0700 (PDT) Received: from ([128.244.198.90]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.108672038; Thu, 14 Apr 2011 08:09:20 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Thu, 14 Apr 2011 08:09:20 -0400 From: "Chimento, Philip F." To: Magnus Westerlund , "draft-ietf-6man-udpchecksums@tools.ietf.org" , "ipv6@ietf.org" Date: Thu, 14 Apr 2011 08:09:17 -0400 Subject: Re: Comments on draft-ietf-6man-udpchecksums-00 Thread-Topic: Comments on draft-ietf-6man-udpchecksums-00 Thread-Index: Acv6m7OGROpgc9LmSLONsgod8CKqrwAARNtO Message-ID: In-Reply-To: <4DA6E215.10306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Marshall Eubanks , "Haberman, Brian K." X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:09:28 -0000 Hi Magnus:=20 Very good comments, thank you. We'll make the changes and address these. Marshall: Do you have the latest XML? If you send it to me, I can try to ge= t these comments addressed by early next week (Mon or Tue). Thanks.=20 Regards, Phil=20 On 4/14/11 8:01 AM, "Magnus Westerlund" wrote: > (resend due to bad author alias address) > Hi, >=20 > I have made a review of the draft and have some comments on it. >=20 > 1. Needs to indicate that it updates RFC2460 (when approved). This > usually goes into the header of the front page. The abstract and as part > of the introduction. >=20 > 2. The abstract is way to meager. It needs to make clear, what it does, > that there are limitations and that it updates RFC 2460. >=20 > 3. Style of writing. This is a document that updates and will be the > specification of a change of the IPv6 specification. Currently it still > reads like a change proposal. From my perspective it needs to be more > authoritative. This is something we have decided to do. Thus the > document should be written like: > 1. Introduction: We are changing the UDP zero checksum rule in IPv6. > 2. Short motivation why. > 3. Change to specification. Old text that is replaced. New text. >=20 > Some places where this is evident: > - Section 1, last paragraph on page 3: Not long term relevant and using > terms that make less sense in an RFC. > - Section 1.4 "Recommend Solution": Wrong title. Should be its own main > section. First paragraph. >=20 > 4. Section 1.4: > In cases, where the encapsulating > protocol uses a zero checksum for UDP, the receiver of packets in > the allowed port range MUST NOT discard packets with a UDP > checksum of zero. >=20 > "in the allowed port range" seems wrong, isn't "to a port that has been > enabled to receive zero checksum" so that the full sentence reads: >=20 > In cases, where the encapsulating protocol uses a zero checksum for UDP, > the receiver of packets to a port that has been enabled to receive zero > checksum MUST NOT discard packets with a UDP checksum of zero. >=20 > 5. Section 1.4 bullet 1: > 1. IPv6 protocol stack implementations SHOULD NOT by default > allow the new method. The default node receiver behaviour > MUST discard all IPv6 packets carrying UDP packets with a zero > checksum. >=20 > I think "new method" is unclear in this sentence. Yes, I know it is from > my draft. However, in the context of actually doing the change it needs > to be more crisp and clear. >=20 > 6. Section 1.4, bullet 3: > 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams > with a zero-checksum. This should remain the case for any > datagram received on a port that does not explicitly enable > zero-checksum processing. A port for which zero-checksum has > been enabled MUST NOT log the datagram. >=20 > Should we clarify that it MUST NOT log for the reason of it having a > zero checksum. It may still be logged but for other reasons. The > simplest change appears to say: >=20 > A port for which zero-checksum has been enabled MUST NOT log the > datagram for that reason. >=20 > 7. Section 1.4, bullet 5: > 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet > integrity checks provided that the tunnel will not > significantly increase the rate of corruption of the inner IP > packet. If a significantly increased corruption rate can > occur, then the tunnel MUST provide an additional integrity > verification mechanism. An integrity mechanism is always > recommended at the tunnel layer to ensure that corruption > rates of the inner most packet are not increased. >=20 > I think the first "MUST" is actually not correct. I think "MAY" is > actually more correct. If you transport IP as inner packet, then you MAY > rely on that being corruption verified by itself, the outer header > doesn't need to take that responsibility providing that the corruption > rate will not be increase. However disallowing additional checks was not > the intention here. >=20 > 8. Section 1.5 should have its own main section. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- Regards,=20 Phil Chimento JHU/APL 240-228-1743 443-778-1743 Philip.Chimento@jhuapl.edu --=20 From gorry@erg.abdn.ac.uk Thu Apr 14 06:57:43 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 06A14E06B8 for ; Thu, 14 Apr 2011 06:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7uiARJPE+zD for ; Thu, 14 Apr 2011 06:57:41 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfc.amsl.com (Postfix) with ESMTP id 98259E069F for ; Thu, 14 Apr 2011 06:57:40 -0700 (PDT) Received: from Gorry-Fairhursts-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p3EDvPgs008584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Apr 2011 14:57:26 +0100 (BST) Message-ID: <4DA6FD44.4080804@erg.abdn.ac.uk> Date: Thu, 14 Apr 2011 14:57:24 +0100 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Chimento, Philip F." Subject: Re: Comments on draft-ietf-6man-udpchecksums-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Marshall Eubanks , "ipv6@ietf.org" , "Haberman, Brian K." , "draft-ietf-6man-udpchecksums@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:57:43 -0000 I agree with the comments from Magnus. I can promise to also check the next revision for consistency with the udpzero draft, but that would be easier with the reorganisation, that Magnus has suggested. I also add the following: There are some pointers to use-cases in the introduction that are not referenced, whereas I would have expected quite tightly-defined use-cases in line with the udpzero draft. "More recently, a discussion on the DCCP mailing list covered the UDP over IPv6 checksum issues. - I recall this in the context of DCCP-over-UDP, but the conclusion was that UDP MUST provide a checksum. I think if you want to discuss DCCP, you should also state the conclusion and rationale why (i.e. because of the need to protect the header fields). The draft later also says: "o A key cause of this issue generally is the lack of protocol support in middleboxes. Specifically, new protocols, such as DCCP, are being forced to use UDP tunnels just to traverse an end- to-end path successfully and avoid having their packets dropped by middleboxes. If this were not the case, the use of UDP-lite might become more viable for some (but not necessarily all) lightweight tunneling protocols." - However, the DCCP working group specifically chose not to use a tunnel approach, and instead used a double encapsulation, in which the processing at the receiver uses both the UDP and DCCP header fields, specifically the UDP checksum was mandated. Maybe this is not the best example? I'm not sure whether UDP-Lite will be supported over IPv6 middleboxes, because I don't personally know about significant deployment of either. "Other users of UDP as a tunneling protocol, for example, L2TP..." - Do you envisage this as a host tunnel? In section 1.3 the draft describes: "UDP keep-alive packets with checksum zero can be sent to validate paths, given that paths between tunnel endpoints can change and so middleboxes in the path may vary during the life of the association." - I agree. Are these being defined for this specification? What functions are required? And if so, are the keep-alive datagrams of any specific format, periodicity, and how do they validate the path, i.e., are the datagrams acknowledged? The draft also says: "We suggest that decoupling IPv6 header protection from transport generally should be studied in this workgroup. One approach might be to consider an extension header for IPv6 containing (at least) a header checksum. However, that is beyond the scope of this draft." - I'm not for or against this, but there are considerations and we need to be clear if this is an IETF recommendation, or a good idea for some future work: There have been other initiatives in the IETF that have looked at the pros and cons of separating the endpoint and routing functions. I'd be most happy to do a detailed review of a new version. Gorry On 14/04/2011 13:09, Chimento, Philip F. wrote: > Hi Magnus: > Very good comments, thank you. We'll make the changes and address these. > > Marshall: Do you have the latest XML? If you send it to me, I can try to get > these comments addressed by early next week (Mon or Tue). > Thanks. > Regards, Phil > > > On 4/14/11 8:01 AM, "Magnus Westerlund" > wrote: > >> (resend due to bad author alias address) >> Hi, >> >> I have made a review of the draft and have some comments on it. >> >> 1. Needs to indicate that it updates RFC2460 (when approved). This >> usually goes into the header of the front page. The abstract and as part >> of the introduction. >> >> 2. The abstract is way to meager. It needs to make clear, what it does, >> that there are limitations and that it updates RFC 2460. >> >> 3. Style of writing. This is a document that updates and will be the >> specification of a change of the IPv6 specification. Currently it still >> reads like a change proposal. From my perspective it needs to be more >> authoritative. This is something we have decided to do. Thus the >> document should be written like: >> 1. Introduction: We are changing the UDP zero checksum rule in IPv6. >> 2. Short motivation why. >> 3. Change to specification. Old text that is replaced. New text. >> >> Some places where this is evident: >> - Section 1, last paragraph on page 3: Not long term relevant and using >> terms that make less sense in an RFC. >> - Section 1.4 "Recommend Solution": Wrong title. Should be its own main >> section. First paragraph. >> >> 4. Section 1.4: >> In cases, where the encapsulating >> protocol uses a zero checksum for UDP, the receiver of packets in >> the allowed port range MUST NOT discard packets with a UDP >> checksum of zero. >> >> "in the allowed port range" seems wrong, isn't "to a port that has been >> enabled to receive zero checksum" so that the full sentence reads: >> >> In cases, where the encapsulating protocol uses a zero checksum for UDP, >> the receiver of packets to a port that has been enabled to receive zero >> checksum MUST NOT discard packets with a UDP checksum of zero. >> >> 5. Section 1.4 bullet 1: >> 1. IPv6 protocol stack implementations SHOULD NOT by default >> allow the new method. The default node receiver behaviour >> MUST discard all IPv6 packets carrying UDP packets with a zero >> checksum. >> >> I think "new method" is unclear in this sentence. Yes, I know it is from >> my draft. However, in the context of actually doing the change it needs >> to be more crisp and clear. >> >> 6. Section 1.4, bullet 3: >> 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams >> with a zero-checksum. This should remain the case for any >> datagram received on a port that does not explicitly enable >> zero-checksum processing. A port for which zero-checksum has >> been enabled MUST NOT log the datagram. >> >> Should we clarify that it MUST NOT log for the reason of it having a >> zero checksum. It may still be logged but for other reasons. The >> simplest change appears to say: >> >> A port for which zero-checksum has been enabled MUST NOT log the >> datagram for that reason. >> >> 7. Section 1.4, bullet 5: >> 5. UDP Tunnels that encapsulate IP MUST rely on the inner packet >> integrity checks provided that the tunnel will not >> significantly increase the rate of corruption of the inner IP >> packet. If a significantly increased corruption rate can >> occur, then the tunnel MUST provide an additional integrity >> verification mechanism. An integrity mechanism is always >> recommended at the tunnel layer to ensure that corruption >> rates of the inner most packet are not increased. >> >> I think the first "MUST" is actually not correct. I think "MAY" is >> actually more correct. If you transport IP as inner packet, then you MAY >> rely on that being corruption verified by itself, the outer header >> doesn't need to take that responsibility providing that the corruption >> rate will not be increase. However disallowing additional checks was not >> the intention here. >> >> 8. Section 1.5 should have its own main section. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > > Regards, > Phil Chimento > > JHU/APL > 240-228-1743 > 443-778-1743 > Philip.Chimento@jhuapl.edu From richih.mailinglist@gmail.com Thu Apr 14 13:24:11 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35D7EE0823 for ; Thu, 14 Apr 2011 13:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLfz76j5+N4I for ; Thu, 14 Apr 2011 13:24:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id 571F7E06B8 for ; Thu, 14 Apr 2011 13:24:09 -0700 (PDT) Received: by yxk30 with SMTP id 30so1111809yxk.31 for ; Thu, 14 Apr 2011 13:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=m1Q8oN4XkpQyKe28nH+uQjz8U2LpCDZ7UXHC1XEFc7k=; b=PYLDDeZAYaO3/+J6VlnuK9Pdnp5OJPWYXtCPG+AytNDu5Ws9tSnfxohCmPErNtbJuQ QaDiP+FjIjQX9AzS1TWj/1h+Bu05srpIkFXOblt7YZCgQgqxRJKGmgZToTJmRGGVzzg7 wX7vd6DAc3OMoA6maifJ+/NVm9qbdwW8dWBlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=lvqRQ6bHyp745K4vDAziJMArf3JnoaC/xvPIEQUNyhd8ypmu+opsniseQSS3auzudy RrsZXd0UGBkm2ucsPFMYIMvXnzypE4wtagjp1vF0/7SjJH3P3bjL46MNHaEHu9XC5AMl NMIYPoqEnq00m96ZHsS7QgnL9L+DKSqwTjtn4= Received: by 10.236.185.137 with SMTP id u9mr40377yhm.124.1302812649153; Thu, 14 Apr 2011 13:24:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.109.130 with HTTP; Thu, 14 Apr 2011 13:23:48 -0700 (PDT) In-Reply-To: References: From: Richard Hartmann Date: Thu, 14 Apr 2011 22:23:48 +0200 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming To: 6man List Content-Type: text/plain; charset=UTF-8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:24:11 -0000 Hi all, after renaming to draft-hartmann-6man-addresspartnaming, I am still waiting for feedback. I am not sure how the exact procedures are: Does lack of feedback mean people are mostly OK with this or that no one cares? Am I too impatient? Should I be doing something I am not doing yet? If I am not getting more feedback soonish, I will most likely release -01 over the weekend and would then start at looking for ways to get this accepted as a WG item. As always, any and all feedback appreciated :) Richard From dougb@dougbarton.us Thu Apr 14 13:58:50 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68D8CE07E6 for ; Thu, 14 Apr 2011 13:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkBd-psQMpkx for ; Thu, 14 Apr 2011 13:58:49 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfc.amsl.com (Postfix) with ESMTP id 8E91BE0732 for ; Thu, 14 Apr 2011 13:58:49 -0700 (PDT) Received: (qmail 30557 invoked by uid 399); 14 Apr 2011 20:58:45 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 14 Apr 2011 20:58:45 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DA76003.4050001@dougbarton.us> Date: Thu, 14 Apr 2011 13:58:43 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Richard Hartmann Subject: Re: Introducing draft-6man-addresspartnaming References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:58:50 -0000 On 04/14/2011 13:23, Richard Hartmann wrote: > Hi all, > > after renaming to draft-hartmann-6man-addresspartnaming, I am still > waiting for feedback. > > > I am not sure how the exact procedures are: Does lack of feedback mean > people are mostly OK with this or that no one cares? To be painfully honest, most likely the latter, sorry. I've never had a problem with "field" as the description, and have never been confused because that's not a unique term. I agree with Karl that hextet is right out. I actually like the term quibble, because of (rather than in spite of) its alternate meaning, given how contentious various elements of v6 design have been, and continue to be. (It also rhymes with nibble.) OTOH, I did think of another candidate, felco (mash-up of "field between the colons"). Apparently this name is used by a brand of pruning shears, but I seriously doubt anyone would get them confused. My feelings won't be hurt if no one thinks this is an improvement, I'm ambivalent about it myself. :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From i.grok@comcast.net Thu Apr 14 17:17:18 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E48DE06E8 for ; Thu, 14 Apr 2011 17:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJvLjPAzRfv9 for ; Thu, 14 Apr 2011 17:17:17 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfc.amsl.com (Postfix) with ESMTP id 7CC5BE05F5 for ; Thu, 14 Apr 2011 17:17:17 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id XcDQ1g0071u4NiLADcHG0a; Fri, 15 Apr 2011 00:17:16 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id XcHF1g00B00PQ6U8hcHG7R; Fri, 15 Apr 2011 00:17:16 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p3F0HEhS025580 for ; Thu, 14 Apr 2011 20:17:14 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p3F0HDPg025578 for ipv6@ietf.org; Thu, 14 Apr 2011 20:17:13 -0400 Date: Thu, 14 Apr 2011 20:17:13 -0400 From: Scott Schmit To: ipv6@ietf.org Subject: Re: Introducing draft-6man-addresspartnaming Message-ID: <20110415001713.GA22852@odin.ulthar.us> Mail-Followup-To: ipv6@ietf.org References: <4DA76003.4050001@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA76003.4050001@dougbarton.us> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:17:18 -0000 On Thu, Apr 14, 2011 at 01:58:43PM -0700, Doug Barton wrote: > On 04/14/2011 13:23, Richard Hartmann wrote: > >Hi all, > > > >after renaming to draft-hartmann-6man-addresspartnaming, I am still > >waiting for feedback. > > > > > >I am not sure how the exact procedures are: Does lack of feedback mean > >people are mostly OK with this or that no one cares? > > To be painfully honest, most likely the latter, sorry. I've never > had a problem with "field" as the description, and have never been > confused because that's not a unique term. I agree with Karl that > hextet is right out. I actually like the term quibble, because of > (rather than in spite of) its alternate meaning, given how > contentious various elements of v6 design have been, and continue to > be. (It also rhymes with nibble.) I happen to agree. I don't see the point. After all, what are the numbers between the dots in IPv4 addresses called? -- Scott Schmit From richih.mailinglist@gmail.com Thu Apr 14 17:48:57 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15F50E07A9 for ; Thu, 14 Apr 2011 17:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKFnicC4MWJY for ; Thu, 14 Apr 2011 17:48:56 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfc.amsl.com (Postfix) with ESMTP id 61C70E0697 for ; Thu, 14 Apr 2011 17:48:56 -0700 (PDT) Received: by gwb20 with SMTP id 20so1191582gwb.31 for ; Thu, 14 Apr 2011 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V8JZLV8v6owlOb+Z2Jl8k7KLF6OUQi2fF4Of3hy0vrU=; b=keglB1LXJ/o4vgy1FMWpNuZ90BT/hzJfUVQM4Rxw2Ar+3SXH321zZIVO5EhjBfPxmU OzuQvSIt3y+UBGO2DTboyIAHcvCHWXA1EB2XLz74G963Vd9PK3xiSdAf9HstPOIaec1O VSFoFRMu07BrtzgxXODH9awNgnghbW6+ZHPnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PCtfTY0JPS6csLHWLXSHk6d6sUi3FSInnuhXtpN74i6/wPsGTKUqIErFhDPTvV+fgl oOBDRgfBWzAH2CIm/x3Nv3LNuUFT3/w0Zy98SWLd6UIHtsEiUxTQClyh0USLmJTj4eWv LoXS0eYPO5fJckTvViQ49CTl7FWci4O89kir4= Received: by 10.236.197.99 with SMTP id s63mr233855yhn.325.1302828536105; Thu, 14 Apr 2011 17:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.109.130 with HTTP; Thu, 14 Apr 2011 17:48:36 -0700 (PDT) In-Reply-To: <20110415001713.GA22852@odin.ulthar.us> References: <4DA76003.4050001@dougbarton.us> <20110415001713.GA22852@odin.ulthar.us> From: Richard Hartmann Date: Fri, 15 Apr 2011 02:48:36 +0200 Message-ID: Subject: Re: Introducing draft-6man-addresspartnaming To: ipv6@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: Scott Schmit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:48:57 -0000 On Fri, Apr 15, 2011 at 02:17, Scott Schmit wrote: > I happen to agree. I don't see the point. After all, what are the > numbers between the dots in IPv4 addresses called? Octects. Richard From albert.e.manfredi@boeing.com Thu Apr 14 17:55:25 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D47A1E06BC for ; Thu, 14 Apr 2011 17:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlpcd-0FJRLK for ; Thu, 14 Apr 2011 17:55:25 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 31AA4E065C for ; Thu, 14 Apr 2011 17:55:25 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3F0tHpI019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Apr 2011 17:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p3F0tHJn017710 for ; Thu, 14 Apr 2011 17:55:17 -0700 (PDT) Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3F0tFuD017639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Apr 2011 17:55:16 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-05.mw.nos.boeing.com ([134.57.119.160]) with mapi; Thu, 14 Apr 2011 19:55:15 -0500 From: "Manfredi, Albert E" To: Richard Hartmann , "ipv6@ietf.org" Date: Thu, 14 Apr 2011 19:55:13 -0500 Subject: RE: Introducing draft-6man-addresspartnaming Thread-Topic: Introducing draft-6man-addresspartnaming Thread-Index: Acv7BuuOVaYciEnwRpeoI8AYlzdJ/gAAHxEg Message-ID: References: <4DA76003.4050001@dougbarton.us><20110415001713.GA22852@odin.ulthar.us> 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-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:55:26 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Richard Hartmann > Sent: Thursday, April 14, 2011 8:49 PM > To: ipv6@ietf.org > Cc: Scott Schmit > Subject: Re: Introducing draft-6man-addresspartnaming >=20 > On Fri, Apr 15, 2011 at 02:17, Scott Schmit wrote: >=20 > > I happen to agree. I don't see the point. After all, what are the > > numbers between the dots in IPv4 addresses called? >=20 > Octects. I also don't find this all that big a deal, but here's another suggestion. If we are to limit ourselves to two syllables, anything wrong with "hexdec"= for singular, "hexdecs" for plural? A very easy global change to the I-D. Bert From dwing@cisco.com Fri Apr 15 08:26:45 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8308E070B; Fri, 15 Apr 2011 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XfUX3oLUyU6; Fri, 15 Apr 2011 08:26:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 31654E066B; Fri, 15 Apr 2011 08:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=671; q=dns/txt; s=iport; t=1302881201; x=1304090801; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=e7ebCOubsbLVKytJC/ExgM/R5IAq/c8usRlxuT6QGYQ=; b=P6E1NPlse184hPtmKXkE8oxHopdk1LO3uZ5QqaFNK8nyvB5/gAmI8Gec I3aKMnTIXZ59AdIcz6lzOtHA+0poSxSs2Ja/BPJ50PWRkYXpsktTZrsXF rhkMziPfLNX5kYfux3gjmM/zk6zRjyyQ/S4/JsIjKu/mRLDMgzz66sqY8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACNjqE2rRDoI/2dsb2JhbACZZ4wcd6c1nH2FbgSFYA X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="338401021" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 15:26:40 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFQeYP021876; Fri, 15 Apr 2011 15:26:40 GMT From: "Dan Wing" To: , , Subject: RTP and UDP checksum=0 Date: Fri, 15 Apr 2011 08:26:40 -0700 Message-ID: <012101cbfb81$84a04500$8de0cf00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv7gYRLEnMobebWS4+AhtzwAMK02A== Content-Language: en-us Cc: avt@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:26:46 -0000 Observation: tunneled packets have two elements actively deciding checksum=0 is okay. Those elements are the tunnel encap and tunnel decap. Question: Should non-tunneled UDP flows, *established with explicit signaling*, also be allowed to decide that checksum=0 is okay? For example, an RTP-over-UDP flow established with RTSP or SIP signaling. Some RTP traffic includes its own checksum at the application layer (e.g., SRTP authentication) and gains little or no benefit to a UDP checksum. Near as I can discern, SIP-signaled flows meet all of the constraints discussed in http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1 -d From pch-b6B5344D9@u-1.phicoh.com Sat Apr 16 02:17:25 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0C793E06C9 for ; Sat, 16 Apr 2011 02:17: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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtCE5VVihQGu for ; Sat, 16 Apr 2011 02:17:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 1A4E1E0675 for ; Sat, 16 Apr 2011 02:17:23 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QB1d3-0001eKC; Sat, 16 Apr 2011 11:17 +0200 Message-Id: To: ipv6@ietf.org Subject: PMTU blackhole detection From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com Date: Sat, 16 Apr 2011 11:17:02 +0200 Cc: john.loughney@nokia.com, narten@us.ibm.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 09:17:25 -0000 PMTU blackhole detection seemed so obvious to me, that I never bothered to find out if there was an RFC specifying that it should be done. That is, until I encountered an admin said that he didn't do PMTU blackhole detection because end-users should just fix their systems (the irony is that this came up when said admin's systems where broken). So now I wonder, is this something that should be discussed in draft-ietf-6man-node-req-bis-08.txt? From pch-b6B5344D9@u-1.phicoh.com Sat Apr 16 03:44:25 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39C6CE0676 for ; Sat, 16 Apr 2011 03:44:25 -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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHVGD9zNta1q for ; Sat, 16 Apr 2011 03:44:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 5B921E066F for ; Sat, 16 Apr 2011 03:44:24 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QB2zH-0001lpC; Sat, 16 Apr 2011 12:44 +0200 Message-Id: To: David Woodhouse Subject: Re: PMTU blackhole detection From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <1302949733.11313.7.camel@macbook.infradead.org> In-reply-to: Your message of "Sat, 16 Apr 2011 11:28:53 +0100 ." <1302949733.11313.7.camel@macbook.infradead.org> Date: Sat, 16 Apr 2011 12:44:17 +0200 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 10:44:25 -0000 In your letter dated Sat, 16 Apr 2011 11:28:53 +0100 you wrote: >On Sat, 2011-04-16 at 11:17 +0200, Philip Homburg wrote: >> >> PMTU blackhole detection seemed so obvious to me, that I never bothered to >> find out if there was an RFC specifying that it should be done. > >Conversely... > >It's always been *so* obvious to me that firewalling ICMP is broken, >that I never bothered to find out of there was an RFC specifying that it >shouldn't be done. > >Perhaps *that* is what should be discussed, instead? I think that's fine. I can understand the argument that breaking things causes bugs to be resolved. On the other hand, the difference between 1500 and 1280 is so small, I wonder if breaking things just because you want to send packets at 1500 bytes makes a lot of sense. One other thing, if this makes the IPv6 experience worse than industry standard for IPv4, then maybe it is also not a good idea. From swmike@swm.pp.se Sat Apr 16 06:28:11 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 37FCBE068E for ; Sat, 16 Apr 2011 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJQEGg5Hf7S4 for ; Sat, 16 Apr 2011 06:28:10 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id A29EAE0613 for ; Sat, 16 Apr 2011 06:28:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2E8C39C; Sat, 16 Apr 2011 15:28:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2A5B29A; Sat, 16 Apr 2011 15:28:09 +0200 (CEST) Date: Sat, 16 Apr 2011 15:28:09 +0200 (CEST) From: Mikael Abrahamsson To: Philip Homburg Subject: Re: PMTU blackhole detection In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: john.loughney@nokia.com, narten@us.ibm.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 13:28:11 -0000 On Sat, 16 Apr 2011, Philip Homburg wrote: > PMTU blackhole detection seemed so obvious to me, that I never bothered to > find out if there was an RFC specifying that it should be done. is what you're looking for I guess? -- Mikael Abrahamsson email: swmike@swm.pp.se From hingkam16@gmail.com Sat Apr 16 17:06:02 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA46CE0673 for ; Sat, 16 Apr 2011 17:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5aqa1dRvdEl for ; Sat, 16 Apr 2011 17:06:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id D60F7E066A for ; Sat, 16 Apr 2011 17:06:01 -0700 (PDT) Received: by iwn39 with SMTP id 39so3983897iwn.31 for ; Sat, 16 Apr 2011 17:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P8R5hfT62+6VQgqtY43fDWDT+Rbxb0yp5toaMn2zuBg=; b=vILEH1zV0WHZj5fzXhq/iYwrcdpb6B8p5mBEbA4URWW13e9awrs+etdI8h/IrOGJwC JigwD4OEUCbN2M2aioHIqTsLoXWgwh7V0BaBQFDOFqs9ZXKxZwtI/8xScZMQ9KamR+QP 372QnuBGnBS9GxqMr5GM+4WAAcWzaj6bdkC9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NT5V2v2CbGTP8loqFv31lfddinVkQ+UcHXx5h49CwYAbIuS2GkezMP0YaDuGr/uaFs YXCWcTULHVauFbuVclr+VZUmDMcDbmv2TFwQvaI6TMHqHkr1RdRxB6VWh5I+1jY6Z3ID WrVTIJ/S9/5ZOR4yIlGcwQ6r8Q7MiglG1ubgQ= MIME-Version: 1.0 Received: by 10.231.39.135 with SMTP id g7mr2694147ibe.173.1302998761421; Sat, 16 Apr 2011 17:06:01 -0700 (PDT) Received: by 10.231.10.131 with HTTP; Sat, 16 Apr 2011 17:06:01 -0700 (PDT) In-Reply-To: <4D7FCAAB.7070608@ericsson.com> References: <20110314223006.15936.74266.idtracker@localhost> <20110314225526.GB52874@verdi> <4D7EAF77.3080504@ericsson.com> <20110315132539.GD52874@verdi> <4D7F7073.3050009@ericsson.com> <20110315201539.GF52874@verdi> <4D7FCAAB.7070608@ericsson.com> Date: Sun, 17 Apr 2011 05:36:01 +0530 Message-ID: Subject: Re: I-D Action:draft-ietf-6man-exthdr-02.txt From: "Hing-Kam (Kam) Lam" To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 00:06:03 -0000 Any update on this work? I thought we were very close to the WG LC last time and the new version is addressing all the points raised. If Yes, can we please move this forward. Kam On Wed, Mar 16, 2011 at 1:53 AM, Suresh Krishnan wrote: > Hi John, > > On 11-03-15 04:15 PM, John Leslie wrote: >> >> Suresh Krishnan wrote: >>> >>> On 11-03-15 09:25 AM, John Leslie wrote: >>>>>> >>>>>> But I don't see the equivalent of Section 4.2 of RFC 2460, specifyin= g >>>>>> the TLV format. >>>>> >>>>> The T is the "Next Header", the L is the "Hdr Ext Len" and V is the >>>>> "Header Specific Data" as specified in the figure in Section 4 of the >>>>> draft. >>>> >>>> Well, of course "Next Header" _isn't_ the Type of this option (rather >>>> it's the Type of the next option). >>>> >>>> And the "Hdr Ext Len" isn't a particularly intuitive coding of Length >>>> either... >>> >>> Yep. You are right on both counts, but I am not sure how we can change >>> this. We cannot chain the headers without the T being in the *previous* >>> header. I think the best we can do is to refrain from calling this TLV = like >>> you said. >> >> =A0 That would satisfy me... >> >> =A0 But, the 2460 section 4.2 TLV also defines four actions when a Type >> isn't recognized (skip and three cases of discard). exthdr-02 gives >> us no way of defining skip-vs-discard. >> >> =A0 I think some mention of this issue would be wise. It appears, at >> first blush, that you intend for a middlebox to skip over these >> prospective extension headers, whereas 2460 calls for dropping the >> packet. > > Right. These behavior flags were added in version -01 of the draft (the > previous version) due to a apparent consensus at the physical wg meeting = but > this change has been rolled back in version -02 due to lack of consensus = in > the mailing list. > >> >> =A0 I'm not prepared to say what the resolution may be; I just think >> it deserves some text (even if only to say, "Beware!"). > > Let's see if we can make some progress at the next meeting. > > Thanks > Suresh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From rja.lists@gmail.com Sun Apr 17 13:54:30 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BBC26E073C for ; Sun, 17 Apr 2011 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqdlcuzkdlg8 for ; Sun, 17 Apr 2011 13:54:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 079F2E0681 for ; Sun, 17 Apr 2011 13:54:29 -0700 (PDT) Received: by vws12 with SMTP id 12so3902642vws.31 for ; Sun, 17 Apr 2011 13:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=6kM7J/0P1G56kUXbmWk/jSlg3/Lyc55rT5SO8VP85PY=; b=ENyaQ3xPWw1clCpLQeqNkKJenzWCVE2joSRQvjpEYbpwVdGQBP1bZ0AJJRBZ0xGUpi 7DKIrrtRa5z0AHUDbKSC54yZhvmVkJboI34EJydEgU4fI20UezPoVTh2sKAUseFcHYPP ln16RHkGYBxGgKNzyWCKg0PSaB6ehovSwHxcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=vmXTXoLpUruvrx1lsI1lE7rhTVQ6/rBYMZ6Tl/Bj8QDZMEC9Y8jDKZPShvt10UbcU3 5wQTTxBVTRk4m0RmP3OcgTXdfVVr7woeyKbaWuL5IpGZPZN2Eifm9nTuSxSTE+098/No uvdZE3cprpgTICG7W1v5Vhu9mkzAinZFuF2j4= Received: by 10.52.91.66 with SMTP id cc2mr5936881vdb.175.1303073669665; Sun, 17 Apr 2011 13:54:29 -0700 (PDT) Received: from [172.17.100.251] ([12.48.234.16]) by mx.google.com with ESMTPS id h21sm1000917vcr.8.2011.04.17.13.54.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Apr 2011 13:54:28 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: draft-ietf-6man-exthdr-02.txt Date: Sun, 17 Apr 2011 16:54:28 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:54:30 -0000 Earlier, Hing-Kam Lam wrote: > I thought we were very close to the WG LC last time and > the new version is addressing all the points raised. Unfortunately, the new version unfortunately does not address my comments, or those of others with similar concerns about the operational impacts of ANY new IPv6 headers on existing IPv6 deployments with routers containing silicon (e.g. ASIC, FPGA) forwarding engines that parse/parse-past the currently defined set of IPv6 headers and extensions. As someone else noted recently on the IPv6 Ops list, in the IETF words such as "SHOULD" or "SHOULD NOT" are entirely ignorable. So those don't address my concerns. As I've said before, I do think that with some specific edits to tighten up the wording (e.g. using words such as "MUST NOT" and requiring more specific justification & documentation than in a normal standards-action if one proposes defining any new IPv6 header), the draft could be edited into a form where it would be widely agreeable. I provided specific suggestions in the past on this, which I don't see reflected in the latest text. Perhaps I've overlooked something. I am on travel, which means that I am both short of time and have VERY limited Internet access. I will try to propose some specific edits to this draft, but I doubt I will be able to post a note to this list with those proposed edits until end of week (at earliest). Cheers, Ran From magnus.westerlund@ericsson.com Mon Apr 18 01:02:30 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A392E07B0; Mon, 18 Apr 2011 01:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGjGGnz2r+My; Mon, 18 Apr 2011 01:02:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id C2781E0790; Mon, 18 Apr 2011 01:02:25 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-51-4dabf010adb7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.41.09202.010FBAD4; Mon, 18 Apr 2011 10:02:25 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Apr 2011 10:02:24 +0200 Message-ID: <4DABF00F.6080600@ericsson.com> Date: Mon, 18 Apr 2011 10:02:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Wing Subject: Re: RTP and UDP checksum=0 References: <012101cbfb81$84a04500$8de0cf00$@com> In-Reply-To: <012101cbfb81$84a04500$8de0cf00$@com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-6man-udpchecksums@tools.ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , "avt@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:02:30 -0000 Dan Wing skrev 2011-04-15 17:26: > Observation: tunneled packets have two elements actively > deciding checksum=0 is okay. Those elements are the > tunnel encap and tunnel decap. > > Question: Should non-tunneled UDP flows, *established with > explicit signaling*, also be allowed to decide that checksum=0 > is okay? For example, an RTP-over-UDP flow established > with RTSP or SIP signaling. Some RTP traffic includes its > own checksum at the application layer (e.g., SRTP authentication) > and gains little or no benefit to a UDP checksum. Near as I > can discern, SIP-signaled flows meet all of the constraints > discussed in > http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1 Dan, I agree that SRTP would be safe to use without checksum also in v6. However, using non-secured RTP without checksums are "a very bad idea" (TM). Also, if you are an end-point generating RTP flows then the UDP checksum overhead is generally not that big of an issue compared to all media processing. I think the only node that where this could make any significant difference are in a transport translator, which only relays an incoming packets to a number of other unicast addresses. I do however, see a need for a number of additional mechanisms, at least signalling if one wants do do this for RTP with SRTP integrity protection enabled. SIP/SDP signalling and maybe also an additional ICE STUN check to verify the capability prior to using it to avoid loss due to middleboxes that doesn't handle zero UDP checksum with v6. My general fear is that the usage of zero checksum for IPv6 is done without thinking and that it is similar in behavior to IPv4 which it clearly is not, but I guess that is difficult to ensure. Soo frankly, is it really worth it for RTP? I guess what you say comes down to if we should ensure that the text is generalized enough that it doesn't only apply to tunnel applications. To me the new specification text before the bullet list appears ok. If only give tunnels as an example. The bullet list also appears ok from a non-tunnel application perspective. So it is likely only the title and some of the introduction text that needs to be ensured that it doesn't only speak of tunneling. I think the authors should ensure this as it appears to be minor modifications and clearly we didn't mean this to only be applicable to one type of applications, but all that meets the considerations. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pch-b6B5344D9@u-1.phicoh.com Mon Apr 18 04:00:54 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3007E0783 for ; Mon, 18 Apr 2011 04:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SqgjSLLOsie for ; Mon, 18 Apr 2011 04:00:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id 6A0A3E0737 for ; Mon, 18 Apr 2011 04:00:50 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QBmCF-0001m9C; Mon, 18 Apr 2011 13:00 +0200 Message-Id: To: Mikael Abrahamsson Subject: Re: PMTU blackhole detection From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: In-reply-to: Your message of "Sat, 16 Apr 2011 15:28:09 +0200 (CEST) ." Date: Mon, 18 Apr 2011 13:00:30 +0200 Cc: john.loughney@nokia.com, narten@us.ibm.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:00:55 -0000 In your letter dated Sat, 16 Apr 2011 15:28:09 +0200 (CEST) you wrote: >On Sat, 16 Apr 2011, Philip Homburg wrote: > >> PMTU blackhole detection seemed so obvious to me, that I never bothered to >> find out if there was an RFC specifying that it should be done. > > is what you're looking for I guess? I guess so. I wonder why google couldn't find it. I'm not sure I like their approach. I'd prefer to treat PMTU blackholes as an exception but they treat it as the normal case. But I guess that a node requirements RFC should refer to it. From wwwrun@rfc-editor.org Mon Apr 18 09:40:26 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49088E07FF; Mon, 18 Apr 2011 09:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmcAu5LHfz0O; Mon, 18 Apr 2011 09:40:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id 018E9E0805; Mon, 18 Apr 2011 09:40:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6C778E0764; Mon, 18 Apr 2011 09:40:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6164 on Using 127-Bit IPv6 Prefixes on Inter-Router Links From: rfc-editor@rfc-editor.org Message-Id: <20110418164019.6C778E0764@rfc-editor.org> Date: Mon, 18 Apr 2011 09:40:19 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:40:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6164 Title: Using 127-Bit IPv6 Prefixes on Inter-Router Links Author: M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten Status: Standards Track Stream: IETF Date: April 2011 Mailbox: mkohno@juniper.net, nitzan@juniper.net, randy@psg.com, maz@iij.ad.jp, lorenzo@google.com, narten@us.ibm.com Pages: 8 Characters: 16057 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-prefixlen-p2p-01.txt URL: http://www.rfc-editor.org/rfc/rfc6164.txt On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK] This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dwing@cisco.com Mon Apr 18 11:45:48 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D63AE086F for ; Mon, 18 Apr 2011 11:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.486 X-Spam-Level: X-Spam-Status: No, score=-111.486 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Gd4wKXFrTeO for ; Mon, 18 Apr 2011 11:45:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id C2D1EE0720 for ; Mon, 18 Apr 2011 11:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1955; q=dns/txt; s=iport; t=1303152346; x=1304361946; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=hyGEwsP0Smw8BBDlRoHisactLmf1Ci8YG0i+s5o9czE=; b=NmvshVDFJaTgWRremRWfKRBrh6uUriNNVPcn55l+5x/bKcra43oCyKUZ 8/LXkC0FM8Kc4s2aYQ9uMRkqhbay68cY24JgOesnIMIntgRZKHA56wkCe ZoK1fR7J/iPa+wsK+qz6VPfri7oxiITNHpaKESARgm/i9xk9oMAyzLqNi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBAAiGrE2rRDoG/2dsb2JhbACXNoFjjCF3qBKcPIVxBIVi X-IronPort-AV: E=Sophos;i="4.64,234,1301875200"; d="scan'208";a="683368266" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2011 18:45:46 +0000 Received: from dwingWS (sjc-vpn6-1063.cisco.com [10.21.124.39]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3IIjjZ3019541; Mon, 18 Apr 2011 18:45:46 GMT From: "Dan Wing" To: "'Philip Homburg'" , "'David Woodhouse'" References: <1302949733.11313.7.camel@macbook.infradead.org> In-Reply-To: Subject: RE: PMTU blackhole detection Date: Mon, 18 Apr 2011 11:45:45 -0700 Message-ID: <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv8I0rZQ4XXwkx5TAK8a0XKbo6yZQB1DSYA Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:45:48 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Philip Homburg > Sent: Saturday, April 16, 2011 3:44 AM > To: David Woodhouse > Cc: ipv6@ietf.org > Subject: Re: PMTU blackhole detection > > In your letter dated Sat, 16 Apr 2011 11:28:53 +0100 you wrote: > >On Sat, 2011-04-16 at 11:17 +0200, Philip Homburg wrote: > >> > >> PMTU blackhole detection seemed so obvious to me, that I never > bothered to > >> find out if there was an RFC specifying that it should be done. > > > >Conversely... > > > >It's always been *so* obvious to me that firewalling ICMP is broken, > >that I never bothered to find out of there was an RFC specifying that > it > >shouldn't be done. > > > >Perhaps *that* is what should be discussed, instead? > > I think that's fine. I can understand the argument that breaking things > causes > bugs to be resolved. > > On the other hand, the difference between 1500 and 1280 is so small, I > wonder if breaking things just because you want to send packets > at 1500 bytes makes a lot of sense. > > One other thing, if this makes the IPv6 experience worse than industry > standard for IPv4, then maybe it is also not a good idea. The IPv6 headers are 20 bytes bigger than IPv4 headers, so a fairer comparison is 1500 against 1260 (1260=1280-20). That is, with a 1500 byte MTU with IPv4, the effective data payload is 1480 bytes (assuming no IP options, which is a reasonable assumption with IPv4); with a 1280 byte MTU with IPv6, the effective data payload is 1240 bytes (assuming no IPv6 extensions). That's a 16.2% reduction in data payload size from IPv4 to IPv6, with a commensurate increase in number of packets to send the same data (assuming MTU-sized packets). This isn't quite "packets per second will increase by 16.2%", though, as of course not all packets are 'full'. But there will be a pps increase. -d From pch-b6B5344D9@u-1.phicoh.com Tue Apr 19 01:28:48 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C0CDE0680 for ; Tue, 19 Apr 2011 01:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.266 X-Spam-Level: X-Spam-Status: No, score=-4.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8FAsQlUh9-l for ; Tue, 19 Apr 2011 01:28:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id DD27EE0665 for ; Tue, 19 Apr 2011 01:28:46 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QC6Ib-0001hKC; Tue, 19 Apr 2011 10:28 +0200 Message-Id: To: "Dan Wing" Subject: Re: PMTU blackhole detection From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> In-reply-to: Your message of "Mon, 18 Apr 2011 11:45:45 -0700 ." <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> Date: Tue, 19 Apr 2011 10:28:35 +0200 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 08:28:48 -0000 In your letter dated Mon, 18 Apr 2011 11:45:45 -0700 you wrote: >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Philip Homburg >> On the other hand, the difference between 1500 and 1280 is so small, I >> wonder if breaking things just because you want to send packets >> at 1500 bytes makes a lot of sense. >> >> One other thing, if this makes the IPv6 experience worse than industry >> standard for IPv4, then maybe it is also not a good idea. > >This isn't quite "packets per second will increase by 16.2%", though, >as of course not all packets are 'full'. But there will be a pps >increase. Yes, but is avoiding that small increase worth the complexity that things break whenever an ICMP doesn't get delivered? From dwing@cisco.com Tue Apr 19 08:47:27 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60D4FE0756 for ; Tue, 19 Apr 2011 08:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.558 X-Spam-Level: X-Spam-Status: No, score=-111.558 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxtKDZRN2XF2 for ; Tue, 19 Apr 2011 08:47:26 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 169D1E0664 for ; Tue, 19 Apr 2011 08:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1275; q=dns/txt; s=iport; t=1303228046; x=1304437646; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0PkdRmBiOM22z/7XwiMh+hdLJJgfAGat5Pgk8g6kDX8=; b=SwAtap/VOXOaa36bc0wU4LGhGkzrwZ5Pwb2UcqwXBsU4H9q68zmqKyPC fl5mgc1vICGDH2c0GHQ8NKYT+OaqyupxXSCBICm2PUYePw7uStY9xBJKz /xJW3x94G5l+hEb3Ns5owRdEz+TE49gJZQm7WYNe/fwFTgdHY3+5jKviF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIBANStrU2rRDoJ/2dsb2JhbACXI4FjjCZ3qAecaYVxBIVn X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="340552941" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2011 15:47:25 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3JFlP8S026111; Tue, 19 Apr 2011 15:47:25 GMT From: "Dan Wing" To: "'Philip Homburg'" References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> In-Reply-To: Subject: RE: PMTU blackhole detection Date: Tue, 19 Apr 2011 08:47:23 -0700 Message-ID: <0f3001cbfea9$13974540$3ac5cfc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+a8+2B6IaRRoeS2W899/mVlHweAAPSTpg Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:47:27 -0000 > -----Original Message----- > From: pch-b6B5344D9@u-1.phicoh.com [mailto:pch-b6B5344D9@u- > 1.phicoh.com] On Behalf Of Philip Homburg > Sent: Tuesday, April 19, 2011 1:29 AM > To: Dan Wing > Cc: ipv6@ietf.org > Subject: Re: PMTU blackhole detection > > In your letter dated Mon, 18 Apr 2011 11:45:45 -0700 you wrote: > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > >> Philip Homburg > >> On the other hand, the difference between 1500 and 1280 is so small, > I > >> wonder if breaking things just because you want to send packets > >> at 1500 bytes makes a lot of sense. > >> > >> One other thing, if this makes the IPv6 experience worse than > industry > >> standard for IPv4, then maybe it is also not a good idea. > > > >This isn't quite "packets per second will increase by 16.2%", though, > >as of course not all packets are 'full'. But there will be a pps > >increase. > > Yes, but is avoiding that small increase worth the complexity that > things break whenever an ICMP doesn't get delivered? No, not yet. But it is a problem worthy of getting fixed. We have slid backwards on the PMTUD problem with IPv6. We need to move the other direction (forwards). -d From suresh.krishnan@ericsson.com Tue Apr 19 13:45:44 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D0D7E0719 for ; Tue, 19 Apr 2011 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.214 X-Spam-Level: X-Spam-Status: No, score=-105.214 tagged_above=-999 required=5 tests=[AWL=1.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACrTOmK4Bu1n for ; Tue, 19 Apr 2011 13:45:43 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 5E948E0670 for ; Tue, 19 Apr 2011 13:45:43 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3JKjNQl014093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Apr 2011 15:45:41 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Apr 2011 16:45:32 -0400 Message-ID: <4DADF436.3040007@ericsson.com> Date: Tue, 19 Apr 2011 16:44:38 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: draft-ietf-6man-exthdr-02.txt References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:45:44 -0000 Hi Ran, On 11-04-17 04:54 PM, RJ Atkinson wrote: > Earlier, Hing-Kam Lam wrote: >> I thought we were very close to the WG LC last time and >> the new version is addressing all the points raised. > > Unfortunately, the new version unfortunately does not address > my comments, or those of others with similar concerns about the > operational impacts of ANY new IPv6 headers on existing IPv6 > deployments with routers containing silicon (e.g. ASIC, FPGA) > forwarding engines that parse/parse-past the currently defined > set of IPv6 headers and extensions. > > As someone else noted recently on the IPv6 Ops list, > in the IETF words such as "SHOULD" or "SHOULD NOT" are > entirely ignorable. So those don't address my concerns. > > As I've said before, I do think that with some specific edits > to tighten up the wording (e.g. using words such as "MUST NOT" > and requiring more specific justification & documentation > than in a normal standards-action if one proposes defining > any new IPv6 header), the draft could be edited into > a form where it would be widely agreeable. The base IPv6 standard [RFC2460] allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this information, provides more flexible handling characteristics and better backward compatibility than using extension headers. Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs. The request for creation of a new IPv6 extension header MUST be accompanied by an specific explanation of why destination options could not be used to convey this information. This was the text I have added in version -02 in response to your comments. This text discourages creation of new extension headers and recommends using an existing extension header (dest opts). What do you think is missing here? > > I provided specific suggestions in the past on this, > which I don't see reflected in the latest text. Perhaps > I've overlooked something. I am on travel, which means > that I am both short of time and have VERY limited Internet > access. > > I will try to propose some specific edits to this draft, > but I doubt I will be able to post a note to this list > with those proposed edits until end of week (at earliest). OK. I will look forward to your proposal. Thanks Suresh From narten@us.ibm.com Tue Apr 19 13:49:24 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A31D5E076F for ; Tue, 19 Apr 2011 13:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.987 X-Spam-Level: X-Spam-Status: No, score=-105.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhU3XPZXriyL for ; Tue, 19 Apr 2011 13:49:23 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfc.amsl.com (Postfix) with ESMTP id 9FFB7E072F for ; Tue, 19 Apr 2011 13:49:23 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3JKSAqA025610 for ; Tue, 19 Apr 2011 16:28:10 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3JKnLEF213582 for ; Tue, 19 Apr 2011 16:49:21 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3JKnKkR029676 for ; Tue, 19 Apr 2011 16:49:20 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-230-152.mts.ibm.com [9.65.230.152]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3JKnJJE029654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2011 16:49:20 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3JKnDA1013131; Tue, 19 Apr 2011 16:49:19 -0400 Message-Id: <201104192049.p3JKnDA1013131@cichlid.raleigh.ibm.com> To: Hitoshi Asaeda Subject: Re: MLD version for node req. draft In-reply-to: <20110222.110200.109949015.asaeda@sfc.wide.ad.jp> References: <20110221.170033.54555648.asaeda@sfc.wide.ad.jp> <201102211530.p1LFU3NA009245@cichlid.raleigh.ibm.com> <20110222.110200.109949015.asaeda@sfc.wide.ad.jp> Comments: In-reply-to Hitoshi Asaeda message dated "Tue, 22 Feb 2011 11:02:00 +0800." Date: Tue, 19 Apr 2011 16:49:13 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:49:24 -0000 Hitoshi Asaeda writes: > >> "Nodes that need to join multicast groups SHOULD also implement either > >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." > > > > Is there a short (less than one page) description of the difference > > between RFCs 3810 and 5790? One that actually explains what the > > implementation differences are? Ah, thanks for this description. The key is is that the EXCLUDE functionality of MLDv2 adds considerable complexity, but is rarely used. SO the Lighteight MLDv2 effectively excludes that functionality. Here is what I propose to put into the Node Requirements revision: 5.10. Multicast Listener Discovery (MLD) for IPv6 Nodes that need to join multicast groups MUST support MLDv1 [RFC2710]. MLDv1 is needed by any node that is expected to receive and process multicast traffic. Note that Neighbor Discovery (as used on most link types -- see Section 5.2) depends on multicast and requires that nodes join Solicited Node multicast addresses. MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting Source-Specific Multicast. The original MLDv2 protocol [RFC3810] supports two types of "filter modes". Using an INCLUDE filter, a node indicates a multicast group along with a list of senders for that group it wishes to receive traffic from. Using an EXCLUDE filter, a node indicates a multicast group along with a list of senders it wishes to exclude receiving traffic from. In practice, EXCLUDE filters are rarely used, but add considerable implementation complexity to MLDv2. Lightweight MLDv2 [RFC5790] is a simplified subset of the original MLDv2 specification that omits EXCLUDE functionality. Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]. Specifically, nodes supporting applications using Source- Specific Multicast that expect to take advantage of MLDv2's EXCLUDE functionality [RFC3569] MUST support MLDv2 as defined in [RFC3810], [RFC4604] and [RFC4607]. Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality will find it sufficient to support MLDv2 as defined in [RFC5790]. If the node only supports applications that use Any-Source Multicast (i.e, they do not use source-specific multicast), implementing MLDv1 [RFC2710] is sufficient. In all cases, however, nodes are strongly encouraged to implement MLDv2 rather than MLDv1, as the presence of a single MLDv1 participant on a link requires that all other nodes on the link operate in version 1 compatibility mode. When MLDv1 is used, the rules in the Source Address Selection for the Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be followed. Thomas Hitoshi Asaeda writes: > >> "Nodes that need to join multicast groups SHOULD also implement either > >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." > > > > Is there a short (less than one page) description of the difference > > between RFCs 3810 and 5790? One that actually explains what the > > implementation differences are? > To start listening a multicast session/channel, an MLDv2 host > specifies either 1) multicast address or 2) source and multicast > addresses. > When the host specifies only multicast address, multicast packets sent > from any source are forwarded to the host. This is ASM. > When the host specifies source address(es) as well as multicast > address, it MUST also specify the "filter mode", which is either > INCLUDE or EXCLUDE. When the host wants to "receive" the multicast > packets sent from the specified source(es), INCLUDE is chosen as the > filter mode. When the host wants to "block" the multicast packets sent > from the specified source(es), EXCLUDE is chosen as the filter mode. > The former case, INCLUDE (S,G) join, is known as SSM. The latter case, > noted by EXCLUDE (S,G) join, is not SSM, rather ASM with an additional > function; to establish EXCLUDE (S,G) state, routers need to maintain > ASM state, because the routers need to forward every source data to > their downstreams "except" the excluded S. > In fact, there are no major applications that require EXCLUDE (S,G) > join/leave. It is only useful to filter out bogus sources in ASM > communications, but if you want to block unwanted source, say Sx, > you'd specify other sources to join the session such as INCLUDE > ({S1,S2,S3},G) (without including Sx). > According to such consideration, talking abour the host-side > implementation, the LW-MLDv2 spec (5790) supports both ASM and SSM > communications, but eliminates EXCLUDE (S,G) join/leave operations. > In fact, implementing both INCLUDE and EXCLUDE mode operations > requires complex state machine in kernel; therefore LW-MLDv2 gives the > chance for simpler kernel implementation. This is very positive > condition, and it is sure according to my experience of both IGMPv3 > and LW-IGMPv3 host-side kernel implementations in NetBSD. (I also > have implemented MLDv2 kernel but no LW-MLDv2.) IMO, it is hence > advantageous especially for mobile terminals or tiny OSes. > Of course, LW-MLDv2 supports interoerability with any MLD versions; it > works either with MLDv1, MLDv2, or LW-MLDv2 routers. > I hope this helps. > Regards, > -- > Hitoshi Asaeda > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Tue Apr 19 16:20:01 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A99F7E0814 for ; Tue, 19 Apr 2011 16:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3Jkmv4uS1CK for ; Tue, 19 Apr 2011 16:20:01 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id C85A5E07E0 for ; Tue, 19 Apr 2011 16:20:00 -0700 (PDT) Received: by pxi20 with SMTP id 20so146989pxi.27 for ; Tue, 19 Apr 2011 16:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=RWG25FhXL7yGFjrWNzeb/cKy+2KM9l7arXoS1pbcs9E=; b=EfopZ8TUOuav91+aZdlsD0t4wEsAJCqkT2i8ZVXHtF1kLSzbarxqYSsf3oSHJeB2cM /qWyQQdaHC1z41wWdkSv47S8JDAlzHIj/37xfbUJT8VgyZCwla+YuSw1PHxo+mlJ1MWX xBctCpAFLKe0CEREwWfrSgFMTfzpwgvb3Mcgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=EtLUJfiNa+lx5Ox+T3oLBsZwpcQo6Z2EKvK8xuVuhuXub2WxALahEqUgC++6m+mQvv k7wyjJrdukcHHLXu3qbGbUUWGdJMi9vja51XDTpJ2E6olYdddqYnNRI75IRGg506Uw5g SJbU45RVIEBBWUt/9+ufYP87/MYrHW+8j5W9w= Received: by 10.68.10.66 with SMTP id g2mr1432686pbb.483.1303255200270; Tue, 19 Apr 2011 16:20:00 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id v3sm222472pbe.99.2011.04.19.16.19.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 16:19:58 -0700 (PDT) Subject: Re: PMTU blackhole detection Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> Date: Tue, 19 Apr 2011 16:19:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:20:01 -0000 Dan, >> On the other hand, the difference between 1500 and 1280 is so small, = I >> wonder if breaking things just because you want to send packets=20 >> at 1500 bytes makes a lot of sense. >>=20 >> One other thing, if this makes the IPv6 experience worse than = industry >> standard for IPv4, then maybe it is also not a good idea. >=20 > The IPv6 headers are 20 bytes bigger than IPv4 headers, so a fairer > comparison is 1500 against 1260 (1260=3D1280-20). That is, with a = 1500 > byte MTU with IPv4, the effective data payload is 1480 bytes (assuming > no IP options, which is a reasonable assumption with IPv4); with a > 1280 byte MTU with IPv6, the effective data payload is 1240 bytes=20 > (assuming no IPv6 extensions). That's a 16.2% reduction in data=20 > payload size from IPv4 to IPv6, with a commensurate increase in=20 > number of packets to send the same data (assuming MTU-sized packets). I am a little confused by the comparisons being made in this thread. There is no guarantee that an 1500 IPv4 packet won't be fragmented, so a = path that drops ICMPv4 packet too big messages will cause PMTU to fail. = The 1280 number is the size of an MTU that IPv6 traffic can go on with = out a need to be fragmented (that is, no PMTU issue). If a path can deliver 1500 byte IPv4 packets, it can also deliver 1500 = byte IPv6 packets. The resulting payloads will be 20 byte less for = IPv6, but that less than a 2% difference in payload size. I doubt middle boxes are going to let ICMPv4 packet too big messages = through, and drop ICMPv6 packet too big messages. Am I missing something here? Bob >=20 > This isn't quite "packets per second will increase by 16.2%", though, > as of course not all packets are 'full'. But there will be a pps > increase. >=20 > -d >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dwing@cisco.com Tue Apr 19 18:05:50 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E649EE0712 for ; Tue, 19 Apr 2011 18:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.612 X-Spam-Level: X-Spam-Status: No, score=-110.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE3QlOqOStDh for ; Tue, 19 Apr 2011 18:05:50 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id F3AC9E07C3 for ; Tue, 19 Apr 2011 18:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3322; q=dns/txt; s=iport; t=1303261550; x=1304471150; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=V0rL3E0rof7eWfQN3tuixc5UsIh3yxt9Z6+CFv7MuAE=; b=Sg3VzlFWLoSwtk/o5Jgp+w5/Dxp2VNLmjHE5pfHvsKQHVmj4fXTlVMQy nUgbCXhBqYZb0ZtEsrWZkHQ7ygpQrmtEoZ/SD3U6UUZiiqa+hmMm/anP8 T11PiPso2ycqL4Iz/VGywppX4sHwjGVJULoAjQID3RQUPIDgmvG4t2r4G A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0BACMxrk2rRDoJ/2dsb2JhbACXM4FjjCd3iG+fPp0WhXEEhWmQAw X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="340911051" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2011 01:05:38 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3K15b03017835; Wed, 20 Apr 2011 01:05:37 GMT From: "Dan Wing" To: "'Bob Hinden'" References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> In-Reply-To: <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> Subject: RE: PMTU blackhole detection Date: Tue, 19 Apr 2011 18:05:35 -0700 Message-ID: <12cf01cbfef7$0df30a40$29d91ec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+6FCzu9SbGXSzTKKRBXQmEr8U3gABBC+Q Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:05:51 -0000 > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Tuesday, April 19, 2011 4:20 PM > To: Dan Wing > Cc: Bob Hinden; 'Philip Homburg'; 'David Woodhouse'; ipv6@ietf.org > Subject: Re: PMTU blackhole detection > > Dan, > > > >> On the other hand, the difference between 1500 and 1280 is so small, > I > >> wonder if breaking things just because you want to send packets > >> at 1500 bytes makes a lot of sense. > >> > >> One other thing, if this makes the IPv6 experience worse than > industry > >> standard for IPv4, then maybe it is also not a good idea. > > > > The IPv6 headers are 20 bytes bigger than IPv4 headers, so a fairer > > comparison is 1500 against 1260 (1260=1280-20). That is, with a 1500 > > byte MTU with IPv4, the effective data payload is 1480 bytes > (assuming > > no IP options, which is a reasonable assumption with IPv4); with a > > 1280 byte MTU with IPv6, the effective data payload is 1240 bytes > > (assuming no IPv6 extensions). That's a 16.2% reduction in data > > payload size from IPv4 to IPv6, with a commensurate increase in > > number of packets to send the same data (assuming MTU-sized packets). > > I am a little confused by the comparisons being made in this thread. > > There is no guarantee that an 1500 IPv4 packet won't be fragmented, so > a path that drops ICMPv4 packet too big messages will cause PMTU to > fail. The 1280 number is the size of an MTU that IPv6 traffic can go > on with out a need to be fragmented (that is, no PMTU issue). > > If a path can deliver 1500 byte IPv4 packets, it can also deliver 1500 > byte IPv6 packets. The resulting payloads will be 20 byte less for > IPv6, but that less than a 2% difference in payload size. > > I doubt middle boxes are going to let ICMPv4 packet too big messages > through, and drop ICMPv6 packet too big messages. > > Am I missing something here? Yes. Over the years, the IETF's own website has suffered two outages (and perhaps three) that were attributed to IPv6 PMTUD failures. To my knowledge, it has suffered no outages attributed to IPv4 PMTUD failures. Google runs its IPv6-facing properties using a 1280 byte MTU, likely to avoid adding IPv6 PMTUD failures to the reasons that IPv6 might provide a worse user experience than IPv4. Afterall, there is no need to try to resolve all problems at once while we're getting IPv6 off the ground. So, while I agree that 1500 should work equally well for both IPv4 and IPv6, it seems that for whatever combination of reasons, it works less well on IPv6 than IPv4. This is perhaps user error (configuration mistakes on firewalls or ACLs), more common use of IPv6-over-IPv4 tunnels than IPv4-over-IPv4 tunnels, bugs in vendor equipment, or something else. -d > Bob > > > > > > > This isn't quite "packets per second will increase by 16.2%", though, > > as of course not all packets are 'full'. But there will be a pps > > increase. > > > > -d > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Apr 19 20:01:20 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DA4AE0767 for ; Tue, 19 Apr 2011 20:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKhEefR+QwLO for ; Tue, 19 Apr 2011 20:01:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 63611E0747 for ; Tue, 19 Apr 2011 20:01:19 -0700 (PDT) Received: by iwn39 with SMTP id 39so312487iwn.31 for ; Tue, 19 Apr 2011 20:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1fYZjri+t6BGKRW79yGYEZ4kvvT8PD0DECuwJeBM+7E=; b=XAD1g3hGsv+MrFHk5wXzNFxqYdGb5wLhtidvnPxx02KWDBDWgwunTqrC4OwTS7l6Fh 93AaZ8pWcdTdYDGyoAL+lDJqTPU7FZfu65IeSyq8CaVXVSsD0iGkCjF/E//3pObw0ZZi 5Xo+DigmSw3VfTxevRz+hNX6yMQzF4pz6tqqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Y1rAKbtp7de9iFvbo/AU//y1B82vr+4aLSfGMeidi4pX761VFdHY5PEZA0W7hPybgL LIPY1LM3EMfuhEvg4jwreQhMDptC9d61UmjncGTLhGjtnJRNKSs1gdZdgUhLKun9Ufeo z9dZM10ZMOQ6qSeOiVubC0IXVbFQHvjJx7wxc= Received: by 10.231.23.67 with SMTP id q3mr1430849ibb.78.1303268478977; Tue, 19 Apr 2011 20:01:18 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id f28sm192036ibh.50.2011.04.19.20.01.14 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 20:01:18 -0700 (PDT) Message-ID: <4DAE4C71.7090509@gmail.com> Date: Wed, 20 Apr 2011 15:01:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing Subject: Re: PMTU blackhole detection References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> <12cf01cbfef7$0df30a40$29d91ec0$@com> In-Reply-To: <12cf01cbfef7$0df30a40$29d91ec0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Bob Hinden' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 03:01:20 -0000 On 2011-04-20 13:05, Dan Wing wrote: >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] >> Sent: Tuesday, April 19, 2011 4:20 PM >> To: Dan Wing >> Cc: Bob Hinden; 'Philip Homburg'; 'David Woodhouse'; ipv6@ietf.org >> Subject: Re: PMTU blackhole detection >> >> Dan, >> >> >>>> On the other hand, the difference between 1500 and 1280 is so small, >> I >>>> wonder if breaking things just because you want to send packets >>>> at 1500 bytes makes a lot of sense. >>>> >>>> One other thing, if this makes the IPv6 experience worse than >> industry >>>> standard for IPv4, then maybe it is also not a good idea. >>> The IPv6 headers are 20 bytes bigger than IPv4 headers, so a fairer >>> comparison is 1500 against 1260 (1260=1280-20). That is, with a 1500 >>> byte MTU with IPv4, the effective data payload is 1480 bytes >> (assuming >>> no IP options, which is a reasonable assumption with IPv4); with a >>> 1280 byte MTU with IPv6, the effective data payload is 1240 bytes >>> (assuming no IPv6 extensions). That's a 16.2% reduction in data >>> payload size from IPv4 to IPv6, with a commensurate increase in >>> number of packets to send the same data (assuming MTU-sized packets). >> I am a little confused by the comparisons being made in this thread. >> >> There is no guarantee that an 1500 IPv4 packet won't be fragmented, so >> a path that drops ICMPv4 packet too big messages will cause PMTU to >> fail. The 1280 number is the size of an MTU that IPv6 traffic can go >> on with out a need to be fragmented (that is, no PMTU issue). >> >> If a path can deliver 1500 byte IPv4 packets, it can also deliver 1500 >> byte IPv6 packets. The resulting payloads will be 20 byte less for >> IPv6, but that less than a 2% difference in payload size. >> >> I doubt middle boxes are going to let ICMPv4 packet too big messages >> through, and drop ICMPv6 packet too big messages. >> >> Am I missing something here? > > Yes. Over the years, the IETF's own website has suffered two outages > (and perhaps three) that were attributed to IPv6 PMTUD failures. To > my knowledge, it has suffered no outages attributed to IPv4 PMTUD > failures. > > Google runs its IPv6-facing properties using a 1280 byte MTU, likely > to avoid adding IPv6 PMTUD failures to the reasons that IPv6 might > provide a worse user experience than IPv4. Afterall, there is no > need to try to resolve all problems at once while we're getting IPv6 > off the ground. > > So, while I agree that 1500 should work equally well for both > IPv4 and IPv6, it seems that for whatever combination of reasons, > it works less well on IPv6 than IPv4. This is perhaps user error > (configuration mistakes on firewalls or ACLs), more common use > of IPv6-over-IPv4 tunnels than IPv4-over-IPv4 tunnels, bugs > in vendor equipment, or something else. Specifically, I discovered while I was a 6to4 user that some sites, but not others, could successfully complete a SYN/ACK exchange (where all the packets were well below 1280 bytes) but never replied to the first HTTP GET command. iirc, it seemed that the server would set its TCP MSS to 1440, regardless of the client setting 1220, and presumably the server sent 1500 byte IPv6 packets that never arrived. I never could debug it. In this situation a 6to4 relay (like any other tunnel end point) should behave according to section 3.2 of RFC 4213. That's quite a complicated section and I suppose there may be buggy implementations, even in the absence of ICMP filtering. Brian From mohacsi@niif.hu Wed Apr 20 00:43:52 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3B28E0761 for ; Wed, 20 Apr 2011 00:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwg9KrEbGWoN for ; Wed, 20 Apr 2011 00:43:51 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfc.amsl.com (Postfix) with ESMTP id B7076E07C0 for ; Wed, 20 Apr 2011 00:43:51 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 1192587241; Wed, 20 Apr 2011 09:43:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id AJR7aA1hd50p; Wed, 20 Apr 2011 09:43:35 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 68888873EA; Wed, 20 Apr 2011 09:43:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 626BE873E6; Wed, 20 Apr 2011 09:43:35 +0200 (CEST) Date: Wed, 20 Apr 2011 09:43:35 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Bob Hinden Subject: Re: PMTU blackhole detection In-Reply-To: <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> Message-ID: References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 07:43:52 -0000 On Tue, 19 Apr 2011, Bob Hinden wrote: > Dan, > > >>> On the other hand, the difference between 1500 and 1280 is so small, I >>> wonder if breaking things just because you want to send packets >>> at 1500 bytes makes a lot of sense. >>> >>> One other thing, if this makes the IPv6 experience worse than industry >>> standard for IPv4, then maybe it is also not a good idea. >> >> The IPv6 headers are 20 bytes bigger than IPv4 headers, so a fairer >> comparison is 1500 against 1260 (1260=1280-20). That is, with a 1500 >> byte MTU with IPv4, the effective data payload is 1480 bytes (assuming >> no IP options, which is a reasonable assumption with IPv4); with a >> 1280 byte MTU with IPv6, the effective data payload is 1240 bytes >> (assuming no IPv6 extensions). That's a 16.2% reduction in data >> payload size from IPv4 to IPv6, with a commensurate increase in >> number of packets to send the same data (assuming MTU-sized packets). > > I am a little confused by the comparisons being made in this thread. > > There is no guarantee that an 1500 IPv4 packet won't be fragmented, so a path that drops ICMPv4 packet too big messages will cause PMTU to fail. The 1280 number is the size of an MTU that IPv6 traffic can go on with out a need to be fragmented (that is, no PMTU issue). > > If a path can deliver 1500 byte IPv4 packets, it can also deliver 1500 byte IPv6 packets. The resulting payloads will be 20 byte less for IPv6, but that less than a 2% difference in payload size. > > I doubt middle boxes are going to let ICMPv4 packet too big messages through, and drop ICMPv6 packet too big messages. Then middleboxes does not follow RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls Best Regards, Janos Mohacsi > > Am I missing something here? > > Bob > > > >> >> This isn't quite "packets per second will increase by 16.2%", though, >> as of course not all packets are 'full'. But there will be a pps >> increase. >> >> -d >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From pch-b6B5344D9@u-1.phicoh.com Wed Apr 20 01:56:29 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9CEE3E065F for ; Wed, 20 Apr 2011 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A25BK1mMYqT2 for ; Wed, 20 Apr 2011 01:56:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfc.amsl.com (Postfix) with ESMTP id BA597E0655 for ; Wed, 20 Apr 2011 01:56:28 -0700 (PDT) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1QCTCy-0001T3C; Wed, 20 Apr 2011 10:56 +0200 Message-Id: To: Brian E Carpenter Subject: Re: PMTU blackhole detection From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> <12cf01cbfef7$0df30a40$29d91ec0$@com> <4DAE4C71.7090509@gmail.com> In-reply-to: Your message of "Wed, 20 Apr 2011 15:01:05 +1200 ." <4DAE4C71.7090509@gmail.com> Date: Wed, 20 Apr 2011 10:56:11 +0200 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:56:29 -0000 In your letter dated Wed, 20 Apr 2011 15:01:05 +1200 you wrote: >In this situation a 6to4 relay (like any other tunnel end point) >should behave according to section 3.2 of RFC 4213. That's quite >a complicated section and I suppose there may be buggy >implementations, even in the absence of ICMP filtering. That illustrates what I'm trying to say. Sending packets with an MTU of 1280 is always safe. So to be able to send packets with an MTU of around 1500, we have a lot of complated machinery that has been shown to be very fragile, both in IPv4 and IPv6. And all we get from that is a rather modest efficiency gain. At the cost of breaking things completely when it goes wrong. So I would suggest that we strongly recommend to host operating system implementors and content providers that they make sure that a sending system's MTU is quickly reduced in the presence of an MTU blackhole. From dwing@cisco.com Wed Apr 20 08:43:18 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08D34E0790 for ; Wed, 20 Apr 2011 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.611 X-Spam-Level: X-Spam-Status: No, score=-110.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pPEN5C9X69l for ; Wed, 20 Apr 2011 08:43:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id E449CE07AC for ; Wed, 20 Apr 2011 08:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4193; q=dns/txt; s=iport; t=1303314175; x=1304523775; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=XDM9IQ/WCWPBRJ7FFHpC1xj+bPydPudl72+J5F/fDEM=; b=ZXeIUExiCD4bD3aVQGQJXHewvlEvMrTZd4aqoIuUTti0GapdmzzhCYzC neLsU//efiIjiVrq9w+hjs+bQ/ZkU7cCDof5CCSuJwt7yJyfyopF82Ahj cvZapk3T7Kb0h0DS6uOFXDTDC5QDsxg/llUvnyu7ESEQ+3FqHUcX/LQ83 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAL/+rk2rRDoH/2dsb2JhbACEUJJhgWOMJ3eIb6IQi1yRKIEpg056BIV0kBM X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="433626043" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 20 Apr 2011 15:42:44 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3KFgivL025146; Wed, 20 Apr 2011 15:42:44 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> <12cf01cbfef7$0df30a40$29d91ec0$@com> <4DAE4C71.7090509@gmail.com> In-Reply-To: <4DAE4C71.7090509@gmail.com> Subject: RE: PMTU blackhole detection Date: Wed, 20 Apr 2011 08:42:41 -0700 Message-ID: <13f501cbff71$95cb7f40$c1627dc0$@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: Acv/B+dDSYIJtqv+STqDp8/iKpNZJQAaZStw Content-Language: en-us Cc: ipv6@ietf.org, 'Bob Hinden' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:43:18 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, April 19, 2011 8:01 PM > To: Dan Wing > Cc: 'Bob Hinden'; ipv6@ietf.org > Subject: Re: PMTU blackhole detection >=20 > On 2011-04-20 13:05, Dan Wing wrote: > >> -----Original Message----- > >> From: Bob Hinden [mailto:bob.hinden@gmail.com] > >> Sent: Tuesday, April 19, 2011 4:20 PM > >> To: Dan Wing > >> Cc: Bob Hinden; 'Philip Homburg'; 'David Woodhouse'; ipv6@ietf.org > >> Subject: Re: PMTU blackhole detection > >> > >> Dan, > >> > >> > >>>> On the other hand, the difference between 1500 and 1280 is so > small, > >> I > >>>> wonder if breaking things just because you want to send packets > >>>> at 1500 bytes makes a lot of sense. > >>>> > >>>> One other thing, if this makes the IPv6 experience worse than > >> industry > >>>> standard for IPv4, then maybe it is also not a good idea. > >>> The IPv6 headers are 20 bytes bigger than IPv4 headers, so a = fairer > >>> comparison is 1500 against 1260 (1260=3D1280-20). That is, with a > 1500 > >>> byte MTU with IPv4, the effective data payload is 1480 bytes > >> (assuming > >>> no IP options, which is a reasonable assumption with IPv4); with a > >>> 1280 byte MTU with IPv6, the effective data payload is 1240 bytes > >>> (assuming no IPv6 extensions). That's a 16.2% reduction in data > >>> payload size from IPv4 to IPv6, with a commensurate increase in > >>> number of packets to send the same data (assuming MTU-sized > packets). > >> I am a little confused by the comparisons being made in this = thread. > >> > >> There is no guarantee that an 1500 IPv4 packet won't be fragmented, > so > >> a path that drops ICMPv4 packet too big messages will cause PMTU to > >> fail. The 1280 number is the size of an MTU that IPv6 traffic can > go > >> on with out a need to be fragmented (that is, no PMTU issue). > >> > >> If a path can deliver 1500 byte IPv4 packets, it can also deliver > 1500 > >> byte IPv6 packets. The resulting payloads will be 20 byte less for > >> IPv6, but that less than a 2% difference in payload size. > >> > >> I doubt middle boxes are going to let ICMPv4 packet too big = messages > >> through, and drop ICMPv6 packet too big messages. > >> > >> Am I missing something here? > > > > Yes. Over the years, the IETF's own website has suffered two = outages > > (and perhaps three) that were attributed to IPv6 PMTUD failures. To > > my knowledge, it has suffered no outages attributed to IPv4 PMTUD > > failures. > > > > Google runs its IPv6-facing properties using a 1280 byte MTU, likely > > to avoid adding IPv6 PMTUD failures to the reasons that IPv6 might > > provide a worse user experience than IPv4. Afterall, there is no > > need to try to resolve all problems at once while we're getting IPv6 > > off the ground. > > > > So, while I agree that 1500 should work equally well for both > > IPv4 and IPv6, it seems that for whatever combination of reasons, > > it works less well on IPv6 than IPv4. This is perhaps user error > > (configuration mistakes on firewalls or ACLs), more common use > > of IPv6-over-IPv4 tunnels than IPv4-over-IPv4 tunnels, bugs > > in vendor equipment, or something else. >=20 > Specifically, I discovered while I was a 6to4 user that some > sites, but not others, could successfully complete a SYN/ACK > exchange (where all the packets were well below 1280 bytes) but > never replied to the first HTTP GET command. iirc, it seemed > that the server would set its TCP MSS to 1440, regardless of the > client setting 1220, and presumably the server sent 1500 byte > IPv6 packets that never arrived. I never could debug it. Ben Stasiewicz has done some research on IPv6 MTU problems, http://ripe60.ripe.net/presentations/Stasiewicz-Measurements_of_IPv6_Path= _MTU_Discovery_Behaviour.pdf -d > In this situation a 6to4 relay (like any other tunnel end point) > should behave according to section 3.2 of RFC 4213. That's quite > a complicated section and I suppose there may be buggy > implementations, even in the absence of ICMP filtering. >=20 > Brian From bob.hinden@gmail.com Wed Apr 20 10:04:20 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C5297E0695 for ; Wed, 20 Apr 2011 10:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.617 X-Spam-Level: X-Spam-Status: No, score=-103.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 881rp1H8BttZ for ; Wed, 20 Apr 2011 10:04:20 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3122CE067D for ; Wed, 20 Apr 2011 10:04:20 -0700 (PDT) Received: by pzk30 with SMTP id 30so613030pzk.31 for ; Wed, 20 Apr 2011 10:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=+2eDgGBszCpctSCrZcU/7mX6N1qlhk87u4le/Fimm2Y=; b=Q/LnCUtmzXzdrTUOis8vvycvZuzvQ5qsm5Ik5vRf78Owc1SHec83DqRekF67z9uT2K +Htcbfp/Tiawk6X9pL+NxwUQ+KAmS2zCD89q7hmO7mfNKwnBp2QBry7fErpQiTb/wSk6 FvpOBhJJDE33Xv5cjR6z3/7A7NFXT/a8KSg/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=q/mql5QZUPyrK9XhtO7jcx3XrbQ84gfON//OxBZ0bqZWNqqF5zIeoauRcdZPPgu5Hk Sj+lTLtnLCdOiCE6xUz0Ppc9vmK1WpIXfpfNLtzmSixFF1TVbLGFaXkrIMYZo22WGGyZ FBNnZlOmGlW/Tzq/SR3INM8EFEOBba7RfFAwc= Received: by 10.68.54.135 with SMTP id j7mr10816192pbp.390.1303319059522; Wed, 20 Apr 2011 10:04:19 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id z7sm733497pbm.53.2011.04.20.10.04.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 10:04:18 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IETF80 6man Minutes Date: Wed, 20 Apr 2011 10:04:15 -0700 Message-Id: <8482FAEE-0F78-4516-BF64-451817360B84@gmail.com> To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:04:20 -0000 The minutes for the Prague IETF 6man working group meeting are now online at: http://www.ietf.org/proceedings/80/minutes/6man.txt Many thanks to Suresh Krishnan for excellent minutes! Bob and Brian From bob.hinden@gmail.com Wed Apr 20 14:25:04 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3CE0E074C for ; Wed, 20 Apr 2011 14:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j+9k9r69CPg for ; Wed, 20 Apr 2011 14:25:04 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id EE706E0728 for ; Wed, 20 Apr 2011 14:25:03 -0700 (PDT) Received: by pxi20 with SMTP id 20so854803pxi.27 for ; Wed, 20 Apr 2011 14:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=d2iYHsgk77LUabWFvs29/Ai8yKnLgke629Y1oGM20AY=; b=t9yxYoGWMNJ9+dTou5Ylx6I0pZMr8J0lw1mNc56P+uCmcYtJ9oq6I3ASNt6liotjLd wprWkIWOpQBaQY3Hhu9B6cbCPNX9L2D7lOO2MB3qqYo5yoZpFoRPpMnPMDzqBKwddrFE z1jn3KDQFVd6owbuAZzOGAm+L8m19wFxppUDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=yCPsUWON8qMrp0NXVw12eChcBLReC4h1uNjKYAlduet1aBqkkW/XR0+pax4LHtK78m xDBlwyoJWSVxrHGhaNU4jo7o9c6uVZyl7b5QHOdV4FKCO4Tlk0kpazNcb19SasPjrsbu qJd3/aSHlTEsiHjvsyMMU//Yfemz4vP9wXcJQ= Received: by 10.68.10.103 with SMTP id h7mr11306531pbb.203.1303334702178; Wed, 20 Apr 2011 14:25:02 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id k1sm852389pbh.34.2011.04.20.14.25.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 14:25:01 -0700 (PDT) Subject: Re: PMTU blackhole detection Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <12cf01cbfef7$0df30a40$29d91ec0$@com> Date: Wed, 20 Apr 2011 14:24:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D2AC00A-F416-489A-A331-69AA56429A01@gmail.com> References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> <12cf01cbfef7$0df30a40$29d91ec0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:25:04 -0000 Dan, >> Am I missing something here? >=20 > Yes. Over the years, the IETF's own website has suffered two outages > (and perhaps three) that were attributed to IPv6 PMTUD failures. To > my knowledge, it has suffered no outages attributed to IPv4 PMTUD > failures. >=20 > Google runs its IPv6-facing properties using a 1280 byte MTU, likely > to avoid adding IPv6 PMTUD failures to the reasons that IPv6 might > provide a worse user experience than IPv4. Afterall, there is no > need to try to resolve all problems at once while we're getting IPv6 > off the ground. >=20 > So, while I agree that 1500 should work equally well for both=20 > IPv4 and IPv6, it seems that for whatever combination of reasons,=20 > it works less well on IPv6 than IPv4. This is perhaps user error=20 > (configuration mistakes on firewalls or ACLs), more common use=20 > of IPv6-over-IPv4 tunnels than IPv4-over-IPv4 tunnels, bugs=20 > in vendor equipment, or something else. Thanks, this was helpful. I suspect that native (dual stack) end-to-end = probably works as well as IPv4, but see that the various tunneling = solutions don't. Bob >=20 > -d >=20 >=20 >> Bob >>=20 >>=20 >>=20 >>>=20 >>> This isn't quite "packets per second will increase by 16.2%", = though, >>> as of course not all packets are 'full'. But there will be a pps >>> increase. >>>=20 >>> -d >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 From bob.hinden@gmail.com Wed Apr 20 14:26:14 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A42E8E0728 for ; Wed, 20 Apr 2011 14:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCf2SL8JMbdR for ; Wed, 20 Apr 2011 14:26:14 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id D4894E0724 for ; Wed, 20 Apr 2011 14:26:13 -0700 (PDT) Received: by pxi20 with SMTP id 20so855446pxi.27 for ; Wed, 20 Apr 2011 14:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=bvW9BvhyMCqSfCZ0AiR/UtuBkWalilf0G/34tQs81TQ=; b=JGmrX9iHoKobO1V/qmGGhlSJHdUChmBoNAT5MpdOrlmwkLf6sPoSxG8DA6CjP18+FV FvhqPi+ZCSeVWZcsJ6C7hfmuL9lclZyevT3nN76NeRDa6Fg/75wiL3bCc0Q+y1/CdSYQ rKU2ewI68m0i2b/KlaVpNgYfjSx4l1j/UFWy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cmz2AklfjBw1eLR6WYDMP3ed2cdMV7n02NkdlCI+MpuCZA3E0zkwwCQxhSmgdYX7LZ Hih6tdZkpavPLEZNyphoaD+T9uMtXPlft18g0x5b9w5epqycAorsAIR8fwqZ2hYKZ8J/ B7uw+tZhJFZauUL77Ppu2a9qe+vvBxeHL8hHc= Received: by 10.68.66.228 with SMTP id i4mr8652399pbt.476.1303334773349; Wed, 20 Apr 2011 14:26:13 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id a4sm218427pbt.32.2011.04.20.14.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 14:26:12 -0700 (PDT) Subject: Re: PMTU blackhole detection Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <13f501cbff71$95cb7f40$c1627dc0$@com> Date: Wed, 20 Apr 2011 14:26:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <252D6288-1D8B-430B-A9CF-0C424265B360@gmail.com> References: <1302949733.11313.7.camel@macbook.infradead.org> <0a6d01cbfdf8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com> <12cf01cbfef7$0df30a40$29d91ec0$@com> <4DAE4C71.7090509@gmail.com> <13f501cbff71$95cb7f40$c1627dc0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden , 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:26:14 -0000 Dan, > Ben Stasiewicz has done some research on IPv6 MTU problems, > = http://ripe60.ripe.net/presentations/Stasiewicz-Measurements_of_IPv6_Path_= MTU_Discovery_Behaviour.pdf >=20 Very interesting. A good next step would be to figure out what caused = each type of failure. Bob From jreddy@ti.com Thu Apr 21 09:15:30 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9A2A0E06A7 for ; Thu, 21 Apr 2011 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg6oIh0SoY9q for ; Thu, 21 Apr 2011 09:15:29 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfc.amsl.com (Postfix) with ESMTP id 78CF6E0655 for ; Thu, 21 Apr 2011 09:15:29 -0700 (PDT) Received: from dlep33.itg.ti.com ([157.170.170.112]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3LGFSi4014759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Apr 2011 11:15:28 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep33.itg.ti.com (8.13.7/8.13.7) with ESMTP id p3LGFSB8009605 for ; Thu, 21 Apr 2011 11:15:28 -0500 (CDT) Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3LGFSah003250 for ; Thu, 21 Apr 2011 11:15:28 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Thu, 21 Apr 2011 11:15:10 -0500 From: "Reddy, Joseph" To: "'ipv6@ietf.org'" Date: Thu, 21 Apr 2011 11:15:03 -0500 Subject: Comment on rpl-routing-header draft Thread-Topic: Comment on rpl-routing-header draft Thread-Index: Acv+5PnAeiiqm4CPQVuDyDRUxMI7lQAkejmQADIWXkA= Message-ID: References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> In-Reply-To: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DE92901D19672647B9ADB0CB499498650508B31DB8dlee02enttico_" MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:15:30 -0000 --_000_DE92901D19672647B9ADB0CB499498650508B31DB8dlee02enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ( resending as original post didn't go through... ) Hi, I have a comment on the rpl-routing-header draft that was noticed during in= teroperability testing conducted by the zigbee alliance. In the most common usage of this header, the border router inserts a source= routing header with the full set of intermediate nodes before forwarding i= t towards the destination within the RPL network. In case of a forwarding error along the route, the intermediate node sends = the icmp error message to the source node, however in this case it actually= needs to send to the node that inserted the routing header. To fix this issue, the suggestion is that the node that inserts the soruce = routing header should include its own address as the first address in the l= ist. This will allow intermediate nodes to send error to it for forwarding = failures. -Regards, Joseph --_000_DE92901D19672647B9ADB0CB499498650508B31DB8dlee02enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
( resending as original post didn’t go through…= )
 
Hi,
 
I have a comment on the rpl-routing-header draft that= was noticed during interoperability testing conducted by the zigbee allian= ce.
 
In the most common usage of this header, the border r= outer inserts a source routing header with the full set of intermediate nod= es before forwarding it towards the destination within the RPL network.
 
In case of a forwarding error along the route, the in= termediate node sends the icmp error message to the source node, however in= this case it actually needs to send to the node that inserted the routing = header.
 
To fix this issue, the suggestion is that the node th= at inserts the soruce routing header should include its own address as the = first address in the list. This will allow intermediate nodes to send error= to it for forwarding failures.
 
 
-Regards, Joseph
 
 --_000_DE92901D19672647B9ADB0CB499498650508B31DB8dlee02enttico_-- From daniel.gavelle@nxp.com Fri Apr 22 01:25:36 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D21E6E0712 for ; Fri, 22 Apr 2011 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV-snrqzmvEh for ; Fri, 22 Apr 2011 01:25:34 -0700 (PDT) Received: from be1ssnxpe2.nxp.com (be1ssnxpe2.nxp.com [57.67.164.70]) by ietfc.amsl.com (Postfix) with ESMTP id 6CBADE0679 for ; Fri, 22 Apr 2011 01:25:33 -0700 (PDT) Received: from EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) by be1ssnxpe2.nxp.com (8.14.4/8.14.4) with ESMTP id p3M8PVSQ024313 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Apr 2011 10:25:31 +0200 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) with mapi; Fri, 22 Apr 2011 10:25:31 +0200 From: Daniel Gavelle To: "Reddy, Joseph" , "'ipv6@ietf.org'" Date: Fri, 22 Apr 2011 10:25:25 +0200 Subject: RE: Comment on rpl-routing-header draft Thread-Topic: Comment on rpl-routing-header draft Thread-Index: Acv+5PnAeiiqm4CPQVuDyDRUxMI7lQAkejmQADIWXkAAIdVUYA== Message-ID: <78B923726E7D59429936580CF127E943A14F57A9B4@eu1rdcrdc1wx032.exi.nxp.com> References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_78B923726E7D59429936580CF127E943A14F57A9B4eu1rdcrdc1wx0_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-22_04:2011-04-22, 2011-04-22, 1970-01-01 signatures=0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 08:25:37 -0000 --_000_78B923726E7D59429936580CF127E943A14F57A9B4eu1rdcrdc1wx0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support Joseph's proposal and plan to add it to our implementation. Regards, Daniel. -- __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Red= dy, Joseph Sent: 21 April 2011 17:15 To: 'ipv6@ietf.org' Subject: Comment on rpl-routing-header draft ( resending as original post didn't go through... ) Hi, I have a comment on the rpl-routing-header draft that was noticed during in= teroperability testing conducted by the zigbee alliance. In the most common usage of this header, the border router inserts a source= routing header with the full set of intermediate nodes before forwarding i= t towards the destination within the RPL network. In case of a forwarding error along the route, the intermediate node sends = the icmp error message to the source node, however in this case it actually= needs to send to the node that inserted the routing header. To fix this issue, the suggestion is that the node that inserts the soruce = routing header should include its own address as the first address in the l= ist. This will allow intermediate nodes to send error to it for forwarding = failures. -Regards, Joseph --_000_78B923726E7D59429936580CF127E943A14F57A9B4eu1rdcrdc1wx0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support Joseph’s proposal and plan to add it to our implementation.

 

=  

= Regards,

=  

= Daniel.

=  

= --

=  

= __________________________________________________

=  

= Daniel Gavelle, Software Team Leader

= Low Power RF Solutions (formerly Jennic Ltd.)

= NXP Semiconductors Furnival Street,

= Sheffield,

= S1 4QT, UK

= Tel: +44 114 281 2655

= Fax: +44 114 281 2951

= Comp Reg No: 3191371 - Registered In England

= http://www.nxp.com http://www.jennic.com

= __________________________________________________

 

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Reddy, Joseph
Sent: 21 April 2011 17:15
To: 'ipv6@ietf.org'
Subject: Comment on rpl-routing-header draft

 

 

 

( resending as original post didn’t go through… )

 

Hi,

 

I have a comment on the rpl-routing-header draft that was noticed during interoperability testing conducted by the zigbee alliance.

 

In the most common usage of this header, the border router inserts a source routing header with the full set of intermediate nodes before forwarding it= towards the destination within the RPL network.

 

In case of a forwarding error along the route, the intermediate node sends the icmp error message to the source node, however in this case it actually nee= ds to send to the node that inserted the routing header.

 

To fix this issue, the suggestion is that the node that inserts the soruce rou= ting header should include its own address as the first address in the list. Thi= s will allow intermediate nodes to send error to it for forwarding failures.<= /span>

 

 

-Regards, Joseph

 

--_000_78B923726E7D59429936580CF127E943A14F57A9B4eu1rdcrdc1wx0_-- From alexandru.petrescu@gmail.com Fri Apr 22 03:05:31 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 486E4E07D9 for ; Fri, 22 Apr 2011 03:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41B5Ox+73C6h for ; Fri, 22 Apr 2011 03:05:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfc.amsl.com (Postfix) with ESMTP id 5BF0FE0810 for ; Fri, 22 Apr 2011 03:05:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p3MA5SE5021521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2011 12:05:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p3MA5Sbs025610; Fri, 22 Apr 2011 12:05:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p3MA5SML019832; Fri, 22 Apr 2011 12:05:28 +0200 Message-ID: <4DB152E8.9050702@gmail.com> Date: Fri, 22 Apr 2011 12:05:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Comment on rpl-routing-header draft References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 10:05:31 -0000 The message from Joseph Reddy is important and makes sense. I have a remark to that message as well: when the RH is built as you suggest (BR inserts is own address in the RH (the one on which interface? an ll address?)) it may be questionable about how the AH authentication header is applied to it. BEcause - we do not have a specification about how to apply AH on RH5 (although we do know how to apply AH on other RHs). But we do have example text suggesting how to apply AH on RH5. The RH5 is currently specified at: http://www.ietf.org/id/draft-ietf-6man-rpl-routing-header-03.txt The example text suggesting applying AH on RH5, in the RoLL WG email archives, somewhere sept or october 2010. Alex Le 21/04/2011 18:15, Reddy, Joseph a écrit : > ( resending as original post didn’t go through… ) > Hi, > I have a comment on the rpl-routing-header draft that was noticed during > interoperability testing conducted by the zigbee alliance. > In the most common usage of this header, the border router inserts a > source routing header with the full set of intermediate nodes before > forwarding it towards the destination within the RPL network. > In case of a forwarding error along the route, the intermediate node > sends the icmp error message to the source node, however in this case it > actually needs to send to the node that inserted the routing header. > To fix this issue, the suggestion is that the node that inserts the > soruce routing header should include its own address as the first > address in the list. This will allow intermediate nodes to send error to > it for forwarding failures. > -Regards, Joseph > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jonhui@cisco.com Fri Apr 22 07:37:37 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9CA6E070F for ; Fri, 22 Apr 2011 07:37:37 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLlS9+Tdy+NQ for ; Fri, 22 Apr 2011 07:37:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 02F51E06AB for ; Fri, 22 Apr 2011 07:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=5665; q=dns/txt; s=iport; t=1303483055; x=1304692655; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=XAfxNly6PAiqofxcziRT1xT8fPFG9xpwBg6yrNxmiMc=; b=Rax20mgQjK/Y5oUgEEGyAUVZNk3BV1p8mYhiY5t4oioT+hmkKfSHKCnj 5sPpti9CJVcYnqSG9g91BKTv0EnB4bHVDV3c5rT6E1g892Bi5DwxemIZq vTuE4xBK4gEKJkeo+9d9aHrBtOls/JVXENr6bdEuS4HMdW7VcAGegXPUK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIKRsU2rRDoH/2dsb2JhbACCY6J7d6c5nGWFdgSFdIg5 X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208,217";a="434879367" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2011 14:37:34 +0000 Received: from dhcp-128-107-155-245.cisco.com (dhcp-128-107-155-245.cisco.com [128.107.155.245]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3MEbYPR007418; Fri, 22 Apr 2011 14:37:34 GMT Subject: Re: Comment on rpl-routing-header draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-905823541 From: Jonathan Hui In-Reply-To: Date: Fri, 22 Apr 2011 07:37:34 -0700 Message-Id: <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> To: "Reddy, Joseph" X-Mailer: Apple Mail (2.1084) Cc: "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:37:37 -0000 --Apple-Mail-1-905823541 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Joseph, I presume that you are not using IP-in-IP tunneling. If you were using = IP-in-IP tunneling as the draft suggests, then the source address of the = inserting router is included in the outer IP header. Your comment seems relevant to draft-hui-6man-rpl-headers-00, which = describes what needs to be done to directly insert the extension header = in the packet (and the risks involved with doing so). Note that this = draft has expired. Is there interest to revive it? -- Jonathan Hui On Apr 21, 2011, at 9:15 AM, Reddy, Joseph wrote: > ( resending as original post didn=92t go through=85 ) > =20 > Hi, > =20 > I have a comment on the rpl-routing-header draft that was noticed = during interoperability testing conducted by the zigbee alliance. > =20 > In the most common usage of this header, the border router inserts a = source routing header with the full set of intermediate nodes before = forwarding it towards the destination within the RPL network. > =20 > In case of a forwarding error along the route, the intermediate node = sends the icmp error message to the source node, however in this case it = actually needs to send to the node that inserted the routing header. > =20 > To fix this issue, the suggestion is that the node that inserts the = soruce routing header should include its own address as the first = address in the list. This will allow intermediate nodes to send error to = it for forwarding failures. > =20 > =20 > -Regards, Joseph > =20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-1-905823541 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Joseph,

I presume that you are not using = IP-in-IP tunneling.  If you were using IP-in-IP tunneling as the = draft suggests, then the source address of the inserting router is = included in the outer IP header.

Your comment = seems relevant to draft-hui-6man-rpl-headers-00, which describes = what needs to be done to directly insert the extension header in the = packet (and the risks involved with doing so).  Note that this = draft has expired.  Is there interest to revive = it?

--
Jonathan = Hui

On Apr 21, 2011, at 9:15 AM, Reddy, Joseph = wrote:

( resending as original post didn=92t go through=85 = )
 
Hi,
 
I have a comment on = the rpl-routing-header draft that was noticed during interoperability = testing conducted by the zigbee alliance.
 
In the most common = usage of this header, the border router inserts a source routing header = with the full set of intermediate nodes before forwarding it towards the = destination within the RPL network.
 
In case of a = forwarding error along the route, the intermediate node sends the icmp = error message to the source node, however in this case it actually needs = to send to the node that inserted the routing = header.
 
To fix this issue, the suggestion is that the node that = inserts the soruce routing header should include its own address as the = first address in the list. This will allow intermediate nodes to send = error to it for forwarding failures.
 
 
-Regards, = Joseph
 
-------------------------------------= -------------------------------
IETF IPv6 working group mailing = list
ipv6@ietf.org
Administrative = Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
----------------------------------------------= ----------------------

= --Apple-Mail-1-905823541-- From Fred.L.Templin@boeing.com Fri Apr 22 10:17:30 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 376F3E06C0 for ; Fri, 22 Apr 2011 10:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL7QTqhzZ0Xe for ; Fri, 22 Apr 2011 10:17:29 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfc.amsl.com (Postfix) with ESMTP id 6DC22E07DC for ; Fri, 22 Apr 2011 10:17:29 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3MHHRgh012566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2011 10:17:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p3MHHRWb002448; Fri, 22 Apr 2011 12:17:27 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3MHHGd9001993 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Apr 2011 12:17:17 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 22 Apr 2011 10:17:17 -0700 From: "Templin, Fred L" To: Bob Hinden , Dan Wing Date: Fri, 22 Apr 2011 10:17:16 -0700 Subject: RE: PMTU blackhole detection Thread-Topic: PMTU blackhole detection Thread-Index: Acv/os/vGgPRA2IySpOv8YCVfVIqEABbUZoA Message-ID: References: <1302949733.11313.7.camel @macbook.infradead.org> <0a6d01cbfdf 8$d3f8b640$7bea22c0$@com> <45C1967C-1877-458C-A29B-AD20BDD271AC@gmail.com>< 12cf01cbfef7$0df30a40$29d91ec0$@com> <4DAE4C71.7090509@gmail.com><13f501cbff71$95cb7f40$c1627dc0$@com> <252D6288-1D8B-430B-A9CF-0C424265B360@gmail.com> In-Reply-To: <252D6288-1D8B-430B-A9CF-0C424265B360@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 Cc: "ipv6@ietf.org" , 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:17:30 -0000 IMHO, IPv6 links that occur in the network (even tunnels) should try to do better than 1280 if possible. Otherwise, VPNs/tunnels that ride over the links may see a too-small MTU resulting in IPv6 fragmentation. Granted, doing better than 1280 may be difficult for some links. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bob Hinden > Sent: Wednesday, April 20, 2011 2:26 PM > To: Dan Wing > Cc: ipv6@ietf.org; Bob Hinden; 'Brian E Carpenter' > Subject: Re: PMTU blackhole detection >=20 > Dan, >=20 > > Ben Stasiewicz has done some research on IPv6 MTU problems, > >=20 > http://ripe60.ripe.net/presentations/Stasiewicz-Measurements_o > f_IPv6_Path_MTU_Discovery_Behaviour.pdf > >=20 >=20 > Very interesting. A good next step would be to figure out=20 > what caused each type of failure. >=20 > Bob >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From prz@mit.edu Mon Apr 18 01:52:43 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71482E066A; Mon, 18 Apr 2011 01:52: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8i+W2xIgWVH; Mon, 18 Apr 2011 01:52:38 -0700 (PDT) Received: from mail.philzimmermann.com (mail.philzimmermann.com [99.107.86.52]) by ietfc.amsl.com (Postfix) with ESMTP id 65816E06DB; Mon, 18 Apr 2011 01:52:38 -0700 (PDT) Received: from [192.168.1.146] (c-71-198-217-5.hsd1.ca.comcast.net [71.198.217.5]) (authenticated bits=0) by mail.philzimmermann.com (8.14.4/8.14.3) with ESMTP id p3I8qJ1F039094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2011 01:52:26 -0700 (PDT) (envelope-from prz@mit.edu) Subject: Re: [AVTCORE] RTP and UDP checksum=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Philip Zimmermann In-Reply-To: <4DABF00F.6080600@ericsson.com> Date: Mon, 18 Apr 2011 01:52:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD70F85-8B35-497C-9FE0-6CE52BE94F43@mit.edu> References: <012101cbfb81$84a04500$8de0cf00$@com> <4DABF00F.6080600@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 22 Apr 2011 10:28:46 -0700 Cc: "draft-ietf-6man-udpchecksums@tools.ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , "avt@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:52:43 -0000 I think it should use the checksum field. It is generally a bad idea = for one layer to neglect its usual built-in error-checking duties = because it assumes another layer will handle it. Let me draw an analogy from the crypto world, we don't use weak 56-bit = DES as our PGP keys because we assume that the email message will pass = through a strong SSL tunnel, so why bother to work so hard to protect = the message with strong keys in PGP? We see to our own layer's = security, without getting lazy and letting another layer handle it. = What if the other layer is not used? What if the email is not passing = through SSL? Oops. Every layer should try to look after its own obligations to protect = packets. If UDP was originally designed to carry checksums, we should = generate them all the time in the UDP layer. Just my two cents. On Apr 18, 2011, at 1:02 AM, Magnus Westerlund wrote: > Dan Wing skrev 2011-04-15 17:26: >> Observation: tunneled packets have two elements actively=20 >> deciding checksum=3D0 is okay. Those elements are the=20 >> tunnel encap and tunnel decap. >>=20 >> Question: Should non-tunneled UDP flows, *established with=20 >> explicit signaling*, also be allowed to decide that checksum=3D0=20 >> is okay? For example, an RTP-over-UDP flow established=20 >> with RTSP or SIP signaling. Some RTP traffic includes its >> own checksum at the application layer (e.g., SRTP authentication) >> and gains little or no benefit to a UDP checksum. Near as I >> can discern, SIP-signaled flows meet all of the constraints >> discussed in=20 >> http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1 >=20 > Dan, >=20 > I agree that SRTP would be safe to use without checksum also in v6. > However, using non-secured RTP without checksums are "a very bad idea" > (TM). >=20 > Also, if you are an end-point generating RTP flows then the UDP = checksum > overhead is generally not that big of an issue compared to all media > processing. I think the only node that where this could make any > significant difference are in a transport translator, which only = relays > an incoming packets to a number of other unicast addresses. >=20 > I do however, see a need for a number of additional mechanisms, at = least > signalling if one wants do do this for RTP with SRTP integrity > protection enabled. SIP/SDP signalling and maybe also an additional = ICE > STUN check to verify the capability prior to using it to avoid loss = due > to middleboxes that doesn't handle zero UDP checksum with v6. >=20 > My general fear is that the usage of zero checksum for IPv6 is done > without thinking and that it is similar in behavior to IPv4 which it > clearly is not, but I guess that is difficult to ensure. Soo frankly, = is > it really worth it for RTP? >=20 > I guess what you say comes down to if we should ensure that the text = is > generalized enough that it doesn't only apply to tunnel applications. = To > me the new specification text before the bullet list appears ok. If = only > give tunnels as an example. The bullet list also appears ok from a > non-tunnel application perspective. So it is likely only the title and > some of the introduction text that needs to be ensured that it doesn't > only speak of tunneling. >=20 > I think the authors should ensure this as it appears to be minor > modifications and clearly we didn't mean this to only be applicable to > one type of applications, but all that meets the considerations. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt ------------------------------------------------ Philip R Zimmermann prz@mit.edu (spelled with 2 n's) http://philzimmermann.com tel +1 831 425-7524 http://zfone.com From jreddy@ti.com Tue Apr 19 16:02:56 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D431E0807 for ; Tue, 19 Apr 2011 16:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5vGxtVFZDl2 for ; Tue, 19 Apr 2011 16:02:55 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfc.amsl.com (Postfix) with ESMTP id C3578E07E0 for ; Tue, 19 Apr 2011 16:02:55 -0700 (PDT) Received: from dlep36.itg.ti.com ([157.170.170.91]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3JN2ss2005068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Apr 2011 18:02:55 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3JN2sGW025846 for ; Tue, 19 Apr 2011 18:02:54 -0500 (CDT) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3JN2sdm017247 for ; Tue, 19 Apr 2011 18:02:54 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Tue, 19 Apr 2011 18:02:37 -0500 From: "Reddy, Joseph" To: "ipv6@ietf.org" Date: Tue, 19 Apr 2011 18:02:36 -0500 Subject: Comment on rpl-routing-header draft Thread-Topic: Comment on rpl-routing-header draft Thread-Index: Acv+5PnAeiiqm4CPQVuDyDRUxMI7lQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DE92901D19672647B9ADB0CB499498650508A7C0EBdlee02enttico_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 22 Apr 2011 10:28:46 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:02:56 -0000 --_000_DE92901D19672647B9ADB0CB499498650508A7C0EBdlee02enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a comment on the rpl-routing-header draft that was noticed during in= teroperability testing conducted by the zigbee alliance. In the most common usage of this header, the border router inserts a source= routing header with the full set of intermediate nodes before forwarding i= t towards the destination within the RPL network. In case of a forwarding error along the route, the intermediate node sends = the icmp error message to the source node, however in this case it actually= needs to send to the node that inserted the routing header. To fix this issue, the suggestion is that the node that inserts the soruce = routing header should include its own address as the first address in the l= ist. This will allow intermediate nodes to send error to it for forwarding = failures. -Regards, Joseph --_000_DE92901D19672647B9ADB0CB499498650508A7C0EBdlee02enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I have a comment on the rpl-routing-header draft that= was noticed during interoperability testing conducted by the zigbee allian= ce.
 
In the most common usage of this header, the border r= outer inserts a source routing header with the full set of intermediate nod= es before forwarding it towards the destination within the RPL network.
 
In case of a forwarding error along the route, the in= termediate node sends the icmp error message to the source node, however in= this case it actually needs to send to the node that inserted the routing = header.
 
To fix this issue, the suggestion is that the node th= at inserts the soruce routing header should include its own address as the = first address in the list. This will allow intermediate nodes to send error= to it for forwarding failures.
 
 
-Regards, Joseph
 
 --_000_DE92901D19672647B9ADB0CB499498650508A7C0EBdlee02enttico_-- From jreddy@ti.com Wed Apr 20 09:21:28 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 245F5E07A2 for ; Wed, 20 Apr 2011 09:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smosfn+mDGah for ; Wed, 20 Apr 2011 09:21:26 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfc.amsl.com (Postfix) with ESMTP id D90D7E065F for ; Wed, 20 Apr 2011 09:21:26 -0700 (PDT) Received: from dlep34.itg.ti.com ([157.170.170.115]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3KGLQ56004108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Apr 2011 11:21:26 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep34.itg.ti.com (8.13.7/8.13.7) with ESMTP id p3KGLPj2011286 for ; Wed, 20 Apr 2011 11:21:25 -0500 (CDT) Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3KGLP6E020617 for ; Wed, 20 Apr 2011 11:21:25 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Wed, 20 Apr 2011 11:21:08 -0500 From: "Reddy, Joseph" To: "'ipv6@ietf.org'" Date: Wed, 20 Apr 2011 11:21:06 -0500 Subject: Comment on rpl-routing-header draft Thread-Topic: Comment on rpl-routing-header draft Thread-Index: Acv+5PnAeiiqm4CPQVuDyDRUxMI7lQAkejmQ Message-ID: References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> In-Reply-To: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DE92901D19672647B9ADB0CB499498650508AE0EC3dlee02enttico_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 22 Apr 2011 10:28:46 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 16:21:28 -0000 --_000_DE92901D19672647B9ADB0CB499498650508AE0EC3dlee02enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ( resending as original post didn't go through... ) Hi, I have a comment on the rpl-routing-header draft that was noticed during in= teroperability testing conducted by the zigbee alliance. In the most common usage of this header, the border router inserts a source= routing header with the full set of intermediate nodes before forwarding i= t towards the destination within the RPL network. In case of a forwarding error along the route, the intermediate node sends = the icmp error message to the source node, however in this case it actually= needs to send to the node that inserted the routing header. To fix this issue, the suggestion is that the node that inserts the soruce = routing header should include its own address as the first address in the l= ist. This will allow intermediate nodes to send error to it for forwarding = failures. -Regards, Joseph --_000_DE92901D19672647B9ADB0CB499498650508AE0EC3dlee02enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
( resending as original post didn’t go through…= )
 
Hi,
 
I have a comment on the rpl-routing-header draft that= was noticed during interoperability testing conducted by the zigbee allian= ce.
 
In the most common usage of this header, the border r= outer inserts a source routing header with the full set of intermediate nod= es before forwarding it towards the destination within the RPL network.
 
In case of a forwarding error along the route, the in= termediate node sends the icmp error message to the source node, however in= this case it actually needs to send to the node that inserted the routing = header.
 
To fix this issue, the suggestion is that the node th= at inserts the soruce routing header should include its own address as the = first address in the list. This will allow intermediate nodes to send error= to it for forwarding failures.
 
 
-Regards, Joseph
 
 --_000_DE92901D19672647B9ADB0CB499498650508AE0EC3dlee02enttico_-- From timbeck04@verizon.net Fri Apr 22 11:44:56 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89427E06A3 for ; Fri, 22 Apr 2011 11:44: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9boVkanuCizt for ; Fri, 22 Apr 2011 11:44:55 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by ietfc.amsl.com (Postfix) with ESMTP id C905BE0655 for ; Fri, 22 Apr 2011 11:44:55 -0700 (PDT) Received: from Inbox ([unknown] [97.255.55.143]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LK20015YHEF8Q2Y@vms173005.mailsrvcs.net> for ipv6@ietf.org; Fri, 22 Apr 2011 13:44:45 -0500 (CDT) Message-id: <0LK200162HEH8Q2Y@vms173005.mailsrvcs.net> MIME-version: 1.0 Content-class: From: "Timothy E. Enos" Subject: RE: PMTU blackhole detection Date: Fri, 22 Apr 2011 14:44:44 -0400 Importance: normal X-Priority: 3 To: "Templin, Fred L" , Bob Hinden , Dan Wing Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=iso-8859-1 Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 18:44:56 -0000 I concur with Fred that IPv6 links over the network should have an MTU >128= 0 if possible.=20 The fragmentation that could occur at say the head-end of a tunnel seems en= ough of a contraindication in general for it having a 1280 MTU. Efficient use of (up)links is clearly another consideration when setting MT= U (and MSS for that matter). Tim Enos Ps 127:3-5 -----Original Message----- From: Templin, Fred L Sent: Friday, April 22, 2011 1:17 PM To: Bob Hinden ; Dan Wing Cc: ipv6@ietf.org ; 'Brian E Carpenter' Subject: RE: PMTU blackhole detection IMHO, IPv6 links that occur in the network (even tunnels) should try to do better than 1280 if possible. Otherwise, VPNs/tunnels that ride over the links may see a too-small MTU resulting in IPv6 fragmentation. Granted, doing better than 1280 may be difficult for some links. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bob Hinden > Sent: Wednesday, April 20, 2011 2:26 PM > To: Dan Wing > Cc: ipv6@ietf.org; Bob Hinden; 'Brian E Carpenter' > Subject: Re: PMTU blackhole detection >=20 > Dan, >=20 > > Ben Stasiewicz has done some research on IPv6 MTU problems, > >=20 > http://ripe60.ripe.net/presentations/Stasiewicz-Measurements_o > f_IPv6_Path_MTU_Discovery_Behaviour.pdf > >=20 >=20 > Very interesting. A good next step would be to figure out=20 > what caused each type of failure. >=20 > Bob >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Fri Apr 22 16:34:20 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6658E0669 for ; Fri, 22 Apr 2011 16:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp1DaUuj4yJv for ; Fri, 22 Apr 2011 16:34:20 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 00120E065F for ; Fri, 22 Apr 2011 16:34:19 -0700 (PDT) Received: by pzk30 with SMTP id 30so653733pzk.31 for ; Fri, 22 Apr 2011 16:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RkdpHalwhBSQW9ad6zTgyUALRzwTtMsriLqoT1phBmg=; b=VbPPpk9qRdlfVliVDdxBoyCWrjFyYsZTJmRsbWoF0gae9st7iHxZdjn4LmhY1h9bbX x9B6/Wql8h3keMNKtlQyk06O88yEkht5mgb8WTew1QUF81tFFDfFY/Sm2rZEU8vA/lPt eMM9sGFUokZ+S8lHPKApq+BhqlbH32j8e1e6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=noC9eIOW2gf5PyK8kaZHVeZIMIR1nHRZJdDSxVvDaCiq0eJ5UkYV+d5P5IzBXC4X7a xRwu1MFW8fNtVQ0Zo8d7tbMomy68Y/vZBBmABnjG8CdSjDY0dFJwpCpe3PmHf8a+OjOF vmC1zm+jx1Occv6KlDYHP7YAf3CvnPKuA+l+0= Received: by 10.68.15.130 with SMTP id x2mr2355345pbc.35.1303515259233; Fri, 22 Apr 2011 16:34:19 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id d10sm2273632pbe.75.2011.04.22.16.34.16 (version=SSLv3 cipher=OTHER); Fri, 22 Apr 2011 16:34:18 -0700 (PDT) Message-ID: <4DB21073.2050209@gmail.com> Date: Sat, 23 Apr 2011 11:34:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: IETF80 6man Minutes References: <8482FAEE-0F78-4516-BF64-451817360B84@gmail.com> In-Reply-To: <8482FAEE-0F78-4516-BF64-451817360B84@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 23:34:20 -0000 > Many thanks to Suresh Krishnan for excellent minutes! I'd really like to echo that. It's a pleasure to see minutes that summarise discussions in good English, rather than just record he said/she said. Regards Brian Carpenter From scott.brim@gmail.com Fri Apr 22 17:56:55 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4D69E0694 for ; Fri, 22 Apr 2011 17:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.238 X-Spam-Level: X-Spam-Status: No, score=-103.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tli2qYdK3Cwd for ; Fri, 22 Apr 2011 17:56:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 0158EE066B for ; Fri, 22 Apr 2011 17:56:54 -0700 (PDT) Received: by iwn39 with SMTP id 39so991924iwn.31 for ; Fri, 22 Apr 2011 17:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=54hVI3upDF31eeatAPPOhls28c7q83BZkpKfC38XPo8=; b=vkQ+R3nfuSWc/oXt3iPh6+wmhUfair2NuY7fRJTItEJUa/cem/XhtTCLU3c+AQDI0t jTCThxMZe3Ssh0wCqJslp0QAKS0XJKh4cdvgG6/DP766rH7fJDlNoQUE07RCaFw/hIUY T4aRNl0L0syjrjC2ylekbfttW/YQ8mJAGiC5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QQgE5k0vnoxb0DXPSfGR3MXsQ25+IjubIZX0HgBChMkmrxtaRtJa/JCJIeYbFeBUGm a8vYVBIOAzoeED717+bn2l8Jd7lLKaOWNIomTtuj0Id6F7ylmpbp25s7jIfT/toTc7A4 ZzeRIng/la6uQPFc0/KiBXNwebDc9rUeRdb7g= MIME-Version: 1.0 Received: by 10.231.192.197 with SMTP id dr5mr1240264ibb.2.1303520214482; Fri, 22 Apr 2011 17:56:54 -0700 (PDT) Received: by 10.231.16.140 with HTTP; Fri, 22 Apr 2011 17:56:54 -0700 (PDT) Received: by 10.231.16.140 with HTTP; Fri, 22 Apr 2011 17:56:54 -0700 (PDT) In-Reply-To: <8482FAEE-0F78-4516-BF64-451817360B84@gmail.com> References: <8482FAEE-0F78-4516-BF64-451817360B84@gmail.com> Date: Fri, 22 Apr 2011 20:56:54 -0400 Message-ID: Subject: Re: IETF80 6man Minutes From: Scott Brim To: Bob Hinden Content-Type: multipart/alternative; boundary=0016e6d279f85780b704a18b731c Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 00:56:55 -0000 --0016e6d279f85780b704a18b731c Content-Type: text/plain; charset=ISO-8859-1 On Apr 20, 2011 1:04 PM, "Bob Hinden" wrote: > > The minutes for the Prague IETF 6man working group meeting are now online at: > > http://www.ietf.org/proceedings/80/minutes/6man.txt > > Many thanks to Suresh Krishnan for excellent minutes! > > Bob and Brian "Scott Brim wanted some form of assurance from the router that the packets would not be exposed on the Internet." More accurately, s/router/network/. The context was that if the network does not let the endpoint do something about protecting its privacy, then it should take responsibility for doing so. This feeds into Thomas's comment that follows. Thanks... Scott --0016e6d279f85780b704a18b731c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 20, 2011 1:04 PM, "Bob Hinden" <bob.hinden@gmail.com> wrote:
>
> The minutes for the Prague IETF 6man working group meeting are now onl= ine at:
>
> =A0 ht= tp://www.ietf.org/proceedings/80/minutes/6man.txt
>
> Many thanks to Suresh Krishnan for excellent minutes!
>
> Bob and Brian

"Scott Brim wanted some form of assurance from the router that the = packets would not be exposed on the Internet."

More accurately, s/router/network/.

The context was that if the network does not let the endpoint do somethi= ng about protecting its privacy, then it should take responsibility for doi= ng so. This feeds into Thomas's comment that follows.

Thanks...=A0 Scott

--0016e6d279f85780b704a18b731c-- From parikshitmahalle@yahoo.com Sun Apr 24 00:57:41 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9050CE0743 for ; Sun, 24 Apr 2011 00:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSDgHw+GVbpT for ; Sun, 24 Apr 2011 00:57:41 -0700 (PDT) Received: from nm1-vm0.bullet.mail.in.yahoo.com (nm1-vm0.bullet.mail.in.yahoo.com [121.101.151.211]) by ietfc.amsl.com (Postfix) with SMTP id 9C806E06A0 for ; Sun, 24 Apr 2011 00:57:40 -0700 (PDT) Received: from [121.101.151.236] by nm1.bullet.mail.in.yahoo.com with NNFMP; 24 Apr 2011 07:57:36 -0000 Received: from [121.101.151.235] by tm1.bullet.mail.in.yahoo.com with NNFMP; 24 Apr 2011 07:59:44 -0000 Received: from [127.0.0.1] by omp1004.mail.in.yahoo.com with NNFMP; 24 Apr 2011 07:57:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 151507.52336.bm@omp1004.mail.in.yahoo.com Received: (qmail 36768 invoked by uid 60001); 24 Apr 2011 07:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303631856; bh=Owwx8+UCc8n6KRSS9T5aPMf+PqvSBRTl/VNxujCVERg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=nZB7B8lq4Y5n+h7nHX65t4RaHwIZd0weK7tTxmZkGYna3vyCUCjJaQVG/ng8EFFPvcopCxL8KsYuHGBFXKxCF8oUZ4Q0z2q1AqXyfBuyupfKsH0Nv5BhobSVzwdTsxKlsvU7IOiwzxS6zSG19MHKjbePWeMd5CuAF7S9xYMGUfw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=0UUx3l+aK6Fywj14yCFSBe5HzqnvhKzEo7gbJZxw8fh+1uEzFjFhK6AK23fZ1HtmOe5C/oU5skBzN0zpIvzAx5DXiGgm2eUzfMkYnD4uQM4VAk+XdryAJIwsiyCHO++tx3nJk/p9s8qKZBJDzI8RUtKAnnAuZjs06v4JQGPIWck=; Message-ID: <74024.36675.qm@web95620.mail.in.yahoo.com> X-YMail-OSG: 5Fr79VkVM1mREXe9PZ3n9YXSHskDlGhMZtk._abeIB4ScBY .8BTnGGpdwBdIUngghsYrh11EXk4d9i6WaX1BCFfmNHIdbd_WQc7FgMvsOIi YiczViXQSiyt7_AbqqOYOBY7ZSoJ..H25y9hVRgPTpQ5Mkpd2huqDxuiQzT5 dJUsrUz82Ob.5vsld7RgMJ3T5YeZTAlFc3428M4GUd2f5q0RoUMzChQ1QqNM RyJqSTMxrDKHnSVUDAEPs2r3AFw7guLg.NanDwlH_rc7bC2v1q8pcdcAws43 sfSQyhXMtC8divYRGpmtGi_2OjCRUVeBu1gOHw86ikdLi45vio4jAWC6Tgjf DPNRw5ID6XvROqD7UyRm5rMrHuywLtaxSvtWnDDZr1vk- Received: from [212.10.16.66] by web95620.mail.in.yahoo.com via HTTP; Sun, 24 Apr 2011 13:27:36 IST X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Sun, 24 Apr 2011 13:27:36 +0530 (IST) From: "Parikshit N. Mahalle" Subject: 6LoWPAN in NS 2 To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-391479726-1303631856=:36675" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 07:59:41 -0000 --0-391479726-1303631856=:36675 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear NS 2 Developers, =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 Do we have 6LoWPAN support in NS 2 !=20 Please reply=A0 with all possible ways... Best Regards =A0 Parikshit N. Mahalle Asstt. Professor Department of Computer Engineering, Sinhgad Technical Education Society's Smt. Kashibai Navale College of Enginering, Off Sinhgad Road Vadgaon (Bk), Pune - 411041 Cell : 9822416316 R : 020 - 26900008 =A0 " HAPPINESS IS FOUND ALONG THE WAY, NOT AT THE END OF ROAD " --0-391479726-1303631856=:36675 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear NS 2 Developers,
           &nbs= p;            &= nbsp;  Do we have 6LoWPAN support in NS 2 !
Please reply  with all possible ways...

Best Regards
 
Parikshit N. Mahalle
= Asstt. Professor
Department of Com= puter Engineering,
Sinhgad Technical Education Society's
Smt. Kashiba= i Navale College of Enginering,
Off Sinhgad Road
Vadgaon (Bk),
Pun= e - 411041
Cell : 9822416316
R : 020 - 26900008
 

" HAPPINESS IS FOUND ALONG THE WAY, NOT AT THE END OF ROA= D "

--0-391479726-1303631856=:36675-- From parikshitmahalle@yahoo.com Sun Apr 24 23:47:14 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7917AE06BC for ; Sun, 24 Apr 2011 23:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.958 X-Spam-Level: X-Spam-Status: No, score=0.958 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siLHksN-VYkT for ; Sun, 24 Apr 2011 23:47:13 -0700 (PDT) Received: from nm3.bullet.mail.in.yahoo.com (nm3.bullet.mail.in.yahoo.com [121.101.151.225]) by ietfc.amsl.com (Postfix) with SMTP id 58458E0694 for ; Sun, 24 Apr 2011 23:47:13 -0700 (PDT) Received: from [121.101.151.236] by nm3.bullet.mail.in.yahoo.com with NNFMP; 25 Apr 2011 06:51:14 -0000 Received: from [121.101.151.232] by tm1.bullet.mail.in.yahoo.com with NNFMP; 25 Apr 2011 06:49:15 -0000 Received: from [127.0.0.1] by omp1001.mail.in.yahoo.com with NNFMP; 25 Apr 2011 06:47:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 9173.75059.bm@omp1001.mail.in.yahoo.com Received: (qmail 84646 invoked by uid 60001); 25 Apr 2011 06:47:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303714026; bh=FgxBZBsiCA7A3crQ0khrigoa088Yty7c5MiDmFm1lpY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=K6IL2akKq0dbWiZM+O2Yfmeff5aVfGsXQdTw6rHgYxul3JxOtjnAPCOogMrQx1X78FZU2X+Wuoocex2ricRhBt3t3d4KnKSedsgbbUr+XfUVUpbhyDAE1REln6BK3FvisqX+0L5/+aqNEbHwoLY0liJoaokywCkMy1aed6KfSoo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=G2IKKIx0MXd8SPqHV4JhwkbNeUsRz+Phbtk3f91z9Y95I8MKm94W4SQhmt++/jDelPOf3ejfMNU5c3FT4hMYMANsVu8Ck8Zcf8BIlng3yWdVLsQYiSZ1oVr9VZG2oYhAjbU7/oLrKxlwgbR86nJUHXG+l9dUEc9Diy04/ohlZ6I=; Message-ID: <851480.56610.qm@web95614.mail.in.yahoo.com> X-YMail-OSG: 8iF8OZUVM1kYAyYIB0upxgC7Qm2gyznbogkn0KjZ4zVOmAS bxzWlIQ9CoYO4klmKnK80A0kftbKq1DWRruScD9296rzqlVVsE1YRiArgf7X 84Y7h_hSvH5XUBOHgyuT032e5VfhtE1DSFWddU4uVHe_YfLe9tMByhtYZIRa E6X8hUtbshehamXHD9l8N1v7HWphfh83RnDbTpEJCdOPJUF6np1AQtdNkxv. 6zw9q9wMSOdU_2e3zK1RtxfJMhNvI82rHLTZv_9LaayLcVQ7Eufylsra6kHe m5PsHE9e4qJ7bzRPe0SOEzYO4A52hoYr81H5dKbMy2YP7Ye9TpLJUOws9uJH z4_6ddQ8d8U1nVI_LfsFC2BfWKR1WRj2t_KCdEJQ4J6M- Received: from [212.10.16.66] by web95614.mail.in.yahoo.com via HTTP; Mon, 25 Apr 2011 12:17:06 IST X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Mon, 25 Apr 2011 12:17:06 +0530 (IST) From: "Parikshit N. Mahalle" Subject: 6LoWPAN in NS 2 To: buptnoc@gmail.com, ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1146979930-1303714026=:56610" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 06:47:14 -0000 --0-1146979930-1303714026=:56610 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear NS 2 Developers, =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 Do we have 6LoWPAN support in NS 2 !=20 Please reply=A0 with all possible ways... Best Regards =A0 Parikshit N. Mahalle Asstt. Professor Department of Computer Engineering, Sinhgad Technical Education Society's Smt. Kashibai Navale College of Enginering, Off Sinhgad Road Vadgaon (Bk), Pune - 411041 Cell : 9822416316 R : 020 - 26900008 =A0 " HAPPINESS IS FOUND ALONG THE WAY, NOT AT THE END OF ROAD " --0-1146979930-1303714026=:56610 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear NS 2 Developers,
   &n= bsp;            = ;           Do we have 6L= oWPAN support in NS 2 !
Please reply  with all possible ways...
Best Regards
 
Parikshit N. Mahalle
= Asstt. Professor
Department of Com= puter Engineering,
Sinhgad Technical Education Society's
Smt. Kashiba= i Navale College of Enginering,
Off Sinhgad Road
Vadgaon (Bk),
Pun= e - 411041
Cell : 9822416316
R : 020 - 26900008
 

" HAPPINESS IS FOUND ALONG THE WAY, NOT AT THE END OF ROA= D "

--0-1146979930-1303714026=:56610-- From asaeda@sfc.wide.ad.jp Mon Apr 25 07:19:57 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB9D1E073C for ; Mon, 25 Apr 2011 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.588 X-Spam-Level: X-Spam-Status: No, score=-97.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ckesErQI7TW for ; Mon, 25 Apr 2011 07:19:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfc.amsl.com (Postfix) with ESMTP id 7D290E0660 for ; Mon, 25 Apr 2011 07:19:56 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4BD65278088; Mon, 25 Apr 2011 23:19:52 +0900 (JST) Date: Mon, 25 Apr 2011 23:19:51 +0900 (JST) Message-Id: <20110425.231951.208621896.asaeda@sfc.wide.ad.jp> To: narten@us.ibm.com Subject: Re: MLD version for node req. draft From: Hitoshi Asaeda In-Reply-To: <201104192049.p3JKnDA1013131@cichlid.raleigh.ibm.com> References: <201102211530.p1LFU3NA009245@cichlid.raleigh.ibm.com> <20110222.110200.109949015.asaeda@sfc.wide.ad.jp> <201104192049.p3JKnDA1013131@cichlid.raleigh.ibm.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 14:19:58 -0000 Hi Thomas, >> >> "Nodes that need to join multicast groups SHOULD also implement either >> >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." >> > >> > Is there a short (less than one page) description of the difference >> > between RFCs 3810 and 5790? One that actually explains what the >> > implementation differences are? > > Ah, thanks for this description. The key is is that the EXCLUDE > functionality of MLDv2 adds considerable complexity, but is rarely > used. SO the Lighteight MLDv2 effectively excludes that functionality. What we also need to understand in the fiter operation is that (*,G) join (i.e. ASM join) is expressed by "EXCLUDE (NULL,G)" in the MLDv2's definition. LW-MLDv2 [RFC5790] of course supports ASM as well as SSM, hence it does not completely eliminate an EXCLUDE filter mode operation. Simply, LW-MLDv2 hosts eliminate the functionality to trigger an "EXCLUDE (S,G)" operation. > Here is what I propose to put into the Node Requirements revision: > > 5.10. Multicast Listener Discovery (MLD) for IPv6 > > Nodes that need to join multicast groups MUST support MLDv1 > [RFC2710]. MLDv1 is needed by any node that is expected to receive > and process multicast traffic. Note that Neighbor Discovery (as used > on most link types -- see Section 5.2) depends on multicast and > requires that nodes join Solicited Node multicast addresses. > > MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting > Source-Specific Multicast. The original MLDv2 protocol [RFC3810] Better to add the SSM's reference. "... supporting Source-Specific Multicast [RFC4607]." In fact, the draft-ietf-6man-node-req-bis-08 refers RFC3569 as the SSM's reference, but RFC4607 seems better as it, I think. > supports two types of "filter modes". Using an INCLUDE filter, a > node indicates a multicast group along with a list of senders for > that group it wishes to receive traffic from. Using an EXCLUDE > filter, a node indicates a multicast group along with a list of > senders it wishes to exclude receiving traffic from. I agree to the above statements. > In practice, EXCLUDE filters are rarely used, but add considerable > implementation complexity to MLDv2. I may want to change this to; "In practice, operations to block source(s) by EXCLUDE filter mode are rarely used, but add considerable implementation complexity to MLDv2." > Lightweight MLDv2 [RFC5790] is a simplified > subset of the original MLDv2 specification that omits EXCLUDE > functionality. I'd change this to; "Lightweight MLDv2 [RFC5790] is a simplified subset of the original MLDv2 specification that omits EXCLUDE filter mode specifying undesired source(s)." > Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 > [RFC5790]. Specifically, nodes supporting applications using Source- > Specific Multicast that expect to take advantage of MLDv2's EXCLUDE > functionality [RFC3569] MUST support MLDv2 as defined in [RFC3810], > [RFC4604] and [RFC4607]. Ok. > Nodes supporting applications that expect > to only take advantage of MLDv2's INCLUDE functionality will find it > sufficient to support MLDv2 as defined in [RFC5790]. "Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support MLDv2 as defined in [RFC5790]." > If the node only supports applications that use Any-Source Multicast > (i.e, they do not use source-specific multicast), implementing MLDv1 > [RFC2710] is sufficient. In all cases, however, nodes are strongly > encouraged to implement MLDv2 rather than MLDv1, as the presence of a > single MLDv1 participant on a link requires that all other nodes on > the link operate in version 1 compatibility mode. "In all cases, however, nodes are strongly encouraged to implement MLDv2 or Lightweight MLDv2 rather than MLDv1, as the presence of a single MLDv1 participant on a link requires that all other nodes on the link operate in version 1 compatibility mode." > When MLDv1 is used, the rules in the Source Address Selection for the > Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be > followed. > > Thomas Regards, -- Hitoshi Asaeda > Hitoshi Asaeda writes: > >> >> "Nodes that need to join multicast groups SHOULD also implement either >> >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." >> > >> > Is there a short (less than one page) description of the difference >> > between RFCs 3810 and 5790? One that actually explains what the >> > implementation differences are? > >> To start listening a multicast session/channel, an MLDv2 host >> specifies either 1) multicast address or 2) source and multicast >> addresses. > >> When the host specifies only multicast address, multicast packets sent >> from any source are forwarded to the host. This is ASM. > >> When the host specifies source address(es) as well as multicast >> address, it MUST also specify the "filter mode", which is either >> INCLUDE or EXCLUDE. When the host wants to "receive" the multicast >> packets sent from the specified source(es), INCLUDE is chosen as the >> filter mode. When the host wants to "block" the multicast packets sent >> from the specified source(es), EXCLUDE is chosen as the filter mode. >> The former case, INCLUDE (S,G) join, is known as SSM. The latter case, >> noted by EXCLUDE (S,G) join, is not SSM, rather ASM with an additional >> function; to establish EXCLUDE (S,G) state, routers need to maintain >> ASM state, because the routers need to forward every source data to >> their downstreams "except" the excluded S. > >> In fact, there are no major applications that require EXCLUDE (S,G) >> join/leave. It is only useful to filter out bogus sources in ASM >> communications, but if you want to block unwanted source, say Sx, >> you'd specify other sources to join the session such as INCLUDE >> ({S1,S2,S3},G) (without including Sx). > >> According to such consideration, talking abour the host-side >> implementation, the LW-MLDv2 spec (5790) supports both ASM and SSM >> communications, but eliminates EXCLUDE (S,G) join/leave operations. >> In fact, implementing both INCLUDE and EXCLUDE mode operations >> requires complex state machine in kernel; therefore LW-MLDv2 gives the >> chance for simpler kernel implementation. This is very positive >> condition, and it is sure according to my experience of both IGMPv3 >> and LW-IGMPv3 host-side kernel implementations in NetBSD. (I also >> have implemented MLDv2 kernel but no LW-MLDv2.) IMO, it is hence >> advantageous especially for mobile terminals or tiny OSes. >> Of course, LW-MLDv2 supports interoerability with any MLD versions; it >> works either with MLDv1, MLDv2, or LW-MLDv2 routers. > >> I hope this helps. > >> Regards, >> -- >> Hitoshi Asaeda > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jreddy@ti.com Mon Apr 25 09:54:13 2011 Return-Path: X-Original-To: ipv6@ietfc.amsl.com Delivered-To: ipv6@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4652AE0766 for ; Mon, 25 Apr 2011 09:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA6WDqxw2QVC for ; Mon, 25 Apr 2011 09:54:10 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfc.amsl.com (Postfix) with ESMTP id 57A72E0749 for ; Mon, 25 Apr 2011 09:54:10 -0700 (PDT) Received: from dlep34.itg.ti.com ([157.170.170.115]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3PGs8Qc023197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Apr 2011 11:54:08 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep34.itg.ti.com (8.13.7/8.13.7) with ESMTP id p3PGs87m025365; Mon, 25 Apr 2011 11:54:08 -0500 (CDT) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3PGs8EI026315; Mon, 25 Apr 2011 11:54:08 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Mon, 25 Apr 2011 11:53:48 -0500 From: "Reddy, Joseph" To: Jonathan Hui Date: Mon, 25 Apr 2011 11:53:46 -0500 Subject: RE: Comment on rpl-routing-header draft Thread-Topic: Comment on rpl-routing-header draft Thread-Index: AcwA+sf+1IXkgfKcQKemmpfluSIrswCbepEg Message-ID: References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> In-Reply-To: <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DE92901D19672647B9ADB0CB499498650508B3293Adlee02enttico_" MIME-Version: 1.0 Cc: "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:54:13 -0000 --_000_DE92901D19672647B9ADB0CB499498650508B3293Adlee02enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, Yes, we do not use IP-in-IP tunneling and instead simply insert the RH head= er in the packet. The other draft you mention is useful but I dont think it is suffcient. We = still need to change the extension header to include the address of the nod= e inserting it...am i missing something ? -Joseph ________________________________ From: Jonathan Hui [mailto:jonhui@cisco.com] Sent: Friday, April 22, 2011 7:38 AM To: Reddy, Joseph Cc: 'ipv6@ietf.org' Subject: Re: Comment on rpl-routing-header draft Hi Joseph, I presume that you are not using IP-in-IP tunneling. If you were using IP-= in-IP tunneling as the draft suggests, then the source address of the inser= ting router is included in the outer IP header. Your comment seems relevant to draft-hui-6man-rpl-headers-00, which describ= es what needs to be done to directly insert the extension header in the pac= ket (and the risks involved with doing so). Note that this draft has expir= ed. Is there interest to revive it? -- Jonathan Hui On Apr 21, 2011, at 9:15 AM, Reddy, Joseph wrote: ( resending as original post didn't go through... ) Hi, I have a comment on the rpl-routing-header draft that was noticed during in= teroperability testing conducted by the zigbee alliance. In the most common usage of this header, the border router inserts a source= routing header with the full set of intermediate nodes before forwarding i= t towards the destination within the RPL network. In case of a forwarding error along the route, the intermediate node sends = the icmp error message to the source node, however in this case it actually= needs to send to the node that inserted the routing header. To fix this issue, the suggestion is that the node that inserts the soruce = routing header should include its own address as the first address in the l= ist. This will allow intermediate nodes to send error to it for forwarding = failures. -Regards, Joseph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_DE92901D19672647B9ADB0CB499498650508B3293Adlee02enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3Dx-msg://13/>
 
Hi Jonathan,

Yes, we do not=20 use IP-in-IP tunneling and instead simply insert the RH header in the= =20 packet.
The other draft you mention is useful but I dont t= hink it=20 is suffcient. We still need to change the extension header to include=20 the address of the node inserting it...am i missing something=20 ?
 
-Joseph

From: Jonathan Hui [mailto:jonhui@cisco= .com]=20
Sent: Friday, April 22, 2011 7:38 AM
To: Reddy,=20 Joseph
Cc: 'ipv6@ietf.org'
Subject: Re: Comment on=20 rpl-routing-header draft


Hi Joseph,

I presume that you are not using IP-in-IP tunneling.  If you were= =20 using IP-in-IP tunneling as the draft suggests, then the source address of = the=20 inserting router is included in the outer IP header.

Your comment seems relevant to draft-hui-6man-rpl-headers-00, whi= ch=20 describes what needs to be done to directly insert the extension header in = the=20 packet (and the risks involved with doing so).  Note that this draft h= as=20 expired.  Is there interest to revive it?

--
Jonathan Hui

On Apr 21, 2011, at 9:15 AM, Reddy, Joseph wrote:
( resending as original p= ost=20 didn’t go through… )
 
Hi,
 
I have a comment on the rpl-routing-header draft that= was=20 noticed during interoperability testing conducted by the zigbee=20 alliance.
 
In the most common usage of this header, the border r= outer=20 inserts a source routing header with the full set of intermediate nodes b= efore=20 forwarding it towards the destination within the RPL network.
 
In case of a forwarding error along the route, the=20 intermediate node sends the icmp error message to the source node, howeve= r in=20 this case it actually needs to send to the node that inserted the routing= =20 header.
 
To fix this issue, the suggestion is that the node th= at=20 inserts the soruce routing header should include its own address as the f= irst=20 address in the list. This will allow intermediate nodes to send error to = it=20 for forwarding failures.
 
 
-Regards, Joseph
 
--------------------------------------= ------------------------------
IETF=20 IPv6 working group mailing list
ipv6@ietf.org
Administrative Request= s: https://www.ietf.org/= mailman/listinfo/ipv6
----------------------------------------------= ----------------------

--_000_DE92901D19672647B9ADB0CB499498650508B3293Adlee02enttico_-- From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Apr 25 23:06:02 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9550E0705 for ; Mon, 25 Apr 2011 23:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGPVr1Zi6c6P for ; Mon, 25 Apr 2011 23:06:02 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id C9C1DE06E6 for ; Mon, 25 Apr 2011 23:06:01 -0700 (PDT) Received: from 219-90-214-243.ip.adam.com.au ([219.90.214.243] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QEbPL-0006jy-FU for ipv6@ietf.org; Tue, 26 Apr 2011 15:35:59 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A3EDB3B337 for ; Tue, 26 Apr 2011 15:35:58 +0930 (CST) Date: Tue, 26 Apr 2011 15:35:58 +0930 From: Mark Smith To: ipv6@ietf.org Subject: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker Message-ID: <20110426153558.269de972@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 06:06:03 -0000 Hi, I'd like to suggest the a few rules to be inserted between Rules 3 and 4 of RFC3484 - Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 2462 sense), then prefer the one that is "preferred." Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB. Suggested rule - Rule X: Prefer greatest preferred lifetime If the addresses SA and SB both have non-zero value preferred lifetimes (are "non-deprecated"), prefer the address with the greatest value preferred lifetime. An example of where this would help produce better behaviour - Geert Hendrickx reported to the ipv6-ops list that his VPS provider was using SLAAC addresses for their own monitoring, while providing static IPv6 address ranges within the same /64 for customers to use for their own purposes, so hosts have both SLAAC addresses and static addresses. When multiple addresses have a "preferred" status, Linux chooses the most recently added/configured address. In this VPS scenario, this meant that outbound connections were using the SLAAC addresses, despite Geert wanting all outbound connections to use the static IPv6 addresses. His VPS provider would not allow SLAAC to switched off. With the above suggested rule, the infinite preferred lifetime of the static addresses verses the (presumably) non-infinite preferred lifetimes of the SLAAC addresses would cause the static addresses to be preferred as the source address. Related to the above suggested rule, I think there may also need to be some final last resort tie breaker rule to cover the situation where two addresses have the same value preferred lifetimes e.g. two static addresses or a static and SLAAC address with infinite preferred lifetimes. I think it'd be best to avoid something variable like most recently added/configured, so possibly something like using the numerically greatest interface id might be adequate. Regards, Mark. From arifumi@nttv6.net Tue Apr 26 04:16:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2389E06B6 for ; Tue, 26 Apr 2011 04:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.031 X-Spam-Level: X-Spam-Status: No, score=-102.031 tagged_above=-999 required=5 tests=[AWL=0.568, 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 s11Qb+STrlV1 for ; Tue, 26 Apr 2011 04:16:50 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 943E5E0670 for ; Tue, 26 Apr 2011 04:16:50 -0700 (PDT) Received: from radiko.smartstream.ne.jp (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p3QBFLkV068486; Tue, 26 Apr 2011 20:15:21 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <20110426153558.269de972@opy.nosense.org> Date: Tue, 26 Apr 2011 20:15:31 +0900 Content-Transfer-Encoding: 7bit Message-Id: <5A3AA65B-C894-4185-A936-0E2268FA846F@nttv6.net> References: <20110426153558.269de972@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:16:59 -0000 Mark, in your case, policy table should be helpful to manipulate source address selection behavior for SLAAC and manually configured addresses. As the final tie breaker, I do not see much sense to use preferred lifetime for that purpose. Indefinite lifetime does not always mean high preference. Regarding determinacy, it should not be useful when you have multiple SLAAC addresses. Kindest regards, On 2011/04/26, at 15:05, Mark Smith wrote: > Hi, > > I'd like to suggest the a few rules to be inserted between Rules 3 and 4 > of RFC3484 - > > Rule 3: Avoid deprecated addresses. > The addresses SA and SB have the same scope. If one of the two > source addresses is "preferred" and one of them is "deprecated" (in > the RFC 2462 sense), then prefer the one that is "preferred." > > Rule 4: Prefer home addresses. > If SA is simultaneously a home address and care-of address and SB is > not, then prefer SA. Similarly, if SB is simultaneously a home > address and care-of address and SA is not, then prefer SB. > If SA is just a home address and SB is just a care-of address, then > prefer SA. Similarly, if SB is just a home address and SA is just a > care-of address, then prefer SB. > > Suggested rule - > > Rule X: Prefer greatest preferred lifetime > If the addresses SA and SB both have non-zero value preferred > lifetimes (are "non-deprecated"), prefer the address with the > greatest value preferred lifetime. > > > An example of where this would help produce better behaviour - > > Geert Hendrickx reported to the ipv6-ops list that his VPS provider > was using SLAAC addresses for their own monitoring, while providing > static IPv6 address ranges within the same /64 for customers to use for > their own purposes, so hosts have both SLAAC addresses and static > addresses. When multiple addresses have a "preferred" status, Linux > chooses the most recently added/configured address. In this VPS > scenario, this meant that outbound connections were using the SLAAC > addresses, despite Geert wanting all outbound connections to use the > static IPv6 addresses. His VPS provider would not allow SLAAC to > switched off. > > With the above suggested rule, the infinite preferred lifetime of the > static addresses verses the (presumably) non-infinite preferred > lifetimes of the SLAAC addresses would cause the static addresses to be > preferred as the source address. > > Related to the above suggested rule, I think there may also need to be > some final last resort tie breaker rule to cover the situation where two > addresses have the same value preferred lifetimes e.g. two static > addresses or a static and SLAAC address with infinite preferred > lifetimes. I think it'd be best to avoid something variable like most > recently added/configured, so possibly something like using the > numerically greatest interface id might be adequate. > > Regards, > Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From narten@us.ibm.com Tue Apr 26 06:01:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDDE076C for ; Tue, 26 Apr 2011 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.812 X-Spam-Level: X-Spam-Status: No, score=-105.812 tagged_above=-999 required=5 tests=[AWL=0.787, 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 GLe3fFeJPxIX for ; Tue, 26 Apr 2011 06:01:13 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id CE40BE076A for ; Tue, 26 Apr 2011 06:01:12 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3QCigtd022315 for ; Tue, 26 Apr 2011 06:44:42 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3QCwTld313980 for ; Tue, 26 Apr 2011 06:59:05 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3QCwSPp025761 for ; Tue, 26 Apr 2011 06:58:28 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-237-220.mts.ibm.com [9.65.237.220]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3QCwRFK025683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 06:58:28 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3QCwNVf014222; Tue, 26 Apr 2011 08:58:26 -0400 Message-Id: <201104261258.p3QCwNVf014222@cichlid.raleigh.ibm.com> To: Hitoshi Asaeda Subject: Re: MLD version for node req. draft In-reply-to: <20110425.231951.208621896.asaeda@sfc.wide.ad.jp> References: <201102211530.p1LFU3NA009245@cichlid.raleigh.ibm.com> <20110222.110200.109949015.asaeda@sfc.wide.ad.jp> <201104192049.p3JKnDA1013131@cichlid.raleigh.ibm.com> <20110425.231951.208621896.asaeda@sfc.wide.ad.jp> Comments: In-reply-to Hitoshi Asaeda message dated "Mon, 25 Apr 2011 23:19:51 +0900." Date: Tue, 26 Apr 2011 08:58:23 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:01:14 -0000 Good clarifications. I have revised the text. Thanks! Thomas Hitoshi Asaeda writes: > Hi Thomas, > >> >> "Nodes that need to join multicast groups SHOULD also implement either > >> >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." > >> > > >> > Is there a short (less than one page) description of the difference > >> > between RFCs 3810 and 5790? One that actually explains what the > >> > implementation differences are? > > > > Ah, thanks for this description. The key is is that the EXCLUDE > > functionality of MLDv2 adds considerable complexity, but is rarely > > used. SO the Lighteight MLDv2 effectively excludes that functionality. > What we also need to understand in the fiter operation is that (*,G) > join (i.e. ASM join) is expressed by "EXCLUDE (NULL,G)" in the MLDv2's > definition. > LW-MLDv2 [RFC5790] of course supports ASM as well as SSM, hence it > does not completely eliminate an EXCLUDE filter mode operation. > Simply, LW-MLDv2 hosts eliminate the functionality to trigger an > "EXCLUDE (S,G)" operation. > > Here is what I propose to put into the Node Requirements revision: > > > > 5.10. Multicast Listener Discovery (MLD) for IPv6 > > > > Nodes that need to join multicast groups MUST support MLDv1 > > [RFC2710]. MLDv1 is needed by any node that is expected to receive > > and process multicast traffic. Note that Neighbor Discovery (as used > > on most link types -- see Section 5.2) depends on multicast and > > requires that nodes join Solicited Node multicast addresses. > > > > MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting > > Source-Specific Multicast. The original MLDv2 protocol [RFC3810] > Better to add the SSM's reference. > "... supporting Source-Specific Multicast [RFC4607]." > In fact, the draft-ietf-6man-node-req-bis-08 refers RFC3569 as the > SSM's reference, but RFC4607 seems better as it, I think. > > supports two types of "filter modes". Using an INCLUDE filter, a > > node indicates a multicast group along with a list of senders for > > that group it wishes to receive traffic from. Using an EXCLUDE > > filter, a node indicates a multicast group along with a list of > > senders it wishes to exclude receiving traffic from. > I agree to the above statements. > > In practice, EXCLUDE filters are rarely used, but add considerable > > implementation complexity to MLDv2. > I may want to change this to; > "In practice, operations to block source(s) by EXCLUDE filter mode are > rarely used, but add considerable implementation complexity to MLDv2." > > Lightweight MLDv2 [RFC5790] is a simplified > > subset of the original MLDv2 specification that omits EXCLUDE > > functionality. > I'd change this to; > "Lightweight MLDv2 [RFC5790] is a simplified subset of the original > MLDv2 specification that omits EXCLUDE filter mode specifying > undesired source(s)." > > Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 > > [RFC5790]. Specifically, nodes supporting applications using Source- > > Specific Multicast that expect to take advantage of MLDv2's EXCLUDE > > functionality [RFC3569] MUST support MLDv2 as defined in [RFC3810], > > [RFC4604] and [RFC4607]. > Ok. > > Nodes supporting applications that expect > > to only take advantage of MLDv2's INCLUDE functionality will find it > > sufficient to support MLDv2 as defined in [RFC5790]. > "Nodes supporting applications that expect to only take advantage of > MLDv2's INCLUDE functionality as well as Any-Source Multicast will > find it sufficient to support MLDv2 as defined in [RFC5790]." > > If the node only supports applications that use Any-Source Multicast > > (i.e, they do not use source-specific multicast), implementing MLDv1 > > [RFC2710] is sufficient. In all cases, however, nodes are strongly > > encouraged to implement MLDv2 rather than MLDv1, as the presence of a > > single MLDv1 participant on a link requires that all other nodes on > > the link operate in version 1 compatibility mode. > "In all cases, however, nodes are strongly encouraged to implement > MLDv2 or Lightweight MLDv2 rather than MLDv1, as the presence of a > single MLDv1 participant on a link requires that all other nodes on > the link operate in version 1 compatibility mode." > > When MLDv1 is used, the rules in the Source Address Selection for the > > Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be > > followed. > > > > Thomas > Regards, > -- > Hitoshi Asaeda > > Hitoshi Asaeda writes: > > > >> >> "Nodes that need to join multicast groups SHOULD also implement either > >> >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." > >> > > >> > Is there a short (less than one page) description of the difference > >> > between RFCs 3810 and 5790? One that actually explains what the > >> > implementation differences are? > > > >> To start listening a multicast session/channel, an MLDv2 host > >> specifies either 1) multicast address or 2) source and multicast > >> addresses. > > > >> When the host specifies only multicast address, multicast packets sent > >> from any source are forwarded to the host. This is ASM. > > > >> When the host specifies source address(es) as well as multicast > >> address, it MUST also specify the "filter mode", which is either > >> INCLUDE or EXCLUDE. When the host wants to "receive" the multicast > >> packets sent from the specified source(es), INCLUDE is chosen as the > >> filter mode. When the host wants to "block" the multicast packets sent > >> from the specified source(es), EXCLUDE is chosen as the filter mode. > >> The former case, INCLUDE (S,G) join, is known as SSM. The latter case, > >> noted by EXCLUDE (S,G) join, is not SSM, rather ASM with an additional > >> function; to establish EXCLUDE (S,G) state, routers need to maintain > >> ASM state, because the routers need to forward every source data to > >> their downstreams "except" the excluded S. > > > >> In fact, there are no major applications that require EXCLUDE (S,G) > >> join/leave. It is only useful to filter out bogus sources in ASM > >> communications, but if you want to block unwanted source, say Sx, > >> you'd specify other sources to join the session such as INCLUDE > >> ({S1,S2,S3},G) (without including Sx). > > > >> According to such consideration, talking abour the host-side > >> implementation, the LW-MLDv2 spec (5790) supports both ASM and SSM > >> communications, but eliminates EXCLUDE (S,G) join/leave operations. > >> In fact, implementing both INCLUDE and EXCLUDE mode operations > >> requires complex state machine in kernel; therefore LW-MLDv2 gives the > >> chance for simpler kernel implementation. This is very positive > >> condition, and it is sure according to my experience of both IGMPv3 > >> and LW-IGMPv3 host-side kernel implementations in NetBSD. (I also > >> have implemented MLDv2 kernel but no LW-MLDv2.) IMO, it is hence > >> advantageous especially for mobile terminals or tiny OSes. > >> Of course, LW-MLDv2 supports interoerability with any MLD versions; it > >> works either with MLDv1, MLDv2, or LW-MLDv2 routers. > > > >> I hope this helps. > > > >> Regards, > >> -- > >> Hitoshi Asaeda > > > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Tue Apr 26 06:07:37 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA769E0767 for ; Tue, 26 Apr 2011 06:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.864 X-Spam-Level: X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=0.735, 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 TisB3xw80eZh for ; Tue, 26 Apr 2011 06:07:37 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAAFE0715 for ; Tue, 26 Apr 2011 06:07:37 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3Q5Axuf029383 for ; Mon, 25 Apr 2011 23:10:59 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3QCugi6049908 for ; Tue, 26 Apr 2011 06:56:42 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3QCuf92020537 for ; Tue, 26 Apr 2011 06:56:42 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-237-220.mts.ibm.com [9.65.237.220]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3QCudoB020146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 06:56:41 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3QCucF4014183; Tue, 26 Apr 2011 08:56:38 -0400 Message-Id: <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> To: "Reddy, Joseph" Subject: Re: Comment on rpl-routing-header draft In-reply-to: References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> Comments: In-reply-to "Reddy, Joseph" message dated "Mon, 25 Apr 2011 11:53:46 -0500." Date: Tue, 26 Apr 2011 08:56:38 -0400 From: Thomas Narten Cc: "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:07:37 -0000 > In the most common usage of this header, the border router inserts a > source routing header with the full set of intermediate nodes before > forwarding it towards the destination within the RPL network. and then. > Yes, we do not use IP-in-IP tunneling and instead simply insert the RH head= > er in the packet. What specification are you following that says do this? Routing headers (as designed and specified) are inserted by an originating node (whether the original sender or a tunnel entry point). If you have a middle node insert this header to an existing packet, no suprise things are not going to work. Thomas From Guillaume.Leclanche@swisscom.com Tue Apr 26 06:10:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F7EE0778 for ; Tue, 26 Apr 2011 06:10:57 -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 cdCNIaAiaxuu for ; Tue, 26 Apr 2011 06:10:57 -0700 (PDT) Received: from mail.swisscom.com (outmail100.swisscom.com [193.222.81.100]) by ietfa.amsl.com (Postfix) with ESMTP id DA15BE0777 for ; Tue, 26 Apr 2011 06:10:56 -0700 (PDT) Received: by intmail1.corproot.net; Tue, 26 Apr 2011 15:10:54 +0200 From: To: , Subject: RE: Introducing draft-6man-addresspartnaming Thread-Topic: Introducing draft-6man-addresspartnaming Thread-Index: AQHL9V97ca/ZFYGqbUCQyaMnydccSpRdt3IAgBJ6A1A= Date: Tue, 26 Apr 2011 13:10:53 +0000 Message-ID: <1BE5D090C6244A49B9815F339F76EA4507AE0129@SG000708.corproot.net> References: In-Reply-To: Accept-Language: fr-CH, de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.222.84.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:10:57 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBSaWNoYXJk IEhhcnRtYW5uDQo+IA0KPiBhZnRlciByZW5hbWluZyB0byBkcmFmdC1oYXJ0bWFubi02bWFuLWFk ZHJlc3NwYXJ0bmFtaW5nLCBJIGFtIHN0aWxsDQo+IHdhaXRpbmcgZm9yIGZlZWRiYWNrLg0KDQpI aSwNCg0KSSd2ZSBiZWVuIHRoaW5raW5nIGFuZCByZWFkaW5nIGFib3V0IGl0LiBJIGJlbGlldmUg dGhhdCBpZiB0aGlzIGRvYyB3aWxsIHN0YW5kYXJkaXplIGFueXRoaW5nLCB0aGVuIGl0IHNob3Vs ZCBiZSBsaW5ndWlzdGljYWxseSBjb3JyZWN0Lg0KQXMgYSBjb25zZXF1ZW5jZSwgImhleHRldCIg Y2FuJ3QgYmUgZXZlbiBtZW50aW9uZWQgZm9yIG9mZmljaWFsIGRvY3VtZW50cy4gSWYgb2ZmaWNp YWwgZG9jdW1lbnRzIHdyaXRlcnMgd2FudC9oYXZlIHRvIHVzZSBhIHdvcmQgKHJhdGhlciB0aGFu ICJiaXRzIDMzIHRvIDQ4IiksIHRoZXkgaGF2ZSB0byB1c2Ugc29tZXRoaW5nIGNvcnJlY3QuIElu IG15IG9waW5pb24gdGhlIElFVEYgY2FuJ3QganVzdCBtZXNzIHdpdGggbGluZ3Vpc3RpYyBmb3Ig dGhlIGZ1biBvZiBpdC4gDQoNCg0KSWYgd2Ugc3BsaXQgIm9jdGV0IiA6DQoib2N0by0iICsgIi1l dCINCg0KU28gaW4gdGhlb3J5IDoNCiJoZXhhZGVjaW0tIiArICItZXQiID0gImhleGFkZWNpbWV0 Ig0KDQoodGhlICJ0IiBpbiAiaGV4ZGVjdGV0IiBjb21lcyBmcm9tICJvY3QtIiBub3QgZnJvbSAi LWV0Iiwgc28gaXQncyBpbmNvcnJlY3QgYXMgd2VsbCkNCg0KDQpTbyBteSBwcm9wb3NhbCBhcyBh biBpbmRpdmlkdWFsIHRoYXQgaGFzIGFic29sdXRlbHkgbm8gYXV0aG9yaXR5IGFib3V0IHRoZSBt YXR0ZXIgaXMgOg0KDQoxIDogImhleGFkZWNpbWV0IiBbaW4gRW5nbGlzaCA6IC/LjGjJm2tzyZnL iGTJm3PJmW3Jm3QvXSBNVVNUIGJlIHVzZWQgaW4gb2ZmaWNpYWwgZG9jdW1lbnRzLg0KMiA6IGRl bGV0ZSBhbnkgbWVudGlvbiBvZiBxdWliYmxlLCBoZXh0ZXQsIGhleGFkZWN0ZXQsIG9yIG90aGVy IHZhcmlhbnRzLg0KDQoNCg0KTGV0J3MgbGVhdmUgaXQgdXAgdG8gcGVvcGxlIHRvIGRlY2lkZSB3 aGljaCBvbmUgdGhleSB3YW50IHRvIHVzZSBmb3IgaW5mb3JtYWwgY29tbXVuaWNhdGlvbiBhbmQg aGF2ZSB0aGlzIGRvYyBzdGFuZGFyZGl6ZSBvbmx5IHRoZSBleGFjdCBvbmx5IG9mZmljaWFsIG5h bWluZyBmb3IgSUVURiBkb2N1bWVudHMuDQoNCg0KR3VpbGxhdW1lDQoNCg0K From jared@puck.nether.net Tue Apr 26 06:27:51 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50C2E0760 for ; Tue, 26 Apr 2011 06:27:51 -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 mYd+0zB5Bb59 for ; Tue, 26 Apr 2011 06:27:51 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id E3A20E075E for ; Tue, 26 Apr 2011 06:27:50 -0700 (PDT) Received: from [10.0.0.241] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p3QDRcIS068518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Apr 2011 09:27:43 -0400 (EDT) (envelope-from jared@puck.nether.net) Subject: Re: Introducing draft-6man-addresspartnaming Mime-Version: 1.0 (Apple Message framework v1216) Content-Type: text/plain; charset=utf-8 From: Jared Mauch In-Reply-To: <1BE5D090C6244A49B9815F339F76EA4507AE0129@SG000708.corproot.net> Date: Tue, 26 Apr 2011 09:27:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1BE5D090C6244A49B9815F339F76EA4507AE0129@SG000708.corproot.net> To: X-Mailer: Apple Mail (2.1216) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 26 Apr 2011 09:27:45 -0400 (EDT) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:27:51 -0000 On Apr 26, 2011, at 9:10 AM, wrote: >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of >> Richard Hartmann >>=20 >> after renaming to draft-hartmann-6man-addresspartnaming, I am still >> waiting for feedback. >=20 > Hi, >=20 > I've been thinking and reading about it. I believe that if this doc = will standardize anything, then it should be linguistically correct. > As a consequence, "hextet" can't be even mentioned for official = documents. If official documents writers want/have to use a word (rather = than "bits 33 to 48"), they have to use something correct. In my opinion = the IETF can't just mess with linguistic for the fun of it.=20 >=20 >=20 > If we split "octet" : > "octo-" + "-et" >=20 > So in theory : > "hexadecim-" + "-et" =3D "hexadecimet" >=20 > (the "t" in "hexdectet" comes from "oct-" not from "-et", so it's = incorrect as well) >=20 >=20 > So my proposal as an individual that has absolutely no authority about = the matter is : >=20 > 1 : "hexadecimet" [in English : /=CB=8Ch=C9=9Bks=C9=99=CB=88d=C9=9Bs=C9=99= m=C9=9Bt/] MUST be used in official documents. > 2 : delete any mention of quibble, hextet, hexadectet, or other = variants. >=20 >=20 >=20 > Let's leave it up to people to decide which one they want to use for = informal communication and have this doc standardize only the exact only = official naming for IETF documents. [having actually read the draft] Seems as reasonable as anything else. I certainly see the interest in = disclosing the alternates considered, the formal document should likely = omit these and some other reference (e.g.: list archive) should refer to = the historical suggestions. - Jared= From magnus.westerlund@ericsson.com Tue Apr 26 09:22:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9116EE0813 for ; Tue, 26 Apr 2011 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, 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 L7eM6kEor-Zx for ; Tue, 26 Apr 2011 09:22:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AD716E080B for ; Tue, 26 Apr 2011 09:22:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-ed-4db6f15c56b3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7D.41.11171.C51F6BD4; Tue, 26 Apr 2011 18:22:52 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 26 Apr 2011 18:22:52 +0200 Message-ID: <4DB6F15C.8060808@ericsson.com> Date: Tue, 26 Apr 2011 18:22:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Submitted new version of draft-ietf-6man-udpzero X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 16:22:57 -0000 Hi, For your information Gorry and I have submitted new versions of https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ There has been no announcement of this due to a bug in the new I-D submission tool that I tried out. The changes in the document are really only editorial. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bob.hinden@gmail.com Tue Apr 26 09:50:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F172CE0713 for ; Tue, 26 Apr 2011 09:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW+1YwEdwDUN for ; Tue, 26 Apr 2011 09:50:28 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5CE06A6 for ; Tue, 26 Apr 2011 09:50:28 -0700 (PDT) Received: by iwn39 with SMTP id 39so870703iwn.31 for ; Tue, 26 Apr 2011 09:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=eZZ6v+T2VMqwbaBqyigi8VPh25S76wnQobzcKcqsaEU=; b=rf3bDVbWiTTcNR0KRCn1dbTK2eXiRHQfY4MDGw8d76r5y4r676LKaQs7HxfzCYVtZd +XjuZNqjJQD5uIjHL9cXzyQPl21gLqtRGcfLWXcgWQCsX4TqlL+vSt1kiL1H5oh9aI5G PGePJDgWK+IAe+cj6IoxmieZ+G3iJY0aRE7j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AnSxhZDtSwHoAqyuiZ5rs3P7xv4zHX5A/F8JzeaCYC+WVf1zhBHm/8m0y8fKS2prG/ KOnzITex8Q2p6kJnxWkIsQIxzc3Vl0n8pIbzsr9dAUW0xrxuHTgosNLQDznFQmvHvAsI RhecI0koB85HzdmewvNvkESyxc0EZPezy06ks= Received: by 10.42.224.198 with SMTP id ip6mr1081402icb.407.1303836627750; Tue, 26 Apr 2011 09:50:27 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id u17sm422505ibm.62.2011.04.26.09.50.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 09:50:26 -0700 (PDT) Subject: Re: IETF80 6man Minutes Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Tue, 26 Apr 2011 09:50:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <112E8400-3128-4918-9CA0-694B7951770D@gmail.com> References: <8482FAEE-0F78-4516-BF64-451817360B84@gmail.com> To: Scott Brim X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 16:50:29 -0000 Scott, Thanks, the minutes have been updated. Bob On Apr 22, 2011, at 5:56 PM, Scott Brim wrote: >=20 > On Apr 20, 2011 1:04 PM, "Bob Hinden" wrote: > > > > The minutes for the Prague IETF 6man working group meeting are now = online at: > > > > http://www.ietf.org/proceedings/80/minutes/6man.txt > > > > Many thanks to Suresh Krishnan for excellent minutes! > > > > Bob and Brian >=20 > "Scott Brim wanted some form of assurance from the router that the = packets would not be exposed on the Internet." >=20 > More accurately, s/router/network/. >=20 > The context was that if the network does not let the endpoint do = something about protecting its privacy, then it should take = responsibility for doing so. This feeds into Thomas's comment that = follows. >=20 > Thanks... Scott >=20 From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Apr 26 15:17:36 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDDDE07DD for ; Tue, 26 Apr 2011 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL3f9OWzxO3g for ; Tue, 26 Apr 2011 15:17:35 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB3E076F for ; Tue, 26 Apr 2011 15:17:35 -0700 (PDT) Received: from 219-90-214-243.ip.adam.com.au ([219.90.214.243] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QEqZX-0000Qn-UX; Wed, 27 Apr 2011 07:47:32 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 454193B337; Wed, 27 Apr 2011 07:47:31 +0930 (CST) Date: Wed, 27 Apr 2011 07:47:30 +0930 From: Mark Smith To: Arifumi Matsumoto Subject: Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker Message-ID: <20110427074730.341d158e@opy.nosense.org> In-Reply-To: <5A3AA65B-C894-4185-A936-0E2268FA846F@nttv6.net> References: <20110426153558.269de972@opy.nosense.org> <5A3AA65B-C894-4185-A936-0E2268FA846F@nttv6.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 22:17:36 -0000 Hi Arifumi, On Tue, 26 Apr 2011 20:15:31 +0900 Arifumi Matsumoto wrote: > Mark, > > in your case, policy table should be helpful to manipulate source > address selection behavior for SLAAC and manually configured > addresses. > True, although that requires actively changing the default policy. > As the final tie breaker, I do not see much sense to use preferred > lifetime for that purpose. Indefinite lifetime does not always mean > high preference. I'm not sure I agree. If I think about the thought process of choosing a particular value for a preferred lifetime, it seems to me that the more you prefer an address, the larger you set the preferred lifetime. An infinite preferred lifetime therefore indicates you want the address to be preferred infinitely. That seems to be consistent with static addresses having infinite preferred and valid lifetimes by default, where as dynamic addresses usually have lower preferred lifetime values. You usually configure static addresses with the intention that they'll be used in preference over to anything else. I think that would be the common expectation of people, yet Linux isn't doing that. However, there doesn't seem to be any rules in RFC3484 that either directly or indirectly makes static addresses preferred over any others. I can see some logic in what Linux is doing, although I don't think this behaviour is described and specified in RFC3484. It seems to be taking the view that the most recently updated information is the most preferred. I think the drawback of that is that fundamentally it is incorporating into the address selection process attributes that aren't specifically address attributes - it is now including how recently the addresses were updated, which in the case of SLAAC addresses means that RA announcement intervals also now have an influence over address selection. If these sorts of address configuration source related attributes were intended to be incorporated into the address selection, then I'd be expecting there'd be rules that specify preference between static, stateful and stateless address configuration sources, and tie breakers within them e.g. router preference in RAs when there are two stateless address configuration sources (i.e. two routers). I think we'd end up with far more rules than exist now if address configuration source attributes were to be intentionally incorporated into the address selection process. So in an update to RFC3484, I'd be seeking some more specific and defined default behavior for when multiple addresses are "non-deprecated". It seems to me that the amount of preference, indicated by the current value of the preferred lifetime would be a fairly simple way to achieve that and be applicable to a number of common scenarios, such as static vs SLAAC, or SLAAC vs SLAAC. > Regarding determinacy, it should not be useful when > you have multiple SLAAC addresses. > I think from a troubleshooing point of view it can be. It is my current expectation to be able to look at a range of current addresses on an interface and be able to be able to predict quite accurately in most cases, based on knowing the default set of address selection rules, the address that is going to be used for new outbound connections. Best regards, Mark. > Kindest regards, > > On 2011/04/26, at 15:05, Mark Smith wrote: > > > Hi, > > > > I'd like to suggest the a few rules to be inserted between Rules 3 and 4 > > of RFC3484 - > > > > Rule 3: Avoid deprecated addresses. > > The addresses SA and SB have the same scope. If one of the two > > source addresses is "preferred" and one of them is "deprecated" (in > > the RFC 2462 sense), then prefer the one that is "preferred." > > > > Rule 4: Prefer home addresses. > > If SA is simultaneously a home address and care-of address and SB is > > not, then prefer SA. Similarly, if SB is simultaneously a home > > address and care-of address and SA is not, then prefer SB. > > If SA is just a home address and SB is just a care-of address, then > > prefer SA. Similarly, if SB is just a home address and SA is just a > > care-of address, then prefer SB. > > > > Suggested rule - > > > > Rule X: Prefer greatest preferred lifetime > > If the addresses SA and SB both have non-zero value preferred > > lifetimes (are "non-deprecated"), prefer the address with the > > greatest value preferred lifetime. > > > > > > An example of where this would help produce better behaviour - > > > > Geert Hendrickx reported to the ipv6-ops list that his VPS provider > > was using SLAAC addresses for their own monitoring, while providing > > static IPv6 address ranges within the same /64 for customers to use for > > their own purposes, so hosts have both SLAAC addresses and static > > addresses. When multiple addresses have a "preferred" status, Linux > > chooses the most recently added/configured address. In this VPS > > scenario, this meant that outbound connections were using the SLAAC > > addresses, despite Geert wanting all outbound connections to use the > > static IPv6 addresses. His VPS provider would not allow SLAAC to > > switched off. > > > > With the above suggested rule, the infinite preferred lifetime of the > > static addresses verses the (presumably) non-infinite preferred > > lifetimes of the SLAAC addresses would cause the static addresses to be > > preferred as the source address. > > > > Related to the above suggested rule, I think there may also need to be > > some final last resort tie breaker rule to cover the situation where two > > addresses have the same value preferred lifetimes e.g. two static > > addresses or a static and SLAAC address with infinite preferred > > lifetimes. I think it'd be best to avoid something variable like most > > recently added/configured, so possibly something like using the > > numerically greatest interface id might be adequate. > > > > Regards, > > Mark. > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 > From jreddy@ti.com Tue Apr 26 16:39:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4F5E06C1 for ; Tue, 26 Apr 2011 16:39:30 -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 BI1z6hvS140Q for ; Tue, 26 Apr 2011 16:39:29 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5FE06AA for ; Tue, 26 Apr 2011 16:39:29 -0700 (PDT) Received: from dlep35.itg.ti.com ([157.170.170.118]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3QNdRr5008174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 18:39:27 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id p3QNdR7T025166; Tue, 26 Apr 2011 18:39:27 -0500 (CDT) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3QNdRlD014608; Tue, 26 Apr 2011 18:39:27 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Tue, 26 Apr 2011 18:39:07 -0500 From: "Reddy, Joseph" To: Thomas Narten Date: Tue, 26 Apr 2011 18:39:06 -0500 Subject: RE: Comment on rpl-routing-header draft Thread-Topic: Comment on rpl-routing-header draft Thread-Index: AcwEEV50JjCbL+sNTUSsAWwjzZgJ9wAWUlvw Message-ID: References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> In-Reply-To: <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 23:39:30 -0000 Hi Thomas Since RPL protocol is intended to operate in networks with constrained devi= ces and lossy, low-bandwidth links, there is a desire to not require IP-in-= IP tunnelling that is usually used for inserting routing headers. This is d= etailed in the draft http://tools.ietf.org/html/draft-hui-6man-rpl-headers-= 00 but I realize now this draft expired recently. Perhaps this can be reviv= ed as it is helps to improve the applicability of RPL protocol.=20 -Joseph -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Tuesday, April 26, 2011 5:57 AM To: Reddy, Joseph Cc: Jonathan Hui; 'ipv6@ietf.org' Subject: Re: Comment on rpl-routing-header draft > In the most common usage of this header, the border router inserts a=20 > source routing header with the full set of intermediate nodes before=20 > forwarding it towards the destination within the RPL network. and then. > Yes, we do not use IP-in-IP tunneling and instead simply insert the RH=20 > head=3D er in the packet. What specification are you following that says do this? Routing headers (as designed and specified) are inserted by an originating = node (whether the original sender or a tunnel entry point). If you have a m= iddle node insert this header to an existing packet, no suprise things are = not going to work. Thomas From narten@us.ibm.com Tue Apr 26 18:08:07 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2CAE0789 for ; Tue, 26 Apr 2011 18:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.91 X-Spam-Level: X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=0.689, 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 GmjoSoMveZ9t for ; Tue, 26 Apr 2011 18:08:06 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 71EA7E0680 for ; Tue, 26 Apr 2011 18:08:06 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3QHMAAB029687 for ; Tue, 26 Apr 2011 11:22:10 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3R17sHm155028 for ; Tue, 26 Apr 2011 19:07:54 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3R17rUZ019544 for ; Tue, 26 Apr 2011 19:07:53 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-237-220.mts.ibm.com [9.65.237.220]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3R17ql3019502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 19:07:53 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3R17pJ8022377; Tue, 26 Apr 2011 21:07:51 -0400 Message-Id: <201104270107.p3R17pJ8022377@cichlid.raleigh.ibm.com> To: "Reddy, Joseph" Subject: Re: Comment on rpl-routing-header draft In-reply-to: References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> Comments: In-reply-to "Reddy, Joseph" message dated "Tue, 26 Apr 2011 18:39:06 -0500." Date: Tue, 26 Apr 2011 21:07:51 -0400 From: Thomas Narten Cc: "'ipv6@ietf.org'" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 01:08:07 -0000 If you are purposefully breaking existing Standards Track specifications (which is what it sounds like you are doing) in order to "not require IP in IP tunneling" (a local optimization), you probably won't get much sympathy here. Certainly not from me! Thomas > Since RPL protocol is intended to operate in networks with > constrained devices and lossy, low-bandwidth links, there is a > desire to not require IP-in-IP tunnelling that is usually used for > inserting routing headers. This is detailed in the draft > http://tools.ietf.org/html/draft-hui-6man-rpl-headers-00 but I > realize now this draft expired recently. Perhaps this can be > revived as it is helps to improve the applicability of RPL > protocol. > -Joseph > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, April 26, 2011 5:57 AM > To: Reddy, Joseph > Cc: Jonathan Hui; 'ipv6@ietf.org' > Subject: Re: Comment on rpl-routing-header draft > > In the most common usage of this header, the border router inserts a > > source routing header with the full set of intermediate nodes before > > forwarding it towards the destination within the RPL network. > and then. > > Yes, we do not use IP-in-IP tunneling and instead simply insert the RH > > head= er in the packet. > What specification are you following that says do this? > Routing headers (as designed and specified) are inserted by an originating node (whether the original sender or a tunnel entry point). If you have a middle node insert this header to an existing packet, no suprise things are not going to work. > Thomas From arifumi@nttv6.net Tue Apr 26 23:44:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EC2E06C5 for ; Tue, 26 Apr 2011 23:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 8MN-mv8Sjiwg for ; Tue, 26 Apr 2011 23:44:48 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1B99FE06AF for ; Tue, 26 Apr 2011 23:44:47 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p3R6hLbu075508; Wed, 27 Apr 2011 15:43:21 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <20110427074730.341d158e@opy.nosense.org> Date: Wed, 27 Apr 2011 15:43:33 +0900 Content-Transfer-Encoding: 7bit Message-Id: <571D70AF-1572-4776-8E17-0D530A845174@nttv6.net> References: <20110426153558.269de972@opy.nosense.org> <5A3AA65B-C894-4185-A936-0E2268FA846F@nttv6.net> <20110427074730.341d158e@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 06:44:52 -0000 Mark, On 2011/04/27, at 7:17, Mark Smith wrote: > Hi Arifumi, > > On Tue, 26 Apr 2011 20:15:31 +0900 > Arifumi Matsumoto wrote: > >> Mark, >> >> in your case, policy table should be helpful to manipulate source >> address selection behavior for SLAAC and manually configured >> addresses. >> > > True, although that requires actively changing the default policy. If the manually configured address is static, you need not change the policy so often. >> As the final tie breaker, I do not see much sense to use preferred >> lifetime for that purpose. Indefinite lifetime does not always mean >> high preference. > > I'm not sure I agree. If I think about the thought process of choosing > a particular value for a preferred lifetime, it seems to me that the > more you prefer an address, the larger you set the preferred lifetime. > An infinite preferred lifetime therefore indicates you want the address > to be preferred infinitely. That seems to be consistent with static > addresses having infinite preferred and valid lifetimes by default, > where as dynamic addresses usually have lower preferred lifetime > values. You usually configure static addresses with the intention that > they'll be used in preference over to anything else. I think that would > be the common expectation of people, yet Linux isn't doing that. > However, there doesn't seem to be any rules in RFC3484 that either > directly or indirectly makes static addresses preferred over any > others. I do not think it is usual or common expectation that a manually configured address should have higher preference over a SLAAC address. Sometimes I have a case where I want to use static address for receiving sessions, and a dynamically assigned address for outgoing sessions. In this case, your suggested lifetime rule always chooses an unexpected address. If I want to use a manually configured address, usually I would turn of SLAAC for that specific interface. Your case of VPS seems to me really specific to your site. And such kind of site local policy should be implemented using the policy table. > I can see some logic in what Linux is doing, although I don't think > this behaviour is described and specified in RFC3484. It seems to be > taking the view that the most recently updated information is the most > preferred. I think the drawback of that is that fundamentally it is > incorporating into the address selection process attributes that aren't > specifically address attributes - it is now including how recently the > addresses were updated, which in the case of SLAAC addresses means that > RA announcement intervals also now have an influence over address > selection. If these sorts of address configuration source related > attributes were intended to be incorporated into the address selection, > then I'd be expecting there'd be rules that specify preference between > static, stateful and stateless address configuration sources, and tie > breakers within them e.g. router preference in RAs when there are two > stateless address configuration sources (i.e. two routers). I'm not sure agree that there should be a default rule for prioritizing static, stateful, stateless addresses. However, I believe using router preference for that purpose is messing things up, in that it is intended for routing purpose. > I think > we'd end up with far more rules than exist now if address configuration > source attributes were to be intentionally incorporated into the > address selection process. > > So in an update to RFC3484, I'd be seeking some more specific and > defined default behavior for when multiple addresses are > "non-deprecated". It seems to me that the amount of preference, > indicated by the current value of the preferred lifetime would be a > fairly simple way to achieve that and be applicable to a number of > common scenarios, such as static vs SLAAC, or SLAAC vs SLAAC. >> Regarding determinacy, it should not be useful when >> you have multiple SLAAC addresses. >> > > I think from a troubleshooing point of view it can be. It is my > current expectation to be able to look at a range of current addresses > on an interface and be able to be able to predict quite accurately in > most cases, based on knowing the default set of address selection rules, > the address that is going to be used for new outbound connections. > As I mentioned above, I see some sense to define address type dependent prioritization, but lifetime should not be used for that purpose. Regards, > Best regards, > Mark. > >> Kindest regards, >> >> On 2011/04/26, at 15:05, Mark Smith wrote: >> >>> Hi, >>> >>> I'd like to suggest the a few rules to be inserted between Rules 3 and 4 >>> of RFC3484 - >>> >>> Rule 3: Avoid deprecated addresses. >>> The addresses SA and SB have the same scope. If one of the two >>> source addresses is "preferred" and one of them is "deprecated" (in >>> the RFC 2462 sense), then prefer the one that is "preferred." >>> >>> Rule 4: Prefer home addresses. >>> If SA is simultaneously a home address and care-of address and SB is >>> not, then prefer SA. Similarly, if SB is simultaneously a home >>> address and care-of address and SA is not, then prefer SB. >>> If SA is just a home address and SB is just a care-of address, then >>> prefer SA. Similarly, if SB is just a home address and SA is just a >>> care-of address, then prefer SB. >>> >>> Suggested rule - >>> >>> Rule X: Prefer greatest preferred lifetime >>> If the addresses SA and SB both have non-zero value preferred >>> lifetimes (are "non-deprecated"), prefer the address with the >>> greatest value preferred lifetime. >>> >>> >>> An example of where this would help produce better behaviour - >>> >>> Geert Hendrickx reported to the ipv6-ops list that his VPS provider >>> was using SLAAC addresses for their own monitoring, while providing >>> static IPv6 address ranges within the same /64 for customers to use for >>> their own purposes, so hosts have both SLAAC addresses and static >>> addresses. When multiple addresses have a "preferred" status, Linux >>> chooses the most recently added/configured address. In this VPS >>> scenario, this meant that outbound connections were using the SLAAC >>> addresses, despite Geert wanting all outbound connections to use the >>> static IPv6 addresses. His VPS provider would not allow SLAAC to >>> switched off. >>> >>> With the above suggested rule, the infinite preferred lifetime of the >>> static addresses verses the (presumably) non-infinite preferred >>> lifetimes of the SLAAC addresses would cause the static addresses to be >>> preferred as the source address. >>> >>> Related to the above suggested rule, I think there may also need to be >>> some final last resort tie breaker rule to cover the situation where two >>> addresses have the same value preferred lifetimes e.g. two static >>> addresses or a static and SLAAC address with infinite preferred >>> lifetimes. I think it'd be best to avoid something variable like most >>> recently added/configured, so possibly something like using the >>> numerically greatest interface id might be adequate. >>> >>> Regards, >>> Mark. >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail: arifumi@nttv6.net >> TEL +81-422-59-3334 FAX +81-422-59-6364 >> -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Apr 27 04:25:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E82E06D0 for ; Wed, 27 Apr 2011 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2fP4i9nRIoU for ; Wed, 27 Apr 2011 04:25:54 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 58A63E06BF for ; Wed, 27 Apr 2011 04:25:53 -0700 (PDT) Received: from 219-90-214-243.ip.adam.com.au ([219.90.214.243] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QF2sR-0001nc-Lg; Wed, 27 Apr 2011 20:55:51 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id DD4363B33B; Wed, 27 Apr 2011 20:55:50 +0930 (CST) Date: Wed, 27 Apr 2011 20:55:50 +0930 From: Mark Smith To: Arifumi Matsumoto Subject: Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker Message-ID: <20110427205550.07cdcb22@opy.nosense.org> In-Reply-To: <571D70AF-1572-4776-8E17-0D530A845174@nttv6.net> References: <20110426153558.269de972@opy.nosense.org> <5A3AA65B-C894-4185-A936-0E2268FA846F@nttv6.net> <20110427074730.341d158e@opy.nosense.org> <571D70AF-1572-4776-8E17-0D530A845174@nttv6.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 11:25:59 -0000 Hi Arifumi, On Wed, 27 Apr 2011 15:43:33 +0900 Arifumi Matsumoto wrote: > Mark, > > On 2011/04/27, at 7:17, Mark Smith wrote: > > > Hi Arifumi, > > > > On Tue, 26 Apr 2011 20:15:31 +0900 > > Arifumi Matsumoto wrote: > > > >> Mark, > >> > >> in your case, policy table should be helpful to manipulate source > >> address selection behavior for SLAAC and manually configured > >> addresses. > >> > > > > True, although that requires actively changing the default policy. > > If the manually configured address is static, you need not change > the policy so often. > In most cases, I think that IPv6 should be as at least as easy to operate IPv4, and hopefully much easier. So I and I think most people would think that configuring an IPv6 static address should be as easy as it is in IPv4, involving no more than specifying the address and the interface. As people seem to be commonly using static IPv6 addresses for servers and servers are quite common, I think having both IPv4 and IPv6 static address configuration involve equivalent effort would be very useful. > >> As the final tie breaker, I do not see much sense to use preferred > >> lifetime for that purpose. Indefinite lifetime does not always mean > >> high preference. > > > > I'm not sure I agree. If I think about the thought process of choosing > > a particular value for a preferred lifetime, it seems to me that the > > more you prefer an address, the larger you set the preferred lifetime. > > An infinite preferred lifetime therefore indicates you want the address > > to be preferred infinitely. That seems to be consistent with static > > addresses having infinite preferred and valid lifetimes by default, > > where as dynamic addresses usually have lower preferred lifetime > > values. You usually configure static addresses with the intention that > > they'll be used in preference over to anything else. I think that would > > be the common expectation of people, yet Linux isn't doing that. > > However, there doesn't seem to be any rules in RFC3484 that either > > directly or indirectly makes static addresses preferred over any > > others. > > I do not think it is usual or common expectation that a manually > configured address should have higher preference over a SLAAC > address. > I provided at least one example where somebody had that expectation, and I have the same expectation. None of the people in the thread of conversation (which I originally intended to link to, apologies for not doing so) ever disputed that static's shouldn't override the SLAAC addresses. Here is the thread - http://lists.cluenet.de/pipermail/ipv6-ops/2010-November/004328.html or in long form - http://www.gossamer-threads.com/lists/nsp/ipv6/26148 Thinking about it in more detail, the only time I ever go to the additional effort of overriding an automated mechanism (such as SLAAC in this case) is when it has an operational property that I find undesirable. People go to an additional effort when they configure static addresses in the presence of SLAAC addressing, so I'd be confident they want those static addresses to normally be preferred over the SLAAC addressing. I'll send a query to the ipv6-ops list just to see if this is a common expectation. > Sometimes I have a case where I want to use static address for > receiving sessions, and a dynamically assigned address for > outgoing sessions. In this case, your suggested lifetime rule > always chooses an unexpected address. > It wouldn't if you specified the preferred lifetime of your static address to zero, leaving the valid lifetime at infinity. For outbound connections the SLAAC address would be preferred because it's preferred lifetime is greater than the static's, while the static address would continue to be valid for incoming connections. > If I want to use a manually configured address, > usually I would turn of SLAAC for that specific interface. > Your case of VPS seems to me really specific to your site. And > such kind of site local policy should be implemented using the > policy table. > > > I can see some logic in what Linux is doing, although I don't think > > this behaviour is described and specified in RFC3484. It seems to be > > taking the view that the most recently updated information is the most > > preferred. I think the drawback of that is that fundamentally it is > > incorporating into the address selection process attributes that aren't > > specifically address attributes - it is now including how recently the > > addresses were updated, which in the case of SLAAC addresses means that > > RA announcement intervals also now have an influence over address > > selection. If these sorts of address configuration source related > > attributes were intended to be incorporated into the address selection, > > then I'd be expecting there'd be rules that specify preference between > > static, stateful and stateless address configuration sources, and tie > > breakers within them e.g. router preference in RAs when there are two > > stateless address configuration sources (i.e. two routers). > > I'm not sure agree that there should be a default rule for prioritizing > static, stateful, stateless addresses. However, I believe using router > preference for that purpose is messing things up, in that it is intended > for routing purpose. > I don't think it is a good idea either. Source and destination address selection is already somewhat complicated to understand, in comparison to IPv4, so adding preferences of sources and timeliness of configuration information would make it far more complicated. > > I think > > we'd end up with far more rules than exist now if address configuration > > source attributes were to be intentionally incorporated into the > > address selection process. > > > > So in an update to RFC3484, I'd be seeking some more specific and > > defined default behavior for when multiple addresses are > > "non-deprecated". It seems to me that the amount of preference, > > indicated by the current value of the preferred lifetime would be a > > fairly simple way to achieve that and be applicable to a number of > > common scenarios, such as static vs SLAAC, or SLAAC vs SLAAC. > > > >> Regarding determinacy, it should not be useful when > >> you have multiple SLAAC addresses. > >> > > > > I think from a troubleshooing point of view it can be. It is my > > current expectation to be able to look at a range of current addresses > > on an interface and be able to be able to predict quite accurately in > > most cases, based on knowing the default set of address selection rules, > > the address that is going to be used for new outbound connections. > > > > As I mentioned above, > I see some sense to define address type dependent prioritization, > but lifetime should not be used for that purpose. > I can't really think of any cases where using preferred lifetime in my suggested manner would cause any problems, and I've been thinking about this occasionally since when that original discussion occurred back in November 2010. So I'm not sure why using the value of the preferred lifetime in this manner would be an issue. Thanks, Mark. > Regards, > > > Best regards, > > Mark. > > > >> Kindest regards, > >> > >> On 2011/04/26, at 15:05, Mark Smith wrote: > >> > >>> Hi, > >>> > >>> I'd like to suggest the a few rules to be inserted between Rules 3 and 4 > >>> of RFC3484 - > >>> > >>> Rule 3: Avoid deprecated addresses. > >>> The addresses SA and SB have the same scope. If one of the two > >>> source addresses is "preferred" and one of them is "deprecated" (in > >>> the RFC 2462 sense), then prefer the one that is "preferred." > >>> > >>> Rule 4: Prefer home addresses. > >>> If SA is simultaneously a home address and care-of address and SB is > >>> not, then prefer SA. Similarly, if SB is simultaneously a home > >>> address and care-of address and SA is not, then prefer SB. > >>> If SA is just a home address and SB is just a care-of address, then > >>> prefer SA. Similarly, if SB is just a home address and SA is just a > >>> care-of address, then prefer SB. > >>> > >>> Suggested rule - > >>> > >>> Rule X: Prefer greatest preferred lifetime > >>> If the addresses SA and SB both have non-zero value preferred > >>> lifetimes (are "non-deprecated"), prefer the address with the > >>> greatest value preferred lifetime. > >>> > >>> > >>> An example of where this would help produce better behaviour - > >>> > >>> Geert Hendrickx reported to the ipv6-ops list that his VPS provider > >>> was using SLAAC addresses for their own monitoring, while providing > >>> static IPv6 address ranges within the same /64 for customers to use for > >>> their own purposes, so hosts have both SLAAC addresses and static > >>> addresses. When multiple addresses have a "preferred" status, Linux > >>> chooses the most recently added/configured address. In this VPS > >>> scenario, this meant that outbound connections were using the SLAAC > >>> addresses, despite Geert wanting all outbound connections to use the > >>> static IPv6 addresses. His VPS provider would not allow SLAAC to > >>> switched off. > >>> > >>> With the above suggested rule, the infinite preferred lifetime of the > >>> static addresses verses the (presumably) non-infinite preferred > >>> lifetimes of the SLAAC addresses would cause the static addresses to be > >>> preferred as the source address. > >>> > >>> Related to the above suggested rule, I think there may also need to be > >>> some final last resort tie breaker rule to cover the situation where two > >>> addresses have the same value preferred lifetimes e.g. two static > >>> addresses or a static and SLAAC address with infinite preferred > >>> lifetimes. I think it'd be best to avoid something variable like most > >>> recently added/configured, so possibly something like using the > >>> numerically greatest interface id might be adequate. > >>> > >>> Regards, > >>> Mark. > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >> > >> > >> -- > >> Arifumi Matsumoto > >> NGN System Architecture Project > >> NTT Service Integration Laboratories > >> E-mail: arifumi@nttv6.net > >> TEL +81-422-59-3334 FAX +81-422-59-6364 > >> > > > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 > From brian@innovationslab.net Wed Apr 27 05:20:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1721E06EF for ; Wed, 27 Apr 2011 05:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 nI78hi+kQ3yR for ; Wed, 27 Apr 2011 05:20:11 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id DE0ADE069A for ; Wed, 27 Apr 2011 05:20:11 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E88118812C for ; Wed, 27 Apr 2011 05:17:39 -0700 (PDT) Received: from tigers.jhuapl.edu (tigers.jhuapl.edu [128.244.119.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 12876136838E for ; Wed, 27 Apr 2011 05:20:10 -0700 (PDT) Message-ID: <4DB809D1.5000003@innovationslab.net> Date: Wed, 27 Apr 2011 08:19:29 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Comment on rpl-routing-header draft References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:20:16 -0000 Hi Joseph, On 4/26/11 7:39 PM, Reddy, Joseph wrote: > > Hi Thomas > > Since RPL protocol is intended to operate in networks with > constrained devices and lossy, low-bandwidth links, there is a desire > to not require IP-in-IP tunnelling that is usually used for inserting > routing headers. This is detailed in the draft > http://tools.ietf.org/html/draft-hui-6man-rpl-headers-00 but I > realize now this draft expired recently. Perhaps this can be revived > as it is helps to improve the applicability of RPL protocol. That draft has been replaced with draft-ietf-6man-rpl-routing-header. I suggest that you take a look at that draft (currently being reviewed by the IESG), especially section 4. Regards, Brian > > -Joseph > > -----Original Message----- From: Thomas Narten > [mailto:narten@us.ibm.com] Sent: Tuesday, April 26, 2011 5:57 AM To: > Reddy, Joseph Cc: Jonathan Hui; 'ipv6@ietf.org' Subject: Re: Comment > on rpl-routing-header draft > >> In the most common usage of this header, the border router inserts >> a source routing header with the full set of intermediate nodes >> before forwarding it towards the destination within the RPL >> network. > > and then. > >> Yes, we do not use IP-in-IP tunneling and instead simply insert the >> RH head= er in the packet. > > What specification are you following that says do this? > > Routing headers (as designed and specified) are inserted by an > originating node (whether the original sender or a tunnel entry > point). If you have a middle node insert this header to an existing > packet, no suprise things are not going to work. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Wed Apr 27 05:35:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F2AE077B for ; Wed, 27 Apr 2011 05:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.951 X-Spam-Level: X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.648, 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 jv7YL702+PDK for ; Wed, 27 Apr 2011 05:35:16 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id EC8EFE0727 for ; Wed, 27 Apr 2011 05:35:15 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3RCWJJv020693 for ; Wed, 27 Apr 2011 06:32:19 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p3RCZ696163310 for ; Wed, 27 Apr 2011 06:35:06 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3RCYbB3029942 for ; Wed, 27 Apr 2011 06:34:37 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-124.mts.ibm.com [9.65.234.124]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3RCYXeM029728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 06:34:35 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3RCYxeM005027; Wed, 27 Apr 2011 08:34:59 -0400 Message-Id: <201104271234.p3RCYxeM005027@cichlid.raleigh.ibm.com> To: Brian Haberman Subject: Re: Comment on rpl-routing-header draft In-reply-to: <4DB809D1.5000003@innovationslab.net> References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> <4DB809D1.5000003@innovationslab.net> Comments: In-reply-to Brian Haberman message dated "Wed, 27 Apr 2011 08:19:29 -0400." Date: Wed, 27 Apr 2011 08:34:59 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:35:16 -0000 Brian Haberman writes: > That draft has been replaced with draft-ietf-6man-rpl-routing-header. I > suggest that you take a look at that draft (currently being reviewed by > the IESG), especially section 4. Hmm. Section 4 says: > Routers SHOULD > use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a > new SRH in datagrams that are sourced by other nodes. SHOULD would be OK, here, if there was some alternative that might be appropriate on some situations. But the document is silent on those alternatives. In which case, I wonder why this is not a MUST. Is it because other types of tunneling would be OK? (If so, giving such an example would be good). But then later: In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due to the added cost and complexity required to process and carry a datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes how to avoid using IPv6-in-IPv6 tunneling in such specific cases and the risks involved. I strongly object to this text. It suggests that that other approaches, presumably including those that violate existing IETF specs, might be OK too. We should not do this. Or am I missing something here? Thomas From brian@innovationslab.net Wed Apr 27 06:03:23 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6322EE0731 for ; Wed, 27 Apr 2011 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 ekwlZH8qcxxa for ; Wed, 27 Apr 2011 06:03:23 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id F0FD4E072E for ; Wed, 27 Apr 2011 06:03:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0ECF98821B; Wed, 27 Apr 2011 06:00:51 -0700 (PDT) Received: from tigers.jhuapl.edu (tigers.jhuapl.edu [128.244.119.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7C6DB136839A; Wed, 27 Apr 2011 06:03:22 -0700 (PDT) Message-ID: <4DB813F0.4090009@innovationslab.net> Date: Wed, 27 Apr 2011 09:02:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Comment on rpl-routing-header draft References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> <4DB809D1.5000003@innovationslab.net> <201104271234.p3RCYxeM005027@cichlid.raleigh.ibm.com> In-Reply-To: <201104271234.p3RCYxeM005027@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:03:23 -0000 Hi Thomas, On 4/27/11 8:34 AM, Thomas Narten wrote: > Brian Haberman writes: > >> That draft has been replaced with draft-ietf-6man-rpl-routing-header. I >> suggest that you take a look at that draft (currently being reviewed by >> the IESG), especially section 4. > > Hmm. Section 4 says: > >> Routers SHOULD >> use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a >> new SRH in datagrams that are sourced by other nodes. > > SHOULD would be OK, here, if there was some alternative that might be > appropriate on some situations. But the document is silent on those > alternatives. In which case, I wonder why this is not a MUST. Is it > because other types of tunneling would be OK? (If so, giving such an > example would be good). I would assume that any type of tunneling would be allowed (e.g., GRE), and agree that it would be useful to enumerate at least general situations where the SHOULD can be ignored. I *thought* some of those alternatives were discussed in the RPL spec, but they don't appear to be (draft-ietf-roll-rpl). > > But then later: > > In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due > to the added cost and complexity required to process and carry a > datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes > how to avoid using IPv6-in-IPv6 tunneling in such specific cases and > the risks involved. > > I strongly object to this text. It suggests that that other > approaches, presumably including those that violate existing IETF > specs, might be OK too. We should not do this. > > Or am I missing something here? I perused draft-hui-6man-rpl-headers and it appears to describe how to insert/remove the RPL routing header at the RPL network border. Would you prefer if the exception alluded to above via reference to that draft be explicitly included in this draft? Regards, Brian From narten@us.ibm.com Wed Apr 27 06:21:12 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7000BE0711 for ; Wed, 27 Apr 2011 06:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.987 X-Spam-Level: X-Spam-Status: No, score=-105.987 tagged_above=-999 required=5 tests=[AWL=0.612, 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 QwMEuqEv+aM4 for ; Wed, 27 Apr 2011 06:21:11 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4E229E072F for ; Wed, 27 Apr 2011 06:21:11 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3R5ZJkE020869 for ; Tue, 26 Apr 2011 23:35:19 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3RDKwBB147238 for ; Wed, 27 Apr 2011 07:20:59 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3RDKw7s018911 for ; Wed, 27 Apr 2011 07:20:58 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-124.mts.ibm.com [9.65.234.124]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3RDKv7n018855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 07:20:57 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3RDKt95005425; Wed, 27 Apr 2011 09:20:56 -0400 Message-Id: <201104271320.p3RDKt95005425@cichlid.raleigh.ibm.com> To: Brian Haberman Subject: Re: Comment on rpl-routing-header draft In-reply-to: <4DB813F0.4090009@innovationslab.net> References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> <4DB809D1.5000003@innovationslab.net> <201104271234.p3RCYxeM005027@cichlid.raleigh.ibm.com> <4DB813F0.4090009@innovationslab.net> Comments: In-reply-to Brian Haberman message dated "Wed, 27 Apr 2011 09:02:40 -0400." Date: Wed, 27 Apr 2011 09:20:55 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:21:12 -0000 > I would assume that any type of tunneling would be allowed (e.g., GRE), > and agree that it would be useful to enumerate at least general > situations where the SHOULD can be ignored. Agreed. > I perused draft-hui-6man-rpl-headers and it appears to describe how to > insert/remove the RPL routing header at the RPL network border. Would > you prefer if the exception alluded to above via reference to that draft > be explicitly included in this draft? I don't immediatly see the value of the draft-hui-6man-rpl-headers at all. It seems incomplete. Is this intended to be standards track? Seems to me, there there are some (important) gaps. As such, the document isn't useful. For example, Section 3 talks about the mechanics of how to restore a packet (by removing headers) in some cases. How on earth is a node supposed to know it needs to do this? How can it distinguish between a packet that was properly created by the originating node (i.e., is fully compliant with existing routing header rules) vs. one where an intermediate router took shortcuts because it didn't want to do tunneling? Is there an assumption this is all manually configured somehow? Or? Thomas From brian@innovationslab.net Wed Apr 27 06:28:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD94E074C for ; Wed, 27 Apr 2011 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 EgfZ5O7oC+o7 for ; Wed, 27 Apr 2011 06:28:34 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 25F77E0734 for ; Wed, 27 Apr 2011 06:28:34 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id F16908811D for ; Wed, 27 Apr 2011 06:26:01 -0700 (PDT) Received: from tigers.jhuapl.edu (tigers.jhuapl.edu [128.244.119.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C947813683D2 for ; Wed, 27 Apr 2011 06:28:33 -0700 (PDT) Message-ID: <4DB819D8.4040709@innovationslab.net> Date: Wed, 27 Apr 2011 09:27:52 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Comment on rpl-routing-header draft References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> <4DB809D1.5000003@innovationslab.net> <201104271234.p3RCYxeM005027@cichlid.raleigh.ibm.com> <4DB813F0.4090009@innovationslab.net> <201104271320.p3RDKt95005425@cichlid.raleigh.ibm.com> In-Reply-To: <201104271320.p3RDKt95005425@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:28:34 -0000 On 4/27/11 9:20 AM, Thomas Narten wrote: >> I would assume that any type of tunneling would be allowed (e.g., GRE), >> and agree that it would be useful to enumerate at least general >> situations where the SHOULD can be ignored. > > Agreed. > >> I perused draft-hui-6man-rpl-headers and it appears to describe how to >> insert/remove the RPL routing header at the RPL network border. Would >> you prefer if the exception alluded to above via reference to that draft >> be explicitly included in this draft? > > I don't immediatly see the value of the draft-hui-6man-rpl-headers at > all. It seems incomplete. > > Is this intended to be standards track? The header indicates Standards Track, but it is an individual draft at this point. The authors have not asked 6MAN to consider adopting it. > > Seems to me, there there are some (important) gaps. As such, the > document isn't useful. > > For example, Section 3 talks about the mechanics of how to restore a > packet (by removing headers) in some cases. How on earth is a node > supposed to know it needs to do this? How can it distinguish between a > packet that was properly created by the originating node (i.e., is > fully compliant with existing routing header rules) vs. one where an > intermediate router took shortcuts because it didn't want to do > tunneling? > > Is there an assumption this is all manually configured somehow? Or? No clue. I would suggest engaging the draft authors or asking on the ROLL WG mailing list. It may also be worthwhile to mention your concerns to the IESG given that the routing header draft's current state. Regards, Brian From narten@us.ibm.com Thu Apr 28 12:37:55 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAE6E0670 for ; Thu, 28 Apr 2011 12:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.048 X-Spam-Level: X-Spam-Status: No, score=-106.048 tagged_above=-999 required=5 tests=[AWL=0.551, 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 KpztiJIOrufn for ; Thu, 28 Apr 2011 12:37:54 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id BB092E0669 for ; Thu, 28 Apr 2011 12:37:53 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3SJYkDo009593 for ; Thu, 28 Apr 2011 13:34:46 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p3SJbHXI067096 for ; Thu, 28 Apr 2011 13:37:18 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3SJanOu022752 for ; Thu, 28 Apr 2011 13:36:49 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-91.mts.ibm.com [9.65.253.91]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3SJama9022684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Apr 2011 13:36:49 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3SJbElL003227 for ; Thu, 28 Apr 2011 15:37:14 -0400 Message-Id: <201104281937.p3SJbElL003227@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Revised draft-ietf-6man-node-req-bis-09.txt Date: Thu, 28 Apr 2011 15:37:14 -0400 From: Thomas Narten X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 19:37:55 -0000 draft-ietf-6man-node-req-bis-09.txt has been posted (for some reason, no announcement went out). This document has all the remaining revisions that I know of. I believe it is ready for advancement. Changes since -08: 1. Updated text w.r.t MLD (as posted on the list). Now also refers to Lightweight MLDv2. 2. Added a paragraph on PMTU, adding a reference to RFC 4821 (Packetization Layer Path MTU Discovery). 3) updated the acknowledgements section. 4) Cleaned up the references, making all SHOULD/MUSTs be normative, pretty much everything else an Informational reference. Thomas From bob.hinden@gmail.com Fri Apr 29 07:41:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA0BE06BF for ; Fri, 29 Apr 2011 07:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y91ALiSWD-F for ; Fri, 29 Apr 2011 07:41:02 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4DE0693 for ; Fri, 29 Apr 2011 07:41:02 -0700 (PDT) Received: by pzk5 with SMTP id 5so2671652pzk.31 for ; Fri, 29 Apr 2011 07:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=U1w9FObiRukceImLiyWIh1xAdIChpGlPyYUO1ulT2c0=; b=avDn1KHRbLg7gLQ4IfwlCvFIwkFZbJFQFcEsFxrtXkBaFC0mLXxP5SMxhQYvM5QmAs mDGgHOeagcNK436xrYYC4R4LoURu9ywCcD29zcPTIqUzRZN4SmBHI//na+zzTqT3nA++ iwsKXbwTonMPzt4lHYEpsDApYcw7g+gmJZXWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=QzoIIALUv9LO1wZUm3eKA0G9vtBobt6Mrq+OFfNFjbKortQJIVrME+RPHNR5PlC3/q FRXpp0tBZScRd7DptIWKOGwtOFAv0R9HmeMtlavd/6VgJ4mri/XpM3T6/5xmqAY9UIQ4 S4Jzb+IgOO5dI7c+nxPkM/Cli20fcWpHBRaMQ= Received: by 10.68.65.229 with SMTP id a5mr5168405pbt.474.1304088061704; Fri, 29 Apr 2011 07:41:01 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id w2sm1952592pbh.14.2011.04.29.07.40.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 07:41:00 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Short 6MAN WG Last Call: Date: Fri, 29 Apr 2011 07:40:57 -0700 Message-Id: <9D2C4F71-29BD-437B-A209-09001BF47374@gmail.com> To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:41:04 -0000 All, This message starts a short 6MAN Working Group Last Call on advancing: Title : IPv6 Node Requirements RFC 4294-bis Author(s) : E. Jankiewicz, et al. Filename : draft-ietf-6man-node-req-bis-09.txt Pages : 30 Date : 2011-April-26 =09 http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07 as an Informational RFC. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on May 6, 2011. An earlier working group last call was completed on January 6, 2011. = Given the time and the number of changes, the chairs think it is best to = have a 1 week working group last call before advancing this document. Regards, Bob Hinden & Brian Haberman 6MAN Chairs From bob.hinden@gmail.com Fri Apr 29 09:35:49 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE3EE06AD for ; Fri, 29 Apr 2011 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.488 X-Spam-Level: X-Spam-Status: No, score=-103.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 IPrJaCTneX5t for ; Fri, 29 Apr 2011 09:35:45 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4EAE069F for ; Fri, 29 Apr 2011 09:35:45 -0700 (PDT) Received: by pxi2 with SMTP id 2so795217pxi.38 for ; Fri, 29 Apr 2011 09:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=LxBuemX8BIR11CV7JGzzAxcHNNXoa0g+lzpQDtJ+4Xk=; b=Xa5XXpGbgRBYHn7J7ntF+fD+LHLS4E7ZC1AmZ00xtoN3nAQbzNbY9PNuU71vc5BDjn gM0SWmlm8xM9SkpYeD55992OvZl/50C9LHm06c3cJNp/uynU673expLMzKFGGRMQEMIw DRdTgbOaxeseHetJ2ptj0XgL2TSrH6Emifmmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=fopGgzmjBj2DAyLa7uUU70AyL7fyD2fslv2mqLQDL9VUB3t5UuFE3RmhALqVpY+WmQ wLD8XnVLPvbIKS82O9wmrY3jA6ozEzQigAveU06wR/E0aHoyJFV19EpjuzxDoa9uhYES oi5zurgsakPuFnuyzxGE1H3PhKlfS8gC72SUg= Received: by 10.68.32.232 with SMTP id m8mr72651pbi.99.1304094945322; Fri, 29 Apr 2011 09:35:45 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id c14sm2003674pbu.84.2011.04.29.09.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 09:35:44 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Short 6MAN WG Last Call: Date: Fri, 29 Apr 2011 09:35:33 -0700 Message-Id: To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:35:49 -0000 [Resend w/ correct link] All, This message starts a short 6MAN Working Group Last Call on advancing: Title : IPv6 Node Requirements RFC 4294-bis Author(s) : E. Jankiewicz, et al. Filename : draft-ietf-6man-node-req-bis-09.txt Pages : 30 Date : 2011-April-26 =09 http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-09 as an Informational RFC. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on May 6, 2011. An earlier working group last call was completed on January 6, 2011. = Given the time and the number of changes, the chairs think it is best to = have a 1 week working group last call before advancing this document. Regards, Bob Hinden & Brian Haberman 6MAN Chairs From narten@us.ibm.com Fri Apr 29 12:16:39 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B849CE0780 for ; Fri, 29 Apr 2011 12:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.074 X-Spam-Level: X-Spam-Status: No, score=-106.074 tagged_above=-999 required=5 tests=[AWL=0.525, 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 xD3fK11BgQU3 for ; Fri, 29 Apr 2011 12:16:38 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id C1383E06AF for ; Fri, 29 Apr 2011 12:16:38 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3TJDa09018090 for ; Fri, 29 Apr 2011 13:13:36 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3TJGMMs137648 for ; Fri, 29 Apr 2011 13:16:22 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3TJLMOA004169 for ; Fri, 29 Apr 2011 13:21:22 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-221-185.mts.ibm.com [9.65.221.185]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3TJLLtq004104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2011 13:21:22 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3TJGK1Y016947; Fri, 29 Apr 2011 15:16:20 -0400 Message-Id: <201104291916.p3TJGK1Y016947@cichlid.raleigh.ibm.com> To: Brian Haberman Subject: Re: Comment on rpl-routing-header draft In-reply-to: <4DB819D8.4040709@innovationslab.net> References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> <4DB809D1.5000003@innovationslab.net> <201104271234.p3RCYxeM005027@cichlid.raleigh.ibm.com> <4DB813F0.4090009@innovationslab.net> <201104271320.p3RDKt95005425@cichlid.raleigh.ibm.com> <4DB819D8.4040709@innovationslab.net> Comments: In-reply-to Brian Haberman message dated "Wed, 27 Apr 2011 09:27:52 -0400." Date: Fri, 29 Apr 2011 15:16:20 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 19:16:39 -0000 I went and reviewed this document in more detail. Below are my comments. I will send Jari a heads-up as well, since this is in his queue for review as well. 2011-04-29 review of -03 Third, to avoid some attacks that lead to the deprecation of RH0, routers along the way MUST verify that loops do not exist with in the source route. THis requirement is processor/resource intensive. and has to be done on every hop on every packet! I don't see how this will be done in practice, given the premise that the nodes have limited resources and hence need the special routing header. Case 2 also occurs whenever a RPL router needs to insert a source route when forwarding datagram. One such use case with RPL is to have all RPL traffic flow through a Border Router and have the Border Router use source routes to deliver datagrams to their final destination. When including the SRH using tunneled-mode, the Border Router would encapsulate the received datagram unmodified using IPv6- in-IPv6 and include a SRH in the outer IPv6 header. Text in this section could be more clear if it was always stated where the packets were going. I.e., being clear about whether a packet is coming from outside the routing domain and being delivered inside the domain, etc. "saying flow through the router" convers a lot of different cases. CmprI 4-bit unsigned integer. Number of prefix octets from each segment, except than the last segment, that are elided. For example, a SRH carrying full IPv6 addresses in Addresses[1..n-1] sets CmprI to 0. CmprE 4-bit unsigned integer. Number of prefix octets from the segment that are elided. For example, a SRH carrying a full IPv6 address in Addresses[n] sets CmprE to 0. I don't understand the difference. is CmprE just for the last address (If so, say so). and when does it make sense to a different prefix length for just the last address? 4.1. Generating Source Routing Headers To deliver an IPv6 datagram to its destination, a router may need to generate a new SRH and specify a strict source route. Routers SHOULD not "strict source route", but the routing header type defined in the previous section. use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a new SRH in datagrams that are sourced by other nodes. Using IPv6-in- IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by a SRH are sent back to the router that generated the routing header. Either the above should be a MUST, or you should explain what you have in mind as far as other alernatives. Do you just been other forms of tunneling? Performing IP-in-IP encapsulation may grow the datagram to a size larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer fragmentation caused by IP-in-IP encapsulation, links within a RPL domain SHOULD be configured with a MTU of at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE (+ additional extension headers or options needed within RPL domain) octets. And any router that adds one of these headers better (MUST) correctly do proper PMTU/"ICMP packet too big" handling. Or you will have black hole and other fun problems. In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due to the added cost and complexity required to process and carry a datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes how to avoid using IPv6-in-IPv6 tunneling in such specific cases and the risks involved. This section should be deleted. Adding such headers would seem to violate existing standards. THis document should not suggest that ever makes sense. The function of SRH is intended to be very similar to IPv4's Strict Source and Record Route option [RFC0791]. After the routing header has been processed and the IPv6 datagram resubmitted to the IPv6 module for processing, the IPv6 Destination Address contains the next hop's address. When forwarding an IPv6 datagram that contains a SRH with a non-zero Segments Left value, if the IPv6 Destination Address is not on-link, a router SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the packet's Source Address. This ICMPv6 Code indicates that the IPv6 Destination Address is not on-link and the router cannot satisfy the strict source route requirement. When generating ICMPv6 error messages, the rules in Section 2.4 of [RFC4443] must be observed. should the packet also be dropped? Why doesn't the above text say that? To detect loops in the SRH, a router MUST determine if the SRH includes multiple addresses assigned to any interface on that router. This is too computation expensive for every forwarding node to do. I don't think it will happen in practice. This is an example of a bad IETF MUST, because it will widely be ignored. For datagrams exiting the RPL domain, RPL Border Routers MUST check for a SRH. If Segments Left is 0, the router MUST remove the SRH from the datagram. If the SRH was included using tunneled mode and the RPL Border Router serves as the tunnel end-point, removing the outer IPv6 header serves to remove the SRH as well. Otherwise, the RPL Border Router assumes that the SRH was included using transport mode and MUST remove the SRH from the IPv6 header. If Segments Left is non-zero, the router MUST drop the datagram. What does "transport mode" mean above? If there is an SRH, and the packet is about to be forwarded outside the domain, the packet gets discarded. Full stop. (Right?) Thomas