From nordmark@acm.org Thu Aug 1 00:49:36 2013 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 79AF721F9DDB; Thu, 1 Aug 2013 00:49:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw5l5XsgLHsC; Thu, 1 Aug 2013 00:49:30 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id A5BDC21F9D89; Thu, 1 Aug 2013 00:49:30 -0700 (PDT) Received: from [10.21.144.176] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r717nHmF016175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 00:49:19 -0700 Message-ID: <51FA12FB.1040709@acm.org> Date: Thu, 01 Aug 2013 09:49:15 +0200 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linda Dunbar Subject: Re: any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06? References: <4A95BA014132FF49AE685FAB4B9F17F645B5269D@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B5269D@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Internet Area , Brian Haberman , "ipv6@ietf.org" , Suresh Krishnan , Tal Mizrahi 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, 01 Aug 2013 07:49:36 -0000 On 7/31/13 11:11 AM, Linda Dunbar wrote: > However, when SEND is used, Access (or Aggregation) switches might not > possess knowledge of the attached hosts (VMs)’ private keys. > > Are there any concerns/feedback for giving the following recommendation > in our draft? Any preferences? > > 1) state that SARP is not recommended when SEND is deployed; > > 2) recommend using RFC6496 (Secure Proxy ND Support for SEND). I think it would be awkward to use RFC 6496 in this context since it requires that the host create a special certificate authorizing the switches to respond on their behalf. (That makes sense in cases like Mobile IP home agents where there is a pre-established relationship between the host and the home agent.) Note that there would be some additional deployment issues as well, since all the hosts on the link would need to be able to do the RFC 6496 validation - not just the normal SeND validation. My take is that *if* we want to have the approach where a host's IP address should map to somebody else's MAC address, then I think the simplest (and secure) approach would be to have the host (somehow) find out the MAC address to use, and then have the hosts send the NAs themselves. Erik From nordmark@acm.org Thu Aug 1 01:18:42 2013 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 361B021F9E5E for ; Thu, 1 Aug 2013 01:18:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANk6v7QI1SM1 for ; Thu, 1 Aug 2013 01:18:33 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7592D21F9E4D for ; Thu, 1 Aug 2013 01:18:15 -0700 (PDT) Received: from [10.21.144.176] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r718I5K1013719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 01:18:07 -0700 Message-ID: <51FA19BB.3050504@acm.org> Date: Thu, 01 Aug 2013 10:18:03 +0200 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: lifetime of the IID - RFC 4941 References: <003701ce8dde$e6114270$b233c750$@rozanak.com> In-Reply-To: <003701ce8dde$e6114270$b233c750$@rozanak.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Andrew Yourtchenko , Dave Thaler , 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: Thu, 01 Aug 2013 08:18:47 -0000 On 7/31/13 1:12 PM, Hosnieh Rafiee wrote: > From the above sections, I presume that the current approach in RFC > 4941 uses the same approach that is defined in RFC 4862. So, it removes > the IID independent of the upper layer protocols. For the questions you are asking, they behave the same. (The difference is that 4862 talks about the lifetimes on the prefixes, and 4941 about the lifetime of an IID. The lifetime of a temporary address is the min of those two lifetimes.) > This means that it makes problem for applications like FTP or other > application even though it continue to keep its connections after the > IID is deprecated if a there is any. Because it considers it as > connection and not if the application using it. We try to minimize the application issues by having a significantly longer default valid lifetime than preferred lifetime. Basically 4941 assumes that an application (that uses temporary addresses) would not keep a connection open for more than 7 days. If instead RFC 4941 had picked a default (preferred, valid) lifetimes of (1, 7) minutes (i.e., minutes instead of days), then things would be more challenging. Hence for shorter lifetimes we'd need something difference. > The advantage of ra-privacy > http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is to have: > > ·*an application layer lifetime.* > > There are some variables that is used to control “the lifetime of the > IID”, “the number of application per IID” and “the number of valid IID”. > The total number of valid IID cannot exceed the max valid IID. So, The > difference of this approach with RFC 4941 is that as long as an > application uses an IID, this IID will not be removed, although, the > maximum lifetime is reached. But it cannot be used for assigning any new > application to it. Also always the assign of application to IID is based > on the highest lifetime. The draft is also handled the exceptional > situation where the maximum number of IID and the maximum number of > application per IID are reached. In this case it increase the local > value which keeps the maximum number of application for a specific IID. > So it can later play with this value to handle this exceptional > situation and again set the application to the IID with highest > lifetime. It also set the lifetime of all IIDs to zero when it receives > new router advertisement. Suppose we wanted to have temporary/privacy addresses with quite short lifetimes, then I think we'd want a way to quickly remove (invalidate) addresses that are no longer used by any applications. Tracking which sockets have an open connection using a given address can definitely help doing that. But what I don't is at what point we'd want to discard such an address when there is a socket that refers to it. I'm assuming we wouldn't want to keep it around forever. With your proposed algorithm can't you get in the state where all the IIDs have exceeded the lifetime, hence a new applications/sockets can not use any of the IIDs? Or is it that in that case all the new applications/sockets would end up using the most recently expired IID? In general if we have shorter lifetimes for temporary/privacy addresses then there would be some additional churn - routers and hosts would need to add entries to their neighbor caches more frequently and we'd see more MLD messages for the solicited node multicast addresses. I don't know what the sweetspot is in the tradeoff between those performance implications and better privacy. To me the obvious place to improve privacy related to IPv6 addresses is to ensure that different IIDs are used when the prefix changes (due to mobility or multihoming). For a host at home there might not be much benefits in changing the IID frequently within the same /64 prefix, because a privacy attacker/snooper could assume that everything from the prefix is comes from one or very few devices and associated individuals. Things are different for hosts at enterprises, public hotspots, etc i.e., on links where there are devices that are associated with a larger set of individuals. For enterprises there are some tradeoffs between various management and security approaches, which might assume that a single device has one IID and the privacy of the users when they communicate outside of the enterprise. My 2 cents, Erik Regards, Erik From rbonica@juniper.net Thu Aug 1 01:37:53 2013 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 8EB8121F9CE7 for ; Thu, 1 Aug 2013 01:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03z3vzV0B2Ya for ; Thu, 1 Aug 2013 01:37:47 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 81B2821F9C82 for ; Thu, 1 Aug 2013 01:37:47 -0700 (PDT) Received: from mail167-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE019.bigfish.com (10.236.130.82) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 08:37:45 +0000 Received: from mail167-co9 (localhost [127.0.0.1]) by mail167-co9-R.bigfish.com (Postfix) with ESMTP id E29987001DC for ; Thu, 1 Aug 2013 08:37:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail167-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbonica@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail167-co9 (localhost.localdomain [127.0.0.1]) by mail167-co9 (MessageSwitch) id 1375346263925543_24419; Thu, 1 Aug 2013 08:37:43 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.248]) by mail167-co9.bigfish.com (Postfix) with ESMTP id D4ADF640047 for ; Thu, 1 Aug 2013 08:37:43 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.54) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 08:37:43 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 01:37:42 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Thu, 1 Aug 2013 01:37:42 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 01:50:38 -0700 Received: from mail134-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 08:37:40 +0000 Received: from mail134-tx2 (localhost [127.0.0.1]) by mail134-tx2-R.bigfish.com (Postfix) with ESMTP id C9F68160185 for ; Thu, 1 Aug 2013 08:37:40 +0000 (UTC) Received: from mail134-tx2 (localhost.localdomain [127.0.0.1]) by mail134-tx2 (MessageSwitch) id 1375346254613276_5226; Thu, 1 Aug 2013 08:37:34 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.243]) by mail134-tx2.bigfish.com (Postfix) with ESMTP id 76FAAA004C; Thu, 1 Aug 2013 08:37:34 +0000 (UTC) Received: from BY2PRD0511HT002.namprd05.prod.outlook.com (157.56.237.149) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 08:37:34 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.72]) by BY2PRD0511HT002.namprd05.prod.outlook.com ([10.255.129.37]) with mapi id 14.16.0341.000; Thu, 1 Aug 2013 08:37:33 +0000 From: Ronald Bonica To: "C. M. Heard" , IPv6 Subject: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjpJdxBsThTTW2kO9nlkD8PFVZw== Date: Thu, 1 Aug 2013 08:37:32 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE25127185AC@BY2PRD0511MB428.namprd05.prod.outlook.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%POBOX.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 01 Aug 2013 08:37:53 -0000 Cmh, When I read this message, my first reaction was to scream "that such a thin= g could not possibly be deployed, because operators will filter anything th= at they don't know or have an immediate use for." But after a few hallway d= iscussions, I am starting to think that the idea might be viable. When the adrenaline and endorphin rush of IETF week has subsided, we should= a) discuss whether this is a viable option and b) if so, define the replac= ement protocol in the Transport Area. Chairs, The conversation proposed above may not be within the charter of 6man. If/w= hen you think that there is a need to move this conversation, I can ask the= transport Ads for a non-WG mailing list. However, if you are happy for at = least the first part of this conversation to occur on this mailing list, we= can continue here. Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Wednesday, July 31, 2013 12:40 AM > To: IPv6 > Subject: RE: "Deprecate" >=20 > On Tue, 30 Jul 2013, Ronald Bonica wrote: > > Thinking a little more about it, RTP and UDP aren't the real > culprits. > > The culprits are the applications that run over them. > > So, we should limit our statement to applications, and not > > "applications and transport layer protocols". >=20 > I don't agree, at least not if the principal reason why IP fragments > get dropped is that they lack the L4 header (or at least that the non- > initial fragments do) and thereby break stateless ACLs. The problem is > that UDP and its kin such as UDP-lite and DCCP lack transport-layer > segmentation, such as is present in TCP, and are thereby force their > clients to rely on IP fragmentation to provide this service. So yes, > these transport protocols are the culprits. >=20 > The idea that immediately comes to mind is to design _replacements_ > transport protocols for UDP and kin that contain a transport layer > segmentation mechanism. These would be for use by applications that > can't get by without such a mechanism; existing applications that don't > need to rely on IP fragmentation can continue to use UDP and kin. The > replacement for UDP might have a header that looks something like this: >=20 > 0 15 16 31 > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Source Port | Destination Port | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Length | Segment Offset |Res|M| > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Identification | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Checksum | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | data octets ... > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... >=20 > (Other and perhaps better possibilities exist, of course.) >=20 > Having said that, I immediately imagine screaming that such a thing > could not possibly be deployed, because operators will filter anything > that they don't know or have an immediate use for, and so it would > never get any traction. >=20 > Well, maybe so, but something has to give. The operations folks have > complained that IP fragmentation is awful, they have to filter > fragments because it defeats their stateless ACLs. OK; let's agree > that's a defect that needs to be fixed. But if you don't want the fix > to break other important stuff (e.g., DNSSEC, as metioned in Section > 3.1 of draft-bonica-6man-frag-deprecate-02), you need a replacement for > IP fragmentation (or an augmentation, such as in > http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by Mark > Andrews). Maybe I just lack imagination, but I can't see any fix that > does not involve SOME change in operator behavior. >=20 > //cmh > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From ietf@meetecho.com Thu Aug 1 02:06:55 2013 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 7182821F8467 for ; Thu, 1 Aug 2013 02:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYEoCwEkGXEa for ; Thu, 1 Aug 2013 02:06:50 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7474921F847C for <6man@ietf.org>; Thu, 1 Aug 2013 02:06:29 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6S1m00h0EaGCq01M6Sil; Thu, 01 Aug 2013 11:06:27 +0200 Date: Thu, 1 Aug 2013 11:06:24 +0200 (CEST) From: Meetecho Team To: 6man@ietf.org Message-ID: <853894615.9.1375347984755.JavaMail.tcastaldi@dell-tcastaldi> Subject: 6MAN session recording available MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8_859580912.1375347984753" 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, 01 Aug 2013 09:06:55 -0000 ------=_Part_8_859580912.1375347984753 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the 6MAN WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#6MAN For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_8_859580912.1375347984753-- From linda.dunbar@huawei.com Thu Aug 1 04:07:48 2013 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 2C69321E805F; Thu, 1 Aug 2013 04:07:36 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQiTmGgVOki8; Thu, 1 Aug 2013 04:07:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBA9A21F9C69; Thu, 1 Aug 2013 04:07:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVQ21566; Thu, 01 Aug 2013 11:06:57 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 12:06:42 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 12:06:55 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 04:06:50 -0700 From: Linda Dunbar To: Erik Nordmark Subject: RE: any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06? Thread-Topic: any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06? Thread-Index: AQHOjourmbP+4/tVPUmfPBOsQ4ICq5mAMTKw Date: Thu, 1 Aug 2013 11:06:49 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B53F25@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645B5269D@dfweml509-mbx.china.huawei.com> <51FA12FB.1040709@acm.org> In-Reply-To: <51FA12FB.1040709@acm.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Internet Area , Brian Haberman , "ipv6@ietf.org" , Suresh Krishnan , Tal Mizrahi 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, 01 Aug 2013 11:07:49 -0000 > -----Original Message----- >=20 > My take is that *if* we want to have the approach where a host's IP > address should map to somebody else's MAC address, then I think the > simplest (and secure) approach would be to have the host (somehow) find > out the MAC address to use, and then have the hosts send the NAs > themselves. [Linda] Thank you for the suggestion. That is very reasonable.=20 >=20 > Erik From moore@network-heretics.com Thu Aug 1 05:35:44 2013 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 1485A21F9476 for ; Thu, 1 Aug 2013 05:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVfY9+rEzIfy for ; Thu, 1 Aug 2013 05:35:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2B321F99AB for ; Thu, 1 Aug 2013 05:32:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BAEB720F62; Thu, 1 Aug 2013 08:31:33 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 01 Aug 2013 08:31:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=x9p V3svPG3e+z1W2oFtO+nuzeog=; b=INTv8hkWha250QxkP/ZZCtAycBqgHQUO/xE w4NliKLUO4ALUxTNAmqbJ5KV44GZjhj/qNXMFIsHTk/Xy98VIymrd/eMNyN//Zqs TtuRsYiOqTxs8skBkYHJI226IE1ZsB09jT3BuYAJANYAJaISnlTfIbwaQRv9qt6A iSfAgXS4= X-Sasl-enc: pFO//nsZaBYp8okANxcF1pmLtJ9DHtvX/hpvYgVWwrl5 1375360292 Received: from dhcp-138f.meeting.ietf.org (unknown [130.129.19.143]) by mail.messagingengine.com (Postfix) with ESMTPA id 2DA2E68018D; Thu, 1 Aug 2013 08:31:32 -0400 (EDT) Subject: Re: ra-privacy: my responses to comments Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-7--231383733 From: Keith Moore In-Reply-To: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> Date: Thu, 1 Aug 2013 14:31:30 +0200 Message-Id: <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1085) Cc: ipv6@ietf.org, Fernando Gont , Dave Thaler 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, 01 Aug 2013 12:35:46 -0000 --Apple-Mail-7--231383733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On reflection I wanted to respond to this a bit more: I was responding to slide 9, and in particular the bullet point that = says "The node Should not use public addresses". When I initially read this, I interpreted "public addresses" with the = meaning that they tend to have in IPv4 - which is to say addresses that = aren't "private addresses". I wasn't sure what public addresses would = mean for IPv6, since we have no private addresses in IPv6. But we used = to have something very similar to private addresses in IPv6 called site = locals. We deprecated them for good reasons, and my first impression = of that slide was that it seemed to be advocating something like the = concept of IPv4 private addresses in IPv6. So that's why I spoke up. = =20 Hosnieh clarified the slide by explaining that by using "public = addresses" she meant addresses resolvable from DNS lookups. But then = the idea that a node should not use "public addresses" is problematic = for different reasons. =20 There are many people (in IETF and elsewhere) who believe that = applications should never use IP addresses directly or in referrals to = other applications. This is often cited as if it were some = architectural principle - in fact just last night, I actually had an AD = state that to me as if it were a principle. I happen to disagree = emphatically with that supposed principle, for many reasons, but I won't = list those reasons here. For the moment it only matters that there is = a widely held belief that all applications should only use names to = refer to hosts or application endpoints. =46rom that point-of-view, = all hosts/nodes need to have names, so (by this definition) all = hosts/nodes need to have public addresses. And the people who believe = that applications should always use names to refer to hosts or = application endpoints have a lot of influence on network protocol design = choices. So a recommendation for hosts to only use addresses not = listed in DNS can have the effect of making those hosts unable to = support various applications. Bottom line: The decision about whether a node should use an address = listed in DNS is not something that should be dictated entirely, or = probably even mostly, by concerns about the privacy of addresses. =20 I would also suggest that the privacy benefit from using addresses not = listed in DNS is probably very small. But in order to evaluate that = benefit, it would help to identify specific threats to privacy that are = remedied by not using addresses listed in DNS. Keith On Jul 30, 2013, at 7:12 AM, Hosnieh Rafiee wrote: > The term public addresses: > @Keith Moore: > Concerns: All IPv6 addresses are public addresses and should be = available. Not chosen a good term. > =20 > I just obtained that term from from the mailing list. Check this old = list : http://www.ietf.org/mail-archive/web/ipv6/current/msg17792.html > A public address is one intended to be resolvable from higher-layer = IDs such as DNS names. > If this is wrong or I misunderstood the meaning , then I will change = it to =93DNS addresses=94 or another term. =20 > What I knew before: > Global addresses =3D Router prefix + IID > Local Addresses =3D local prefix + IID > What I understood: > Public addresses =3D router prefix + IID and has DNS records (like a = domain) > =20 --Apple-Mail-7--231383733 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On = reflection I wanted to respond to this a bit more:

I = was responding to slide 9, and in particular the bullet point that says = "The node Should not use public = addresses".

When I initially read this, I = interpreted "public addresses" with the meaning that they tend to have = in IPv4 - which is to say addresses that aren't "private addresses". =   I wasn't sure what public addresses would mean for IPv6, since we = have no private addresses in IPv6.   But we used to have something = very similar to private addresses in IPv6 called site locals.   We = deprecated them for good reasons, and my first impression of that slide = was that it seemed to be advocating something like the concept of IPv4 = private addresses in IPv6.   So that's why I spoke up.   =  

Hosnieh clarified the slide by = explaining that by using "public addresses" she meant addresses = resolvable from DNS lookups.   But then the idea that a node should = not use "public addresses" is problematic for different reasons. =  

There are many people (in IETF and = elsewhere) who believe that applications should never use IP addresses = directly or in referrals to other applications.   This is often = cited as if it were some architectural principle - in fact just last = night, I actually had an AD state that to me as if it were a principle. =   I happen to disagree emphatically with that supposed principle, = for many reasons, but I won't list those reasons here.   For the = moment it only matters that there is a widely held belief that all = applications should only use names to refer to hosts or application = endpoints.   =46rom that point-of-view, all hosts/nodes need to = have names, so (by this definition) all hosts/nodes need to have public = addresses.   And the people who believe that applications should = always use names to refer to hosts or application endpoints have a lot = of influence on network protocol design choices.   So a = recommendation for hosts to only use addresses not listed in DNS can = have the effect of making those hosts unable to support various = applications.

Bottom line:  The decision = about whether a node should use an address listed in DNS is not = something that should be dictated entirely, or probably even mostly, by = concerns about the privacy of addresses.   =  

I would also suggest that the privacy = benefit from using addresses not listed in DNS is probably very small. =   But in order to evaluate that benefit, it would help to identify = specific threats to privacy that  are remedied by not using = addresses listed in = DNS.

Keith


= = --Apple-Mail-7--231383733-- From swb@internet2.edu Thu Aug 1 06:27:50 2013 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 32EC721E8090 for ; Thu, 1 Aug 2013 06:27:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtpoYFUtIeAC for ; Thu, 1 Aug 2013 06:27:43 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 40FBB21E8145 for ; Thu, 1 Aug 2013 06:26:11 -0700 (PDT) Received: from mail184-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 13:26:10 +0000 Received: from mail184-co1 (localhost [127.0.0.1]) by mail184-co1-R.bigfish.com (Postfix) with ESMTP id 419C848011D; Thu, 1 Aug 2013 13:26:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0810HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 8 X-BigFish: S8(zzbb2dI98dIzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1f5fh1b1cn1b1bi1155h) Received: from mail184-co1 (localhost.localdomain [127.0.0.1]) by mail184-co1 (MessageSwitch) id 1375363567820539_17128; Thu, 1 Aug 2013 13:26:07 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.240]) by mail184-co1.bigfish.com (Postfix) with ESMTP id C419F100049; Thu, 1 Aug 2013 13:26:07 +0000 (UTC) Received: from BY2PRD0810HT005.namprd08.prod.outlook.com (157.56.237.101) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 13:26:07 +0000 Received: from swbi2mbp.local (198.108.5.211) by pod51019.outlook.com (10.255.94.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 1 Aug 2013 13:26:05 +0000 Message-ID: <51FA61E8.6040909@internet2.edu> Date: Thu, 1 Aug 2013 15:26:00 +0200 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Keith Moore Subject: Re: ra-privacy: my responses to comments References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> In-Reply-To: <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [198.108.5.211] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: ipv6@ietf.org, Dave Thaler , Fernando Gont 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, 01 Aug 2013 13:27:50 -0000 On 08/01/13 14:31, Keith Moore allegedly wrote: > There are many people (in IETF and elsewhere) who believe that > applications should never use IP addresses directly or in referrals to > other applications. This is often cited as if it were some > architectural principle - in fact just last night, I actually had an AD > state that to me as if it were a principle. I happen to disagree > emphatically with that supposed principle, for many reasons, but I won't > list those reasons here. You may have to if you want to press your case. > For the moment it only matters that there is > a widely held belief that all applications should only use names to > refer to hosts or application endpoints. From that point-of-view, all > hosts/nodes need to have names, so (by this definition) all hosts/nodes > need to have public addresses. All sources of Internet public services need to have DNS names, but that's it. Other than that, "names" are only needed in higher layer communications, and can be handled there. For example, your laptop doesn't need a name to open communication with a SIP server, but once it does it can use one or more SIP-level identifiers for its end of the SIP-level communication. From ietf@rozanak.com Thu Aug 1 06:47:53 2013 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 6303221E80D4 for ; Thu, 1 Aug 2013 06:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8Bqd7QJRBiU for ; Thu, 1 Aug 2013 06:47:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 84E6621F91CE for ; Thu, 1 Aug 2013 06:47:33 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lil1h-1UV0dk30yT-00cwQ3; Thu, 01 Aug 2013 09:47:24 -0400 From: "Hosnieh Rafiee" To: "'Scott Brim'" , "'Keith Moore'" References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> In-Reply-To: <51FA61E8.6040909@internet2.edu> Subject: RE: ra-privacy: my responses to comments Date: Thu, 1 Aug 2013 15:47:09 +0200 Message-ID: <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbXFc5o58wZih1CtFZfBYjBYLViQJir6nxAh3GifiaQrtIwA== Content-Language: en-us X-Provags-ID: V02:K0:u5Qe3BA0yHQpFYRGbakrYJx//SKrQQ3cxfYMdknDJRl ERY0F8lYmbV8lZ+ZAVdZ65EjPfbV77qfzgKTo2Y0ZiC3zs+shK /glO2ssSgLyXrtLWqI5UeQJGQKwwS15Bm4MZroL04eFHbuKBpt CFOZSVfKucR6Hvn08eIhmBnCulrjey4dtGBFbJIHvteiGmaI1v KHlA+chnDz2emJQzAb9rUtoz6Y8u4+VJnCkxmPv6sWhdgGvJ+x mwYAMZHqrCOTE5KpCQDWwVOQkTJXqKkDX2jDUd6wmsaRZwHodF HyPhYkjLJxD34yKI3ENDt2noyWbzs3rdodBIP2iPaNw5M8z7M3 lG2vUfOzc1ZPLmHNyRM4= Cc: ipv6@ietf.org, 'Fernando Gont' , 'Dave Thaler' 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, 01 Aug 2013 13:47:53 -0000 Many thanks for your comments. > > On 08/01/13 14:31, Keith Moore allegedly wrote: > > There are many people (in IETF and elsewhere) who believe that > > applications should never use IP addresses directly or in referrals to > > other applications. This is often cited as if it were some > > architectural principle - in fact just last night, I actually had an AD > > state that to me as if it were a principle. I happen to disagree > > emphatically with that supposed principle, for many reasons, but I won't > > list those reasons here. > > You may have to if you want to press your case. > > > For the moment it only matters that there is a widely held belief that > > all applications should only use names to > > refer to hosts or application endpoints. From that point-of-view, all > > hosts/nodes need to have names, so (by this definition) all hosts/nodes > > need to have public addresses. > > All sources of Internet public services need to have DNS names, but that's it. > Other than that, "names" are only needed in higher layer communications, and > can be handled there. For example, your laptop doesn't need a name to open > communication with a SIP server, but once it does it can use one or more SIP- > level identifiers for its end of the SIP-level communication. That is the actual case. I assume that the node who are clients would use Privacy Extension RFC. I do not think you use it for your servers. This is why I said that nodes who wants to have privacy should not have "DNS names" or addresses that are defined in DNS but if they want to have they MUST not generate it based on MAC address. Of course it is "should" and not 'must". However, if you have wording issue, I can change it to "Might". Thanks, Best, Hosnieh From moore@network-heretics.com Thu Aug 1 07:10:00 2013 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 065EC21E81DB for ; Thu, 1 Aug 2013 07:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICEg7aWCaze6 for ; Thu, 1 Aug 2013 07:09:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 10DBA21E81E5 for ; Thu, 1 Aug 2013 07:09:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0F969215DE; Thu, 1 Aug 2013 10:09:45 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 01 Aug 2013 10:09:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=fvp Kzz0/HhFXoBKG6QHhDdbKlrU=; b=CR7zOITDD/+ySGwbwDLKQkLPV+V8jZLfC85 R7rI7AZCrPO4R0RD2gF6E1qpCKc5hdR4Fe3wmnhA9VNYNWwGjT9OEKvH1UvbjbEF lxxCwhlte22URcnAaB0dCvNyTOZCaYuFZdSKYQpWAXXnFq9RRg5/IIE7D/QP4K0G Sg1Mc0iQ= X-Sasl-enc: x1fzvLU40tsbpSFY51mN9dZunO1qqdQbdLG3hKNTgiBa 1375366184 Received: from dhcp-138f.meeting.ietf.org (unknown [130.129.19.143]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E7796800C7; Thu, 1 Aug 2013 10:09:44 -0400 (EDT) Subject: Re: ra-privacy: my responses to comments Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-8--225491433 From: Keith Moore In-Reply-To: <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> Date: Thu, 1 Aug 2013 16:09:43 +0200 Message-Id: <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> To: "Hosnieh Rafiee" X-Mailer: Apple Mail (2.1085) Cc: ipv6@ietf.org, 'Fernando Gont' , 'Dave Thaler' 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, 01 Aug 2013 14:10:01 -0000 --Apple-Mail-8--225491433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2013, at 3:47 PM, Hosnieh Rafiee wrote: >> All sources of Internet public services need to have DNS names, but = that's it. >> Other than that, "names" are only needed in higher layer = communications, and >> can be handled there. For example, your laptop doesn't need a name = to open >> communication with a SIP server, but once it does it can use one or = more SIP- >> level identifiers for its end of the SIP-level communication. >=20 > That is the actual case. I assume that the node who are clients would = use > Privacy Extension RFC. I do not think you use it for your servers. =20 I do not think it is appropriate to assume that nodes are either clients = or servers. Nodes can (and routinely do) support several applications = in which the local protocol engine acts as a client, a server, or a = peer, depending on the needs of each application. > This is > why I said that nodes who wants to have privacy should not have "DNS = names" > or addresses that are defined in DNS but if they want to have they = MUST not > generate it based on MAC address.=20 > Of course it is "should" and not 'must". However, if you have wording = issue, > I can change it to "Might". I recommend removing the text, or replacing it with something like "The = choice of whether to list a node's address in DNS properly depends on = many factors, including the set of applications to be run on the host. = Not listing a node's address in the public DNS may increase the node's = privacy, but may also impair its ability to support certain = applications." Keith --Apple-Mail-8--225491433 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All sources of Internet public services = need to have DNS names, but that's it.
Other than that, "names" are only needed in higher layer = communications, and
can be handled = there.  For example, your laptop doesn't need a name to = open
communication with a SIP = server, but once it does it can use one or more = SIP-
level identifiers for its end = of the SIP-level communication.

That is the actual = case. I assume that the node who are clients would use
Privacy = Extension RFC. I do not think you use it for your servers. =  

I do not think it is = appropriate to assume that nodes are either clients or servers.   =  Nodes can (and routinely do) support several applications in which = the local protocol engine acts as a client, a server, or a peer, = depending on the needs of each = application.

This = is
why I said that nodes who wants to have privacy should not have = "DNS names"
or addresses that are defined in DNS but if they want to = have they MUST not
generate it based on MAC address. 
Of course it is = "should" and not 'must". However, if you have wording issue,
I can = change it to "Might".

I = recommend removing the text, or replacing it with something like "The = choice of whether to list a node's address in DNS properly depends on = many factors, including the set of applications to be run on the host. =   Not listing a node's address in the public DNS may increase the = node's privacy, but may also impair its ability to support certain = applications."

Keith


= --Apple-Mail-8--225491433-- From swb@internet2.edu Thu Aug 1 07:18:36 2013 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 11C4021E8195 for ; Thu, 1 Aug 2013 07:18:36 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DePHu6B7ql5W for ; Thu, 1 Aug 2013 07:18:24 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0521F9E4D for ; Thu, 1 Aug 2013 07:17:48 -0700 (PDT) Received: from mail202-db8-R.bigfish.com (10.174.8.244) by DB8EHSOBE027.bigfish.com (10.174.4.90) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 14:17:47 +0000 Received: from mail202-db8 (localhost [127.0.0.1]) by mail202-db8-R.bigfish.com (Postfix) with ESMTP id 645E0B80194; Thu, 1 Aug 2013 14:17:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.237.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 8 X-BigFish: S8(zzbb2dI98dIzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1f5fh1b1cn1b1bi1155h) Received: from mail202-db8 (localhost.localdomain [127.0.0.1]) by mail202-db8 (MessageSwitch) id 1375366665880941_4336; Thu, 1 Aug 2013 14:17:45 +0000 (UTC) Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.235]) by mail202-db8.bigfish.com (Postfix) with ESMTP id CDD3440202; Thu, 1 Aug 2013 14:17:45 +0000 (UTC) Received: from BY2PRD0811HT005.namprd08.prod.outlook.com (157.56.237.5) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 14:17:43 +0000 Received: from swbi2mbp.local (198.108.5.211) by pod51019.outlook.com (10.255.91.168) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 1 Aug 2013 14:17:32 +0000 Message-ID: <51FA6DF8.5040404@internet2.edu> Date: Thu, 1 Aug 2013 16:17:28 +0200 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Keith Moore Subject: Re: ra-privacy: my responses to comments References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> In-Reply-To: <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [198.108.5.211] X-OriginatorOrg: internet2.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: ipv6@ietf.org, 'Dave Thaler' , 'Fernando Gont' 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, 01 Aug 2013 14:18:37 -0000 On 08/01/13 16:09, Keith Moore allegedly wrote: > I do not think it is appropriate to assume that nodes are either clients > or servers. Nodes can (and routinely do) support several applications > in which the local protocol engine acts as a client, a server, or a > peer, depending on the needs of each application. "sources of Internet public services". They may also be clients of public services but that's orthogonal. "peer" is also a nit - if you want an unknown someone to be able to contact you, you need to make yourself findable, whether the protocol design is p2p or not. Otherwise you don't. From moore@network-heretics.com Thu Aug 1 07:21:54 2013 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 3F30D21E80DC for ; Thu, 1 Aug 2013 07:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L67kErqHFt8m for ; Thu, 1 Aug 2013 07:21:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id CC25B21E81E0 for ; Thu, 1 Aug 2013 07:21:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 049A320AA7; Thu, 1 Aug 2013 10:21:20 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 01 Aug 2013 10:21:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=5KaSG/iCHYNgMLbxgBUYqE9WPYk=; b=HE 0ukaDoH1QIceu1SNxKlQAVSB9k9zobqOaWw9kyKZErW2KEFhPw0EdxaOEpUy2IRF Uny2YxYHtaEOyWF5URJSi5uu7b5WRYGYFo1vdY4WY7QWJPV6HVwB2cqrzR9C6NeH QYyshvu1RfegMtjhvGGuvKUiFZC4Snvdatd3ClSbQ= X-Sasl-enc: ONpGxQS84KBPVs4cIlBwxldLHaW7yqo9VQcy9hZYnJzP 1375366879 Received: from dhcp-138f.meeting.ietf.org (unknown [130.129.19.143]) by mail.messagingengine.com (Postfix) with ESMTPA id 5028CC00E86; Thu, 1 Aug 2013 10:21:19 -0400 (EDT) Subject: Re: ra-privacy: my responses to comments Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <51FA6DF8.5040404@internet2.edu> Date: Thu, 1 Aug 2013 16:21:17 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> <51FA6DF8.5040404@internet2.edu> To: Scott Brim X-Mailer: Apple Mail (2.1085) Cc: ipv6@ietf.org, 'Dave Thaler' , 'Fernando Gont' 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, 01 Aug 2013 14:21:54 -0000 On Aug 1, 2013, at 4:17 PM, Scott Brim wrote: > On 08/01/13 16:09, Keith Moore allegedly wrote: >> I do not think it is appropriate to assume that nodes are either clients >> or servers. Nodes can (and routinely do) support several applications >> in which the local protocol engine acts as a client, a server, or a >> peer, depending on the needs of each application. > > "sources of Internet public services". They may also be clients of > public services but that's orthogonal. "peer" is also a nit - if you > want an unknown someone to be able to contact you, you need to make > yourself findable, whether the protocol design is p2p or not. Otherwise > you don't. > I don't think we're disagreeing here. Keith From rja.lists@gmail.com Thu Aug 1 07:35:34 2013 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 7E7E521E8223 for ; Thu, 1 Aug 2013 07:35:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gpPk9dkDxIU for ; Thu, 1 Aug 2013 07:35:33 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0632B21F9F51 for ; Thu, 1 Aug 2013 07:35:21 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id u12so1103387qcx.7 for ; Thu, 01 Aug 2013 07:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=zZnTQTNoyppj6Wr27397xNDvj+H8LzU6MPjNac/4GUU=; b=OkewE7nMM2eqsVStlPamSSLWyST//hlUOcUdj5DcoDNTdWEdZZrzcGrUrf/njVj5r3 B9yQPZkBoLsBhi1s/jWtJtUlvXsOKjJHujCL0nOUXZ67/+N8htr1Q3kRpp6p/Cm9NedO to8O/6wFPtsiOmpZbPm7AmnsVDVoByQiyLF5qAzvuleT/M5OC9dQiJaMY3X7w5JwWYsG 2xfKG87X3vubXQl+hht4UtiLy7XsO/NCea9BL9XRZTzXKYG517QVzdKL1/qrwRGi0nRA dY0hs2j8LcRC+Nbc1LCs7QzjB8kDT0yvIN8N3lTDG0gBLKQEsX/bZT+EkugxhlauJxkX ew+Q== X-Received: by 10.224.182.79 with SMTP id cb15mr5169369qab.48.1375367721450; Thu, 01 Aug 2013 07:35:21 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id g9sm5429205qaz.4.2013.08.01.07.35.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 07:35:20 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: "Deprecate" Date: Thu, 1 Aug 2013 10:35:20 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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, 01 Aug 2013 14:35:34 -0000 On Tuesday 30th July, Ron Bonica wrote, in part: > I think that we heard the following at yesterday's meeting: >=20 > Title > =3D=3D=3D=3D=3D > The document should be renamed "IPv6 Fragmentation Considered = Ineffective" That is an improvement because it more accurately describes=20 the content of the draft. One might also consider a title that reframed it in terms of advice to application designers. > Deprecation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > All instances of the word "deprecate" should be removed > from the document. > =20 > Therefore: > -- The document should not request any IANA actions > -- The document doesn't UDPDATE 2460 > -- The document doesn't need to be PS. BCP is good enough Agree with all of the above. Either BCP or Informational is fine. > Recommendation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The Recommendation section should be renamed "Conclusion". > It should include the following statements: >=20 > - The IETF SHOULD NOT standardize an new protocols that > rely on IPv6 fragmentation I think we should allow the IESG/IETF more leeway to handle situations currently unforeseen. So I would suggest an edit along these lines: s/rely on IPv6 fragmentation/rely on IPv6 fragmentation if a=20 practical alternative to fragmentation exists for that protocol./ > ---*New* applications and transport layer protocols SHOULD support > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is = unreliable Neither approach is 100% reliable in the most general case. So, I'd suggest that new apps and transport-layer protocols=20 SHOULD support both PLMTUD and ICMP-based PMTUD. Supporting=20 both enhances the chances that some form of Path MTU Discovery=20 will work for a given session. > --*New* applications or transport layer protocols that cannot > support effective PMTUD MUST NOT in any circumstances send IPv6 > packets that exceed the IPv6 minimum MTU of 1280 bytes. I would change s/MUST NOT/SHOULD NOT/.=20 I'd delete the phrase "of 1280 bytes" as well, mainly because it is redundant, and partly so that this BCP would not need updating if the=20 1280 number changed in future. (It has already changed from unspecified to 576 to 1280 over time.) This document is all good advice, but I know of multiple IPv6=20 deployments where PMTUD works quite well. If an application=20 is deployed in such an environment, and knows that it is=20 (e.g. some locally-developed application as different from=20 a standard application such as HTTP), then the application=20 ought to be able to use the IETF standards-track PMTUD mechanism without violating other IETF standards-track specifications. > - Legacy applications and transport layer protocols will continue > to generate fragments Since this is basically a document with lots of good advice,=20 I'd also add some very clear and specific recommendations that=20 middleboxes and firewalls: A) MUST NOT block ICMP-based PMTUD messages where the indicated link MTU is equal-to or greater-than the standard IPv6 minimum link MTU. B) SHOULD NOT block ICMP-based PMTUD messages where the indicated link MTU is less than the standard IPv6 minimum link MTU in order to avoid breaking real-world nested tunnel deployments using IETF standards-track technologies. Discussion: Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode, or some other IETF specified technology, are NOT going away. If the physical MTU is 1280, then the tunnel MTU will be smaller. Nested tunnels are not unusual and can be difficult to detect absent a working PMTUD mechanism (whatever that might be). Tunnel-based deployments are just as real, and just as unlikely to disappear, as the current issues with PMTUD deployments. The document should be clear about this. > --- In the interest of backwards compatibility, IPv6 stacks and = forwarding > nodes MUST continue to support inbound fragmented IPv6 packets as = specified > in [RFC2460]. Yes. In particular, receiving hosts will need to continue to support IPv6 fragment reassembly for sessions terminating at such hosts. =20 > - Implementers and operators need to be aware that on many paths = through > the Internet, IPv6 fragmentation will fail. Legacy applications and = transport > layer protocols that do not conform to the previous paragraph can = expect connectivity failures as a result. s/can expect/might experience/ We don't want to use words that a naive reader/implementer would misinterpret as consent for violating RFC-2460 et seq. > --- Therefore, if a legacy protocol is capable of breaking its > dependence on IPv6 fragmentation, it should consider doing so. Agreed. Yours, Ran From rja.lists@gmail.com Thu Aug 1 07:41:52 2013 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 EF9A611E815F for ; Thu, 1 Aug 2013 07:41:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT2bnEulhLq0 for ; Thu, 1 Aug 2013 07:41:51 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC521E8250 for ; Thu, 1 Aug 2013 07:41:08 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c1so703837qcz.33 for ; Thu, 01 Aug 2013 07:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=BVVEq1RzR/0zuoconthal+id1qrZvw/u1gw0BXKxscE=; b=Q3IJkoe/U7RGPbKyv8D/fS44gAvrjgOrIlOaUtANj/0xsjzmLn7vgIF6KlUqEt2mNZ ZwS50xno8ti5J4JXnJzyZv5mee3PoUP4oX22m/Qi5egrZ6CJxFIjnDE9raMTtkH/hrh+ E7OCLnZO4hH0ZneGMBCsWmcxkLa6tyVymt+BvI2udsOEXvg6mHZwlrau+pQv7uW191hl U8vYsWTU7S97c/FR2wCQkjcU7r8swWmTK9b43vBttxEQ4cvUmeqUfF2BRNNBs/rk+swx lNQnnNhHBcKwDivE4VGnhQiisWsc0pmL2Dt3v1QPKzzJzUVL6sopO1JYY2b+L+NR8kIW HH8g== X-Received: by 10.224.12.81 with SMTP id w17mr5182036qaw.37.1375368066826; Thu, 01 Aug 2013 07:41:06 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id n8sm4767325qez.2.2013.08.01.07.41.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 07:41:06 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: "Deprecate" Date: Thu, 1 Aug 2013 10:41:04 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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, 01 Aug 2013 14:41:52 -0000 On July 30th, Bob Hinden wrote, in part: > I think the draft (especially since is headed toward BCP) > should also include a message that PMTUD is useful and > should not be blocked by routers/firewalls/middleboxes/etc. Aside: My note of a few minutes before had a bit of candidate text. > There are lots of valid reasons to not want to do IPv6 fragmentation, > but there was a lot of discussion about encouraging the use of PMTUD. > > Bob +10 to all of Bob's comments above. Yours, Ran From rja.lists@gmail.com Thu Aug 1 07:45:34 2013 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 8448C11E8152 for ; Thu, 1 Aug 2013 07:45:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTAYm7No8qYv for ; Thu, 1 Aug 2013 07:45:34 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8A11E8145 for ; Thu, 1 Aug 2013 07:45:33 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cr7so1153505qab.1 for ; Thu, 01 Aug 2013 07:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=FXNVeKD5qhwvZgUe7JssFdg46kiKWBYWZUjtDj66WA0=; b=jZAJTFyaWdEI7kAwtF0a+IvP1ijTbCQwFYbbXFZmkcxh0JH/Sv1MCX+CTmql/Cw89P VgU8JrmIcmlLKypw4GkspcVGdOmihNq00MGe+H9PEzgyJVeBW/OFS/4aJTYp/Ky8aUyq M3Br3I8DcgAYbinVyrEndFijIuBaaGj3TVNPkF8tHFRZF3RKZqCcq53rCnTlgXQ5QqoH g9kYMWRfLZVMGh6qyhgJJyYNpHmZZH6vAsvMHZAgoSDCOFjOnLODXQ8T7rLvi+Tm4lfO tm+S61uHw1Ib07bjkDqRGJvo0YMyOzVWwIgUviIWvzK3W/1E5qpO8Ya+MqKR/t0YGAGl WAlQ== X-Received: by 10.224.56.3 with SMTP id w3mr4865157qag.65.1375368331732; Thu, 01 Aug 2013 07:45:31 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id b6sm1782008qar.13.2013.08.01.07.45.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 07:45:31 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: UDP+Fragmentation (was: "Deprecate") Date: Thu, 1 Aug 2013 10:45:30 -0400 Message-Id: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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, 01 Aug 2013 14:45:34 -0000 I agree that C.M. Heard's ideas should be explored in more detail by the IETF. (I defer to the Powers That Be which list that might belong to -- TSV WG list might be one option, but it is not as likely to have IPv6 operators as well represented as the IPv6 list seems to have.) Yours, Ran From Fred.L.Templin@boeing.com Thu Aug 1 08:37:50 2013 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 9EA5B21E815C for ; Thu, 1 Aug 2013 08:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqPSEep6DYP8 for ; Thu, 1 Aug 2013 08:37:45 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3221E818D for ; Thu, 1 Aug 2013 08:37:44 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r71FbiN0013261 for ; Thu, 1 Aug 2013 10:37:44 -0500 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r71FbgdC013229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Aug 2013 10:37:43 -0500 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-NWHT-03.nw.nos.boeing.com (130.247.71.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 1 Aug 2013 08:37:42 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.41]) with mapi id 14.02.0328.011; Thu, 1 Aug 2013 08:37:41 -0700 From: "Templin, Fred L" To: Ronald Bonica , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjpJdxBsThTTW2kO9nlkD8PFVZ5mAe9+Q Date: Thu, 1 Aug 2013 15:37:41 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DC4E7@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE25127185AC@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE25127185AC@BY2PRD0511MB428.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 01 Aug 2013 15:37:50 -0000 Hi Ron, SEAL already handles the segmentation/reassembly such that it would not be necessary to define a new UDP. Plus, SEAL can be used independently of any transport layer, e.g., for IP-in-IP tunneling. If you are looking for a replacement for IPv6 fragmentation (which you should be) IMHO SEAL is the more versatile alternative. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Thursday, August 01, 2013 1:38 AM > To: C. M. Heard; IPv6 > Subject: UDP+Fragmentation (was: "Deprecate") >=20 > Cmh, >=20 > When I read this message, my first reaction was to scream "that such a > thing could not possibly be deployed, because operators will filter > anything that they don't know or have an immediate use for." But after > a few hallway discussions, I am starting to think that the idea might > be viable. >=20 > When the adrenaline and endorphin rush of IETF week has subsided, we > should a) discuss whether this is a viable option and b) if so, define > the replacement protocol in the Transport Area. >=20 > Chairs, >=20 > The conversation proposed above may not be within the charter of 6man. > If/when you think that there is a need to move this conversation, I can > ask the transport Ads for a non-WG mailing list. However, if you are > happy for at least the first part of this conversation to occur on this > mailing list, we can continue here. >=20 > Ron >=20 >=20 >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > > C. M. Heard > > Sent: Wednesday, July 31, 2013 12:40 AM > > To: IPv6 > > Subject: RE: "Deprecate" > > > > On Tue, 30 Jul 2013, Ronald Bonica wrote: > > > Thinking a little more about it, RTP and UDP aren't the real > > culprits. > > > The culprits are the applications that run over them. > > > So, we should limit our statement to applications, and not > > > "applications and transport layer protocols". > > > > I don't agree, at least not if the principal reason why IP fragments > > get dropped is that they lack the L4 header (or at least that the > non- > > initial fragments do) and thereby break stateless ACLs. The problem > is > > that UDP and its kin such as UDP-lite and DCCP lack transport-layer > > segmentation, such as is present in TCP, and are thereby force their > > clients to rely on IP fragmentation to provide this service. So yes, > > these transport protocols are the culprits. > > > > The idea that immediately comes to mind is to design _replacements_ > > transport protocols for UDP and kin that contain a transport layer > > segmentation mechanism. These would be for use by applications that > > can't get by without such a mechanism; existing applications that > don't > > need to rely on IP fragmentation can continue to use UDP and kin. > The > > replacement for UDP might have a header that looks something like > this: > > > > 0 15 16 31 > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Source Port | Destination Port | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Length | Segment Offset |Res|M| > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Identification | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Checksum | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | data octets ... > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > (Other and perhaps better possibilities exist, of course.) > > > > Having said that, I immediately imagine screaming that such a thing > > could not possibly be deployed, because operators will filter > anything > > that they don't know or have an immediate use for, and so it would > > never get any traction. > > > > Well, maybe so, but something has to give. The operations folks have > > complained that IP fragmentation is awful, they have to filter > > fragments because it defeats their stateless ACLs. OK; let's agree > > that's a defect that needs to be fixed. But if you don't want the > fix > > to break other important stuff (e.g., DNSSEC, as metioned in Section > > 3.1 of draft-bonica-6man-frag-deprecate-02), you need a replacement > for > > IP fragmentation (or an augmentation, such as in > > http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by > Mark > > Andrews). Maybe I just lack imagination, but I can't see any fix > that > > does not involve SOME change in operator behavior. > > > > //cmh > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ietf@rozanak.com Thu Aug 1 09:33:02 2013 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 D9F8C21E819C for ; Thu, 1 Aug 2013 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHihYD-LyWwc for ; Thu, 1 Aug 2013 09:32:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA7121E80BE for ; Thu, 1 Aug 2013 09:32:52 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M0hHi-1UCPAq45SI-00u8Bs; Thu, 01 Aug 2013 12:32:48 -0400 From: "Hosnieh Rafiee" To: "'Keith Moore'" References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> In-Reply-To: <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> Subject: RE: ra-privacy: my responses to comments Date: Thu, 1 Aug 2013 18:32:35 +0200 Message-ID: <000301ce8ed4$bf3b2b60$3db18220$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbXFc5o58wZih1CtFZfBYjBYLViQJir6nxmlOwFzA= Content-Language: en-us X-Provags-ID: V02:K0:Q4xYpMdefMDttOqEOF4k5o9BVQCpfLsMVXEixcGp5dE 80/PEL62WJGFolXYSgIMSS6bGHWB6j+D64qMFLVgWGgBz26SiQ CaZm+pxnc/NenZ1yaaPHbfi/rtBCl2CqzUMmaRScmpUsIhUc1R Li9jFFub5kBdRyPfT34oMca4bZWmYRwMhXUJ0aViWxy3ijuhDI EL9MAsXyTFfgGMKaLQlaTQM77IIUAHl5IWOJvJ44S63bsjTOuW cpUlI3RQQKlkBr8mpskfn6myOS8vhu72ZznJBVVPBoFBwnlpG7 4l7rREasfML9Id6lbsIJXkLKqkQyE+Eg7uDECO2MBy0SaiBQ4H EBK3VwKYkiLn77kVOLpU= Cc: Andrew Yourtchenko , ipv6@ietf.org, 'Dave Thaler' 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, 01 Aug 2013 16:33:02 -0000 Thanks a lot for your comments. They were actually quite helpful and made some good points. Here are my answers: >There are many people (in IETF and elsewhere) who believe that applications should never use IP addresses directly or in referrals to Other applications. This is often cited as if it were >some architectural principle - in fact just last night, I actually had an AD state that to me as if it were a principle. I happen to disagree emphatically with that supposed principle, for many >reasons, but I won't list those reasons here. For the moment it only matters that there is a widely held belief that all applications should only use names to refer to hosts or application >endpoints. From that point-of-view, all hosts/nodes need to have names, so (by this definition) all hosts/nodes need to have public addresses. And the people who believe that applications >should always use names to refer to hosts or application endpoints have a lot of influence on network protocol design choices. So a recommendation for hosts to only use addresses not >listed in DNS can have the effect of making those hosts unable to support various applications. I imagine the name that you want to be publicly available is different than the names that you use it in local link for some applications. Right? >Bottom line: The decision about whether a node should use an address listed in DNS is not something that should be dictated entirely, or probably even mostly, by concerns about the privacy of addresses. This is actually what I tried to explained in the draft but not very successfully. I will have to use different wording in addressing this problem and not convey the meaning that one is forced to do as explained in draft but explain the repercussions that could ensue if one doesn't follow the advice given in the draft. >I would also suggest that the privacy benefit from using addresses not listed in DNS is probably very small. But in order to evaluate that benefit, it would help to identify specific threats to >privacy that are remedied by not using addresses listed in DNS. It is not small. If you ask the DNS guys (or probably you are one of them?), they will tell you that nowadays the types of attacks against DNS have changed. The attackers now use DNS as a tool with which to attack other nodes on the network. One such attack is node scanning, which is not feasible in the traditional way with IPv6. This is because, as you know, there are 2^64 addresses in each subnet. One might use DNS to find the IP address of other nodes in a target network. As I said during my talk, we implemented this attack using DNS. We obtained a lot of names all of which resided in public DNS servers. Even with the use of security this would not be prevented, but the chances of this type of attack being perpetrated would be diminished. If you are interested, you can download the attacking tool that we used from our website (easily search ipv6ssl and hpi). It is publicly available.It is not an optimized tool as our purpose was for research. We will upload a more optimized version soon. Thanks, Best, Hosnieh From heard@pobox.com Thu Aug 1 10:12:02 2013 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 70F7621E8211 for ; Thu, 1 Aug 2013 10:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbEmXQvzr+SQ for ; Thu, 1 Aug 2013 10:11:57 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122A221E820D for ; Thu, 1 Aug 2013 10:11:55 -0700 (PDT) Received: (qmail 25756 invoked from network); 1 Aug 2013 10:11:52 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Aug 2013 10:11:52 -0700 Date: Thu, 1 Aug 2013 10:11:52 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: UDP+Fragmentation (was: "Deprecate") In-Reply-To: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 01 Aug 2013 17:12:02 -0000 On Thu, 1 Aug 2013, RJ Atkinson wrote: > I agree that C.M. Heard's ideas should be explored > in more detail by the IETF. Not just my suggestion, but other ideas as well: - put UDP source and destination ports in a new IPv6 option that and add it along with a fragment header when fragmenting UDP packets (suggested on-list by Mark Andrews). - generic transport encapsulation within UDP (suggested to me off-list by Mark Smith, based on a draft by Stuart Cheshire et. al.). - SEAL (suggested on-list by Fred Templin) > (I defer to the Powers That Be which list that might > belong to -- TSV WG list might be one option, but > it is not as likely to have IPv6 operators as well > represented as the IPv6 list seems to have.) That's really important -- it doesn't do anyone any good to have a theoretical solution that operators are not willing to deploy. We all need to work together here. Thanks, Mike Heard From brian.e.carpenter@gmail.com Thu Aug 1 13:26:19 2013 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 3481311E80D2 for ; Thu, 1 Aug 2013 13:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0sMiKmouaeD for ; Thu, 1 Aug 2013 13:26:18 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B204F21E80BA for ; Thu, 1 Aug 2013 13:26:18 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so2509188pbb.41 for ; Thu, 01 Aug 2013 13:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9KMWKYYR4Ui1mq2NR+wXPXb5K/ZsB0tRo/P0jvUONVk=; b=dQ2go3+SghxdKb2msGVqTWxCtvuconcSRgktugkWNdHOiMJfyS9shDrfV81xM7Kky/ vwsip0dXXjQrcY8KYx7bF1taqXmO+cL8T6S26MVs2TVCVvR4uBKpuwhRDppwch3280hM YMLfaAuAsmr+b5zQELoop/w9Qrw88DfmOd17FBrH0IWGU9MQhIiKlANTiAKGNHPmN+Iz H1NHtdTqXeIaVqp5DgdVhp2wi+qy7jJf5cioITGzgahtImMSbI7M+h7yNsb238oKHppF /yEGDJWOhZx0JXT/KB7GRRU6QlG9SLpCd1AXgS/iEkqqnzYLvZ8+Wk8JlEi+6VGbretg tRtg== X-Received: by 10.66.159.72 with SMTP id xa8mr6479914pab.38.1375388778473; Thu, 01 Aug 2013 13:26:18 -0700 (PDT) Received: from [192.168.178.23] (107.199.69.111.dynamic.snap.net.nz. [111.69.199.107]) by mx.google.com with ESMTPSA id z14sm5844459pbt.0.2013.08.01.13.26.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 13:26:17 -0700 (PDT) Message-ID: <51FAC46D.2020705@gmail.com> Date: Fri, 02 Aug 2013 08:26:21 +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: ra-privacy: my responses to comments References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> In-Reply-To: <51FA61E8.6040909@internet2.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Keith Moore , Dave Thaler , Fernando Gont 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, 01 Aug 2013 20:26:19 -0000 On 02/08/2013 01:26, Scott Brim wrote: > On 08/01/13 14:31, Keith Moore allegedly wrote: >> There are many people (in IETF and elsewhere) who believe that >> applications should never use IP addresses directly or in referrals to >> other applications. This is often cited as if it were some >> architectural principle - in fact just last night, I actually had an AD >> state that to me as if it were a principle. I happen to disagree >> emphatically with that supposed principle, for many reasons, but I won't >> list those reasons here. > > You may have to if you want to press your case. Some of Keith's arguments on this point were captured in draft-carpenter-behave-referral-object-01, but that draft also contains the statement: " In some cases, this problem may be readily solved by passing a Fully Qualified Domain Name (FQDN) instead of an IP address. Indeed, that is an architecturally preferred solution [RFC1958]. " That's indeed what RFC 1958 says. >> For the moment it only matters that there is >> a widely held belief that all applications should only use names to >> refer to hosts or application endpoints. From that point-of-view, all >> hosts/nodes need to have names, so (by this definition) all hosts/nodes >> need to have public addresses. > > All sources of Internet public services need to have DNS names, but > that's it. Other than that, "names" are only needed in higher layer > communications, and can be handled there. For example, your laptop > doesn't need a name to open communication with a SIP server, but once it > does it can use one or more SIP-level identifiers for its end of the > SIP-level communication. It can, but applications can get into trouble for a whole lot of reasons discussed in the above draft and its successors (draft-carpenter-grobj-reqts and draft-carpenter-referral-ps). Brian From ietf@rozanak.com Thu Aug 1 13:43:42 2013 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 1B19011E813F for ; Thu, 1 Aug 2013 13:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvZhAfp8wiWb for ; Thu, 1 Aug 2013 13:43:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1316411E816F for ; Thu, 1 Aug 2013 13:43:17 -0700 (PDT) Received: from kopoli (g225091208.adsl.alicedsl.de [92.225.91.208]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M24nL-1UBVmD36Ff-00tCnk; Thu, 01 Aug 2013 16:43:11 -0400 From: "Hosnieh Rafiee" To: "'Keith Moore'" References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> In-Reply-To: Subject: RE: ra-privacy: my responses to comments Date: Thu, 1 Aug 2013 22:42:58 +0200 Message-ID: <000001ce8ef7$b9ae0960$2d0a1c20$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbXFc5o58wZih1CtFZfBYjBYLViQJir6nxmlOwFzCAAHEWUA== Content-Language: en-us X-Provags-ID: V02:K0:Z3+EYcA0UGx39UF6PWaRGGz1qqWMogUqmRnaJmey4q9 r1yAiJQRP7gWYMSCOgSjzzR6Nm/MGgLGhVMt2qswlIz4XETDNW HVeH6/GefQ3IqMMYUKgc6MsIHYA8A6bviZrCAudoPIbvriMcRd MgrctXWuMvOWspIR2/B16pETi09ENpI3PRB18DEm9jb2MIIXXE xuugPnuObhzMfmJKPZCHH6MXsbG/4RtuBVvPsVgKc9VL1n76rU Ps5GlnOfRMMDn9WdPADUp41vEWVyV3r438vs43yK/aIsZiA8qJ Hnt8SYKUOlS8my9jhIm894m0I/+P92BPuLh4CrMx4YH0zMj12q q7ym7P6vx5vWm08wWivc= Cc: Andrew Yourtchenko , ipv6@ietf.org, 'Dave Thaler' 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, 01 Aug 2013 20:43:42 -0000 Thanks a lot for your comments. They were actually quite helpful and made some good points. Here are my answers: >There are many people (in IETF and elsewhere) who believe that applications should never use IP addresses directly or in referrals to Other applications. This is often cited as if it were >some architectural principle - in fact just last night, I actually had an AD state that to me as if it were a principle. I happen to disagree emphatically with that supposed principle, for many >reasons, but I won't list those reasons here. For the moment it only matters that there is a widely held belief that all applications should only use names to refer to hosts or application >endpoints. From that point-of-view, all hosts/nodes need to have names, so (by this definition) all hosts/nodes need to have public addresses. And the people who believe that applications >should always use names to refer to hosts or application endpoints have a lot of influence on network protocol design choices. So a recommendation for hosts to only use addresses not >listed in DNS can have the effect of making those hosts unable to support various applications. I imagine the name that you want to be publicly available is different than the names that you use it in local link for some applications. Right? >Bottom line: The decision about whether a node should use an address listed in DNS is not something that should be dictated entirely, or probably even mostly, by concerns about the privacy of addresses. This is actually what I tried to explained in the draft but not very successfully. I will have to use different wording in addressing this problem and not convey the meaning that one is forced to do as explained in draft but explain the repercussions that could ensue if one doesn't follow the advice given in the draft. >I would also suggest that the privacy benefit from using addresses not listed in DNS is probably very small. But in order to evaluate that benefit, it would help to identify specific threats to >privacy that are remedied by not using addresses listed in DNS. It is not small. If you ask the DNS guys (or probably you are one of them?), they will tell you that nowadays the types of attacks against DNS have changed. The attackers now use DNS as a tool with which to attack other nodes on the network. One such attack is node scanning, which is not feasible in the traditional way with IPv6. This is because, as you know, there are 2^64 addresses in each subnet. One might use DNS to find the IP address of other nodes in a target network. As I said during my talk, we implemented this attack using DNS. We obtained a lot of names all of which resided in public DNS servers. Even with the use of security this would not be prevented, but the chances of this type of attack being perpetrated would be diminished. If you are interested, you can download the attacking tool that we used from our website (easily search ipv6ssl and hpi). It is publicly available.It is not an optimized tool as our purpose was for research. We will upload a more optimized version soon. Thanks, Best, Hosnieh From moore@network-heretics.com Thu Aug 1 13:51:47 2013 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 C03CB11E814B for ; Thu, 1 Aug 2013 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWbbBTPQbA5D for ; Thu, 1 Aug 2013 13:51:42 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 90ACA11E8150 for ; Thu, 1 Aug 2013 13:51:42 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C53D320EEB; Thu, 1 Aug 2013 16:51:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 01 Aug 2013 16:51:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=qfsdrGyQqzKV7fJDDfM0rGmm2vY=; b=SZ n+qPKpSHMjwss4ZXePHwLVg9jM+GwApvJ4jF6ur3qZW0MbVnb4gEYZ0zFhZNmi7d 1Quy7RjTA/KKUNV0+1HqOdS9ro2J0+3TWs6gxnd67kpqB1aqGKVtr9y9qs6APKWX hmijcNOnueX/3y2vFwkWMxxsObRnY4OZ8V8f94zuI= X-Sasl-enc: fNpgQdPmZJh+ms+o9oEJZpRE0P0NNrjseNW+Vesk2JUc 1375390298 Received: from surfer-172-29-8-65-hotspot.internet-for-guests.com (unknown [87.193.195.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 0DC95680109; Thu, 1 Aug 2013 16:51:37 -0400 (EDT) Subject: Re: ra-privacy: my responses to comments Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <000001ce8ef7$b9ae0960$2d0a1c20$@rozanak.com> Date: Thu, 1 Aug 2013 22:51:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55FB9711-5D28-4C17-9C81-5D41E5110C5C@network-heretics.com> References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <000001ce8ef7$b9ae0960$2d0a1c20$@rozanak.com> To: "Hosnieh Rafiee" X-Mailer: Apple Mail (2.1085) Cc: Andrew Yourtchenko , ipv6@ietf.org, 'Dave Thaler' 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, 01 Aug 2013 20:51:48 -0000 I do think it might be useful to recommend that DNS servers be = configured as to refuse requests to list DNS zones as a means to thwart = attackers from looking for IPv6 addresses. But assuming that such = listing is disabled, I don't know why listing a host's address in DNS = would make that host a more likely target for attack. In other words, = why is DNS name probing any more feasible of an attack than IPv6 address = probing? Keith From bob.hinden@gmail.com Thu Aug 1 14:20:23 2013 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 D5D5C11E81AC for ; Thu, 1 Aug 2013 14:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcv6czQAKKQe for ; Thu, 1 Aug 2013 14:20:16 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C83DF21E824A for ; Thu, 1 Aug 2013 14:15:04 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so2178413wes.29 for ; Thu, 01 Aug 2013 14:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vYK9llmn2ip5WCd++g8cqJzpHrB8lkuSFnDr521aqaY=; b=O4BK7FxUXW+a9CQ9pHztRQGzqQxIGre+899VZzc9GdLgbW2dSJsCY+vQ4g+sgBiu8b 0mnNx1hYySBRsBMQWnhetzHzayLZNrFRnZuK07QIRmuIk84ns7dx3sK/B8vfc8gC+KI4 HnezGMCarGcG+WJqKa617w2DQlOW+cIdgBlKxcjSzUFQ5caJkf+EqHa5JjoY9o8r/jfZ BWXAZ0mU31hWurbE9EDUZucsdMEw0XOVdH6XO9b6YmTSuax5DIltgxNwmSzbbjQuJK3O uPqCTbRD6zt7QypKhKLUASxKzN3SPEtPOl1iiHWzwsNhFSliGkcFZnAlfaIbYPr/vK8G WrPg== X-Received: by 10.194.95.100 with SMTP id dj4mr2780015wjb.55.1375391703894; Thu, 01 Aug 2013 14:15:03 -0700 (PDT) Received: from ?IPv6:2001:df8::64:490b:e9b4:9dde:6e96? ([2001:df8:0:64:490b:e9b4:9dde:6e96]) by mx.google.com with ESMTPSA id hb2sm510786wib.0.2013.08.01.14.15.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 14:15:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: UDP+Fragmentation (was: "Deprecate") From: Bob Hinden In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE25127185AC@BY2PRD0511MB428.namprd05.prod.outlook.com> Date: Thu, 1 Aug 2013 23:14:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4FCDFF10-07A5-4184-8C61-0ADCDB93F1AC@gmail.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B965346@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE251271361B@BY2PRD0511MB428.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE25127185AC@BY2PRD0511MB428.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1508) Cc: "C. M. Heard" , IPv6 , 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: Thu, 01 Aug 2013 21:20:24 -0000 Ron, On Aug 1, 2013, at 10:37 AM, Ronald Bonica wrote: > Cmh, >=20 > When I read this message, my first reaction was to scream "that such a = thing could not possibly be deployed, because operators will filter = anything that they don't know or have an immediate use for." But after a = few hallway discussions, I am starting to think that the idea might be = viable. >=20 > When the adrenaline and endorphin rush of IETF week has subsided, we = should a) discuss whether this is a viable option and b) if so, define = the replacement protocol in the Transport Area. >=20 > Chairs, >=20 > The conversation proposed above may not be within the charter of 6man. = If/when you think that there is a need to move this conversation, I can = ask the transport Ads for a non-WG mailing list. However, if you are = happy for at least the first part of this conversation to occur on this = mailing list, we can continue here. >=20 >=20 My personal opinion is that the conversation can start on 6man. We have = some history of how to make TCP and UDP work over IPv6, so I think it's = OK to start here. I am sure the ADs will decide to move it gains steam = and they wish it elsewhere. Thanks, Bob >=20 >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of >> C. M. Heard >> Sent: Wednesday, July 31, 2013 12:40 AM >> To: IPv6 >> Subject: RE: "Deprecate" >>=20 >> On Tue, 30 Jul 2013, Ronald Bonica wrote: >>> Thinking a little more about it, RTP and UDP aren't the real >> culprits. >>> The culprits are the applications that run over them. >>> So, we should limit our statement to applications, and not >>> "applications and transport layer protocols". >>=20 >> I don't agree, at least not if the principal reason why IP fragments >> get dropped is that they lack the L4 header (or at least that the = non- >> initial fragments do) and thereby break stateless ACLs. The problem = is >> that UDP and its kin such as UDP-lite and DCCP lack transport-layer >> segmentation, such as is present in TCP, and are thereby force their >> clients to rely on IP fragmentation to provide this service. So yes, >> these transport protocols are the culprits. >>=20 >> The idea that immediately comes to mind is to design _replacements_ >> transport protocols for UDP and kin that contain a transport layer >> segmentation mechanism. These would be for use by applications that >> can't get by without such a mechanism; existing applications that = don't >> need to rely on IP fragmentation can continue to use UDP and kin. = The >> replacement for UDP might have a header that looks something like = this: >>=20 >> 0 15 16 31 >> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >> | Source Port | Destination Port | >> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >> | Length | Segment Offset |Res|M| >> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >> | Identification | >> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >> | Checksum | >> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >> | data octets ... >> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... >>=20 >> (Other and perhaps better possibilities exist, of course.) >>=20 >> Having said that, I immediately imagine screaming that such a thing >> could not possibly be deployed, because operators will filter = anything >> that they don't know or have an immediate use for, and so it would >> never get any traction. >>=20 >> Well, maybe so, but something has to give. The operations folks have >> complained that IP fragmentation is awful, they have to filter >> fragments because it defeats their stateless ACLs. OK; let's agree >> that's a defect that needs to be fixed. But if you don't want the = fix >> to break other important stuff (e.g., DNSSEC, as metioned in Section >> 3.1 of draft-bonica-6man-frag-deprecate-02), you need a replacement = for >> IP fragmentation (or an augmentation, such as in >> http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by = Mark >> Andrews). Maybe I just lack imagination, but I can't see any fix = that >> does not involve SOME change in operator behavior. >>=20 >> //cmh >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Thu Aug 1 14:46:35 2013 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 4261821E8289 for ; Thu, 1 Aug 2013 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca37i8Hicf8A for ; Thu, 1 Aug 2013 14:46:27 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EFDCB11E81C5 for ; Thu, 1 Aug 2013 14:28:38 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so2102737wgg.0 for ; Thu, 01 Aug 2013 14:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=FAQS8LH39ZPGQuOFOvGUgnb64Poa7+RBUlPePoh7zQY=; b=puGp9GreYRRIi1ImIljFcScLjBDUkmX5i/AaniOfZmK49WyPhF+g1TCdNM2CQltl/s k1VTIOzah3wajg0M3bjdIeHZFbohjW81swIopLbPrszFP89qJye8qXDbcIKa2WmU10a5 h/9NDsUGtQczAMC1kYCqelyqkv+5DlAt8/7sRB8Vd70bF4ahAK/Ha344NOC2SS6f9j+j Fe3XD28QNoG4IoHe30gzFcVM1NWwD7RyDXY2Kgx56nvaY3d/swIZZhFS1OSUlKoeQYBe 1a7bPfOalN0fSv05O4WcvmdUDe7+SkbUpk1rH+jvjKcLxjQyeeGSJ2x41GnkXq8ghCjC hthA== X-Received: by 10.180.82.101 with SMTP id h5mr9122416wiy.27.1375390829321; Thu, 01 Aug 2013 14:00:29 -0700 (PDT) Received: from dhcp-43dd.meeting.ietf.org (dhcp-43dd.meeting.ietf.org. [130.129.67.221]) by mx.google.com with ESMTPSA id dt17sm164235wic.1.2013.08.01.14.00.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 14:00:27 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Test Message-Id: <8A1044EA-303B-4D96-9A36-62427DF54591@gmail.com> Date: Thu, 1 Aug 2013 23:00:24 +0200 To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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, 01 Aug 2013 21:46:35 -0000 Test, please ignore. From Fred.L.Templin@boeing.com Thu Aug 1 16:11:08 2013 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 3DA5511E81A7 for ; Thu, 1 Aug 2013 16:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7ZXgin8QWWK for ; Thu, 1 Aug 2013 16:10:51 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3611E821C for ; Thu, 1 Aug 2013 15:40:53 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r71MfZ6K031354 for ; Thu, 1 Aug 2013 15:41:35 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r71MfYN0031349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Aug 2013 15:41:35 -0700 Received: from XCH-BLV-306.nw.nos.boeing.com (130.247.25.218) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 1 Aug 2013 15:40:52 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.159]) with mapi id 14.02.0328.011; Thu, 1 Aug 2013 15:40:51 -0700 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOfQZWiYfnka6nOUeBop7mpmo4ZpmBE+pg Date: Thu, 1 Aug 2013 22:40:51 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 01 Aug 2013 23:11:08 -0000 Hi Ran, > Discussion: > Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode, > or some other IETF specified technology, are NOT going away. Yes, this is the same as I and others have been saying all along. > If the physical MTU is 1280, then the tunnel MTU will be smaller. Not allowed; the tunnel MUST be able to do a minimum 1280. > Nested tunnels are not unusual and can be difficult to detect > absent a working PMTUD mechanism (whatever that might be). Agree that nested tunnels are not unusual and are in fact in common widespread deployment. But, there is no need to "detect" them from the source host's perspective as long as they honor the IPv6 1280 minMTU. That means that tunnels MUST be prepared to do a small amount of fragmentation and reassembly when necessary. Thanks - Fred fred.l.templin@boeing.com From albert.e.manfredi@boeing.com Thu Aug 1 17:12:30 2013 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 7796F11E8257 for ; Thu, 1 Aug 2013 17:12: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3nkYsX-l7L4 for ; Thu, 1 Aug 2013 17:12:17 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2421E83BC for ; Thu, 1 Aug 2013 16:26:25 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r71NQOIj020554 for ; Thu, 1 Aug 2013 16:26:24 -0700 Received: from XCH-PHX-206.sw.nos.boeing.com (xch-phx-206.sw.nos.boeing.com [137.136.238.17]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r71NQM0j020541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 1 Aug 2013 16:26:23 -0700 Received: from XCH-BLV-212.nw.nos.boeing.com (137.136.239.115) by XCH-PHX-206.sw.nos.boeing.com (137.136.238.17) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 1 Aug 2013 16:26:22 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.42]) by XCH-BLV-212.nw.nos.boeing.com ([169.254.12.44]) with mapi id 14.02.0328.011; Thu, 1 Aug 2013 16:26:22 -0700 From: "Manfredi, Albert E" To: Scott Brim Subject: RE: ra-privacy: my responses to comments Thread-Topic: ra-privacy: my responses to comments Thread-Index: AQHOjrlVqeEWF0tlIkK7jI8o0OnIjZmAzTkAgAAF6ICAAAZPgIAAAioAgAAiwRA= Date: Thu, 1 Aug 2013 23:26:21 +0000 Message-ID: <021E64FECA7E5A4699562F4E667164810B4708D6@XCH-PHX-503.sw.nos.boeing.com> References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> <51FA6DF8.5040404@internet2.edu> In-Reply-To: <51FA6DF8.5040404@internet2.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 02 Aug 2013 00:12:30 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of S= cott > Brim > "peer" is also a nit - if you > want an unknown someone to be able to contact you, you need to make > yourself findable, whether the protocol design is p2p or not. Otherwise > you don't. I also object to the notion that every host or application should be identi= fied by name and not by address. In a peer to peer network, the peers can c= ertainly have the other peers' IP addresses known to them. You don't need a= DNS at all, in situations like this. Matter of fact, I would suggest that the Client Identifier Option of DHCP i= s precisely for such scenarios. Where the unconfigured peer needs to be giv= en a specific IP address, because that's the only way the other peers can f= ind it. Bert From marka@isc.org Thu Aug 1 18:32:54 2013 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 3B1EF21E829E for ; Thu, 1 Aug 2013 18:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e50xlVBon4v for ; Thu, 1 Aug 2013 18:32:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 350CF11E8433 for ; Thu, 1 Aug 2013 17:36:05 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F131CC944A; Fri, 2 Aug 2013 00:35:51 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375403764; bh=OujrC5rmkly5yCK+vPzeRH0eCgDsfqX26MCJ7M/mA34=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Z8TUBH7XSyJDUQ63XHw1RH+xF1j9rT4zBaL578z9dEnYAKx3tcUYf3JGKm0q+WCta STsmyzkIQPDuz0OVSuDYdEGG5nJGMwtJrEaBthwIImO2fSz1+g0Ed5WUgcgQTDStjq EyA+JvdCE4ekR+ie+IqgJYZrrc5ceTNPaLbjMo94= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 2 Aug 2013 00:35:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B000B160306; Fri, 2 Aug 2013 00:39:43 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nlwEXhyFIPew; Fri, 2 Aug 2013 00:39:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 69A78160305; Fri, 2 Aug 2013 00:39:41 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3B7A4160303; Fri, 2 Aug 2013 00:39:41 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 71BB137EE821; Fri, 2 Aug 2013 10:35:47 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> Subject: Re: "Deprecate" In-reply-to: Your message of "Thu, 01 Aug 2013 22:40:51 +0000." <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 02 Aug 2013 10:35:47 +1000 Message-Id: <20130802003547.71BB137EE821@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "ipv6@ietf.org" , RJ Atkinson 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, 02 Aug 2013 01:32:54 -0000 In message <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.co m>, "Templin, Fred L" writes: > Hi Ran, > > > Discussion: > > Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode, > > or some other IETF specified technology, are NOT going away. > > Yes, this is the same as I and others have been saying all along. > > > If the physical MTU is 1280, then the tunnel MTU will be smaller. > > Not allowed; the tunnel MUST be able to do a minimum 1280. > > > Nested tunnels are not unusual and can be difficult to detect > > absent a working PMTUD mechanism (whatever that might be). > > Agree that nested tunnels are not unusual and are in fact in > common widespread deployment. But, there is no need to "detect" > them from the source host's perspective as long as they honor > the IPv6 1280 minMTU. That means that tunnels MUST be prepared > to do a small amount of fragmentation and reassembly when > necessary. And if we generate appoximately equal sized fragments rather than 1280 byte fragments + a runt fragment tunnels would need to fragment less often. Your 1500 byte UDP payloads become 2 x 750 byte fragments which can be encapulated multiple times. It doesn't take a lot of math to work out what size to fragment at to produce optimal fragment sizes for a given MTU. Mark > Thanks - Fred > fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Thu Aug 1 21:09:26 2013 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 7AD0311E8104 for ; Thu, 1 Aug 2013 21:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNCQVuQ0rd6J for ; Thu, 1 Aug 2013 21:09:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7323211E80FE for ; Thu, 1 Aug 2013 21:09:19 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 538D6C9432; Fri, 2 Aug 2013 04:09:06 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375416559; bh=R+uUHYwwi8qBIN0eR0Uxmp0hyJEQhIHe+gZhXaNm0iY=; h=Cc:From:Subject:In-reply-to:Date; b=faDcKXAxjfJUtf51/2p34ZJnKPyLo8/kIMriRrrkVLOMtT14G1sRInvTuGInvWAdN X8s+KwAkyp2ZajldKdK/P9QhJ9hJvMh7BENkHOOBNwu/1h6w3knbCv2tBIh+ZlAV9P C6bZDFHQIp/gMxSuVFb9v2hs7CXXUwjo+EXThYB8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 2 Aug 2013 04:09:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AB6C316030C; Fri, 2 Aug 2013 04:12:58 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nGs-TGbdBAtV; Fri, 2 Aug 2013 04:12:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 76B1816030B; Fri, 2 Aug 2013 04:12:56 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 45D2616030A; Fri, 2 Aug 2013 04:12:56 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id D62ED37F079D; Fri, 2 Aug 2013 14:09:00 +1000 (EST) From: Mark Andrews Subject: Re: "Deprecate" In-reply-to: Your message of "Wed, 31 Jul 2013 10:54:03 +1000." Date: Fri, 02 Aug 2013 14:09:00 +1000 Message-Id: <20130802040900.D62ED37F079D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Maintanence 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, 02 Aug 2013 04:09:26 -0000 Mark Andrews writes: > > I can write up my suggestion as a I-D. It provides the information > stateless middleware needs to pass fragments. It also helps firewalls > that decide they need to see the entire contents of packets by > providing protection to their reassembly queues. Done. http://www.ietf.org/id/draft-andrews-6man-fragopt-00.txt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From markzzzsmith@yahoo.com.au Thu Aug 1 21:55:40 2013 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 0271911E81E0 for ; Thu, 1 Aug 2013 21:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfG1AY8ro-DC for ; Thu, 1 Aug 2013 21:55:24 -0700 (PDT) Received: from nm38-vm5.bullet.mail.bf1.yahoo.com (nm38-vm5.bullet.mail.bf1.yahoo.com [72.30.239.21]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7311E8104 for ; Thu, 1 Aug 2013 21:55:24 -0700 (PDT) Received: from [98.139.215.142] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 02 Aug 2013 04:55:23 -0000 Received: from [98.139.212.200] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 02 Aug 2013 04:55:23 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 02 Aug 2013 04:55:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 667516.93845.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 70596 invoked by uid 60001); 2 Aug 2013 04:55:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1375419323; bh=VuBndBKOeuRJgbjW4N5ULsrAHWCenzu+HEBGYMBV7cE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EpgKNdU6O06/6sredYylvDA/iKWhDUmp1bDCO/m5kt8+bFreEP3AAdVARG9aDdFtJrs4i9BXBPNuMF9O4C05JnUyiTl2xkQZXqDNFnnyzWbAEQHjWzYmdhyaccGABJG6CPi3Yn6zgys/CXVm9cl1oc17u7hrEFd/qw1gES0IS3w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QAKGr9FApKF6xcYn8pUzUiFPQ0/zVDrICe8LFOrZ9IbFRkT679ZdgLzxrTPqGAHL4VjtYAEIwsWPuEQjBUhvCR0eWrMu/czPWHA7pwWknc0z/JNPx2yAeVtJhyYqvFUm8RKpJIIPXct6l6yjrH8hS5hRF3ar2XkiE4dQDbc5Qh0=; X-YMail-OSG: tlquz44VM1l1GLm0H4M5wy1Y7AX8SSq6Gq8TcwU9K4qtpGl T1lBeELp92SeDUHDsu01y5V6N62_tcAfEJ3.xWADx0SvSmy0mgYv4l5VCMUt zdwul2jmrLU8E8uu.WMT27jak13dPJ_MJqxNAkX_MMF9u.1CSjwP.2gd0GdK Fiv3VPVXzjLNt_Ct6Mjo41vBlzDzqieAmLP6.NmgWC1Je1b..uV_q_gPjXnC 0.xZsG8nw9ijneBmm2zxpbarYP8mPJpyYOz4IMJjsHzp6UuK63ppnPiz9ORB lLfX7IYDZHO1nWw1VjR6qYfRHjsddaeG9O1hAsUABdvKM8fmHKB1Z1_r2ioB abXze1ILODDcrbvg4L9H_2POjp3AVeQdiAW6CrWtXjU.i5tuLjNyf10UI0.W FGWcAY8mDYSP4IThTiNqp6HeHN3v3K1V3UIenMT59EauKSdxp3uv4OclEHvu DSw_J7phJiTSZ3lW92bvaRw4V9061lVm4QGm0rgPagaWML4cB07giYU_aaes ymPSU44TOiejO2vu68_LK0bIr2WJStMdw32qTDLAW3mJXuNeoPG9OE4Trjd0 wJT88PA.1umLk4UNJfaoks5Gf0zTpHJ2Lq0DGTIQbLrE5 Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 01 Aug 2013 21:55:23 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20.Cj4gVG86IElQdjYgPGlwdjZAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IEZyaWRheSwgMiBBdWd1c3QgMjAxMyAzOjExIEFNCj4gU3ViamVjdDogUmU6IFVEUCtGcmFnbWVudGF0aW9uICh3YXM6ICJEZXByZWNhdGUiKQo.IAo.IE9uIFRodSwgMSBBdWcgMjAxMywgUkogQXRraW5zb24gd3JvdGU6Cj4.ICBJIGFncmVlIHRoYXQgQy5NLiBIZWFyZCdzIGlkZWFzIHNob3VsZCBiZSBleHABMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> Message-ID: <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 1 Aug 2013 21:55:23 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: UDP+Fragmentation (was: "Deprecate") To: "C. M. Heard" , IPv6 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 04:55:40 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: C. M. Heard =0A> To: IPv6 =0A> Cc: =0A> Sent: Friday, 2 August 2013= 3:11 AM=0A> Subject: Re: UDP+Fragmentation (was: "Deprecate")=0A> =0A> On = Thu, 1 Aug 2013, RJ Atkinson wrote:=0A>> I agree that C.M. Heard's ideas s= hould be explored=0A>> in more detail by the IETF.=A0 =0A> =0A> Not just m= y suggestion, but other ideas as well:=0A> =0A> - put UDP source and destin= ation ports in a new IPv6 option that and =0A> =A0 add it along with a frag= ment header when fragmenting UDP packets =0A> =A0 (suggested on-list by Mar= k Andrews).=0A> =0A> - generic transport encapsulation within UDP (suggeste= d to me=0A> =A0 off-list by Mark Smith, based on a draft by Stuart Cheshire= =0A> =A0 et. al.).=0A>=A0=0A=0AFor those on the list, the draft I mentione= d was :=0A=0AEncapsulation of TCP and other Transport Protocols over UDP=0A= http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00=0A=0A=0ANote that= this basically proposes translating the TCP header into UDP header fields,= and then for the missing fields, appending them after the UDP header.=A0I = was a bit confused by what was proposed, until I thought about a web server= specifically listening on UDP port 80, knowing that UDP port 80 is TCP ove= r UDP, and then decoding the UDP fields and subsequent fields as a TCP head= er.=0A=0A=0A> - SEAL (suggested on-list by Fred Templin)=0A> =0A>> (I defe= r to the Powers That Be which list that might=0A>> belong to -- TSV WG lis= t might be one option, but=0A>> it is not as likely to have IPv6 operators= as well=0A>> represented as the IPv6 list seems to have.)=0A> =0A> That's= really important -- it doesn't do anyone any good to have a =0A> theoretic= al solution that operators are not willing to deploy.=A0 We =0A> all need t= o work together here.=0A>=A0=0A=0AActually, it has occurred to me that ther= e are two fragmentation related problems, rather than one:=0A=0A(1) fragmen= tation doesn't work reliably=0A=0A(2) fragments can hide transport layer pr= otocol ports, preventing simple ACL filtering etc.=0A=0AThe reaction to (2)= of dropping fragments causes (1).=0A=0AA general solution like SEAL (which= I think in the big picture would be better), probably doesn't solve (2) (I= assume, I've had nothing more than a brief look), so the people who care a= bout (2) won't find SEAL or similar addresses their problem.=0A=0ARegards,= =0AMark. From markzzzsmith@yahoo.com.au Thu Aug 1 23:12:38 2013 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 986FE11E823D for ; Thu, 1 Aug 2013 23:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRdUnkvVY8jC for ; Thu, 1 Aug 2013 23:12:33 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4211E8221 for ; Thu, 1 Aug 2013 23:12:29 -0700 (PDT) Received: from [98.139.212.149] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 02 Aug 2013 06:12:28 -0000 Received: from [98.139.212.194] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Aug 2013 06:12:28 -0000 Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 02 Aug 2013 06:12:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 775083.29147.bm@omp1003.mail.bf1.yahoo.com Received: (qmail 29001 invoked by uid 60001); 2 Aug 2013 06:12:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1375423948; bh=46kUm0AqMZqG/6JvRA6sXVBNUoW5KaYOzx7NvOLU/wo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qQodsNBBUIg0l7UUSA3LpjZLievYTnCRTAtaIu+SCXAfJKCACDJERxdvC4SLStMJ8m1EGhRJq88q6kXK8MN5X8DQVFyLAXOIvUVdTn1ishvwJwgNLrclqirsty9yUedgWq4MplakWBaVtwMTjFEfNHo/E5YKk8bffOnVfSqM244= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wzm7r5Fmei6320lCOQQseozGxk9tuXFHYFMnMP2lA5OE28kzhodauT8wAnPLGM2rzHhE4Ux1K9lXxaDaIdl8if91o8Cx5V0sGoGjzGiHD22hTgxR8eBxlWz7HY+kck5aiQfZ9cBzDOnLmZ5xE4+yUtky4XYAg/OR67LP0hG9mQA=; X-YMail-OSG: ceDH2UcVM1kMoxQrY4zkJYJe_TYc1II_.GPCbSxZANZdxDQ YNoWeHTnhhZDeWIgJmLEcatirA.Dy_Dweqv0uy1IvBNLBa0WR3iUoE6le_gq UWUtbg4B_LWCxqVa3mpEen4IMlsiQJSMYT_PUUvTWjvbX5KdyqhhHlZ_0tI8 d80SU_Je3FRXNR0aJPbasNJmIjQ8orgJdrHoK1xcQXvjsOjgEOc35C7EFixz QWQyiDrTS13gEOb.1qagCfVh5WibxV1ZPUsdpYn.FjjLIomRBazZ22rhn.D5 Z8uMB1HP3WfOCCL_5exWbL7Fa6L2pKMrRkrymB.esSnbzg.3COtZZH8Jb1vi oIOjc.WadcaUOHOTTEiKK34DD9GYpOksHgZs7w4VqH0JiAWZ0r3setaEDWBE _1gWHh3HUiF7mm9mNQUr4__dHO5b51zS.G.klqzdv76TAz9hfIM8ZnjGTExB E6cYdOnTPq9gpyd84RqlPeHWRZhMcejkYY7WJmlmZ6M9rBLTH31ZXFDbJXCC 16bTYem1sTuLbqzzf_7nLeLUa1ZqNRtnbYRNSjpxH9nIy1cgVBCDHWaaDeyg oVVdgw5W8Nh0Y7bKsAUNMpRbNvpZu6ucUUFRbmqEYStY- Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 01 Aug 2013 23:12:28 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBUbzogQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT47IElQdjYgPGlwdjZAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IEZyaWRheSwgMiBBdWd1c3QgMjAxMyAyOjU1IFBNCj4gU3ViamVjdDogUmU6IFVEUCtGcmFnbWVudGF0aW9uICh3YXM6ICJEZXByZWNhdGUiKQo.IAo.IEhpLAo.IAo.IAo.IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPj4gIEYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> Message-ID: <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 1 Aug 2013 23:12:28 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: UDP+Fragmentation (was: "Deprecate") To: Mark ZZZ Smith , "C. M. Heard" , IPv6 In-Reply-To: <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:12:38 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark ZZZ Smith =0A> To: C. M. Heard ; IPv6 =0A> Cc: =0A> Sent: Friday, 2 August 2013 2:55 PM=0A> Subject: Re: UDP+F= ragmentation (was: "Deprecate")=0A> =0A> Hi,=0A> =0A> =0A> ----- Original M= essage -----=0A>> From: C. M. Heard =0A>> To: IPv6 =0A>> Cc: =0A>> Sent: Friday, 2 August 2013 3:11 AM=0A>> Subje= ct: Re: UDP+Fragmentation (was: "Deprecate")=0A>> =0A=0A>> - generic= transport encapsulation within UDP (suggested to me=0A>> =A0 off-list by = Mark Smith, based on a draft by Stuart Cheshire =0A>> =A0 et. al.).=0A>> = =A0=0A> =0A> For those on the list, the draft I mentioned was :=0A> =0A> En= capsulation of TCP and other Transport Protocols over UDP=0A> http://tools.= ietf.org/html/draft-cheshire-tcp-over-udp-00=0A> =0A> =0A> Note that this b= asically proposes translating the TCP header into UDP header =0A> fields, a= nd then for the missing fields, appending them after the UDP header.=A0I = =0A> was a bit confused by what was proposed, until I thought about a web s= erver =0A> specifically listening on UDP port 80, knowing that UDP port 80 = is TCP over UDP, =0A> and then decoding the UDP fields and subsequent field= s as a TCP header.=0A> =0A> =0A=0A=0AAnd actually to better clarify, my (qu= ick) suggestion was to put fragmentation fields after the UDP header, simil= ar to how that draft places the TCP fields after the UDP header. From rbonica@juniper.net Fri Aug 2 00:58:43 2013 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 BB67511E823B for ; Fri, 2 Aug 2013 00:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh38WYcQ-Bva for ; Fri, 2 Aug 2013 00:58:34 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8C21E829F for ; Fri, 2 Aug 2013 00:58:27 -0700 (PDT) Received: from mail230-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Aug 2013 07:58:25 +0000 Received: from mail230-va3 (localhost [127.0.0.1]) by mail230-va3-R.bigfish.com (Postfix) with ESMTP id C0D4E1C00C9 for ; Fri, 2 Aug 2013 07:58:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz9371I542I1432I1418I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail230-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rbonica@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.149; KIP:(null); UIP:(null); (null); H:BY2PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail230-va3 (localhost.localdomain [127.0.0.1]) by mail230-va3 (MessageSwitch) id 137543030438189_13566; Fri, 2 Aug 2013 07:58:24 +0000 (UTC) Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.246]) by mail230-va3.bigfish.com (Postfix) with ESMTP id F08C3BA01E6 for ; Fri, 2 Aug 2013 07:58:23 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 2 Aug 2013 07:58:23 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 00:58:22 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Fri, 2 Aug 2013 00:58:22 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 01:11:18 -0700 Received: from mail30-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Aug 2013 07:58:21 +0000 Received: from mail30-va3 (localhost [127.0.0.1]) by mail30-va3-R.bigfish.com (Postfix) with ESMTP id 4CFB216033D for ; Fri, 2 Aug 2013 07:58:21 +0000 (UTC) Received: from mail30-va3 (localhost.localdomain [127.0.0.1]) by mail30-va3 (MessageSwitch) id 1375430299257510_4296; Fri, 2 Aug 2013 07:58:19 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.229]) by mail30-va3.bigfish.com (Postfix) with ESMTP id 38F16420047; Fri, 2 Aug 2013 07:58:19 +0000 (UTC) Received: from BY2PRD0511HT003.namprd05.prod.outlook.com (157.56.237.149) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 2 Aug 2013 07:58:18 +0000 Received: from BY2PRD0511MB428.namprd05.prod.outlook.com ([169.254.5.72]) by BY2PRD0511HT003.namprd05.prod.outlook.com ([10.255.129.38]) with mapi id 14.16.0341.000; Fri, 2 Aug 2013 07:58:17 +0000 From: Ronald Bonica To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjsRZiYfnka6nOUeBop7mpmo4ZpmBiL2A Date: Fri, 2 Aug 2013 07:58:16 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 02 Aug 2013 07:58:43 -0000 Hi Ran, Thanks for the review. Comments inline..... > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > RJ Atkinson > Sent: Thursday, August 01, 2013 4:35 PM > To: ipv6@ietf.org > Subject: Re: "Deprecate" >=20 > On Tuesday 30th July, Ron Bonica wrote, in part: > > I think that we heard the following at yesterday's meeting: > > > > Title > > =3D=3D=3D=3D=3D > > The document should be renamed "IPv6 Fragmentation Considered > Ineffective" >=20 > That is an improvement because it more accurately describes the content > of the draft. Agree. I think that we should go with Brian's proposed title. >=20 > One might also consider a title that reframed it in terms of advice to > application designers. >=20 > > Deprecation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > All instances of the word "deprecate" should be removed from the > > document. > > > > Therefore: > > -- The document should not request any IANA actions > > -- The document doesn't UDPDATE 2460 > > -- The document doesn't need to be PS. BCP is good enough >=20 > Agree with all of the above. > Either BCP or Informational is fine. Agree >=20 > > Recommendation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Recommendation section should be renamed "Conclusion". > > It should include the following statements: > > > > - The IETF SHOULD NOT standardize an new protocols that > > rely on IPv6 fragmentation >=20 > I think we should allow the IESG/IETF more leeway to handle situations > currently unforeseen. >=20 > So I would suggest an edit along these lines: >=20 > s/rely on IPv6 fragmentation/rely on IPv6 fragmentation if a practical > alternative to fragmentation exists for that protocol./ Also agree. Furthermore, we can now make clear that the two following state= ments regarding *New* applications offer practical alternatives. These are = a) PMTUD/PLMTUD and b) short PDUs >=20 > > ---*New* applications and transport layer protocols SHOULD support > > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is > > unreliable >=20 > Neither approach is 100% reliable in the most general case. >=20 > So, I'd suggest that new apps and transport-layer protocols SHOULD > support both PLMTUD and ICMP-based PMTUD. Supporting both enhances the > chances that some form of Path MTU Discovery will work for a given > session. >=20 How about MUST support PMTUD and SHOULD support PLMTUD, just in case ICMP P= TB is filtered. This statement would make most currently deployed TCP stack= s compliant. So, if a new protocol runs over TCP, it is compliant. > > --*New* applications or transport layer protocols that cannot support > > effective PMTUD MUST NOT in any circumstances send IPv6 packets that > > exceed the IPv6 minimum MTU of 1280 bytes. >=20 > I would change s/MUST NOT/SHOULD NOT/. >=20 > I'd delete the phrase "of 1280 bytes" as well, mainly because it is > redundant, and partly so that this BCP would not need updating if the > 1280 number changed in future. (It has already changed from > unspecified to 576 to 1280 over time.) I think that MUST is OK, so long as we are clear that we are talking about = an application for which IP fragmentation has already been ruled out. >=20 > This document is all good advice, but I know of multiple IPv6 > deployments where PMTUD works quite well. If an application is > deployed in such an environment, and knows that it is (e.g. some > locally-developed application as different from a standard application > such as HTTP), then the application ought to be able to use the IETF > standards-track PMTUD mechanism without violating other IETF standards- > track specifications. Ack. >=20 > > - Legacy applications and transport layer protocols will continue > > to generate fragments >=20 > Since this is basically a document with lots of good advice, I'd also > add some very clear and specific recommendations that middleboxes and > firewalls: >=20 > A) MUST NOT block ICMP-based PMTUD messages where the indicated > link MTU is equal-to or greater-than the standard IPv6 minimum > link MTU. >=20 > B) SHOULD NOT block ICMP-based PMTUD messages where the indicated > link MTU is less than the standard IPv6 minimum link MTU in order > to avoid breaking real-world nested tunnel deployments using > IETF standards-track technologies. >=20 I would say that ICMP PTB messages MUST never be blocked, even if the MTU i= s small. RFC 2460 specifies one corner case where the MTU can be small. >=20 > Discussion: > Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode, > or some other IETF specified technology, are NOT going away. If > the physical MTU is 1280, then the tunnel MTU will be smaller. > Nested tunnels are not unusual and can be difficult to detect > absent a working PMTUD mechanism (whatever that might be). >=20 > Tunnel-based deployments are just as real, and just as unlikely > to disappear, as the current issues with PMTUD deployments. The > document should be clear about this. Yes. Currently the section on Tunnels contains one word of text, "TBD". I w= ill fix that in the next revision. >=20 > > --- In the interest of backwards compatibility, IPv6 stacks and > > forwarding nodes MUST continue to support inbound fragmented IPv6 > > packets as specified in [RFC2460]. >=20 > Yes. In particular, receiving hosts will need to continue to support > IPv6 fragment reassembly for sessions terminating at such hosts. Agree >=20 > > - Implementers and operators need to be aware that on many paths > > through the Internet, IPv6 fragmentation will fail. Legacy > > applications and transport layer protocols that do not conform to the > previous paragraph can expect connectivity failures as a result. >=20 > s/can expect/might experience/ OK Ron >=20 > We don't want to use words that a naive reader/implementer would > misinterpret as consent for violating RFC-2460 et seq. >=20 > > --- Therefore, if a legacy protocol is capable of breaking its > > dependence on IPv6 fragmentation, it should consider doing so. >=20 > Agreed. >=20 > Yours, >=20 > Ran >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nordmark@sonic.net Thu Aug 1 09:01:43 2013 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 1A63621E8088 for ; Thu, 1 Aug 2013 09:01:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUVWJwJuFFKL for ; Thu, 1 Aug 2013 09:01:37 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9FA21E8124 for ; Thu, 1 Aug 2013 09:01:37 -0700 (PDT) Received: from [10.21.120.181] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r71G1RZN011537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 09:01:28 -0700 Message-ID: <51FA8654.4090908@sonic.net> Date: Thu, 01 Aug 2013 18:01:24 +0200 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Keith Moore Subject: Re: ra-privacy: my responses to comments References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> In-Reply-To: <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Aug 2013 01:27:13 -0700 Cc: ipv6@ietf.org, Dave Thaler , Fernando Gont 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, 01 Aug 2013 16:01:43 -0000 On 8/1/13 2:31 PM, Keith Moore wrote: > Hosnieh clarified the slide by explaining that by using "public > addresses" she meant addresses resolvable from DNS lookups. But then > the idea that a node should not use "public addresses" is problematic > for different reasons. Keith, From a terminology perspective we have RFC 4941 defining temporary addresses, but that document doesn't provide a term for the non-temporary addresses. 4941 does have some text saying a "public" (i.e., non-secret) server address, registered in the DNS FWIW RFC 5014 consistently uses "public" to refer to "not temporary". > There are many people (in IETF and elsewhere) who believe that > applications should never use IP addresses directly or in referrals to > other applications. I don't think there is any particular assumption about the role of the DNS (or other registries like SIP proxies) versus IP addresses in referrals in this work. Instead this work is using the terms the same way that RFC 5014 does. Regards, Erik From ietf@rozanak.com Fri Aug 2 01:43:04 2013 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 A775511E82E4 for ; Fri, 2 Aug 2013 01:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23y3iOilaSk5 for ; Fri, 2 Aug 2013 01:42:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0A21E8269 for ; Fri, 2 Aug 2013 01:38:07 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Ma0RD-1UlZ7b1GGt-00LYRF; Fri, 02 Aug 2013 04:38:01 -0400 From: "Hosnieh Rafiee" To: "'Manfredi, Albert E'" , "'Scott Brim'" References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> <51FA6DF8.5040404@internet2.edu> <021E64FECA7E5A4699562F4E667164810B4708D6@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E667164810B4708D6@XCH-PHX-503.sw.nos.boeing.com> Subject: RE: ra-privacy: my responses to comments Date: Fri, 2 Aug 2013 10:37:48 +0200 Message-ID: <003d01ce8f5b$961c8350$c25589f0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbXFc5o58wZih1CtFZfBYjBYLViQJir6nxAh3GifgCQ42DQQH5jmjVAbTXOwMCNzAJYJoCrYOA Content-Language: en-us X-Provags-ID: V02:K0:PIYw2EJNycNQcFCgfreQ4HMx3aCKn32kTpq0EMDhY+B 1EFdY3QT5pPDwsYsL1HI1bGLFvkPR0CZ0NggACYfkKpjsYttFl gW+s4TUcPUEQ/hoADP4FH/uHjbRSQYoxEAs/c8xdmGPM+dcn56 qfgSVXuo96xebfT9zPVOJyjKtBH2T9Z5pN3yK9R594B9wgR7c/ pMQ1F1sq0zyLq4yPpqEFdrvdG+xPKUYIECE3bTCvrWtW4OsDfS k8OjyS6e2RDEp81kDkkHeRXfV6pymN2By+0V4uxg/QbrVR4nbR JLmd6/rrKZbKOiob/2LWpHEZxd8Wlz1sEPyv7uK39pAXn5zbed 1sMhaLnIxK7ZvRC85VZw= Cc: ipv6@ietf.org, Keith Moore 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, 02 Aug 2013 08:43:04 -0000 Hi, Thanks for your comments. > > > "peer" is also a nit - if you > > want an unknown someone to be able to contact you, you need to make > > yourself findable, whether the protocol design is p2p or not. > > Otherwise you don't. > > I also object to the notion that every host or application should be identified by > name and not by address. In a peer to peer network, the peers can certainly > have the other peers' IP addresses known to them. You don't need a DNS at all, > in situations like this. > > Matter of fact, I would suggest that the Client Identifier Option of DHCP is > precisely for such scenarios. Where the unconfigured peer needs to be given a > specific IP address, because that's the only way the other peers can find it. > DHCPv6 is another approach to generate an IID. So, the choice of using DNS name is out of scope of ra-privacy document. In ra-privacy draft, we explained that having a DNS names (not local names)/ public names would have a negative effect on user's privacy. This is why, the node "should" not have public addresses(that has public DNS names) if it cares about privacy. But also we explained that if a node wants to have public addresses, it "must" not generate it based on MAC..[..]. Our reason: you usually don't have public DNS names for your clients and you usually use it for your host. Some says that you should not separate the type of nodes (clients or servers...) and so you should not use "should" for this case. So, I agreed that I can use "recommended" or "might" and then explain the circumstances of having public DNS names. Thanks, Hosnieh From he@uninett.no Fri Aug 2 01:52:06 2013 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 50CF121F9D7B for ; Fri, 2 Aug 2013 01:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxoc9Gr3yPpg for ; Fri, 2 Aug 2013 01:51:50 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id DBA7B11E81B0 for ; Fri, 2 Aug 2013 01:48:14 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 3F3B33D0B3; Fri, 2 Aug 2013 10:48:12 +0200 (CEST) Date: Fri, 02 Aug 2013 10:48:12 +0200 (CEST) Message-Id: <20130802.104812.224186382.he@uninett.no> To: rja.lists@gmail.com Subject: Re: "Deprecate" From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 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: Fri, 02 Aug 2013 08:52:07 -0000 >> Title >> =3D=3D=3D=3D=3D >> The document should be renamed "IPv6 Fragmentation Considered Ineffe= ctive" > > That is an improvement because it more accurately describes = > the content of the draft. I'm not entirely certain I agree. The suggested title indicates admittance of defeat against mis-configured middleboxes and over- paranoid network administrators, and an implicit willingness to surrender the authority to define our protocols. I'm at the moment not entirely certain I have a suggested alternative title; I may need to give that a bit of thought. Something perhaps about "deployment considerations"? >> - Legacy applications and transport layer protocols will continue >> to generate fragments > > Since this is basically a document with lots of good advice, = > I'd also add some very clear and specific recommendations that = > middleboxes and firewalls: > > A) MUST NOT block ICMP-based PMTUD messages where the indicated > link MTU is equal-to or greater-than the standard IPv6 minimum > link MTU. > > B) SHOULD NOT block ICMP-based PMTUD messages where the indicated > link MTU is less than the standard IPv6 minimum link MTU in order > to avoid breaking real-world nested tunnel deployments using > IETF standards-track technologies. Yes, please, thank you! Much throughout this discussion there seems to have been a lack of will to retain the authority to define the protocols with the IETF, and I see the above two points as good steps to amend that on this particular issue. >> - Implementers and operators need to be aware that on many paths >> through the Internet, IPv6 fragmentation will fail. Legacy >> applications and transport layer protocols that do not conform to >> the previous paragraph can expect connectivity failures as a >> result. > > s/can expect/might experience/ > > We don't want to use words that a naive reader/implementer > would misinterpret as consent for violating RFC-2460 et seq. For basically the same reasons as above, I agree with this change. Best regards, - H=E5vard From ietf@rozanak.com Fri Aug 2 02:06:00 2013 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 40B9B21E82B7 for ; Fri, 2 Aug 2013 02:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2kxR0kY-Jxm for ; Fri, 2 Aug 2013 02:05:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A2EEA21E82BA for ; Fri, 2 Aug 2013 01:59:53 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Ln8jt-1UQKcb2qej-00hKA7; Fri, 02 Aug 2013 04:59:52 -0400 From: "Hosnieh Rafiee" To: "'Keith Moore'" References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <000001ce8ef7$b9ae0960$2d0a1c20$@rozanak.com> <55FB9711-5D28-4C17-9C81-5D41E5110C5C@network-heretics.com> In-Reply-To: <55FB9711-5D28-4C17-9C81-5D41E5110C5C@network-heretics.com> Subject: RE: ra-privacy: my responses to comments Date: Fri, 2 Aug 2013 10:59:41 +0200 Message-ID: <003f01ce8f5e$a3cad580$eb608080$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbXFc5o58wZih1CtFZfBYjBYLViQJir6nxAGte21oB5gOSv5pCYKBg Content-Language: en-us X-Provags-ID: V02:K0:xRSrcvwMI9LN86Voht33B1FQ14nz9qKPXAaTHxBRe4s 8DgtEz2mdgVQsMnyrqBYNTWfYvV+mxPWT+D6vr1fVmIXq3ANV4 loZ1VtHIK1FxDeAoV5mz8y/gpTuaArIjljnBIvZ3ByKnAmsgNm rrD9vsteVQjwEMb4yqO8kUkfMBspMXWWG6k5xV1iVQMG7I8K1g EATC+xPA2b6ogmWS+RW+WXRzZ8hZeRIpygVqdsKKi5U7YfA7Qk cU+QstztHDfzyLoKEbrTYu7cNzNnzPDD0rCH8IAgIuL0+KeOKf E/6MUWoSJLfY/V1lTGOKuhHWKku08uItk6BrEwoMEnGXvQQWRM vNRN+JB7Gly8VRsvC9Qc= Cc: ipv6@ietf.org, Dave Thaler 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, 02 Aug 2013 09:06:00 -0000 Hi, Again Thanks for your comments. > I do think it might be useful to recommend that DNS servers be configured as to > refuse requests to list DNS zones as a means to thwart attackers from looking > for IPv6 addresses. But assuming that such listing is disabled, I don't know why > listing a host's address in DNS would make that host a more likely target for > attack. In other words, why is DNS name probing any more feasible of an > attack than IPv6 address probing? To do brute force scanning, you need to do brute force attacks against 2^64 addresses which might take years! If you are in the same LAN or can eavesdrops ICMPv6 messages exchanged among nodes or send ICMPv6 messages, then you can also find nodes. But if you are not access to these capabilities, the best next option is guessing and using DNS servers. If DNS is not secure then you can spoof the source IP address of the legitimate DNS server and ask for axfr. If it is secure then there are other ways to attack DNS server and obtain nodes that I explained in my other message. There is other way also to have a website that use it as a honey pot in order to store IP addresses of nodes. However, it might not occurrence because of NAT and many other reasons. Thanks, Best, Hosnieh From arturo.servin@gmail.com Fri Aug 2 02:06:52 2013 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 D2D3511E8167 for ; Fri, 2 Aug 2013 02:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHWh0460i+3N for ; Fri, 2 Aug 2013 02:06:50 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6B11E8269 for ; Fri, 2 Aug 2013 02:01:50 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so455759pab.1 for ; Fri, 02 Aug 2013 02:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ztZ/LxfOAsla3u2ENyJFkeBQzveh65OSpkggJaF3j8o=; b=fynIaqrf3sthID0QrXR923RQqpovDFOS3zHW0x5pq9IY4ewgNIL/U24QR0QullxaBU FY65JVbAt+pJGOYBQIiHExBov86MNPE0UcFmNpwmutIojaBrCCBqFgww6aVR5AZv1Rmm wU6UFewEyHbrcLsCFn+do1/Yz5G/Tp3Ncl4KqkEWLTvcn5oNfjllcml1OVuEk6rnu4sO ZeCzS2XdvmYP6H3jjp+tZkuBJV+1hKKRmoaU/JwQosWnz0PYhRbRNRV2AszhYBrwuzm4 u5ygU2JH0YlrRSLddNXyWxDxk6HzAjHaUbyQ3crYfM1N6KakW3uOeUSU6nISMLZpBLu0 WXRw== X-Received: by 10.68.239.66 with SMTP id vq2mr6494136pbc.182.1375434102765; Fri, 02 Aug 2013 02:01:42 -0700 (PDT) Received: from dhcp-156a.meeting.ietf.org ([2001:df8:0:16:da1:de39:fc54:e86a]) by mx.google.com with ESMTPSA id sp4sm9022709pbc.45.2013.08.02.02.01.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 02:01:41 -0700 (PDT) Message-ID: <51FB7575.6050904@gmail.com> Date: Fri, 02 Aug 2013 11:01:41 +0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: "Deprecate" References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180D66E2@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713E52@BY2PRD0511MB428.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2512713E52@BY2PRD0511MB428.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Maintanence , Bob Hinden , "Fred Baker \(fred\)" 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, 02 Aug 2013 09:06:52 -0000 They aren't. There are still many places where I come from where operators do not support native IPv6 and people need to rely in tunnels to start trying IPv6. Regards, as On 7/30/13 11:55 PM, Ronald Bonica wrote: > Fred, > > I was thinking of tunnels as legacy applications, but we may need to make this explicit. > > Ron From randy@psg.com Fri Aug 2 02:13:15 2013 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 CD26C11E8210 for ; Fri, 2 Aug 2013 02:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBMaGzu7CroR for ; Fri, 2 Aug 2013 02:13:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7B011E831C for ; Fri, 2 Aug 2013 02:10:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V5BNB-0002oE-OZ; Fri, 02 Aug 2013 09:10:10 +0000 Date: Fri, 02 Aug 2013 11:10:12 +0200 Message-ID: From: Randy Bush To: Arturo Servin Subject: Re: "Deprecate" In-Reply-To: <51FB7575.6050904@gmail.com> References: <8C48B86A895913448548E6D15DA7553B963A9D@xmb-rcd-x09.cisco.com> <33F639DD-2CD8-4580-A0C8-F63068497BEA@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713455@BY2PRD0511MB428.namprd05.prod.outlook.com> <2134F8430051B64F815C691A62D983180D66E2@XCH-BLV-504.nw.nos.boeing.com> <2CF4CB03E2AA464BA0982EC92A02CE2512713E52@BY2PRD0511MB428.namprd05.prod.outlook.com> <51FB7575.6050904@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention 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, 02 Aug 2013 09:13:15 -0000 > There are still many places where I come from where operators do not > support native IPv6 and people need to rely in tunnels to start trying > IPv6. in this case. ipv6 is *inside* the tunnel so, unless you are one of the sickies who think ipv4 inside mpls inside ipv6 inside ipv4 inside gre inside a chocolate bar is rational, this is a bit of a non sequitur randy From ietf@rozanak.com Fri Aug 2 02:44:56 2013 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 2C97311E8308 for ; Fri, 2 Aug 2013 02:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geuCzoDetlMC for ; Fri, 2 Aug 2013 02:44:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C10E011E812C for ; Fri, 2 Aug 2013 02:44:37 -0700 (PDT) Received: from kopoli (dhcp-1698.meeting.ietf.org [130.129.22.152]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MTj7Q-1UegnG1nF2-00QOja; Fri, 02 Aug 2013 05:44:29 -0400 From: "Hosnieh Rafiee" To: "'Keith Moore'" References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA61E8.6040909@internet2.edu> <000601ce8ebd$a3fd9070$ebf8b150$@rozanak.com> <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> In-Reply-To: <9A40F508-4924-4836-BF4E-80DCF46D3BDE@network-heretics.com> Subject: RE: ra-privacy: my responses to comments Date: Fri, 2 Aug 2013 11:44:14 +0200 Message-ID: <006701ce8f64$deac04c0$9c040e40$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbXFc5o58wZih1CtFZfBYjBYLViQJir6nxAh3GifgCQ42DQQH5jmjVmiIjIvA= Content-Language: en-us X-Provags-ID: V02:K0:MuL6yROEKuqdpGbiBXPDS7glrn9wOCCLaxaxVxAT0Ai Lpou2SPJE187WwUdKTYcsxnRfRMA3rKQB8vD08mtj9rGg0Rx/5 3zyz2Le9s9xDhHO3tE0p386Np4xiwbCcmlbI/naXOGmENsdZW2 Z4LxjItr6S4Pcq2qo+eqx05+MI1lSBd8gqQJ0bkisyj2kYIGpV vrV2yA1uzJBt+Ap6I6UkSiU+OMQ8eF5ryZELgsJ7+zHG4ovSnb hW93pmP66Rc1Mv+FK5oDsqdm8PeY0xAllTYqX0b/0n5O5TURFJ 3M/0hfu5ldQjDVbIE/uTWqPA93oDqbnT4xr8ovD0wKZ5EeJ0Zx CZisRzR0Ra7/SljrWtH8= Cc: ipv6@ietf.org, 'Scott Brim' , 'Fernando Gont' , 'Dave Thaler' 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, 02 Aug 2013 09:44:56 -0000 Hi, Thank you so much. >I recommend removing the text, or replacing it with something like "The choice of whether to list a node's address in DNS properly depends on = many factors, including the set of >applications to be run on the host. =A0 = Not listing a node's address in the public DNS may increase the node's = privacy, but may also impair its ability to support certain applications." Ok. Thanks. Best, Hosnieh From Francis.Dupont@fdupont.fr Fri Aug 2 03:55:13 2013 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 B9D9221E82DB for ; Fri, 2 Aug 2013 03:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXMdFPEZfgFl for ; Fri, 2 Aug 2013 03:55:11 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED4311E8251 for ; Fri, 2 Aug 2013 03:55:09 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r72At3YS042894; Fri, 2 Aug 2013 12:55:03 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201308021055.r72At3YS042894@givry.fdupont.fr> From: Francis Dupont To: Mark Andrews Subject: Re: "Deprecate" In-reply-to: Your message of Fri, 02 Aug 2013 10:35:47 +1000. <20130802003547.71BB137EE821@drugs.dv.isc.org> Date: Fri, 02 Aug 2013 12:55:03 +0200 Sender: Francis.Dupont@fdupont.fr Cc: RJ Atkinson , "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, 02 Aug 2013 10:55:14 -0000 In your previous mail you wrote: > And if we generate appoximately equal sized fragments rather than > 1280 byte fragments + a runt fragment tunnels would need to fragment > less often. Your 1500 byte UDP payloads become 2 x 750 byte fragments > which can be encapulated multiple times. => I did this for the ISC AFTR code (the partner asked for). > It doesn't take a lot of math to work out what size to fragment at to > produce optimal fragment sizes for a given MTU. => yes, it is not hard even the alignment constraints are not too easy to handle (I coded it in two parts, first compute an ideal fragment size, second integrate alignment constraints to produce fragments with the same size at the exception of the last one). I didn't see a huge difference but it looks better on the wire, no tiny last fragement for instance... Regards Francis.Dupont@fdupont.fr From rja.lists@gmail.com Fri Aug 2 05:06:03 2013 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 44CE911E8347 for ; Fri, 2 Aug 2013 05:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+dEz1nGf1n5 for ; Fri, 2 Aug 2013 05:05:51 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8A11E82BE for ; Fri, 2 Aug 2013 05:05:50 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id s11so264675qcv.6 for ; Fri, 02 Aug 2013 05:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=bpBkBISX3ymeAR+sm+XVQo+oS1xKcXGyWlwEnRTiYWE=; b=P5/pTYaZPvIZzYYheaIz7lqm0peAvVVtUe2sx68PHIAvgg30YmW20GGTGyae3bJImi MJLPOYzteHrntRduzTuZ5IH88FciJ8XAkckynh5kKusDpeN6BANUCc7tLdR1SrgjNTeO VDWNFrHm0OBNXKqd23irVDQe4APgsErrvNAe+TxBf+Xd9o3bz55LaZSpuADrIQyeSGeg lWiSoTBw1nV7DS4c9d46nRFElPWpiaCD+wgojaqIO6jRECOk68qocjFvGjzJAkbKjyPg FZsOBjn0poBqCu9CRCpcNRL8wW1x/DviYOPPncpR6qAWlKNR8TgIyCeq3/MqJagCB+il Xj4g== X-Received: by 10.224.5.7 with SMTP id 7mr10488231qat.61.1375445150336; Fri, 02 Aug 2013 05:05:50 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id n16sm12456073qae.8.2013.08.02.05.05.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 05:05:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: "Deprecate" From: RJ Atkinson In-Reply-To: <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 2 Aug 2013 08:05:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) 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, 02 Aug 2013 12:06:03 -0000 On 01 Aug 2013, at 18:40 , Templin, Fred L wrote: >> If the physical MTU is 1280, then the tunnel MTU will be smaller. > > Not allowed; the tunnel MUST be able to do a minimum 1280. A number of nested tunnel deployments that I'm aware of simply do not support that 1280 MTU inside the innermost tunnel -- because of accumulated tunnel encapsulation overhead. Those nested tunnel deployments are just as real as the PMTUD operational issues. Each is applicable to some environments, but not necessarily to all paths and all deployments. If this document is to be reality-based, we need to acknowledge all of the operational realities that have an impact on this topic, not just acknowledge some of the operational realities. Yours, Ran From rja.lists@gmail.com Fri Aug 2 05:12:10 2013 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 DF5FA11E8313 for ; Fri, 2 Aug 2013 05:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZrBY57-cTYC for ; Fri, 2 Aug 2013 05:12:07 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB8211E8357 for ; Fri, 2 Aug 2013 05:11:54 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so265547qab.4 for ; Fri, 02 Aug 2013 05:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=msPY6ynHn9clqRipCJxhPDneyzP6puAeuyVLBXyHEoE=; b=h/fLs0YjdIc91mV+OTEQ/5TqhbnjySQSk+kdvwbkHuWFnvev2tIA4N2x2YkrHTsgL5 CN6Ejo4lrh3tHt8q4DO/pYNBDauC4cJUAIPpsZDeuCGhHx1JjE6O6dwkiFtUYuskDyK8 W8bpE+iKH5WC6ThABb2h5V/eHkBvBoU7x341oOPR3YCuA5SvHoUQnuSpLmFvMLew9hhe jcvm23fD+R03+z32znX8yE5F1AH9W7EIW4WHXMWMXPUQ9brJbGvazcabnpYLGodrFV18 nCdeemzvTom3GPGTEb89UqpnxyBXv8bUyXCElQ64WY/RRlP4W1gmehCTvqrrvfB3FInP YaCg== X-Received: by 10.49.49.8 with SMTP id q8mr8503330qen.47.1375445513779; Fri, 02 Aug 2013 05:11:53 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id om8sm1497535qeb.4.2013.08.02.05.11.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 05:11:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: "Deprecate" From: RJ Atkinson In-Reply-To: <20130802003547.71BB137EE821@drugs.dv.isc.org> Date: Fri, 2 Aug 2013 08:11:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: <66F97631-921B-49B2-9CCC-A1DB23F323F5@gmail.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> <20130802003547.71BB137EE821@drugs.dv.isc.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) 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, 02 Aug 2013 12:12:10 -0000 On 01 Aug 2013, at 20:35 , Mark Andrews wrote: > And if we generate appoximately equal sized fragments > rather than 1280 byte fragments + a runt fragment, > tunnels would need to fragment less often. Your 1500 byte > UDP payloads become 2 x 750 byte fragments which can be > encapsulated multiple times. > > It doesn't take a lot of math to work out what size > to fragment at to produce optimal fragment sizes > for a given MTU. All of the above seems like practical advice that should be considered for inclusion in this document. (NB: I still would like to see C. M. Heard's ideas explored in more detail by the IETF as they remain interesting and possibly very useful even if the above suggestions are implemented and deployed. :-) Yours, Ran From rja.lists@gmail.com Fri Aug 2 05:35:42 2013 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 20C7A11E833C for ; Fri, 2 Aug 2013 05:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRpyMsEUp-Bi for ; Fri, 2 Aug 2013 05:35:41 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8615B11E8319 for ; Fri, 2 Aug 2013 05:34:32 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so283633qcx.18 for ; Fri, 02 Aug 2013 05:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=UKQ1iZOfKCBMImODAtUdj8GOniYaeUKZFXxxLbcip0s=; b=p/7Zv9sW1MVt3n/d+xISFO/FEd5aD1/rOj2OyNvChBYuLyruBv5j2SmJte1pFRwknz CkH/rPkAKd71+gVeN4nXzGwhgbOIPWCLJs1sdjIniubRZ/ElYOMjeisZPga7y/Xrb1XE KUkFdWzDVQ02zcpGzYIufg9vNrzq1lUqnnSvHh6uybv3rlJS5UAnCXRkpsZ7cY8k0jJ+ rAz7/1m9Yu9IdKLtBZNt0+jAuZvihO1KdV3qH3SUMDs0BcKEVCVQ1NdPNHe7PDKJAbwY e402S2zGCuqFh5W/dYnRv1OVl9Hb4Xru9N0km3IsdsxmlND8tTt4ocejD3x1aACt2VeK Ynnw== X-Received: by 10.224.53.196 with SMTP id n4mr10551954qag.104.1375446868919; Fri, 02 Aug 2013 05:34:28 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id e8sm1358018qai.1.2013.08.02.05.34.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 05:34:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: "Deprecate" From: RJ Atkinson In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> Date: Fri, 2 Aug 2013 08:34:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) 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, 02 Aug 2013 12:35:42 -0000 On 02 Aug 2013, at 03:58 , Ronald Bonica wrote: > Furthermore, we can now make clear that the two following > statements regarding *New* applications offer practical > alternatives. >=20 > These are: > a) PMTUD/PLMTUD > and b) short PDUs Agree. I am reluctant to say that any of those are sufficient in all deployments, because there are too many IPv6 deployments to evaluate, but clearly each of those mechanisms can be useful. > How about: > MUST support PMTUD and SHOULD support PLMTUD, > just in case ICMP PTB is filtered. Fine. "MUST support PMTUD" and "SHOULD support PLMTUD". >> I would change s/MUST NOT/SHOULD NOT/. >>=20 >> I'd delete the phrase "of 1280 bytes" as well, mainly because it is >> redundant, and partly so that this BCP would not need updating if the >> 1280 number changed in future. (It has already changed from >> unspecified to 576 to 1280 over time.) >=20 > I think that MUST is OK, so long as we are clear that we are talking > about an application for which IP fragmentation has already been > ruled out. I'd like to read the draft text in an I-D first. > I would say that ICMP PTB messages MUST never be blocked, > even if the MTU is small. RFC 2460 specifies one corner case > where the MTU can be small. Agree. Fernando has identified some scenarios where the advertised=20 MTU will be smaller than 1280. Additionally, I've seen some other=20 real-world scenarios where it happens. So, I'd suggest that the document outline several scenarios where the MTU can be small, so that implementers and operators reading the document will realise that smaller MTUs can appear in the wild. > Yes. Currently the section on Tunnels contains one word of text, > "TBD". I will fix that in the next revision. =46rom an implementation perspective, most often it is expensive & complex for a tunnel endpoint reassemble transit fragments. =20 In the current global Internet, few router implementers are=20 comfortable trying to reassemble anywhere in the middle of the=20 path, in part because of the additional attack surface that reassembling transit traffic would create. Instead, at tunnel egress, any fragments are likely to be=20 merely decapsulated and then forwarded. So, it is critical=20 that end systems be able to reassemble fragments as fragments=20 will continue to exist in the real world. Yours, Ran From Fred.L.Templin@boeing.com Fri Aug 2 07:54:34 2013 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 B06FB11E8106 for ; Fri, 2 Aug 2013 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoOhkp7rWi44 for ; Fri, 2 Aug 2013 07:54:25 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id E1A0011E80EC for ; Fri, 2 Aug 2013 07:54:24 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r72EsNPc029110 for ; Fri, 2 Aug 2013 07:54:24 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r72EsLir029078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 2 Aug 2013 07:54:22 -0700 Received: from XCH-BLV-401.nw.nos.boeing.com (130.247.25.18) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 2 Aug 2013 07:54:21 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.219]) with mapi id 14.02.0328.011; Fri, 2 Aug 2013 07:54:20 -0700 From: "Templin, Fred L" To: Mark Andrews Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOjxg6iYfnka6nOUeBop7mpmo4ZpmCAPYQ Date: Fri, 2 Aug 2013 14:54:20 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DD8C6@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> <20130802003547.71BB137EE821@drugs.dv.isc.org> In-Reply-To: <20130802003547.71BB137EE821@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org" , RJ Atkinson 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, 02 Aug 2013 14:54:34 -0000 Hi Mark, > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Thursday, August 01, 2013 5:36 PM > To: Templin, Fred L > Cc: RJ Atkinson; ipv6@ietf.org > Subject: Re: "Deprecate" >=20 >=20 > In message <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV- > 504.nw.nos.boeing.co > m>, "Templin, Fred L" writes: > > Hi Ran, > > > > > Discussion: > > > Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel- > mode, > > > or some other IETF specified technology, are NOT going away. > > > > Yes, this is the same as I and others have been saying all along. > > > > > If the physical MTU is 1280, then the tunnel MTU will be smaller. > > > > Not allowed; the tunnel MUST be able to do a minimum 1280. > > > > > Nested tunnels are not unusual and can be difficult to detect > > > absent a working PMTUD mechanism (whatever that might be). > > > > Agree that nested tunnels are not unusual and are in fact in > > common widespread deployment. But, there is no need to "detect" > > them from the source host's perspective as long as they honor > > the IPv6 1280 minMTU. That means that tunnels MUST be prepared > > to do a small amount of fragmentation and reassembly when > > necessary. >=20 > And if we generate appoximately equal sized fragments rather than > 1280 byte fragments + a runt fragment tunnels would need to fragment > less often. Your 1500 byte UDP payloads become 2 x 750 byte fragments > which can be encapulated multiple times. Yes, SEAL covers this in earlier document versions. "Approximately equal length is what it used to say; now it says: " breaks the inner packet into N non-overlapping segments (where N is minimized and each segment is significantly smaller than (MINMTU-HLEN) to allow for additional encapsulations in the path)." but I can modify this to say: "in N approximately equal length non-overlapping segments" to bring back what I had in earlier versions. Thanks - Fred fred.l.templin@boeing.com > It doesn't take a lot of math to work out what size to fragment at to > produce optimal fragment sizes for a given MTU. >=20 > Mark >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Fred.L.Templin@boeing.com Fri Aug 2 08:04:59 2013 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 78A9711E80FA for ; Fri, 2 Aug 2013 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0rWwLeUKt3S for ; Fri, 2 Aug 2013 08:04:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29011E80E7 for ; Fri, 2 Aug 2013 08:04:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r72F4r1o027852 for ; Fri, 2 Aug 2013 08:04:53 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r72F4rsX027847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 2 Aug 2013 08:04:53 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (130.247.25.157) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 2 Aug 2013 08:04:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.38]) with mapi id 14.02.0328.011; Fri, 2 Aug 2013 08:04:52 -0700 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOj3igiYfnka6nOUeBop7mpmo4ZpmCA2zQ Date: Fri, 2 Aug 2013 15:04:52 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DD8F5@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 02 Aug 2013 15:04:59 -0000 Hi Ran, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > RJ Atkinson > Sent: Friday, August 02, 2013 5:06 AM > To: ipv6@ietf.org > Subject: Re: "Deprecate" >=20 >=20 > On 01 Aug 2013, at 18:40 , Templin, Fred L wrote: > >> If the physical MTU is 1280, then the tunnel MTU will be smaller. > > > > Not allowed; the tunnel MUST be able to do a minimum 1280. >=20 > A number of nested tunnel deployments that I'm aware of > simply do not support that 1280 MTU inside the innermost > tunnel -- because of accumulated tunnel encapsulation > overhead. If you mean an innermost IPv4 tunnel, I have certainly seen that with IPv4 GRE within IPsec. If you mean an innermost IPv6 tunnel, that is broken as far as the specs are concerned. The innermost tunnel is not allowed to send a PTB reporting an MTU size smaller than 1280. Thanks - Fred fred.l.templin@boeing.com > Those nested tunnel deployments are just as real as the PMTUD > operational issues. Each is applicable to some environments, > but not necessarily to all paths and all deployments. >=20 > If this document is to be reality-based, we need to acknowledge > all of the operational realities that have an impact on this topic, > not just acknowledge some of the operational realities. >=20 > Yours, >=20 > Ran >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Fri Aug 2 08:41:21 2013 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 CA7D211E80EE for ; Fri, 2 Aug 2013 08:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ3onHoWEmyx for ; Fri, 2 Aug 2013 08:41:15 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 9114E11E80D3 for ; Fri, 2 Aug 2013 08:41:15 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r72FfCvX027607 for ; Fri, 2 Aug 2013 08:41:12 -0700 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r72FfBnD027584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 2 Aug 2013 08:41:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.81]) with mapi id 14.02.0328.011; Fri, 2 Aug 2013 08:41:13 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOj3igiYfnka6nOUeBop7mpmo4ZpmCA2zQgAAJCgA= Date: Fri, 2 Aug 2013 15:41:13 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DD972@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180DD8F5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180DD8F5@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 02 Aug 2013 15:41:21 -0000 Hi, Up to now, the SEAL spec has focused on "tunnel mode", and had the singular statement: "(A transport-mode of operation is also possible, but out of scope for this document.)" in the introduction. (Indeed, the first edition of SEAL (RFC5320) did specify a transport mode of operation, but that document will be obsolete by the second edition.) So, in light of these discussions I decided that now might be a good time to bring transport mode back into scope and as such have added the following new section to the document. Please send comments and suggestions. I will post a new draft version by the end of the day that will include both tunnel and transport modes. Thanks - Fred fred.l.templin@boeing.com 6. SEAL Transport Mode Specification SEAL is also used for transport-mode operation. Transport mode refers to a SEAL encapsulation in which a layer-4 header appears immediately following the SEAL header. The type of layer-4 header is indicated in the "NEXTHDR" field the same as for tunnel mode. The SEAL header is identical to the version used for tunnel mode, except that the "LINK_ID" and "LEVEL" fields are omitted, and the transport layer port numbers are included in each non-initial segment (see: Figure 6). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEXTHDR |VER|C|P|I|V|R|M| Offset | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port (when Offset!=3D0) | Dest Port (when Offset!=3D0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Vector (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 6: SEAL Header Format The "Source Port" and "Dest Port" are taken from the corresponding fields in the transport layer next header that appears immediately following the SEAL header in the initial segment. For example, for UDP [RFC0768] the transport layer source/dest ports are 16 bits in length and are copied from the transport layer header. All segmentation is exactly as specified in SEAL tunnel mode, and the SEAL Control Message Protocol (SCMP) operates the same as for tunnel mode. For example, the source node can probe the path MTU to the destination by setting the P bit in a probe packet and waiting for an acknowledgement from the destination. SEAL transport mode is useful for transport layer protocols that have no way to segment the large packets they send. It is a universal format that can be applied to any such transport. From Fred.L.Templin@boeing.com Fri Aug 2 08:59:40 2013 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 749C221E80C2 for ; Fri, 2 Aug 2013 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slSse+t7ESlp for ; Fri, 2 Aug 2013 08:59:35 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83721E80BD for ; Fri, 2 Aug 2013 08:59:35 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r72FxYXD001931 for ; Fri, 2 Aug 2013 08:59:35 -0700 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r72FxYNQ001922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 2 Aug 2013 08:59:34 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.44]) with mapi id 14.02.0328.011; Fri, 2 Aug 2013 08:59:34 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOj3igiYfnka6nOUeBop7mpmo4ZpmCA2zQgAAJCgCAAAbWgA== Date: Fri, 2 Aug 2013 15:59:33 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DD9BF@XCH-BLV-504.nw.nos.boeing.com> References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180DD8F5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180DD972@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180DD972@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 02 Aug 2013 15:59:40 -0000 One other thing to add: "SEAL transport mode implementations SHOULD configure reassembly buffers that are large enough to accommodate a maximum-sized SEAL packet, i.e., they SHOULD configure a 64KB reassembly buffer size." Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Friday, August 02, 2013 8:41 AM > To: ipv6@ietf.org > Subject: RE: "Deprecate" >=20 > Hi, >=20 > Up to now, the SEAL spec has focused on "tunnel mode", and had the > singular statement: >=20 > "(A transport-mode of operation is also possible, but out of scope > for this document.)" >=20 > in the introduction. (Indeed, the first edition of SEAL (RFC5320) > did specify a transport mode of operation, but that document will > be obsolete by the second edition.) So, in light of these discussions > I decided that now might be a good time to bring transport mode back > into scope and as such have added the following new section to the > document. Please send comments and suggestions. I will post a new > draft version by the end of the day that will include both tunnel > and transport modes. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > 6. SEAL Transport Mode Specification >=20 > SEAL is also used for transport-mode operation. Transport mode > refers to a SEAL encapsulation in which a layer-4 header appears > immediately following the SEAL header. The type of layer-4 header > is > indicated in the "NEXTHDR" field the same as for tunnel mode. The > SEAL header is identical to the version used for tunnel mode, except > that the "LINK_ID" and "LEVEL" fields are omitted, and the transport > layer port numbers are included in each non-initial segment (see: > Figure 6). >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NEXTHDR |VER|C|P|I|V|R|M| Offset | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Port (when Offset!=3D0) | Dest Port (when Offset!=3D0) = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Integrity Check Vector (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... >=20 > Figure 6: SEAL Header Format >=20 > The "Source Port" and "Dest Port" are taken from the corresponding > fields in the transport layer next header that appears immediately > following the SEAL header in the initial segment. For example, for > UDP [RFC0768] the transport layer source/dest ports are 16 bits in > length and are copied from the transport layer header. All > segmentation is exactly as specified in SEAL tunnel mode, and the > SEAL Control Message Protocol (SCMP) operates the same as for tunnel > mode. For example, the source node can probe the path MTU to the > destination by setting the P bit in a probe packet and waiting for > an > acknowledgement from the destination. >=20 > SEAL transport mode is useful for transport layer protocols that > have > no way to segment the large packets they send. It is a universal > format that can be applied to any such transport. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jtatuya@infoblox.com Fri Aug 2 09:13:02 2013 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 CB8D621E80CF for ; Fri, 2 Aug 2013 09:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4+eufBZpHSg for ; Fri, 2 Aug 2013 09:12:58 -0700 (PDT) Received: from mx1.infoblox.com (mx1.infoblox.com [205.234.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4126321E804C for <6man@ietf.org>; Fri, 2 Aug 2013 09:12:58 -0700 (PDT) X-ASG-Debug-ID: 1375459285-0454fc63da9b9f0001-V1QpKo Received: from x2008hub1.infoblox.com (x2008hub1.infoblox.com [205.234.19.248]) by mx1.infoblox.com with ESMTP id 1N1VYKWAjOGqCpQY; Fri, 02 Aug 2013 09:01:25 -0700 (PDT) X-Barracuda-Envelope-From: jtatuya@infoblox.com X-Barracuda-Apparent-Source-IP: 205.234.19.248 Received: from jinmei-mbp.infoblox.com (10.102.29.200) by x2008hub1.infoblox.com (10.120.3.105) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 2 Aug 2013 09:01:24 -0700 Date: Fri, 2 Aug 2013 09:01:24 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Ralph Droms (rdroms)" Subject: Re: New Version Notification for draft-droms-6man-multicast-scopes-02.txt In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA37C9AE4@xmb-aln-x04.cisco.com> X-ASG-Orig-Subj: Re: New Version Notification for draft-droms-6man-multicast-scopes-02.txt References: <20130730143843.19014.69414.idtracker@ietfa.amsl.com> <4518F39EB578034D8C99A9B7776CDBA37C9AE4@xmb-aln-x04.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.102.29.200] X-Barracuda-Connect: x2008hub1.infoblox.com[205.234.19.248] X-Barracuda-Start-Time: 1375459285 X-Barracuda-URL: http://205.234.19.209:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at infoblox.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.137570 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "6man@ietf.org" <6man@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, 02 Aug 2013 16:13:02 -0000 At Tue, 30 Jul 2013 14:42:28 +0000, "Ralph Droms (rdroms)" wrote: > This rev includes the fixes discussed and agreed to in the 6man WG meeting on 7/29: I'm not sure if this version addresses the second comment of mine on the 00 version, which you seem to have accepted: http://www.ietf.org/mail-archive/web/ipv6/current/msg18553.html Maybe the following paragraph also intends to cover that point? > * Added a paragraph, based on the suggestion from Dave Thaler, further defining "Realm-Local scope": > > Realm-Local scope is the largest scope that is automatically > configured, i.e., automatically derived from physical > connectivity or other, non-multicast-related configuration. -- JINMEI, Tatuya Infoblox Inc. From Grant.Welch@riverbed.com Fri Aug 2 09:45:11 2013 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 251BA21E80E7 for ; Fri, 2 Aug 2013 09:45:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 496zmYWdvT-F for ; Fri, 2 Aug 2013 09:45:07 -0700 (PDT) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1145921E80AE for ; Fri, 2 Aug 2013 09:45:07 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 02 Aug 2013 09:45:06 -0700 Received: from SFO1EXC-MBXP12.nbttech.com ([fe80::6d89:92e0:1030:143c]) by 365EXCH-HUB-P1.nbttech.com ([::1]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 09:45:06 -0700 From: Grant Welch To: "ipv6@ietf.org" Subject: Question regarding RFC2460, section 4.7 "No Next Header" Thread-Topic: Question regarding RFC2460, section 4.7 "No Next Header" Thread-Index: Ac6PnBHbpAkmMPYtSQm9YQFr78juUw== Date: Fri, 2 Aug 2013 16:45:05 +0000 Message-ID: <629FA04445464743B6C3BACCE6A250EE9A708207@sfo1exc-mbxp12.nbttech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 02 Aug 2013 09:53:36 -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: Fri, 02 Aug 2013 16:46:02 -0000 To whom it concerns, I found the latter portion of the section of interest. ...If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded. Which led me to ponder what the use cases were in mind to preserve data tha= t one could argue as potentially superfluous. I feel like I have done due d= iligence in trying to answer why, but have come up empty. And, I couldn't f= ind a better place to post my question, so you will have to accept my deepe= st apologies if this is the correct forum to ask it. (My searches included = Google, published papers, and the ietf.org website.)=20 To more formally phrase my questions let me extrapolate my interpretation. = RFC2460, section 4.7 makes it necessary to preserve the IP packet payload r= egardless of the fact that the 'Next Header' field seems to have stated tha= t there will be no more data. That is not necessarily true of course becaus= e semantically speaking it's just saying there's no more headers. So, one m= ight forgo all standard or documented transport level protocols and use the= 'No Next Header' option to signal to network hardware to stop further inte= rpretation of the data and to force middleboxes to preserve the data. Is this a correct interpretation? Are there other ramifications that I am m= issing? This portion of the RFC was written back in 1995 and I cannot find any docu= mentation about the decision process to amend it in. Does anyone have any r= ecollections about the process? If there were expected use cases at the tim= e? Again, my apologies if this is the wrong forum. If so, might you direct me = toward the correct one? Thanks for your time. ------------------- - grant welch - gwelch@riverbed.com - desk: 217.531.8303=20 From dougb@dougbarton.us Fri Aug 2 10:05:47 2013 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 4F4DF11E8121 for ; Fri, 2 Aug 2013 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+ya4J0Cnatk for ; Fri, 2 Aug 2013 10:05:46 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FD11E810F for ; Fri, 2 Aug 2013 10:05:46 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id 6111B22B1A for ; Fri, 2 Aug 2013 17:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1375463146; bh=iKlMqrstkb7lUvHxQKukCywgpMyqIyWpmGbZu2aERJ4=; h=Date:From:To:Subject:References:In-Reply-To; b=rRzBMSfWzIjMLVv2AYB+blZoGkK1FoexRguAm7kNAG2mhpZpWHRPsqmkV19CxUcMr uyhxrgAt4uZRMx7r8W0M0TLi3Yg/VtIwHwGWDicqRNS7fh0xwXIkNeO6xYBOnw9STk Z9XYT1Pgu/1BQy7OjZIWl2r2JDEGbhL2rIUnsjQQ= Message-ID: <51FBE6E9.9000800@dougbarton.us> Date: Fri, 02 Aug 2013 10:05:45 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ra-privacy: my responses to comments References: <001501ce8ce3$6b6885c0$42399140$@rozanak.com> <2A391D77-60A5-49E4-BF56-47FBE7477AB9@network-heretics.com> <51FA8654.4090908@sonic.net> In-Reply-To: <51FA8654.4090908@sonic.net> X-Enigmail-Version: 1.5.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Fri, 02 Aug 2013 17:05:47 -0000 On 08/01/2013 09:01 AM, Erik Nordmark wrote: > On 8/1/13 2:31 PM, Keith Moore wrote: > >> Hosnieh clarified the slide by explaining that by using "public >> addresses" she meant addresses resolvable from DNS lookups. But then >> the idea that a node should not use "public addresses" is problematic >> for different reasons. > > Keith, > > From a terminology perspective we have RFC 4941 defining temporary > addresses, but that document doesn't provide a term for the > non-temporary addresses. 4941 does have some text saying > a "public" (i.e., non-secret) server address, registered > in the DNS > FWIW RFC 5014 consistently uses "public" to refer to "not temporary". I'm not sure the conclusions you're drawing are valid there. The 3 commonly accepted categories are SLAAC, static, and 4941/temporary. The fact that an address may or may not be published in the DNS is orthogonal to the type of address. Doug From heard@pobox.com Fri Aug 2 10:35:23 2013 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 9E17611E80EE for ; Fri, 2 Aug 2013 10:35:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUoD9ACSS9Ng for ; Fri, 2 Aug 2013 10:35:18 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48111E80E8 for ; Fri, 2 Aug 2013 10:35:13 -0700 (PDT) Received: (qmail 15777 invoked from network); 2 Aug 2013 10:35:08 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Aug 2013 10:35:08 -0700 Date: Fri, 2 Aug 2013 10:35:07 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: "ipv6@ietf.org" Subject: RE: "Deprecate" In-Reply-To: <2134F8430051B64F815C691A62D983180DD972@XCH-BLV-504.nw.nos.boeing.com> Message-ID: References: <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com> <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180DD8F5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180DD972@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 02 Aug 2013 17:35:23 -0000 Thanks for adding transport mode ... it's essential for addressing the issues under discussion on this thread. //cmh On Fri, 2 Aug 2013, Templin, Fred L wrote: > Hi, > > Up to now, the SEAL spec has focused on "tunnel mode", and had the > singular statement: > > "(A transport-mode of operation is also possible, but out of scope > for this document.)" > > in the introduction. (Indeed, the first edition of SEAL (RFC5320) > did specify a transport mode of operation, but that document will > be obsolete by the second edition.) So, in light of these discussions > I decided that now might be a good time to bring transport mode back > into scope and as such have added the following new section to the > document. Please send comments and suggestions. I will post a new > draft version by the end of the day that will include both tunnel > and transport modes. > > Thanks - Fred > fred.l.templin@boeing.com > > 6. SEAL Transport Mode Specification > > SEAL is also used for transport-mode operation. Transport mode > refers to a SEAL encapsulation in which a layer-4 header appears > immediately following the SEAL header. The type of layer-4 header is > indicated in the "NEXTHDR" field the same as for tunnel mode. The > SEAL header is identical to the version used for tunnel mode, except > that the "LINK_ID" and "LEVEL" fields are omitted, and the transport > layer port numbers are included in each non-initial segment (see: > Figure 6). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NEXTHDR |VER|C|P|I|V|R|M| Offset | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Port (when Offset!=0) | Dest Port (when Offset!=0) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Integrity Check Vector (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > > Figure 6: SEAL Header Format > > The "Source Port" and "Dest Port" are taken from the corresponding > fields in the transport layer next header that appears immediately > following the SEAL header in the initial segment. For example, for > UDP [RFC0768] the transport layer source/dest ports are 16 bits in > length and are copied from the transport layer header. All > segmentation is exactly as specified in SEAL tunnel mode, and the > SEAL Control Message Protocol (SCMP) operates the same as for tunnel > mode. For example, the source node can probe the path MTU to the > destination by setting the P bit in a probe packet and waiting for an > acknowledgement from the destination. > > SEAL transport mode is useful for transport layer protocols that have > no way to segment the large packets they send. It is a universal > format that can be applied to any such transport. > From brian.e.carpenter@gmail.com Fri Aug 2 14:05:11 2013 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 8C08111E80E7 for ; Fri, 2 Aug 2013 14:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHOOkjO6jXmh for ; Fri, 2 Aug 2013 14:05:10 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 40AEE11E80D7 for ; Fri, 2 Aug 2013 14:05:09 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so1089736pab.21 for ; Fri, 02 Aug 2013 14:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7qA+km0FxZPliGh6N+4qo3cfEG9YjZYah3ZiZ25c8v0=; b=UuZNAt5RG43+cJbb2As8ujvdNZjYYaJzrzH22E7D84PdB/0f6aZ+KLRDp/b8dw5fri eC0pXxoNKksaWi2OM4+FWg0+n+ZkN3t1zY5/6SuEyQlaTY12BhFwEDNsE67llXYGXHdJ xl6citjaXSWvLbFwNevkyEBNqfVwU4XufnoaHmSVJt/Vb9teMSy72m1FFttGy+9x83ba dCJJPnARYJPVyGS50ryrhd5OzXjKDY1X9ynMgsjl9o7bMrXU14or8pUR+3vu7QMKgNbg 2aiNwCrcTcoIJ0X1blb6lo2Nvv/DpH6PWi4tGyzt0KWa/JRRhSv/kOhJ1djiGk/rVoKK FJUg== X-Received: by 10.66.164.199 with SMTP id ys7mr12592935pab.104.1375477500341; Fri, 02 Aug 2013 14:05:00 -0700 (PDT) Received: from [192.168.178.23] (225.199.69.111.dynamic.snap.net.nz. [111.69.199.225]) by mx.google.com with ESMTPSA id eq5sm12185388pbc.15.2013.08.02.14.04.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 14:04:59 -0700 (PDT) Message-ID: <51FC1F06.7070600@gmail.com> Date: Sat, 03 Aug 2013 09:05:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Grant Welch Subject: Re: Question regarding RFC2460, section 4.7 "No Next Header" References: <629FA04445464743B6C3BACCE6A250EE9A708207@sfo1exc-mbxp12.nbttech.com> In-Reply-To: <629FA04445464743B6C3BACCE6A250EE9A708207@sfo1exc-mbxp12.nbttech.com> Content-Type: text/plain; charset=UTF-8 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: Fri, 02 Aug 2013 21:05:11 -0000 On 03/08/2013 04:45, Grant Welch wrote: > To whom it concerns, > > I found the latter portion of the section of interest. > > ...If the Payload Length field of the IPv6 header indicates the > presence of octets past the end of a header whose Next Header field > contains 59, those octets must be ignored, and passed on unchanged if > the packet is forwarded. It seems to me that this is simply an expression of the general principle that the network should be transparent to packets from end to end. I doubt there is anything more to it than that. It goes with the general requirement that forwarding nodes must transmit all extension headers transparently (the topic of draft-ietf-6man-ext-transmit). Brian > > Which led me to ponder what the use cases were in mind to preserve data that one could argue as potentially superfluous. I feel like I have done due diligence in trying to answer why, but have come up empty. And, I couldn't find a better place to post my question, so you will have to accept my deepest apologies if this is the correct forum to ask it. (My searches included Google, published papers, and the ietf.org website.) > > To more formally phrase my questions let me extrapolate my interpretation. RFC2460, section 4.7 makes it necessary to preserve the IP packet payload regardless of the fact that the 'Next Header' field seems to have stated that there will be no more data. That is not necessarily true of course because semantically speaking it's just saying there's no more headers. So, one might forgo all standard or documented transport level protocols and use the 'No Next Header' option to signal to network hardware to stop further interpretation of the data and to force middleboxes to preserve the data. > > Is this a correct interpretation? Are there other ramifications that I am missing? > > This portion of the RFC was written back in 1995 and I cannot find any documentation about the decision process to amend it in. Does anyone have any recollections about the process? If there were expected use cases at the time? > > Again, my apologies if this is the wrong forum. If so, might you direct me toward the correct one? > > Thanks for your time. > > ------------------- > - grant welch > - gwelch@riverbed.com > - desk: 217.531.8303 > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ietf@rozanak.com Fri Aug 2 14:19:06 2013 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 5118B21E8050 for ; Fri, 2 Aug 2013 14:19:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT7-yGPqZFHX for ; Fri, 2 Aug 2013 14:19:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DE30911E80D7 for ; Fri, 2 Aug 2013 14:18:31 -0700 (PDT) Received: from kopoli (f052069233.adsl.alicedsl.de [78.52.69.233]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MD9hU-1UorXM0FjQ-00HGkg; Fri, 02 Aug 2013 17:18:30 -0400 From: "Hosnieh Rafiee" To: Subject: Question about ug bits Date: Fri, 2 Aug 2013 23:18:19 +0200 Message-ID: <000001ce8fc5$d2530af0$76f920d0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6PxMqsDpAItReRRWGZudWFfiUpwA== Content-Language: en-us X-Provags-ID: V02:K0:ikpeaxTiAHUksUOGt7K8+rEbqaKozuaafUxcaAmKQ7d hCMdu5NFiXwL01oXKAXZufLXO7f1Un8Vgi/KIgqS/JrwLKBypP pevVgnu8ZLFHD+KivPOB+tpwvAE65DpDwpvYlpK3vswl3HxdP+ n0Hp5Ma8+0D3dWA8xZ7HedJbkPn5COppR5hqlRWck1hh6K3Zfa jacVDrLHK46zvvrIFyo35HZuk2QS6MB1iI0cFEP5k35QlRgTgd 4UYeqTW50vpL3G/V+gNuPtqylleHHPe9msIEgYNvNWTAuYw6tR cGZWHoggzQZFvHYJMx1300QAkqTc/KqkZjjydKrnHIvJfAnPTC DKhrL9piG3gS2GMh2+p8= 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, 02 Aug 2013 21:19:06 -0000 Hello, have a question. Is it possible to use bits u and g (reserved bits) as part of the IID interface when using any IID generation approach? For instance, using it for SSAS. Thanks, Best, Hosnieh From brian.e.carpenter@gmail.com Fri Aug 2 15:44:19 2013 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 5539A11E810E for ; Fri, 2 Aug 2013 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfmliJ2vL87Y for ; Fri, 2 Aug 2013 15:44:18 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 487FC11E8133 for ; Fri, 2 Aug 2013 15:44:18 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so1145209pdc.33 for ; Fri, 02 Aug 2013 15:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nYm0YmeR5byASrpC9IA4gsVmrM9d6Vec6jwiuXPE1uM=; b=NlIHJSI5PB6mpjv7a39nTP75LgHTzwKNJI7yqm3cetoCiz2/CR6lNkE0us7LmD1+TI NYG72c0HBLx5hK98t6ild+vbg/ai0mhNubcC3lDSw/6zXXAk6ykGHzki7yd37JzbHnKv 2syVDwQUr44z4bw7dp/TfImt0RecKZrJEYjcxRX+kCXqNPr86U1C9hzCiNlVcOCyTNVO sMe+QG7oQwCNIRuMR+d3/APoJZSXRRRwdLAdPTNV/Nws6lEYS0UpyzFjG7UW/pF91njz CDWg1BuAHQalp44hXHeSISCM6eDYyi8JfD77MGDhCJiTV6DCcbi0Cjqold87YvDj9mvh XQwg== X-Received: by 10.66.118.129 with SMTP id km1mr12577102pab.127.1375483457915; Fri, 02 Aug 2013 15:44:17 -0700 (PDT) Received: from [192.168.178.23] (225.199.69.111.dynamic.snap.net.nz. [111.69.199.225]) by mx.google.com with ESMTPSA id ot4sm12781499pac.17.2013.08.02.15.44.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 15:44:17 -0700 (PDT) Message-ID: <51FC364C.1020001@gmail.com> Date: Sat, 03 Aug 2013 10:44:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Question about ug bits References: <000001ce8fc5$d2530af0$76f920d0$@rozanak.com> In-Reply-To: <000001ce8fc5$d2530af0$76f920d0$@rozanak.com> Content-Type: text/plain; charset=UTF-8 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: Fri, 02 Aug 2013 22:44:19 -0000 Hosnieh, Please see http://tools.ietf.org/html/draft-ietf-6man-ug-01 whose WG Last Call just ended, with a few comments to be incorporated. IMHO, since we seem to agree that these bits have no defined semantics in an IID, you can specify them as you want in a new IID format. I would only suggest paying attention to the last paragraph of section 3: "To the extent that each method of IID creation specifies the values of the "u" and "g" bits, and that each new method is carefully designed in the light of its predecessors, these bits tend to reduce the chances of duplicate IIDs." Regards Brian Carpenter On 03/08/2013 09:18, Hosnieh Rafiee wrote: > Hello, > > have a question. Is it possible to use bits u and g (reserved bits) as part > of the IID interface when using any IID generation approach? For instance, > using it for SSAS. > > Thanks, > Best, > Hosnieh > > -------------------------------------------------------------------- > 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 Aug 2 15:50:48 2013 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 CBB9F11E8133 for ; Fri, 2 Aug 2013 15:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COEZ+QDsZq7b for ; Fri, 2 Aug 2013 15:50:47 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6D811E80F9 for ; Fri, 2 Aug 2013 15:50:47 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z11so1146609pdj.17 for ; Fri, 02 Aug 2013 15:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PENvBizIcpjGU7TSZ1XSQQpbDlcT6X9F8LwR797mrmo=; b=kraQmM+eIX0o8nSHD57CboALoDudwyvWjxzp7yygzfPuB4wdWMRPm2v5pDWsClJdwe MFyhCO21i1YZJGIFx7AwXaFtV2efK2uqG1uYJGnHUfgaL0V1kJ9Y4zxnKmWwJIXrM0cW 5/S33IcrvV2le3vKTHXfW9TCGe2SoP2aesEcbMynx9HnNKqGcaZZuuxkjcNWtjDPOMN/ tslj4Yyw1/JkRwOzPUqEUNKfXcPUd58j6xeJaF3BW53I4g4tcXEKIwdmUpZ29Ws4bq5m W6gDaDlrwO1uQkWV9UrMInjNbeKH5TXAbJU0xv8UMEvcV5/rIcfKQKeR0ABeM2na1mNJ bH2A== X-Received: by 10.68.110.165 with SMTP id ib5mr10053110pbb.196.1375483846955; Fri, 02 Aug 2013 15:50:46 -0700 (PDT) Received: from [192.168.178.23] (225.199.69.111.dynamic.snap.net.nz. [111.69.199.225]) by mx.google.com with ESMTPSA id e7sm10969031pbc.11.2013.08.02.15.50.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 15:50:46 -0700 (PDT) Message-ID: <51FC37D1.3060009@gmail.com> Date: Sat, 03 Aug 2013 10:50:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith Subject: Re: UDP+Fragmentation References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 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, 02 Aug 2013 22:50:48 -0000 On 02/08/2013 18:12, Mark ZZZ Smith wrote: > > ----- Original Message ----- >> From: Mark ZZZ Smith >> To: C. M. Heard ; IPv6 >> Cc: >> Sent: Friday, 2 August 2013 2:55 PM >> Subject: Re: UDP+Fragmentation (was: "Deprecate") >> >> Hi, >> >> >> ----- Original Message ----- >>> From: C. M. Heard >>> To: IPv6 >>> Cc: >>> Sent: Friday, 2 August 2013 3:11 AM >>> Subject: Re: UDP+Fragmentation (was: "Deprecate") >>> > >>> - generic transport encapsulation within UDP (suggested to me >>> off-list by Mark Smith, based on a draft by Stuart Cheshire >>> et. al.). >>> >> For those on the list, the draft I mentioned was : >> >> Encapsulation of TCP and other Transport Protocols over UDP >> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 >> >> >> Note that this basically proposes translating the TCP header into UDP header >> fields, and then for the missing fields, appending them after the UDP header. I >> was a bit confused by what was proposed, until I thought about a web server >> specifically listening on UDP port 80, knowing that UDP port 80 is TCP over UDP, >> and then decoding the UDP fields and subsequent fields as a TCP header. >> > And actually to better clarify, my (quick) suggestion was to put fragmentation fields after the UDP header, similar to how that draft places the TCP fields after the UDP header. May I make a plea for any such proposal to be carefully evaluated against common practices in stateful firewalls and load balancers. I'm rather concerned that the problems these middleboxes create with conventional fragmentation will soon come back with UDP-encapsulated fragmentation. (There is no problem in computer science that can't be made harder by recursion.) Brian From ietf@rozanak.com Sat Aug 3 00:26:38 2013 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 EEF6A21F9B01 for ; Sat, 3 Aug 2013 00:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1i1a6ZZojVd for ; Sat, 3 Aug 2013 00:26:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB4C11E815F for ; Sat, 3 Aug 2013 00:26:34 -0700 (PDT) Received: from kopoli (f052069187.adsl.alicedsl.de [78.52.69.187]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MStm1-1UeKsM3BYL-00RmMJ; Sat, 03 Aug 2013 03:26:31 -0400 From: "Hosnieh Rafiee" To: "'Brian E Carpenter'" References: <000001ce8fc5$d2530af0$76f920d0$@rozanak.com> <51FC364C.1020001@gmail.com> In-Reply-To: <51FC364C.1020001@gmail.com> Subject: RE: Question about ug bits Date: Sat, 3 Aug 2013 09:26:06 +0200 Message-ID: <001b01ce901a$c1eb0f00$45c12d00$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHE08z5bJ2GWImNvUVZoWgGuxuIlALtcM5LmX8h/tA= Content-Language: en-us X-Provags-ID: V02:K0:oFLWnrC4Ax0b9urQ39KefYRSRjFGE+Fj/IMAbnj/aXD KGLf1zxbwCEgOXPl+w98a7l61Q2c+Ck0u86ui49iEzknqOTKvl JoxX8W1XGuFJ5IJwHqEpZ6wEWiXwcBu6gTnvOL5UFMkjzV4ab1 ow/EsbxeZmm/7pGfsjlIV5/LlC1O23gi/YK85S7JQBUVP0J1Y4 JcxP7Sni8e6+RXGKFlIbQ216v3ika4v+f5wMge8eSC+u6QEp0g Cnil2jFdVx0Q59tImVI+2OEQl+xu4v/+hTb5hfHzc6WspF2/tn KxsOJw4gFoy5sSdcA0ttlw3yP0Zuq19ZVWxD0GiM/DxNg/kQS2 2XvLWjhJgXnlWSCDCgl4= 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, 03 Aug 2013 07:26:39 -0000 Hi Brian, Yes, I followed the discussion about your draft. This is why I asked to = be sure about my assumption. Thank you for clarifications. Best, Hosnieh >=20 > Hosnieh, >=20 > Please see http://tools.ietf.org/html/draft-ietf-6man-ug-01 > whose WG Last Call just ended, with a few comments to be incorporated. >=20 > IMHO, since we seem to agree that these bits have no defined semantics = in an > IID, you can specify them as you want in a new IID format. I would = only suggest > paying attention to the last paragraph of section 3: >=20 > "To the extent that each method of IID creation specifies the values = of the "u" > and "g" bits, and that each new method is carefully designed in the = light of its > predecessors, these bits tend to reduce the chances of duplicate = IIDs." >=20 > Regards > Brian Carpenter >=20 > On 03/08/2013 09:18, Hosnieh Rafiee wrote: > > Hello, > > > > have a question. Is it possible to use bits u and g (reserved bits) = as > > part of the IID interface when using any IID generation approach? = For > > instance, using it for SSAS. > > > > Thanks, > > Best, > > Hosnieh > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > From heard@pobox.com Sat Aug 3 09:21:05 2013 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 7C33D21F9D1C for ; Sat, 3 Aug 2013 09:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iek+YdO1RJP2 for ; Sat, 3 Aug 2013 09:21:01 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236F121F9C40 for ; Sat, 3 Aug 2013 09:20:55 -0700 (PDT) Received: (qmail 23371 invoked from network); 3 Aug 2013 09:20:51 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Aug 2013 09:20:51 -0700 Date: Sat, 3 Aug 2013 09:20:51 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: UDP+Fragmentation In-Reply-To: <51FC37D1.3060009@gmail.com> Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 03 Aug 2013 16:21:05 -0000 On Sat, 3 Aug 2013, Brian E Carpenter wrote: > On 02/08/2013 18:12, Mark ZZZ Smith wrote: > > [ Mark ZZZ Smith wrote ] ... > > > [ C. M. Heard wrote ] ... > > > > - generic transport encapsulation within UDP (suggested to me > > > > off-list by Mark Smith, based on a draft by Stuart Cheshire > > > > et. al.). ... > May I make a plea for any such proposal to be carefully evaluated against > common practices in stateful firewalls and load balancers. I'm rather concerned > that the problems these middleboxes create with conventional fragmentation > will soon come back with UDP-encapsulated fragmentation. (There is no problem > in computer science that can't be made harder by recursion.) Yes, UDP-encapsulated fragmentation (in its simplest form) has exactly the same issue as conventional IP fragmentation -- it hides the actual L4 header information in all but the first fragment. Operators who filter conventional IP fragments would have exactly the same motivation to filter UDP-encapsulated fragments. On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: > (2) fragments can hide transport layer protocol ports, preventing > simple ACL filtering etc. ... > A general solution like SEAL (which I think in the big picture > would be better), probably doesn't solve (2) SEAL transport mode, as currently proposed, addresses the problem by including port numbers in all non-initial segments:. See: https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 Mike Heard From gandhar.ietf@gmail.com Sun Aug 4 21:37:16 2013 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 6D2AC21E80D9 for ; Sun, 4 Aug 2013 21:37:16 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnVS+bgh9whY for ; Sun, 4 Aug 2013 21:37:15 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7A46721E80D8 for ; Sun, 4 Aug 2013 21:37:15 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so2337535vbg.25 for ; Sun, 04 Aug 2013 21:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=De7NXXGxov6LnDAqzL0jew3+BA3aEu+J1b411EeNgME=; b=F7Kx1OOVRd4iJ0QRCpwqajVzRgK0LAHeVDPCT/FS40kHFaTVfq8ZEC388t0OtjxnPw Fr2Dv1FeWDx3h3BxMKDzo7d1NJyI5Vdu/G9FyuCGq3e+01vJyv7pODgpnvEJs4iPsJ8F QNL/SnWqAe0d683Y6lJyZQeeIRcT5/kRDdDLPFgadZXk4zPb63QQbxoDF02Nw4lf2eUQ KeWg6rtACeKgk1DPaoqAFnxDACWtNaRk3ZCkYkdIvnKM3tpcXtONHiVBsueGeI4ccnR7 th3T6X0rEiub245O2zopgmeKQhW1yMxZnotpiq6eR4lMITyrh8vB1LmfBaxpr0VJM4GP no+w== MIME-Version: 1.0 X-Received: by 10.221.47.193 with SMTP id ut1mr5163015vcb.8.1375677434860; Sun, 04 Aug 2013 21:37:14 -0700 (PDT) Received: by 10.58.219.71 with HTTP; Sun, 4 Aug 2013 21:37:14 -0700 (PDT) In-Reply-To: <51FC1F06.7070600@gmail.com> References: <629FA04445464743B6C3BACCE6A250EE9A708207@sfo1exc-mbxp12.nbttech.com> <51FC1F06.7070600@gmail.com> Date: Mon, 5 Aug 2013 10:07:14 +0530 Message-ID: Subject: Re: Question regarding RFC2460, section 4.7 "No Next Header" From: Gandhar Gokhale To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113392ecd4998d04e32bdc08 Cc: Grant Welch , "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, 05 Aug 2013 04:37:16 -0000 --001a113392ecd4998d04e32bdc08 Content-Type: text/plain; charset=ISO-8859-1 Hi, I remember having read in one of the conversations that the intention for this was supporting experimentation with new transport layer protocols. Having the no-next header followed by the experimental protocol and payload would allow the end points to test the new protocol without the network requiring to know about it. On Sat, Aug 3, 2013 at 2:35 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 03/08/2013 04:45, Grant Welch wrote: > > To whom it concerns, > > > > I found the latter portion of the section of interest. > > > > ...If the Payload Length field of the IPv6 header indicates the > > presence of octets past the end of a header whose Next Header field > > contains 59, those octets must be ignored, and passed on unchanged if > > the packet is forwarded. > > It seems to me that this is simply an expression of the general principle > that the network should be transparent to packets from end to end. > I doubt there is anything more to it than that. It goes with the general > requirement that forwarding nodes must transmit all extension headers > transparently (the topic of draft-ietf-6man-ext-transmit). > > Brian > > > > > Which led me to ponder what the use cases were in mind to preserve data > that one could argue as potentially superfluous. I feel like I have done > due diligence in trying to answer why, but have come up empty. And, I > couldn't find a better place to post my question, so you will have to > accept my deepest apologies if this is the correct forum to ask it. (My > searches included Google, published papers, and the ietf.org website.) > > > > To more formally phrase my questions let me extrapolate my > interpretation. RFC2460, section 4.7 makes it necessary to preserve the IP > packet payload regardless of the fact that the 'Next Header' field seems to > have stated that there will be no more data. That is not necessarily true > of course because semantically speaking it's just saying there's no more > headers. So, one might forgo all standard or documented transport level > protocols and use the 'No Next Header' option to signal to network hardware > to stop further interpretation of the data and to force middleboxes to > preserve the data. > > > > Is this a correct interpretation? Are there other ramifications that I > am missing? > > > > This portion of the RFC was written back in 1995 and I cannot find any > documentation about the decision process to amend it in. Does anyone have > any recollections about the process? If there were expected use cases at > the time? > > > > Again, my apologies if this is the wrong forum. If so, might you direct > me toward the correct one? > > > > Thanks for your time. > > > > ------------------- > > - grant welch > > - gwelch@riverbed.com > > - desk: 217.531.8303 > > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -- Gandhar Gokhale Networking Components Group LSI --001a113392ecd4998d04e32bdc08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I remember having read in one of th= e conversations that the intention for this was supporting experimentation = with new transport layer protocols. Having the no-next header followed by t= he experimental protocol and payload would allow the end points to test the= new protocol without the network requiring to know about it.=A0


On Sat,= Aug 3, 2013 at 2:35 AM, Brian E Carpenter <brian.e.carpenter@gm= ail.com> wrote:
On 03/08/2013 04:45, Grant= Welch wrote:
> To whom it concerns,
>
> I found the latter portion of the section of interest.
>
> =A0 =A0...If the Payload Length field of the IPv6 header indicates the=
> =A0 =A0presence of octets past the end of a header whose Next Header f= ield
> =A0 =A0contains 59, those octets must be ignored, and passed on unchan= ged if
> =A0 =A0the packet is forwarded.

It seems to me that this is simply an expression of the general princ= iple
that the network should be transparent to packets from end to end.
I doubt there is anything more to it than that. It goes with the general requirement that forwarding nodes must transmit all extension headers
transparently (the topic of draft-ietf-6man-ext-transmit).

=A0 =A0Brian

>
> Which led me to ponder what the use cases were in mind to preserve dat= a that one could argue as potentially superfluous. I feel like I have done = due diligence in trying to answer why, but have come up empty. And, I could= n't find a better place to post my question, so you will have to accept= my deepest apologies if this is the correct forum to ask it. (My searches = included Google, published papers, and the ietf.org website.)
>
> To more formally phrase my questions let me extrapolate my interpretat= ion. RFC2460, section 4.7 makes it necessary to preserve the IP packet payl= oad regardless of the fact that the 'Next Header' field seems to ha= ve stated that there will be no more data. That is not necessarily true of = course because semantically speaking it's just saying there's no mo= re headers. So, one might forgo all standard or documented transport level = protocols and use the 'No Next Header' option to signal to network = hardware to stop further interpretation of the data and to force middleboxe= s to preserve the data.
>
> Is this a correct interpretation? Are there other ramifications that I= am missing?
>
> This portion of the RFC was written back in 1995 and I cannot find any= documentation about the decision process to amend it in. Does anyone have = any recollections about the process? If there were expected use cases at th= e time?
>
> Again, my apologies if this is the wrong forum. If so, might you direc= t me toward the correct one?
>
> Thanks for your time.
>
> -------------------
> - grant welch
> - gwelch@riverbed.com
> - desk: 217.531.8303
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= br> > -------------------------------------------------------------------- >
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--
Gandha= r Gokhale
Networking Components Group
LSI
--001a113392ecd4998d04e32bdc08-- From brian.e.carpenter@gmail.com Sun Aug 4 22:30:26 2013 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 3B6A111E8146 for ; Sun, 4 Aug 2013 22:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vpYPQHfVuZN for ; Sun, 4 Aug 2013 22:30:25 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1111E8140 for ; Sun, 4 Aug 2013 22:30:25 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id bv13so2777451pdb.30 for ; Sun, 04 Aug 2013 22:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oK6exyH/FYtYN8+Cc8EIsemqZPk0tuDimM7hslJfE+Y=; b=DZoeS6lN2gIT6KkFevFB2NSIk8uM/jzJkBCBxd+iU/znKv06epRFSU5HFvdoTkFSbC GkqVY6Joh873SdY8mP3T16sARYPSY1CSIF7gcvToYzrYJ45KGn1alef1C8PEIlQtt+CS lcTrnuO+X2zkvHc/JNp+8FmVVWJW4DKOYYO1uVIbDPDGl3TDVGGPq5TAnHADRk+NIhHp Z063TaGZ1UiMbKT5xdwDXRWv2+joICK7LKOsbXN4L6oO1zfg/WExvos3O7uHshVP2XsL udj0NsyTuLGADEziaw2Q0Q0o7VvlOERQwIddNtS2phJzZwT7Uomg61GvMoHzngJLSobe GZ1A== X-Received: by 10.66.136.71 with SMTP id py7mr1280842pab.2.1375680625241; Sun, 04 Aug 2013 22:30:25 -0700 (PDT) Received: from [192.168.178.20] (6.199.69.111.dynamic.snap.net.nz. [111.69.199.6]) by mx.google.com with ESMTPSA id bt1sm25136585pbb.2.2013.08.04.22.30.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 Aug 2013 22:30:24 -0700 (PDT) Message-ID: <51FF386C.3000302@gmail.com> Date: Mon, 05 Aug 2013 17:30:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gandhar Gokhale Subject: Re: Question regarding RFC2460, section 4.7 "No Next Header" References: <629FA04445464743B6C3BACCE6A250EE9A708207@sfo1exc-mbxp12.nbttech.com> <51FC1F06.7070600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Grant Welch , "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, 05 Aug 2013 05:30:26 -0000 On 05/08/2013 16:37, Gandhar Gokhale wrote: > Hi, > I remember having read in one of the conversations that the intention for > this was supporting experimentation with new transport layer protocols. > Having the no-next header followed by the experimental protocol and payload > would allow the end points to test the new protocol without the network > requiring to know about it. The network isn't required to know about new extension headers either. I can't imagine a firewall that discards unknown extension headers that doesn't also discard phantom bytes. Brian > > > On Sat, Aug 3, 2013 at 2:35 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 03/08/2013 04:45, Grant Welch wrote: >>> To whom it concerns, >>> >>> I found the latter portion of the section of interest. >>> >>> ...If the Payload Length field of the IPv6 header indicates the >>> presence of octets past the end of a header whose Next Header field >>> contains 59, those octets must be ignored, and passed on unchanged if >>> the packet is forwarded. >> It seems to me that this is simply an expression of the general principle >> that the network should be transparent to packets from end to end. >> I doubt there is anything more to it than that. It goes with the general >> requirement that forwarding nodes must transmit all extension headers >> transparently (the topic of draft-ietf-6man-ext-transmit). >> >> Brian >> >>> Which led me to ponder what the use cases were in mind to preserve data >> that one could argue as potentially superfluous. I feel like I have done >> due diligence in trying to answer why, but have come up empty. And, I >> couldn't find a better place to post my question, so you will have to >> accept my deepest apologies if this is the correct forum to ask it. (My >> searches included Google, published papers, and the ietf.org website.) >>> To more formally phrase my questions let me extrapolate my >> interpretation. RFC2460, section 4.7 makes it necessary to preserve the IP >> packet payload regardless of the fact that the 'Next Header' field seems to >> have stated that there will be no more data. That is not necessarily true >> of course because semantically speaking it's just saying there's no more >> headers. So, one might forgo all standard or documented transport level >> protocols and use the 'No Next Header' option to signal to network hardware >> to stop further interpretation of the data and to force middleboxes to >> preserve the data. >>> Is this a correct interpretation? Are there other ramifications that I >> am missing? >>> This portion of the RFC was written back in 1995 and I cannot find any >> documentation about the decision process to amend it in. Does anyone have >> any recollections about the process? If there were expected use cases at >> the time? >>> Again, my apologies if this is the wrong forum. If so, might you direct >> me toward the correct one? >>> Thanks for your time. >>> >>> ------------------- >>> - grant welch >>> - gwelch@riverbed.com >>> - desk: 217.531.8303 >>> >>> >>> -------------------------------------------------------------------- >>> 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 otroan@employees.org Mon Aug 5 02:20:37 2013 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 BB01021F9DCA for ; Mon, 5 Aug 2013 02:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL3YpEB47N-3 for ; Mon, 5 Aug 2013 02:20:26 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E4A3F21F8FF8 for ; Mon, 5 Aug 2013 02:15:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALts/1GQ/khL/2dsb2JhbABagwa/foEeFnSCJAEBBAE6PwULCxI0SQ4GiB0GtHmPZjMHgxl0A6kvgxk6 X-IronPort-AV: E=Sophos;i="4.89,729,1367971200"; d="scan'208";a="16343761" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 05 Aug 2013 09:14:48 +0000 Received: from dhcp-lys01-vla250-10-147-112-79.cisco.com (dhcp-lys01-vla250-10-147-112-79.cisco.com [10.147.112.79]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r759EjYe030376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Aug 2013 09:14:46 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: "Deprecate" From: Ole Troan In-Reply-To: <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> Date: Mon, 5 Aug 2013 11:14:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1508) 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, 05 Aug 2013 09:20:39 -0000 Ran, > In the current global Internet, few router implementers are=20 > comfortable trying to reassemble anywhere in the middle of the=20 > path, in part because of the additional attack surface that > reassembling transit traffic would create. >=20 > Instead, at tunnel egress, any fragments are likely to be=20 > merely decapsulated and then forwarded. So, it is critical=20 > that end systems be able to reassemble fragments as fragments=20 > will continue to exist in the real world. that would also be a significant change in the IPv6 architecture. IPv6 over IPv6 tunnels do outer fragmentation today (RFC2473) and tunnel = egress must perform reassembly. cheers, Ole= From ayourtch@cisco.com Mon Aug 5 03:52:06 2013 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 CA5A221F9E01 for ; Mon, 5 Aug 2013 03:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3ES6ecSPExB for ; Mon, 5 Aug 2013 03:51:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DD06421F9DF7 for ; Mon, 5 Aug 2013 03:51:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r75Apvmg027483 for ; Mon, 5 Aug 2013 12:51:57 +0200 (CEST) Received: from [10.61.213.28] ([10.61.213.28]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r75Apr5E016631; Mon, 5 Aug 2013 12:51:53 +0200 (CEST) Date: Mon, 5 Aug 2013 12:51:53 +0200 (CEST) From: ayourtch X-X-Sender: ayourtch@ayourtch-mac To: samita.chakrabarti@ericsson.com, nordmark@cisco.com, pthubert@cisco.com, mrw@lilacglade.org Subject: draft-chakrabarti-nordmark-6man-efficient-nd review Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 05 Aug 2013 03:57:04 -0700 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, 05 Aug 2013 10:52:06 -0000 Hi, I've read through the document, and the problem that it touches is indeed *very* acute - I've experienced it every time in the large-scale wireless deployments. The below is a braindump written as I was reading the doc - I deliberately left some of the pieces that might have been explained later in the document, so if you want you might preempt these by adding explicit forward references. ---------- Overall, after reading the doc: 1) I think address registration introduces a new attack vector (registration flood). More thoughts on this inline. 2) I think there are a few more "multicast chatter" cases that are missed - inline. 3) Given that the FHS is a "must" in IPv6 network, if we assume its presence, I think the protocol may be simplified, and be made more router-centric, I think there may be a possible optimization which would not involve changing the end hosts - as I'd guess it'll take a while for the end hosts to adapt. Now, I'm using the text from -02 from the below URL, will copypaste anchors from it and comments interspersing. http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd/?include_text=1 " joining the network the host does not wait for the Router Advertisements as the NEAR routers do not perform periodic multicast RA as per RFC 4861. Instead, the EAH sends a multicast RS to find out a NEAR router in the network. The RS message is the same as in RFC 4861. " The RS sending mechanism will be resilient, I assume, such that the node does get RA even in a high-loss environments, right ? Maybe useful to include a paragraph or two on the unreliability of this mechanism. I think Suresh said he had something on this, probably worth referencing. " The TID field is used together with age of a registration for arbitration between two routers (default or backbone) to ensure freshness and ownership of the registration of a given target address. " freshness - yes.. ownership - not sure.. seems like I might spoof this value easily.. ? " Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only solicited RAs are RECOMMENDED. An RA MUST" This is sometime years in the future when there's no legacy IPv6 nodes ? Especially in context of mobile byod-type networks (e.g. ciscolive net), I think the router might need to support both. OTOH, the *interval* of the multicast RAs can be cranked up. This is what I am doing now, and it does help... Okay, I see sometime later: "The efficiency-aware default router MUST not send periodic RA unless it is configured to support both legacy IPv6 and efficiency-aware hosts. If the Router is configured for efficiency-aware hosts support, it MUST send Router Advertisements with E-bit flag ON and MUST NOT set 'L' bit in the advertisements." Fair enough. But then if the router configured for interop, do we still send RAs "relatively frequently" or do we say also to decrease their default frequency ? Maybe a micro-optimization, not sure. I need to measure this somehow with existing gear. "containing Router's link-layer address (this is optional in [ND]. An RA MUST carry Prefix information option with L bit being unset, so that hosts do not multicast any NS messages" for the routable addresses, yes this solves the problem. But what I noticed today is this use case: Bonjour advertising the services using all sorts of addresses, including link-local addresses. So, then the devices will do ND on link-local addresses, etc. - so this will solve the problem only partially, I think. " Unlike RFC4861 which suggests multicast Router Advertisements, this specification optimizes the exchange by always unicasting RAs in response to RS." Yay! :-) (with my wireless hat on:) One thing (maybe) to mention is to say that in the final architecture this may be configurable depending on the media type ? a broadcast medium with low capacity could still make use of mcast RAs. " The efficiency-aware host MUST NOT send or accept re-direct messages. It does not join solicited node multicast address. " Again, yay! Does this mean we can get rid of MLD queries as well ? " one with ARO and another without ARO then the NS message with ARO gets the precedence and the NS without ARO is ignored. This behavior protects the router from Denial Of Service attacks. Similarly, if " What about two AROs that are different ? " Lifetime expires. If an ARO arrives for an NCE that is in UNCREACHABLE state, that NCE should be marked as STALE. " Can we then use this STALE state as an excuse to clean up the table if it gets full(er) on the router, similar to what we do today with binding table with FHS ? I feel we should discuss - "what happens when the resources on the router are exhausted or close to exhaustion - how does it recover gracefully from this condition, if at all". "However, it will create legacy NCE for NS messages for other routers in the network. This mode is able to prevent ND flooding on the link." I don't understand. Is this for more than one router running in a kind of redundant mode ? I'd need to understand the exact topology in question, but I think I have a comment for this part :-) " An efficiency-aware Router(NEAR) SHOULD be able to have configuration knob to configure itself in Mixed-Mode where it will support both efficiency-aware hosts and legacy hosts. " Would this be an excuse for some vendors to not implement the mixed mode ? I have a vague feeling that this should be "MUST" to help enable transition, but probably "SHOULD" is for the routers made specifically for the energy-efficient environments ? Is this something that justified by enough of a ballast of having to support the legacy mode ? My hunch is that probably there is not a whole lot, but maybe I am wrong... " The new default router then first send an NS to its peers with a link scope multicast message to IPv6 address ff02::2 with the ARO option. " So, I think the movement scenario presents another attack vector, if I understand it right - unless there is a signaling mechanism for asserting the host's identity... I don't have a good solution now, just think this is a problem. Maybe something like a binding table will take care of it - if it's centralized at a L2 device that sees everything. I think it is a solved problem there... " value of TID wins. Note that the registration ownership and local movement detection behavior in NEAR router MUST be optionally configured. The NEAR routers MAY implement this feature. " So does this mean that by default we'll "protect" the existing entry ? " The efficiency-aware behavior documented in this specification avoids the ND DOS attacks by: o Having the hosts register with the default router o Having the hosts send their packets via the default router o Not resolving addresses for the Routing Solicitor by mandating SLLA option along with RS o Checking for duplicates in NCE before the registration o Checking against the MAC-address and EUI-64 id is possible now for NCE matches " The way I see it, it does prevent the attack which destination guard prevents, and that's it. On the other hand, it introduces a new attack where a malicious host on local network can send a lot of registrations and exhaust resources of the router. I think this is where a mechanism from the network to signal "you're trying too much" could be useful. OTOH if implemented straightforwardly, this may become a way for the network to try to control the hosts... I don't know the answer yet. Maybe I am ratholing, sorry :-) " router. At this point, the default routers use Neighbor Advertisements(NA) to arbitrate the latest ownership of the registration of host. The ownership of registration is useful for " I think I had some questions about this earlier - maybe would benefit from a reflow, and having the same "movement stuff" in the same place ? " if EAH node implements DNA host capability as well, then it SHOULD give preference to the NEAR routers in its candidate list of routers. " I think this is an over-spec. There is already "router preference" field, which can be happily used to enable more than one use case, including the ability to switch back and forth from legacy routers. " multicast messages in the IPv6 ND procedure, it does not affect normal IPv6 multicast packets and ability of nodes to join and leave the multicast group or forwarding multicast traffic or responding to multicast queries. " ahha - so MLD queries are still sent by the querier routers ? I think that might be quite an impact as well (e.g. on WLC by default MLD querier time is 90 seconds). " These optimizations are not known to introduce any new threats against Neighbor Discovery beyond what is already documented for IPv6 [RFC 3756]. " As I noted above, I think this mechanism does introduce a new attack vector... I am not sure if it does also introduce the attack vector of stealing the address, seems like it might. Hope it helps. --a From Fred.L.Templin@boeing.com Mon Aug 5 10:09:18 2013 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 3EFCF21F9F85 for ; Mon, 5 Aug 2013 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23Jte36CZ4ao for ; Mon, 5 Aug 2013 10:09:13 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 644AF21F9F21 for ; Mon, 5 Aug 2013 10:09:13 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r75H9tXY016262 for ; Mon, 5 Aug 2013 10:09:55 -0700 Received: from XCH-PHX-412.sw.nos.boeing.com (xch-phx-412.sw.nos.boeing.com [10.57.37.44]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r75H9tig016251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 5 Aug 2013 10:09:55 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-412.sw.nos.boeing.com ([169.254.12.73]) with mapi id 14.02.0328.011; Mon, 5 Aug 2013 10:09:11 -0700 From: "Templin, Fred L" To: "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOkGV+4SMEeC7qyE6QlR5ihkVRYZmG2Feg Date: Mon, 5 Aug 2013 17:09:10 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 05 Aug 2013 17:09:18 -0000 Hi Mike, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Saturday, August 03, 2013 9:21 AM > To: IPv6 > Subject: Re: UDP+Fragmentation >=20 > On Sat, 3 Aug 2013, Brian E Carpenter wrote: > > On 02/08/2013 18:12, Mark ZZZ Smith wrote: > > > [ Mark ZZZ Smith wrote ] > ... > > > > [ C. M. Heard wrote ] > ... > > > > > - generic transport encapsulation within UDP (suggested to me > > > > > off-list by Mark Smith, based on a draft by Stuart Cheshire > > > > > et. al.). > ... > > May I make a plea for any such proposal to be carefully evaluated > against > > common practices in stateful firewalls and load balancers. I'm rather > concerned > > that the problems these middleboxes create with conventional > fragmentation > > will soon come back with UDP-encapsulated fragmentation. (There is no > problem > > in computer science that can't be made harder by recursion.) >=20 > Yes, UDP-encapsulated fragmentation (in its simplest form) has > exactly the same issue as conventional IP fragmentation -- it hides > the actual L4 header information in all but the first fragment. > Operators who filter conventional IP fragments would have exactly > the same motivation to filter UDP-encapsulated fragments. >=20 > On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: > > (2) fragments can hide transport layer protocol ports, preventing > > simple ACL filtering etc. > ... > > A general solution like SEAL (which I think in the big picture > > would be better), probably doesn't solve (2) >=20 > SEAL transport mode, as currently proposed, addresses the problem by > including port numbers in all non-initial segments:. See: >=20 > https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 Thanks for pointing this out. Another problem I have heard is that initial fragments are sometimes so small that the L4 information does not fit, or that non-initial fragments may sometimes "overlap" the initial fragment and invalidate any filtering checks that were applied to the initial fragment. SEAL addresses this by requiring that the initial fragment be at least 256 bytes in length and that all fragments except the final one contain an integer multiple of 256 byte blocks. Overlapping fragments are also explicitly forbidden. Thanks - Fred fred.l.templin@boeing.com > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rja.lists@gmail.com Mon Aug 5 14:16:17 2013 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 C77E821F9D9C for ; Mon, 5 Aug 2013 14:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrzWRR0Ts4f9 for ; Mon, 5 Aug 2013 14:16:17 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 225F021F9D5E for ; Mon, 5 Aug 2013 14:16:17 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b10so2023940qen.6 for ; Mon, 05 Aug 2013 14:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=hJhCLFcut/Dmb54aJpLPL9hHxcvGcqSwZZkDr0Prl9M=; b=AKwn40P/JP/x+Vr+SGi4Wub8kpqHQaiQop8dY87oyi0ZcBKZgrCdEvvtOENcZxCCgK 3AVksNqs+Z6Pl+NL6L/WAyOsdYe3cvXVZQpvRVOLXowY1EFZ26XQkTromr6Q7KomJLBw WIjTNYXFVDkFRuaV1FEV6ruyGQK7bpdas0DyKc1EJzzYrFMsBNdIQeJ4cjJHUBrn1Acp 8noMmCH54l1F5CQMlBX4AO5qZzyqwiqoFWseQ7Y7o9q9Yda8CkJCSf5w2nlK3P59av1v UB+hdQ+59NTcn34JTodw6cuJOmeOCo6BM+Ci6bPuLuqgRfoFJ1YnRmOj0fAmJrQElSbP o3qQ== X-Received: by 10.224.169.3 with SMTP id w3mr31005303qay.13.1375737376599; Mon, 05 Aug 2013 14:16:16 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id a2sm1457934qek.7.2013.08.05.14.16.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 14:16:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: "Deprecate" From: RJ Atkinson In-Reply-To: <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> Date: Mon, 5 Aug 2013 17:16:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) 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, 05 Aug 2013 21:16:17 -0000 On 05 Aug 2013, at 05:14 , Ole Troan wrote: > that would also be a significant change in the IPv6 architecture. Actually, suggesting that hosts need to be able to perform reassembly (which what I was suggesting) is NEITHER an architectural change NOR a change to existing IPv6 host requirements, because IPv6 hosts ALREADY have to be able to reassemble an IPv6 packet from fragments. For example, consider that an original NFS/UDP/IPv6 frame might be larger than link MTU (e.g. in a tunnelled environment with some DSL/PPPoE encapsulation overhead), relying upon IPv6 fragmentation inside the originating host to be sent through to the destination host. At the point that a receiving host is receiving fragments, each received fragment will have an IPv6 Fragmentation Header. The process of reassembly within a destination is identical, regardless of who sent the packet to that receiver. Kindly note that I have implementation experience with this in 4.4 BSD, in Cisco IOS, and in another IPv6 implementation. The receiving system's reassembly procedure does not care why it is receiving fragments, and does not need to care why, because the reassembly process is identical. Reassembly is computationally expensive, of course, which is why I earlier said I thought it desirable to pursue the ideas from C.M. Heard et alia. RFC-2460 covers reassembly by hosts in a lot of detail, primarily in Section 4.5, but also in other places. There can be no doubt that IPv6 hosts already are required to be able to perform IPv6 fragment reassembly. Some example text fragments (supporting the notion that IPv6 hosts ALREADY need to support reassembly) from RFC-2460 follow... RFC-2460, page 18: "In order to send a packet that is too large to fit in the MTU of the path to its destination, a source node may divide the packet into fragments and send each fragment as a separate packet, to be reassembled at the receiver." RFC-2460, page 21: "At the destination, fragment packets are reassembled into their original, unfragmented form, as illustrated: ..." RFC-2460, page 24: "In order to send a packet larger than a path's MTU, a node may use the IPv6 Fragment header to fragment the packet at the source and have it reassembled at the destination(s). However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). RFC-2460, page 25: "A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size." Yours, Ran Atkinson From marka@isc.org Mon Aug 5 18:14:25 2013 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 5861B21F9425 for ; Mon, 5 Aug 2013 18:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCx90RA+5DWS for ; Mon, 5 Aug 2013 18:14:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC7021F9D93 for <6man@ietf.org>; Mon, 5 Aug 2013 18:14:20 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B6766C944A for <6man@ietf.org>; Tue, 6 Aug 2013 01:14:06 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375751659; bh=FNVSwU+fKG2PX2NTNRy9mAIBjFXl3ugtqvFSapdNV8w=; h=To:From:Subject:Date; b=fR3B/af1cx+RkRc2oHL0yTOsE8RIYPYDhfDc3Q1/7ZOuH4olRfc7MIHdi08tuScB2 0g0bM1IsP9BNK0cUOWjMJwUO5bnE7PdwJfMZyBQKmY6wYa1UZgdkg311qCW4QIlUVe M8BUfyo/V8UR6RTsI//T2GqMO/3iRH1kQccn+xWU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for <6man@ietf.org>; Tue, 6 Aug 2013 01:14:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 12917160362 for <6man@ietf.org>; Tue, 6 Aug 2013 01:18:16 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6cEMD6gMtZUk for <6man@ietf.org>; Tue, 6 Aug 2013 01:18:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D9645160360 for <6man@ietf.org>; Tue, 6 Aug 2013 01:18:15 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id ACF5A16035F for <6man@ietf.org>; Tue, 6 Aug 2013 01:18:15 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 769C1380908C for <6man@ietf.org>; Tue, 6 Aug 2013 11:14:02 +1000 (EST) To: 6man@ietf.org From: Mark Andrews Subject: draft-andrews-6man-fragopt updated Date: Tue, 06 Aug 2013 11:14:02 +1000 Message-Id: <20130806011402.769C1380908C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist 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, 06 Aug 2013 01:14:25 -0000 http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Aug 5 18:41:59 2013 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 3FA6C21F9DB0 for ; Mon, 5 Aug 2013 18:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPZ3qQ5I23sn for ; Mon, 5 Aug 2013 18:41:54 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 46ABE21F9DF1 for ; Mon, 5 Aug 2013 18:41:40 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 113F1C9463; Tue, 6 Aug 2013 01:41:26 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375753299; bh=gAsh92Qrp5XsmQUmPq/RM0Qi6EcL/cjdgLOs8AK/FTo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=MZaq50GSVgbcxJaCJnknBnnjIdkVobUqwaCPYrDWCQgNnV4DIzjWCzHnb7r8l467F gqAEpCOjpDx4eiUMvyO38eed78jrHgjRbSIc90HFWUWAbhnRKioCWkPb0qf7U/a7Wh uuJ1h1MwevaQ555u4IeZn5rxVD6fm9ANeEeJp5iQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 6 Aug 2013 01:41:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 79A20160362; Tue, 6 Aug 2013 01:45:35 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Tij6PFJGxdxv; Tue, 6 Aug 2013 01:45:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 17C28160360; Tue, 6 Aug 2013 01:45:35 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A6FCE16035F; Tue, 6 Aug 2013 01:45:34 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 690C4380946F; Tue, 6 Aug 2013 11:41:22 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Mon, 05 Aug 2013 17:09:10 +0000." <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 06 Aug 2013 11:41:22 +1000 Message-Id: <20130806014122.690C4380946F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "C. M. Heard" , IPv6 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, 06 Aug 2013 01:41:59 -0000 In message <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.co m>, "Templin, Fred L" writes: > Hi Mike, > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > C. M. Heard > > Sent: Saturday, August 03, 2013 9:21 AM > > To: IPv6 > > Subject: Re: UDP+Fragmentation > > > > On Sat, 3 Aug 2013, Brian E Carpenter wrote: > > > On 02/08/2013 18:12, Mark ZZZ Smith wrote: > > > > [ Mark ZZZ Smith wrote ] > > ... > > > > > [ C. M. Heard wrote ] > > ... > > > > > > - generic transport encapsulation within UDP (suggested to me > > > > > > off-list by Mark Smith, based on a draft by Stuart Cheshire > > > > > > et. al.). > > ... > > > May I make a plea for any such proposal to be carefully evaluated > > against > > > common practices in stateful firewalls and load balancers. I'm rather > > concerned > > > that the problems these middleboxes create with conventional > > fragmentation > > > will soon come back with UDP-encapsulated fragmentation. (There is no > > problem > > > in computer science that can't be made harder by recursion.) > > > > Yes, UDP-encapsulated fragmentation (in its simplest form) has > > exactly the same issue as conventional IP fragmentation -- it hides > > the actual L4 header information in all but the first fragment. > > Operators who filter conventional IP fragments would have exactly > > the same motivation to filter UDP-encapsulated fragments. > > > > On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: > > > (2) fragments can hide transport layer protocol ports, preventing > > > simple ACL filtering etc. > > ... > > > A general solution like SEAL (which I think in the big picture > > > would be better), probably doesn't solve (2) > > > > SEAL transport mode, as currently proposed, addresses the problem by > > including port numbers in all non-initial segments:. See: > > > > https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 > > Thanks for pointing this out. Another problem I have heard is that > initial fragments are sometimes so small that the L4 information > does not fit, or that non-initial fragments may sometimes "overlap" > the initial fragment and invalidate any filtering checks that were > applied to the initial fragment. SEAL addresses this by requiring > that the initial fragment be at least 256 bytes in length and that > all fragments except the final one contain an integer multiple of > 256 byte blocks. Overlapping fragments are also explicitly forbidden. > > Thanks - Fred > fred.l.templin@boeing.com > > > Mike Heard > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- SEAL however doesn't appear to be incrementally deployable. You need the destination to be SEAL aware as it is a destination header not a destination option. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Aug 5 18:55:32 2013 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 ACC3621F9B53 for ; Mon, 5 Aug 2013 18:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSsKMMVp2K0Y for ; Mon, 5 Aug 2013 18:55:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D25D21F9AA7 for ; Mon, 5 Aug 2013 18:55:17 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E925BC94BA; Tue, 6 Aug 2013 01:55:02 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375754116; bh=qFBNTUCEPpCWeomGQ7xeDYxi3s7S7j0wJ5rN3WFlwyY=; h=Cc:From:References:Subject:In-reply-to:Date; b=pBNFJF7EvNdb2repiIHKrvxWLjS3k8zntzmauD5Cg4QAOvYzLONQAfrrCiXXGSODW VegAZegOOw19/VbGeuKoLYfQCr84CSnr4+YBYAZEOi7eM5ao7rftLIaA1QfdW1TqXm eKEpywkwI/+SFKnzAGcbANOwq3vPsR85CDG4o47s= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 6 Aug 2013 01:55:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5C2D516035F; Tue, 6 Aug 2013 01:59:12 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZXnjHsyEtcb9; Tue, 6 Aug 2013 01:59:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A0341160362; Tue, 6 Aug 2013 01:59:10 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 38D99160360; Tue, 6 Aug 2013 01:59:10 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7EE1F3809C29; Tue, 6 Aug 2013 11:54:58 +1000 (EST) From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> <20130806014122.690C4380946F@drugs.dv.isc.org> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Tue, 06 Aug 2013 11:41:22 +1000." <20130806014122.690C4380946F@drugs.dv.isc.org> Date: Tue, 06 Aug 2013 11:54:58 +1000 Message-Id: <20130806015458.7EE1F3809C29@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "C. M. Heard" , IPv6 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, 06 Aug 2013 01:55:33 -0000 In message <20130806014122.690C4380946F@drugs.dv.isc.org>, Mark Andrews writes: > > In message <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing. > co > m>, "Templin, Fred L" writes: > > Hi Mike, > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > > C. M. Heard > > > Sent: Saturday, August 03, 2013 9:21 AM > > > To: IPv6 > > > Subject: Re: UDP+Fragmentation > > > > > > On Sat, 3 Aug 2013, Brian E Carpenter wrote: > > > > On 02/08/2013 18:12, Mark ZZZ Smith wrote: > > > > > [ Mark ZZZ Smith wrote ] > > > ... > > > > > > [ C. M. Heard wrote ] > > > ... > > > > > > > - generic transport encapsulation within UDP (suggested to me > > > > > > > off-list by Mark Smith, based on a draft by Stuart Cheshire > > > > > > > et. al.). > > > ... > > > > May I make a plea for any such proposal to be carefully evaluated > > > against > > > > common practices in stateful firewalls and load balancers. I'm rather > > > concerned > > > > that the problems these middleboxes create with conventional > > > fragmentation > > > > will soon come back with UDP-encapsulated fragmentation. (There is no > > > problem > > > > in computer science that can't be made harder by recursion.) > > > > > > Yes, UDP-encapsulated fragmentation (in its simplest form) has > > > exactly the same issue as conventional IP fragmentation -- it hides > > > the actual L4 header information in all but the first fragment. > > > Operators who filter conventional IP fragments would have exactly > > > the same motivation to filter UDP-encapsulated fragments. > > > > > > On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: > > > > (2) fragments can hide transport layer protocol ports, preventing > > > > simple ACL filtering etc. > > > ... > > > > A general solution like SEAL (which I think in the big picture > > > > would be better), probably doesn't solve (2) > > > > > > SEAL transport mode, as currently proposed, addresses the problem by > > > including port numbers in all non-initial segments:. See: > > > > > > https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 > > > > Thanks for pointing this out. Another problem I have heard is that > > initial fragments are sometimes so small that the L4 information > > does not fit, or that non-initial fragments may sometimes "overlap" > > the initial fragment and invalidate any filtering checks that were > > applied to the initial fragment. SEAL addresses this by requiring > > that the initial fragment be at least 256 bytes in length and that > > all fragments except the final one contain an integer multiple of > > 256 byte blocks. Overlapping fragments are also explicitly forbidden. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Mike Heard > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > SEAL however doesn't appear to be incrementally deployable. You need s/incrementally/opportunistically/ > the destination to be SEAL aware as it is a destination header not a > destination option. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Mon Aug 5 19:56:59 2013 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 5248321F9D7C; Mon, 5 Aug 2013 19:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7L8-lbDwZFM; Mon, 5 Aug 2013 19:56:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB4121F9D7D; Mon, 5 Aug 2013 19:56:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ext-transmit-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130806025658.27861.21642.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2013 19:56:58 -0700 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, 06 Aug 2013 02:56:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-02.txt Pages : 9 Date : 2013-08-05 Abstract: Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ext-transmit-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Mon Aug 5 20:04:18 2013 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 0A1BE21F9EA9 for ; Mon, 5 Aug 2013 20:04: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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZU2lYHAnC8E for ; Mon, 5 Aug 2013 20:04:17 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 86DAC21F9377 for ; Mon, 5 Aug 2013 20:04:17 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id u10so3975914pdi.36 for ; Mon, 05 Aug 2013 20:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=N/xSienaVNwnkVf9AENHrjQZ7+K5GpI79Q3hc66upRg=; b=nV3lYHPj7F3WmSn2/pzevl5RBYh4LimCcy73UIBiYf60cYmKh3siXz/JMHxqDx7kBw MXJ/r2iOv2faRKwzv54Kj7IaHI5nQ61PkyTjhsiPk+QENs+CtL4vV5OQA6I7l3SrCLxl f1R8fvv2ZLYZ1QTsJXqaoDXxKuVp45lQO/pLZ9NY6VDwN+6KLy1d633Fx60G3rZkNUcK 0iqyK7ncPvVakY+1w4aWHTBRKO9i+SzjRP+vwbZ7X4v7HKIIyj5nCGHztucalhLGnCFd uU/FLH8mWzwqICNkEDrxnWfmiKyH9ubTIRZAi1/3/05xPKSX9O068FUdtmpEf+wZMlwL yZag== X-Received: by 10.68.211.233 with SMTP id nf9mr25937019pbc.26.1375758257159; Mon, 05 Aug 2013 20:04:17 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id ep4sm2179599pbd.35.2013.08.05.20.04.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 20:04:16 -0700 (PDT) Message-ID: <520067AF.6020103@gmail.com> Date: Tue, 06 Aug 2013 15:04:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-ext-transmit-02.txt] 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: Tue, 06 Aug 2013 03:04:18 -0000 Following the WGLC, this version has one substantive update after some off-list comments from Bjoern Zeeb: the standardised experimental extensions header types (253 and 254) are mentioned. We need to list them because they are standardised, but we have exempted them from the "allow by default" set since they are experimental Brian & Sheng -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-ext-transmit-02.txt Date: Mon, 05 Aug 2013 19:56:58 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-02.txt Pages : 9 Date : 2013-08-05 Abstract: Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From heard@pobox.com Mon Aug 5 20:12:49 2013 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 9B24C21F9A2D for ; Mon, 5 Aug 2013 20:12:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG17IKRQ9qyW for ; Mon, 5 Aug 2013 20:12:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0369821F99FD for ; Mon, 5 Aug 2013 20:12:43 -0700 (PDT) Received: (qmail 25447 invoked from network); 5 Aug 2013 20:12:40 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Aug 2013 20:12:40 -0700 Date: Mon, 5 Aug 2013 20:12:40 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: UDP+Fragmentation In-Reply-To: <20130806014122.690C4380946F@drugs.dv.isc.org> Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> <20130806014122.690C4380946F@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 06 Aug 2013 03:12:49 -0000 On Tue, 6 Aug 2013, Mark Andrews wrote: > SEAL however doesn't appear to be incrementally deployable. You need > the destination to be SEAL aware as it is a destination header not a > destination option. Except for the hop-by-hop option proposal in http://tools.ietf.org/id/draft-andrews-6man-fragopt all of the proposals informally floated so far suffer from that disadvantage. That includes a new version of UDP with segmentation, generic transport encapsulation within UDP, and SEAL. As mentioned elsewhere, generic transport encapsulation within UDP does not really address the problem, as it lacks L4 header information in all fragments except the first (see http://www.ietf.org/mail-archive/web/ipv6/current/msg18687.html). The hop-by-hop option proposal and SEAL suffer from a security hole: the L4 information is duplicated, and thereby creating a security hole. An attacker could put one thing in the option or in the SEAL header (to be interpreted by a middlebox) and another thing in the actual transport header (to be interpreted by an end system). A new version of UDP would not have this problem, as the same header would be interpreted by both the middlebox and the end system. The hop-by-hop option proposal suffers from another problem. Quoting from http://tools.ietf.org/id/draft-ietf-6man-ext-transmit-02.txt Section 2.2: It is to be expected that high performance routers will either ignore it, or assign packets containing it to a slow processing path. Designers planning to use a Hop-by-Hop option need to be aware of this likely behaviour. The problem in the present case arises if high performance routers put packets with hop-by-hop options on a slow path. //cmh From marka@isc.org Mon Aug 5 20:35:13 2013 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 0373221F9DC7 for ; Mon, 5 Aug 2013 20:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaV6XoXw2v09 for ; Mon, 5 Aug 2013 20:35:08 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF5521F9A38 for ; Mon, 5 Aug 2013 20:35:08 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id EEA3DC9497; Tue, 6 Aug 2013 03:34:54 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375760108; bh=BUo6GZ9lvRq5LkMH8V1QkwJ2ZBiISrr41sINNbghTNs=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=d/T3nJ5QaQT8cA2oQwN/qVZ3c/6/DY8rMANw01GiqZ39oTtDf9TN14Yk18muXwEEz dNiavJKX16pEkIpI3kDoLmcZ1cS2tJhK0WptF0hNl8ep3qfEmZtZyQTquGqNi+6S4T LSFclJqB0ipoCk2hB7hyIrHWasgg3MkP7CVfSg44= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 6 Aug 2013 03:34:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B8FA4160116; Tue, 6 Aug 2013 03:39:04 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id sSyPDSn1gV0c; Tue, 6 Aug 2013 03:39:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 16A90160360; Tue, 6 Aug 2013 03:39:04 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id DA71E160116; Tue, 6 Aug 2013 03:39:03 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 393DF380D3C4; Tue, 6 Aug 2013 13:34:51 +1000 (EST) To: "C. M. Heard" From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> <20130806014122.690C4380946F@drugs.dv.isc.org> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Mon, 05 Aug 2013 20:12:40 -0700." Date: Tue, 06 Aug 2013 13:34:51 +1000 Message-Id: <20130806033451.393DF380D3C4@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 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, 06 Aug 2013 03:35:13 -0000 In message , "C. M. Heard" writes: > On Tue, 6 Aug 2013, Mark Andrews wrote: > > SEAL however doesn't appear to be incrementally deployable. You need > > the destination to be SEAL aware as it is a destination header not a > > destination option. > > Except for the hop-by-hop option proposal in > > http://tools.ietf.org/id/draft-andrews-6man-fragopt > > all of the proposals informally floated so far suffer from that > disadvantage. That includes a new version of UDP with segmentation, > generic transport encapsulation within UDP, and SEAL. > > As mentioned elsewhere, generic transport encapsulation within UDP > does not really address the problem, as it lacks L4 header > information in all fragments except the first (see > http://www.ietf.org/mail-archive/web/ipv6/current/msg18687.html). > > The hop-by-hop option proposal and SEAL suffer from a security hole: > the L4 information is duplicated, and thereby creating a security > hole. An attacker could put one thing in the option or in the SEAL > header (to be interpreted by a middlebox) and another thing in the > actual transport header (to be interpreted by an end system). A new > version of UDP would not have this problem, as the same header would > be interpreted by both the middlebox and the end system. Actually draft-andrews-6man-fragopt doesn't as the option is in all fragments and policy devices can decide whether to pass mis-matching initial fragments or not. I don't see policy devices passing non-initial fragments where you can't do this check. A filter rule like "pass dstport 80 srcport any" would enforce that destination ports matched but wouldn't care that the source ports didn't. > The hop-by-hop option proposal suffers from another problem. Quoting > from http://tools.ietf.org/id/draft-ietf-6man-ext-transmit-02.txt > Section 2.2: > > It is to be expected that high performance routers will either > ignore it, or assign packets containing it to a slow processing > path. Designers planning to use a Hop-by-Hop option need to be > aware of this likely behaviour. > > The problem in the present case arises if high performance routers > put packets with hop-by-hop options on a slow path. Well properly design your router. It is a design choice to slow path hop-by-hop processing. > //cmh > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Mon Aug 5 20:37:25 2013 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 B4A1621F9FF4; Mon, 5 Aug 2013 20:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2dKHdjpkRYb; Mon, 5 Aug 2013 20:37:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6521F9A38; Mon, 5 Aug 2013 20:37:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ug-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130806033725.7325.87429.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2013 20:37:25 -0700 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, 06 Aug 2013 03:37:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-02.txt Pages : 11 Date : 2013-08-05 Abstract: The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no generic meaning and that the identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those bits apply only to interface identifiers that are derived from an IEEE link-layer address. It updates RFC 4291 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ug There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ug-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ug-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Mon Aug 5 20:40:29 2013 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 7D1D121F9A30 for ; Mon, 5 Aug 2013 20:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CQOo7DmnCtZ for ; Mon, 5 Aug 2013 20:40:28 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C6FF821F9958 for ; Mon, 5 Aug 2013 20:40:28 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 5so3991363pdd.20 for ; Mon, 05 Aug 2013 20:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=DwDCQLANTyoRZ8dtnnWhS1KiBGRnIBewo6WSOBV5VCw=; b=BWsQ1e6f377Jm2aKfRTvEKJbF9wVxcWE1nYg0o/3dsLRITvF9QmVG/rWM9PWItLi6K rJKPLdlb3udKxCgsmSqOTlBLs1VLd1yrmWO5U5cUBd8Thc0kTTCLRGLfBXdRVNHy/SqL bP5sSK/edJQhkPkB76a0Fyfl8Ls4f5Z97yoQ6KSPqPks3HvN4j9jGG5ZwfnOWb3q1bYW I8SJrJxpzKHIDAunjFEVNWM/jmj0xF/vdMdcI8RaGAtQzJ4PlBwtk3AFd+kTwBq3Vi6U cSHCaZWuBddm9s06SBul/7iRVvWcK42ER4jPqJNi+W5tFjA7XwXkG2rqrU0xkxU44XYg LSfQ== X-Received: by 10.66.234.232 with SMTP id uh8mr780492pac.155.1375760425949; Mon, 05 Aug 2013 20:40:25 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id tr10sm2351160pbc.22.2013.08.05.20.40.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 20:40:25 -0700 (PDT) Message-ID: <52007027.9050800@gmail.com> Date: Tue, 06 Aug 2013 15:40:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-ug-02.txt] 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: Tue, 06 Aug 2013 03:40:29 -0000 We incorporated WG Last Call comments: removed the open issue, clarified IEEE bit names, clarified DAD text as discussed, updated references, minor editorial corrections. Also, we have one more question for the WG: should we delete the third paragraph of the IANA Considerations? It doesn't seem to add much value. Brian & Sheng -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-ug-02.txt Date: Mon, 05 Aug 2013 20:37:25 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-02.txt Pages : 11 Date : 2013-08-05 Abstract: The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no generic meaning and that the identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those bits apply only to interface identifiers that are derived from an IEEE link-layer address. It updates RFC 4291 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ug There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ug-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ug-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From heard@pobox.com Mon Aug 5 20:53:32 2013 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 03E1A11E80D1 for ; Mon, 5 Aug 2013 20:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AndklG77ZnrA for ; Mon, 5 Aug 2013 20:53:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B121F9FE5 for ; Mon, 5 Aug 2013 20:53:26 -0700 (PDT) Received: (qmail 5556 invoked from network); 5 Aug 2013 20:53:23 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Aug 2013 20:53:23 -0700 Date: Mon, 5 Aug 2013 20:53:23 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: UDP+Fragmentation (was: "Deprecate") In-Reply-To: Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 06 Aug 2013 03:53:32 -0000 On Thu, 1 Aug 2013, C. M. Heard wrote: > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > I agree that C.M. Heard's ideas should be explored > > in more detail by the IETF. The idea was essentially UDP with segmentation fields, which would require a new protocol number. In an offline discussion with Mark Smith and I kicked around an idea for an alternate version not requiring a new protocol number, but relying instead on the redundancy of the UDP Length field. The UDP Length field is not actually needed; TCP does not have one but rather relies on the length reported by the IP layer. Under current standards, the UDP Length field must be at least 8 and cannot exceed the IP payload length minus the combined length of any extension headers -- let's call this the L4 length from IP. Existing implementations are supposed to drop UDP datagrams that fail this check, and all the ones I know of do so. The question then arises whether it might reasonably be possible to re-purpose the case UDP Length > L4 length from IP to mean a segmented UDP datagram. In that case 8 <= UDP Length <= L4 length from IP would be intepreted as a standard unsegmented UDP datagram, as is it now. That's the case pictured below. Note that if the L4 length indicated by the IP layer exceeds the UDP Length, then the extra octets would be discarded and are not delivered to the application; that is the behavior of the implementations I know of. 0 15 16 31 +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Length <= L4 length from IP | Checksum | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | data octets ... +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... Now suppose that we have a long UDP datagram that we want to send in segments. We set the Length and Checksum fields as usual, and then cut the datagram into segments, each of which looks like this: 0 15 16 31 +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Length > L4 length from IP | Checksum | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | (reserved = 0) | Segment Offset |Res|M| +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ | data octets ... +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... We put the same UDP header in each segment, so (if we take some care in how we choose the length of the segments) each one will have a UDP Length field that is greater than the IP payload length minus the combined length of any extension headers. Implementations that conform to the current specifications should discard these segments, and so should not mistakenly consider the segmentation fields as part of the application data. That should make it possible for segmented UDP datagrams to safely coexist with conventional unsegmented one, without getting a new protocol number. Possible downsides: some middleboxes may filter such "erroneous" datagrams, and some existing erroneous implementations may fail to do the checks they should and might mistake these segments for ordinary UDP datagrams. Note that this idea does not work with UDP-lite, which replaces the Length field with a Checksum Coverage field. That could easily be too short to exceed the L4 length from IP. Mike Heard From Grant.Welch@riverbed.com Mon Aug 5 13:42:08 2013 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 1B08A21F9BBF for ; Mon, 5 Aug 2013 13:42:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFu+KbXgCM+j for ; Mon, 5 Aug 2013 13:42:04 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8611721F9DF0 for ; Mon, 5 Aug 2013 13:42:02 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 05 Aug 2013 13:42:01 -0700 Received: from SFO1EXC-MBXP12.nbttech.com ([fe80::6d89:92e0:1030:143c]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%15]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 13:42:01 -0700 From: Grant Welch To: Brian E Carpenter , Gandhar Gokhale Subject: RE: Question regarding RFC2460, section 4.7 "No Next Header" Thread-Topic: Question regarding RFC2460, section 4.7 "No Next Header" Thread-Index: Ac6PnBHbpAkmMPYtSQm9YQFr78juUwAYpOMAAHRfAAAAAdrAAAAPb16w Date: Mon, 5 Aug 2013 20:42:00 +0000 Message-ID: <629FA04445464743B6C3BACCE6A250EE9A70959E@sfo1exc-mbxp12.nbttech.com> References: <629FA04445464743B6C3BACCE6A250EE9A708207@sfo1exc-mbxp12.nbttech.com> <51FC1F06.7070600@gmail.com> <51FF386C.3000302@gmail.com> In-Reply-To: <51FF386C.3000302@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 05 Aug 2013 21:51:17 -0700 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, 05 Aug 2013 20:42:08 -0000 VGhhbmsgeW91IGJvdGggZm9yIHlvdXIgcmVzcG9uc2VzLiBJdCBzZWVtcyB0aGF0IEkgd2FzIHNp bXBseSBvdmVyIHRoaW5raW5nIHRoZSBkZWNpc2lvbiBwcm9jZXNzLg0KDQpBcyBmYXIgYXMgdGhl IGltcGxpY2F0aW9ucywgQnJpYW4sIEkgdGhpbmsgeW91IGFyZSByaWdodC4gRWl0aGVyIHRoZSBO ZXR3b3JrIEFkbWluIHdpbGwgZWl0aGVyIGJlIHBlcm1pc3NpdmUtdG8gb3IgcmVzdHJpY3RpdmUt dG8gYm90aCBldmVudHMgKCJwaGFudG9tIGJ5dGVzIiBhbmQgdW5yZWdpc3RlcmVkIGV4dGVuc2lv biBoZWFkZXJzKS4gVGhlcmUncyB1bmxpa2VseSB0byBiZSBtdWNoIG1pZGRsZSBncm91bmQuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0NCi0gZ3JhbnQgd2VsY2gNCi0gZ3dlbGNoQHJpdmVyYmVkLmNv bQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiBNb25kYXks IEF1Z3VzdCAwNSwgMjAxMyAxMjozMCBBTQ0KPiBUbzogR2FuZGhhciBHb2toYWxlDQo+IENjOiBH cmFudCBXZWxjaDsgaXB2NkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUXVlc3Rpb24gcmVnYXJk aW5nIFJGQzI0NjAsIHNlY3Rpb24gNC43ICJObyBOZXh0IEhlYWRlciINCj4gDQo+IE9uIDA1LzA4 LzIwMTMgMTY6MzcsIEdhbmRoYXIgR29raGFsZSB3cm90ZToNCj4gPiBIaSwNCj4gPiBJIHJlbWVt YmVyIGhhdmluZyByZWFkIGluIG9uZSBvZiB0aGUgY29udmVyc2F0aW9ucyB0aGF0IHRoZSBpbnRl bnRpb24NCj4gPiBmb3IgdGhpcyB3YXMgc3VwcG9ydGluZyBleHBlcmltZW50YXRpb24gd2l0aCBu ZXcgdHJhbnNwb3J0IGxheWVyDQo+IHByb3RvY29scy4NCj4gPiBIYXZpbmcgdGhlIG5vLW5leHQg aGVhZGVyIGZvbGxvd2VkIGJ5IHRoZSBleHBlcmltZW50YWwgcHJvdG9jb2wgYW5kDQo+ID4gcGF5 bG9hZCB3b3VsZCBhbGxvdyB0aGUgZW5kIHBvaW50cyB0byB0ZXN0IHRoZSBuZXcgcHJvdG9jb2wg d2l0aG91dA0KPiA+IHRoZSBuZXR3b3JrIHJlcXVpcmluZyB0byBrbm93IGFib3V0IGl0Lg0KPiAN Cj4gVGhlIG5ldHdvcmsgaXNuJ3QgcmVxdWlyZWQgdG8ga25vdyBhYm91dCBuZXcgZXh0ZW5zaW9u IGhlYWRlcnMgZWl0aGVyLg0KPiBJIGNhbid0IGltYWdpbmUgYSBmaXJld2FsbCB0aGF0IGRpc2Nh cmRzIHVua25vd24gZXh0ZW5zaW9uIGhlYWRlcnMgdGhhdA0KPiBkb2Vzbid0IGFsc28gZGlzY2Fy ZCBwaGFudG9tIGJ5dGVzLg0KPiANCj4gICAgQnJpYW4NCj4gDQo+ID4NCj4gPg0KPiA+IE9uIFNh dCwgQXVnIDMsIDIwMTMgYXQgMjozNSBBTSwgQnJpYW4gRSBDYXJwZW50ZXIgPA0KPiA+IGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPj4gT24gMDMvMDgvMjAxMyAw NDo0NSwgR3JhbnQgV2VsY2ggd3JvdGU6DQo+ID4+PiBUbyB3aG9tIGl0IGNvbmNlcm5zLA0KPiA+ Pj4NCj4gPj4+IEkgZm91bmQgdGhlIGxhdHRlciBwb3J0aW9uIG9mIHRoZSBzZWN0aW9uIG9mIGlu dGVyZXN0Lg0KPiA+Pj4NCj4gPj4+ICAgIC4uLklmIHRoZSBQYXlsb2FkIExlbmd0aCBmaWVsZCBv ZiB0aGUgSVB2NiBoZWFkZXIgaW5kaWNhdGVzIHRoZQ0KPiA+Pj4gICAgcHJlc2VuY2Ugb2Ygb2N0 ZXRzIHBhc3QgdGhlIGVuZCBvZiBhIGhlYWRlciB3aG9zZSBOZXh0IEhlYWRlcg0KPiBmaWVsZA0K PiA+Pj4gICAgY29udGFpbnMgNTksIHRob3NlIG9jdGV0cyBtdXN0IGJlIGlnbm9yZWQsIGFuZCBw YXNzZWQgb24gdW5jaGFuZ2VkDQo+IGlmDQo+ID4+PiAgICB0aGUgcGFja2V0IGlzIGZvcndhcmRl ZC4NCj4gPj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIGlzIHNpbXBseSBhbiBleHByZXNzaW9u IG9mIHRoZSBnZW5lcmFsDQo+ID4+IHByaW5jaXBsZSB0aGF0IHRoZSBuZXR3b3JrIHNob3VsZCBi ZSB0cmFuc3BhcmVudCB0byBwYWNrZXRzIGZyb20gZW5kDQo+IHRvIGVuZC4NCj4gPj4gSSBkb3Vi dCB0aGVyZSBpcyBhbnl0aGluZyBtb3JlIHRvIGl0IHRoYW4gdGhhdC4gSXQgZ29lcyB3aXRoIHRo ZQ0KPiA+PiBnZW5lcmFsIHJlcXVpcmVtZW50IHRoYXQgZm9yd2FyZGluZyBub2RlcyBtdXN0IHRy YW5zbWl0IGFsbCBleHRlbnNpb24NCj4gPj4gaGVhZGVycyB0cmFuc3BhcmVudGx5ICh0aGUgdG9w aWMgb2YgZHJhZnQtaWV0Zi02bWFuLWV4dC10cmFuc21pdCkuDQo+ID4+DQo+ID4+ICAgIEJyaWFu DQo+ID4+DQo+ID4+PiBXaGljaCBsZWQgbWUgdG8gcG9uZGVyIHdoYXQgdGhlIHVzZSBjYXNlcyB3 ZXJlIGluIG1pbmQgdG8gcHJlc2VydmUNCj4gPj4+IGRhdGENCj4gPj4gdGhhdCBvbmUgY291bGQg YXJndWUgYXMgcG90ZW50aWFsbHkgc3VwZXJmbHVvdXMuIEkgZmVlbCBsaWtlIEkgaGF2ZQ0KPiA+ PiBkb25lIGR1ZSBkaWxpZ2VuY2UgaW4gdHJ5aW5nIHRvIGFuc3dlciB3aHksIGJ1dCBoYXZlIGNv bWUgdXAgZW1wdHkuDQo+ID4+IEFuZCwgSSBjb3VsZG4ndCBmaW5kIGEgYmV0dGVyIHBsYWNlIHRv IHBvc3QgbXkgcXVlc3Rpb24sIHNvIHlvdSB3aWxsDQo+ID4+IGhhdmUgdG8gYWNjZXB0IG15IGRl ZXBlc3QgYXBvbG9naWVzIGlmIHRoaXMgaXMgdGhlIGNvcnJlY3QgZm9ydW0gdG8NCj4gPj4gYXNr IGl0LiAoTXkgc2VhcmNoZXMgaW5jbHVkZWQgR29vZ2xlLCBwdWJsaXNoZWQgcGFwZXJzLCBhbmQg dGhlDQo+ID4+IGlldGYub3JnIHdlYnNpdGUuKQ0KPiA+Pj4gVG8gbW9yZSBmb3JtYWxseSBwaHJh c2UgbXkgcXVlc3Rpb25zIGxldCBtZSBleHRyYXBvbGF0ZSBteQ0KPiA+PiBpbnRlcnByZXRhdGlv bi4gUkZDMjQ2MCwgc2VjdGlvbiA0LjcgbWFrZXMgaXQgbmVjZXNzYXJ5IHRvIHByZXNlcnZlDQo+ ID4+IHRoZSBJUCBwYWNrZXQgcGF5bG9hZCByZWdhcmRsZXNzIG9mIHRoZSBmYWN0IHRoYXQgdGhl ICdOZXh0IEhlYWRlcicNCj4gPj4gZmllbGQgc2VlbXMgdG8gaGF2ZSBzdGF0ZWQgdGhhdCB0aGVy ZSB3aWxsIGJlIG5vIG1vcmUgZGF0YS4gVGhhdCBpcw0KPiA+PiBub3QgbmVjZXNzYXJpbHkgdHJ1 ZSBvZiBjb3Vyc2UgYmVjYXVzZSBzZW1hbnRpY2FsbHkgc3BlYWtpbmcgaXQncw0KPiA+PiBqdXN0 IHNheWluZyB0aGVyZSdzIG5vIG1vcmUgaGVhZGVycy4gU28sIG9uZSBtaWdodCBmb3JnbyBhbGwg c3RhbmRhcmQNCj4gPj4gb3IgZG9jdW1lbnRlZCB0cmFuc3BvcnQgbGV2ZWwgcHJvdG9jb2xzIGFu ZCB1c2UgdGhlICdObyBOZXh0IEhlYWRlcicNCj4gPj4gb3B0aW9uIHRvIHNpZ25hbCB0byBuZXR3 b3JrIGhhcmR3YXJlIHRvIHN0b3AgZnVydGhlciBpbnRlcnByZXRhdGlvbg0KPiA+PiBvZiB0aGUg ZGF0YSBhbmQgdG8gZm9yY2UgbWlkZGxlYm94ZXMgdG8gcHJlc2VydmUgdGhlIGRhdGEuDQo+ID4+ PiBJcyB0aGlzIGEgY29ycmVjdCBpbnRlcnByZXRhdGlvbj8gQXJlIHRoZXJlIG90aGVyIHJhbWlm aWNhdGlvbnMgdGhhdA0KPiA+Pj4gSQ0KPiA+PiBhbSBtaXNzaW5nPw0KPiA+Pj4gVGhpcyBwb3J0 aW9uIG9mIHRoZSBSRkMgd2FzIHdyaXR0ZW4gYmFjayBpbiAxOTk1IGFuZCBJIGNhbm5vdCBmaW5k DQo+ID4+PiBhbnkNCj4gPj4gZG9jdW1lbnRhdGlvbiBhYm91dCB0aGUgZGVjaXNpb24gcHJvY2Vz cyB0byBhbWVuZCBpdCBpbi4gRG9lcyBhbnlvbmUNCj4gPj4gaGF2ZSBhbnkgcmVjb2xsZWN0aW9u cyBhYm91dCB0aGUgcHJvY2Vzcz8gSWYgdGhlcmUgd2VyZSBleHBlY3RlZCB1c2UNCj4gPj4gY2Fz ZXMgYXQgdGhlIHRpbWU/DQo+ID4+PiBBZ2FpbiwgbXkgYXBvbG9naWVzIGlmIHRoaXMgaXMgdGhl IHdyb25nIGZvcnVtLiBJZiBzbywgbWlnaHQgeW91DQo+ID4+PiBkaXJlY3QNCj4gPj4gbWUgdG93 YXJkIHRoZSBjb3JyZWN0IG9uZT8NCj4gPj4+IFRoYW5rcyBmb3IgeW91ciB0aW1lLg0KPiA+Pj4N Cj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0gZ3JhbnQgd2VsY2gNCj4gPj4+IC0g Z3dlbGNoQHJpdmVyYmVkLmNvbQ0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmcgQWRt aW5pc3RyYXRpdmUNCj4gPj4+IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pg0KPiA+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPj4gaXB2NkBp ZXRmLm9yZw0KPiA+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4NCj4g Pg0KPiA+DQo= From otroan@employees.org Tue Aug 6 03:52:51 2013 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 0CB0521F9DB8 for ; Tue, 6 Aug 2013 03:52:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgtawu1i8l2y for ; Tue, 6 Aug 2013 03:52:50 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 3021721F9633 for ; Tue, 6 Aug 2013 03:52:47 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-74.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 26CD35F8A; Tue, 6 Aug 2013 03:52:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: "Deprecate" From: Ole Troan In-Reply-To: <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> Date: Tue, 6 Aug 2013 12:52:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1508) 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, 06 Aug 2013 10:52:51 -0000 >> that would also be a significant change in the IPv6 architecture. >=20 > Actually, suggesting that hosts need to be able to perform > reassembly (which what I was suggesting) is NEITHER an=20 > architectural change NOR a change to existing IPv6 host requirements,=20= > because IPv6 hosts ALREADY have to be able to reassemble an IPv6=20 > packet from fragments. the significant change to the architecture in your proposal, is that = intermediate routers (in this case the tunnel ingress) are allowed to fragment packets. cheers, Ole >=20 > For example, consider that an original NFS/UDP/IPv6 frame might be=20 > larger than link MTU (e.g. in a tunnelled environment with some=20 > DSL/PPPoE encapsulation overhead), relying upon IPv6 fragmentation=20 > inside the originating host to be sent through to the destination=20 > host. >=20 > At the point that a receiving host is receiving fragments, each > received fragment will have an IPv6 Fragmentation Header. The > process of reassembly within a destination is identical, > regardless of who sent the packet to that receiver. =20 >=20 > Kindly note that I have implementation experience with this=20 > in 4.4 BSD, in Cisco IOS, and in another IPv6 implementation. =20 > The receiving system's reassembly procedure does not care why=20 > it is receiving fragments, and does not need to care why,=20 > because the reassembly process is identical. Reassembly is=20 > computationally expensive, of course, which is why I earlier said=20 > I thought it desirable to pursue the ideas from C.M. Heard et alia. >=20 > RFC-2460 covers reassembly by hosts in a lot of detail,=20 > primarily in Section 4.5, but also in other places. =20 > There can be no doubt that IPv6 hosts already are > required to be able to perform IPv6 fragment reassembly. >=20 > Some example text fragments (supporting the notion that IPv6 > hosts ALREADY need to support reassembly) from RFC-2460 follow... >=20 > RFC-2460, page 18: > "In order to send a packet that is too large to fit=20 > in the MTU of the path to its destination, a source node=20 > may divide the packet into fragments and send each fragment=20 > as a separate packet, to be reassembled at the receiver." >=20 > RFC-2460, page 21: > "At the destination, fragment packets are reassembled=20 > into their original, unfragmented form, as illustrated: > ..." >=20 > RFC-2460, page 24: > "In order to send a packet larger than a path's MTU, a node=20 > may use the IPv6 Fragment header to fragment the packet at=20 > the source and have it reassembled at the destination(s). =20 > However, the use of such fragmentation is discouraged in any=20 > application that is able to adjust its packets to fit the=20 > measured path MTU (i.e., down to 1280 octets). >=20 > RFC-2460, page 25: > "A node must be able to accept a fragmented packet that,=20 > after reassembly, is as large as 1500 octets. A node is=20 > permitted to accept fragmented packets that reassemble=20 > to more than 1500 octets. An upper-layer protocol or=20 > application that depends on IPv6 fragmentation to send=20 > packets larger than the MTU of a path should not send packets=20 > larger than 1500 octets unless it has assurance that the=20 > destination is capable of reassembling packets of that=20 > larger size." >=20 > Yours, >=20 > Ran Atkinson >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Tue Aug 6 07:25:22 2013 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 281D721F99FB for ; Tue, 6 Aug 2013 07:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf7GEtaGOtn0 for ; Tue, 6 Aug 2013 07:25:16 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0021F9FA7 for ; Tue, 6 Aug 2013 07:25:10 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76EP9WI019325 for ; Tue, 6 Aug 2013 07:25:09 -0700 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76EP8WK019304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 6 Aug 2013 07:25:08 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.77]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 07:25:08 -0700 From: "Templin, Fred L" To: "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOklLP4SMEeC7qyE6QlR5ihkVRYZmIOxgA Date: Tue, 6 Aug 2013 14:25:07 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E0673@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> <20130806014122.690C4380946F@drugs.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 14:25:22 -0000 Hi Mike, > The hop-by-hop option proposal and SEAL suffer from a security hole: > the L4 information is duplicated, and thereby creating a security > hole. An attacker could put one thing in the option or in the SEAL > header (to be interpreted by a middlebox) and another thing in the > actual transport header (to be interpreted by an end system). A new > version of UDP would not have this problem, as the same header would > be interpreted by both the middlebox and the end system. For SEAL, that is a bug in the spec which is easily fixed. What it should say is that the initial segment does not carry the L4 information from the transport layer protocol so the middlebox interprets only based on the actual transport header. It is only in non-initial segment that the transport layer information needs to appear in the header. I'll fix that. Thanks - Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Tue Aug 6 08:02:57 2013 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 CEB3D21E805A for ; Tue, 6 Aug 2013 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjkYGd9rLlQy for ; Tue, 6 Aug 2013 08:02:51 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66921F9C52 for ; Tue, 6 Aug 2013 08:02:51 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76F2pJd015247 for ; Tue, 6 Aug 2013 08:02:51 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76F2nFZ015223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 6 Aug 2013 08:02:50 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.239]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 08:02:49 -0700 From: "Templin, Fred L" To: IPv6 Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOklLP4SMEeC7qyE6QlR5ihkVRYZmIOxgAgAAGrYA= Date: Tue, 6 Aug 2013 15:02:48 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E06ED@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <1375419323.69865.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1375423948.4442.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51FC37D1.3060009@gmail.com> <2134F8430051B64F815C691A62D983180DF7A6@XCH-BLV-504.nw.nos.boeing.com> <20130806014122.690C4380946F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E0673@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E0673@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 15:02:58 -0000 Hi, In these discussions, it seems like we might be losing sight of what problem or problems we are trying to address. The focus of the non-SEAL proposals seems to be solely on making L4 port information available in non-initial fragments. Important yes, but there are other problems that need to be addressed. For example, for the tiny fragment attack SEAL mandates that the initial fragment be at least 256 bytes in length such that a tiny fragment attack is not physically possible. Non initial fragments are also physically constrained such that they cannot begin before the 256th byte, so an overlapping fragment that corrupts the transport layer headers is not possible. SEAL also provides a path MTU probing facility to determine when the path MTU is large enough to suspend the segmentation and reassembly process. SEAL also works in the absence of ICMP Packet Too Big messages. It also provides a tunnel-mode as well as transport-mode of operation, and supports all combinations of IPv6/IPv4 tunneling (6-in-6, 4-in-6, 6-in-4, 4-in-4). And, SEAL is also a universal encapsulation framework that works with any existing transport layer protocol that needs to use it. So, there are lots of issues to be addressed - not just one. Thanks - Fred fred.l.templin@boeing.com From rja.lists@gmail.com Tue Aug 6 10:06:07 2013 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 9F9A121F9EF5 for ; Tue, 6 Aug 2013 10:06:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edJr3xflYh2T for ; Tue, 6 Aug 2013 10:06:07 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 24D0021F9EED for ; Tue, 6 Aug 2013 10:06:07 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so1779925qab.7 for ; Tue, 06 Aug 2013 10:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=csutFmyPVCSzE2izVHhaZwNu1QCkkPkgmbNwcJ9r0Qs=; b=dukET3eYyWSg+yVt2XpENn/BL7839Kolw+W5WZ36LMH/oh2p1kc3OaI4HQ6f5t8F+j KrN2L5BznyfkUl6X0LAV3QZpdpUeOrLrTPzZyY8wKe4JqdxSoBJSl/GCqSmKLKOOWTTL UiHfYQ2cN/4FCQv1yXsAv7lyFiy7rRo9JnI4Io75WRTr7kNpciMQexEWLN5TKvwXpsu6 FFrcfsPZDyGzjeHyKx69BipQE6F9ZA4Jdp7BbuModNZN9TzdcxndXP2ljjY9L61eNe8T xRVgMmM9X3u8HmvRRnpPZx00HIkHZH53O6dkXfVzgFqp3kx8WyidIksp2I76B54iIBG/ wY9w== X-Received: by 10.49.83.105 with SMTP id p9mr3248462qey.11.1375808766409; Tue, 06 Aug 2013 10:06:06 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id g9sm5568200qaz.4.2013.08.06.10.06.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 10:06:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: "Deprecate" From: RJ Atkinson In-Reply-To: Date: Tue, 6 Aug 2013 13:06:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: <44DD17CB-FC14-4E21-A350-4201AEF1CD78@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) 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, 06 Aug 2013 17:06:07 -0000 On 06 Aug 2013, at 06:52 , Ole Troan wrote: > the significant change to the architecture in your proposal, > is that intermediate routers (in this case the tunnel ingress) > are allowed to fragment packets. That is a misunderstanding of what I wrote. Tunnel ingress devices already are allowed to fragment IPv6 packets by various IETF approved tunnelling specifications, as you have agreed. To be VERY clear, I am not proposing ANY change to specs. If one thinks I have proposed a specification change, that is a misunderstanding. I am simply observing that end systems ALREADY are required to support IPv6 fragment reassembly -- e.g., for reasons unrelated to tunnels. Yours, Ran From Fred.L.Templin@boeing.com Tue Aug 6 10:21:25 2013 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 F326E21F9F9A for ; Tue, 6 Aug 2013 10:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEjLLZKR24a9 for ; Tue, 6 Aug 2013 10:21:16 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74B21F9EA8 for ; Tue, 6 Aug 2013 10:21:13 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76HLBuQ029649 for ; Tue, 6 Aug 2013 12:21:11 -0500 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76HLANn029362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 6 Aug 2013 12:21:11 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.33]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 10:21:10 -0700 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOksdEb4hQ1uPQyEGB8hnfCjzuiZmIajFQ Date: Tue, 6 Aug 2013 17:21:09 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E085F@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> <44DD17CB-FC14-4E21-A350-4201AEF1CD78@gmail.com> In-Reply-To: <44DD17CB-FC14-4E21-A350-4201AEF1CD78@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 17:21:25 -0000 > Tunnel ingress devices already are allowed to fragment > IPv6 packets by various IETF approved tunnelling > specifications, as you have agreed. Fragmentation of the inner packet before encapsulation is different from fragmentation of the outer packet after encapsulation. Ole was referring to the latter case, where the tunnel ingress is acting as a host when it fragments the encapsulated packet and the tunnel egress gets to reassemble. The tunnel MUST uphold the IPv6 minMTU of 1280; otherwise, it would be a degenerate link. The tunnel SHOULD allow larger packets through when it can do so without resulting in an MTU-related black hole; otherwise, it would fail to take advantage of larger path MTUs when they are available. And, the whole thing needs to work when ICMP PTBs are unavailable. This discussion is coming full circle to what we discussed earlier when we already established that tunnels MUST support the IPv6 minMTU even if some fragmentation and reassembly is necessary. Thanks - Fred fred.l.templin@boeing.com From rbonica@juniper.net Tue Aug 6 11:49:25 2013 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 DEC2D21F997A for ; Tue, 6 Aug 2013 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.809 X-Spam-Level: X-Spam-Status: No, score=-101.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRtqgM9D7g8f for ; Tue, 6 Aug 2013 11:49:20 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC9811E80F9 for ; Tue, 6 Aug 2013 11:49:19 -0700 (PDT) Received: from mail136-db9-R.bigfish.com (10.174.16.225) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 18:49:18 +0000 Received: from mail136-db9 (localhost [127.0.0.1]) by mail136-db9-R.bigfish.com (Postfix) with ESMTP id 02A02602FB; Tue, 6 Aug 2013 18:49:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail136-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(377454003)(51704005)(24454002)(81342001)(76482001)(47976001)(4396001)(83072001)(31966008)(74706001)(81542001)(47736001)(47446002)(69226001)(54356001)(74876001)(19580395003)(50986001)(76786001)(46102001)(66066001)(83322001)(74366001)(65816001)(19580385001)(561944002)(76576001)(51856001)(33646001)(74662001)(80022001)(74316001)(59766001)(74502001)(80976001)(79102001)(77982001)(56816003)(49866001)(53806001)(56776001)(76796001)(63696002)(54316002)(19580405001)(16406001)(77096001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB241; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail136-db9 (localhost.localdomain [127.0.0.1]) by mail136-db9 (MessageSwitch) id 1375814956395008_8070; Tue, 6 Aug 2013 18:49:16 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.229]) by mail136-db9.bigfish.com (Postfix) with ESMTP id 5CA5F2C01F1; Tue, 6 Aug 2013 18:49:16 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 18:49:15 +0000 Received: from BL2PR05MB241.namprd05.prod.outlook.com (10.242.198.139) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 18:49:14 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB241.namprd05.prod.outlook.com (10.242.198.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 18:49:12 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 18:49:12 +0000 From: Ronald Bonica To: "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoA== Date: Tue, 6 Aug 2013 18:49:11 +0000 Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0930AAFAD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 06 Aug 2013 18:49:26 -0000 Mike, The proposal sounds elegant. I will try to paraphrase it to make sure that = I understand. When originating a UDP datagram, the host always queries it underlying IP s= tack to determine the PMTU for the destination. If the PMTU greater than or= equal to the size of the payload plus the UDP header plus the IP header, p= lus all IP extension headers, the originating host emits a conventional UDP= packet which is characterized as follows: - Protocol =3D 17 - Length <=3D L4 length from IP If the PMTU less than the size of the payload plus the UDP header plus the = IP header, plus all IP extension headers, the originating host emits an unc= onventional UDP packet which is characterized as follows: - Protocol =3D 17 - Length > L4 length from IP - Segment Offset, M-bit and Identification fields added to UDP header befor= e the payload If an unconventional UDP packet arrives a destination that supports unconve= ntional packets, it is reassembled at the transport layer. If an unconventi= onal UDP packet arrives a destination that does not support unconventional = packets, it is discarded. Do I have this much right? Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Monday, August 05, 2013 11:53 PM > To: IPv6 > Subject: Re: UDP+Fragmentation (was: "Deprecate") >=20 > On Thu, 1 Aug 2013, C. M. Heard wrote: > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > I agree that C.M. Heard's ideas should be explored in more detail > by > > > the IETF. >=20 > The idea was essentially UDP with segmentation fields, which would > require a new protocol number. >=20 > In an offline discussion with Mark Smith and I kicked around an idea > for an alternate version not requiring a new protocol number, but > relying instead on the redundancy of the UDP Length field. The UDP > Length field is not actually needed; TCP does not have one but rather > relies on the length reported by the IP layer. Under current > standards, the UDP Length field must be at least 8 and cannot exceed > the IP payload length minus the combined length of any extension > headers -- let's call this the L4 length from IP. Existing > implementations are supposed to drop UDP datagrams that fail this > check, and all the ones I know of do so. >=20 > The question then arises whether it might reasonably be possible to re- > purpose the case UDP Length > L4 length from IP to mean a segmented UDP > datagram. >=20 > In that case 8 <=3D UDP Length <=3D L4 length from IP would be intepreted > as a standard unsegmented UDP datagram, as is it now. > That's the case pictured below. Note that if the L4 length indicated > by the IP layer exceeds the UDP Length, then the extra octets would be > discarded and are not delivered to the application; that is the > behavior of the implementations I know of. >=20 > 0 15 16 31 > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Source Port | Destination Port | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Length <=3D L4 length from IP | Checksum | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | data octets ... > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... >=20 > Now suppose that we have a long UDP datagram that we want to send in > segments. We set the Length and Checksum fields as usual, and then cut > the datagram into segments, each of which looks like this: >=20 > 0 15 16 31 > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Source Port | Destination Port | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Length > L4 length from IP | Checksum | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | (reserved =3D 0) | Segment Offset |Res|M| > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | Identification | > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > | data octets ... > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... >=20 > We put the same UDP header in each segment, so (if we take some care in > how we choose the length of the segments) each one will have a UDP > Length field that is greater than the IP payload length minus the > combined length of any extension headers. Implementations that conform > to the current specifications should discard these segments, and so > should not mistakenly consider the segmentation fields as part of the > application data. That should make it possible for segmented UDP > datagrams to safely coexist with conventional unsegmented one, without > getting a new protocol number. >=20 > Possible downsides: some middleboxes may filter such "erroneous" > datagrams, and some existing erroneous implementations may fail to do > the checks they should and might mistake these segments for ordinary > UDP datagrams. >=20 > Note that this idea does not work with UDP-lite, which replaces the > Length field with a Checksum Coverage field. That could easily be too > short to exceed the L4 length from IP. >=20 > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Tue Aug 6 11:57:49 2013 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 B6CFF11E80EF for ; Tue, 6 Aug 2013 11:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voa3+KgKdsCs for ; Tue, 6 Aug 2013 11:57:44 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id ADF2711E80EA for ; Tue, 6 Aug 2013 11:57:43 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76IvgRj012259 for ; Tue, 6 Aug 2013 13:57:43 -0500 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76Ivg2i011936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 6 Aug 2013 13:57:42 -0500 Received: from XCH-BLV-501.nw.nos.boeing.com (130.247.25.190) by XCH-NWHT-01.nw.nos.boeing.com (130.247.70.222) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 6 Aug 2013 11:57:41 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.153]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 11:57:41 -0700 From: "Templin, Fred L" To: Ronald Bonica , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLg Date: Tue, 6 Aug 2013 18:57:40 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 18:57:49 -0000 With a protocol as ossified as UDP, I have a hard time imagining all middleboxes passing the packets with what they would see as a corrupted length field. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, August 06, 2013 11:49 AM > To: C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Mike, >=20 > The proposal sounds elegant. I will try to paraphrase it to make sure > that I understand. >=20 > When originating a UDP datagram, the host always queries it underlying > IP stack to determine the PMTU for the destination. If the PMTU greater > than or equal to the size of the payload plus the UDP header plus the > IP header, plus all IP extension headers, the originating host emits a > conventional UDP packet which is characterized as follows: >=20 > - Protocol =3D 17 > - Length <=3D L4 length from IP >=20 > If the PMTU less than the size of the payload plus the UDP header plus > the IP header, plus all IP extension headers, the originating host > emits an unconventional UDP packet which is characterized as follows: >=20 > - Protocol =3D 17 > - Length > L4 length from IP > - Segment Offset, M-bit and Identification fields added to UDP header > before the payload >=20 > If an unconventional UDP packet arrives a destination that supports > unconventional packets, it is reassembled at the transport layer. If an > unconventional UDP packet arrives a destination that does not support > unconventional packets, it is discarded. >=20 > Do I have this much right? >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > > C. M. Heard > > Sent: Monday, August 05, 2013 11:53 PM > > To: IPv6 > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > I agree that C.M. Heard's ideas should be explored in more detail > > by > > > > the IETF. > > > > The idea was essentially UDP with segmentation fields, which would > > require a new protocol number. > > > > In an offline discussion with Mark Smith and I kicked around an idea > > for an alternate version not requiring a new protocol number, but > > relying instead on the redundancy of the UDP Length field. The UDP > > Length field is not actually needed; TCP does not have one but rather > > relies on the length reported by the IP layer. Under current > > standards, the UDP Length field must be at least 8 and cannot exceed > > the IP payload length minus the combined length of any extension > > headers -- let's call this the L4 length from IP. Existing > > implementations are supposed to drop UDP datagrams that fail this > > check, and all the ones I know of do so. > > > > The question then arises whether it might reasonably be possible to > re- > > purpose the case UDP Length > L4 length from IP to mean a segmented > UDP > > datagram. > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would be intepret= ed > > as a standard unsegmented UDP datagram, as is it now. > > That's the case pictured below. Note that if the L4 length indicated > > by the IP layer exceeds the UDP Length, then the extra octets would > be > > discarded and are not delivered to the application; that is the > > behavior of the implementations I know of. > > > > 0 15 16 31 > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Source Port | Destination Port | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Length <=3D L4 length from IP | Checksum | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | data octets ... > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > Now suppose that we have a long UDP datagram that we want to send in > > segments. We set the Length and Checksum fields as usual, and then > cut > > the datagram into segments, each of which looks like this: > > > > 0 15 16 31 > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Source Port | Destination Port | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Length > L4 length from IP | Checksum | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | (reserved =3D 0) | Segment Offset |Res|M| > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Identification | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | data octets ... > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > We put the same UDP header in each segment, so (if we take some care > in > > how we choose the length of the segments) each one will have a UDP > > Length field that is greater than the IP payload length minus the > > combined length of any extension headers. Implementations that > conform > > to the current specifications should discard these segments, and so > > should not mistakenly consider the segmentation fields as part of the > > application data. That should make it possible for segmented UDP > > datagrams to safely coexist with conventional unsegmented one, > without > > getting a new protocol number. > > > > Possible downsides: some middleboxes may filter such "erroneous" > > datagrams, and some existing erroneous implementations may fail to do > > the checks they should and might mistake these segments for ordinary > > UDP datagrams. > > > > Note that this idea does not work with UDP-lite, which replaces the > > Length field with a Checksum Coverage field. That could easily be > too > > short to exceed the L4 length from IP. > > > > Mike Heard > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rbonica@juniper.net Tue Aug 6 14:54:04 2013 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 0679C21F9CF1 for ; Tue, 6 Aug 2013 14:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7npboyDe9HK for ; Tue, 6 Aug 2013 14:53:58 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F311E80D1 for ; Tue, 6 Aug 2013 14:53:54 -0700 (PDT) Received: from mail97-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 21:53:53 +0000 Received: from mail97-am1 (localhost [127.0.0.1]) by mail97-am1-R.bigfish.com (Postfix) with ESMTP id 1D2C5180305; Tue, 6 Aug 2013 21:53:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail97-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(24454002)(199002)(377454003)(13464003)(51704005)(63696002)(74502001)(65816001)(47446002)(76482001)(56776001)(83322001)(80022001)(74706001)(16406001)(76576001)(77096001)(69226001)(56816003)(51856001)(80976001)(74366001)(47976001)(54316002)(79102001)(77982001)(50986001)(76786001)(74876001)(74662001)(46102001)(4396001)(561944002)(33646001)(74316001)(53806001)(83072001)(49866001)(59766001)(81542001)(66066001)(19580395003)(76796001)(31966008)(81342001)(19580405001)(19580385001)(54356001)(47736001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail97-am1 (localhost.localdomain [127.0.0.1]) by mail97-am1 (MessageSwitch) id 137582603178687_5963; Tue, 6 Aug 2013 21:53:51 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.254]) by mail97-am1.bigfish.com (Postfix) with ESMTP id 100D260041; Tue, 6 Aug 2013 21:53:51 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 21:53:51 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 21:53:50 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 21:53:43 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 21:53:43 +0000 From: Ronald Bonica To: "Templin, Fred L" , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnA= Date: Tue, 6 Aug 2013 21:53:42 +0000 Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0930AAFAD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 06 Aug 2013 21:54:04 -0000 Fred, If that's the case, we have a good argument for changing Mike's proposal ev= er so slightly, so that it uses a new protocol ID. But still, Mike's propos= al is elegant because: a) It solves the problem at the right layer b) It reuses UDP transport machinery. (The only exception is the in LENGTH = field) c) It reuses IP fragmentation machinery (moving it to the transport layer) d) Aside from b) and c), it introduces no new protocol machinery. So, it ca= n be described in a few short pages. This is in stark contrast to SEAL (dra= ft-templin-intarea-seal-61) whose protocol machinery requires 41 pages to d= escribe which required 61 draft versions to get right. Ron > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, August 06, 2013 2:58 PM > To: Ronald Bonica; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > With a protocol as ossified as UDP, I have a hard time imagining all > middleboxes passing the packets with what they would see as a corrupted > length field. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of Ronald Bonica > > Sent: Tuesday, August 06, 2013 11:49 AM > > To: C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > Mike, > > > > The proposal sounds elegant. I will try to paraphrase it to make sure > > that I understand. > > > > When originating a UDP datagram, the host always queries it > underlying > > IP stack to determine the PMTU for the destination. If the PMTU > > greater than or equal to the size of the payload plus the UDP header > > plus the IP header, plus all IP extension headers, the originating > > host emits a conventional UDP packet which is characterized as > follows: > > > > - Protocol =3D 17 > > - Length <=3D L4 length from IP > > > > If the PMTU less than the size of the payload plus the UDP header > plus > > the IP header, plus all IP extension headers, the originating host > > emits an unconventional UDP packet which is characterized as follows: > > > > - Protocol =3D 17 > > - Length > L4 length from IP > > - Segment Offset, M-bit and Identification fields added to UDP header > > before the payload > > > > If an unconventional UDP packet arrives a destination that supports > > unconventional packets, it is reassembled at the transport layer. If > > an unconventional UDP packet arrives a destination that does not > > support unconventional packets, it is discarded. > > > > Do I have this much right? > > > > Ron > > > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > Of > > > C. M. Heard > > > Sent: Monday, August 05, 2013 11:53 PM > > > To: IPv6 > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > I agree that C.M. Heard's ideas should be explored in more > > > > > detail > > > by > > > > > the IETF. > > > > > > The idea was essentially UDP with segmentation fields, which would > > > require a new protocol number. > > > > > > In an offline discussion with Mark Smith and I kicked around an > idea > > > for an alternate version not requiring a new protocol number, but > > > relying instead on the redundancy of the UDP Length field. The UDP > > > Length field is not actually needed; TCP does not have one but > > > rather relies on the length reported by the IP layer. Under > current > > > standards, the UDP Length field must be at least 8 and cannot > exceed > > > the IP payload length minus the combined length of any extension > > > headers -- let's call this the L4 length from IP. Existing > > > implementations are supposed to drop UDP datagrams that fail this > > > check, and all the ones I know of do so. > > > > > > The question then arises whether it might reasonably be possible to > > re- > > > purpose the case UDP Length > L4 length from IP to mean a segmented > > UDP > > > datagram. > > > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would be > > > intepreted as a standard unsegmented UDP datagram, as is it now. > > > That's the case pictured below. Note that if the L4 length > > > indicated by the IP layer exceeds the UDP Length, then the extra > > > octets would > > be > > > discarded and are not delivered to the application; that is the > > > behavior of the implementations I know of. > > > > > > 0 15 16 > 31 > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | Source Port | Destination Port > | > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | Length <=3D L4 length from IP | Checksum > | > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | data octets ... > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > Now suppose that we have a long UDP datagram that we want to send > in > > > segments. We set the Length and Checksum fields as usual, and then > > cut > > > the datagram into segments, each of which looks like this: > > > > > > 0 15 16 > 31 > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | Source Port | Destination Port > | > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | Length > L4 length from IP | Checksum > | > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | (reserved =3D 0) | Segment Offset > |Res|M| > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | Identification > | > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+- > +-+ > > > | data octets ... > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > We put the same UDP header in each segment, so (if we take some > care > > in > > > how we choose the length of the segments) each one will have a UDP > > > Length field that is greater than the IP payload length minus the > > > combined length of any extension headers. Implementations that > > conform > > > to the current specifications should discard these segments, and so > > > should not mistakenly consider the segmentation fields as part of > > > the application data. That should make it possible for segmented > > > UDP datagrams to safely coexist with conventional unsegmented one, > > without > > > getting a new protocol number. > > > > > > Possible downsides: some middleboxes may filter such "erroneous" > > > datagrams, and some existing erroneous implementations may fail to > > > do the checks they should and might mistake these segments for > > > ordinary UDP datagrams. > > > > > > Note that this idea does not work with UDP-lite, which replaces the > > > Length field with a Checksum Coverage field. That could easily be > > too > > > short to exceed the L4 length from IP. > > > > > > Mike Heard > > > ------------------------------------------------------------------- > - > > > 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 > > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Tue Aug 6 15:07:16 2013 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 8705821F9EB2 for ; Tue, 6 Aug 2013 15:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKmJLETY8dhW for ; Tue, 6 Aug 2013 15:07:11 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 010BA21F9EB0 for ; Tue, 6 Aug 2013 15:07:10 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76M785k010805 for ; Tue, 6 Aug 2013 15:07:08 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76M77oK010797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 6 Aug 2013 15:07:07 -0700 Received: from XCH-EXCO-101.nw.nos.boeing.com (130.247.25.30) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 6 Aug 2013 15:07:10 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-EXCO-101.nw.nos.boeing.com ([fe80::fc2d:7b3b:2de5:b12c%15]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 15:07:09 -0700 From: "Templin, Fred L" To: Ronald Bonica , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnCAAAXBcA== Date: Tue, 6 Aug 2013 22:07:09 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 22:07:16 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Tuesday, August 06, 2013 2:54 PM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Fred, >=20 > If that's the case, we have a good argument for changing Mike's > proposal ever so slightly, so that it uses a new protocol ID. But > still, Mike's proposal is elegant because: >=20 > a) It solves the problem at the right layer > b) It reuses UDP transport machinery. (The only exception is the in > LENGTH field) > c) It reuses IP fragmentation machinery (moving it to the transport > layer) > d) Aside from b) and c), it introduces no new protocol machinery. So, > it can be described in a few short pages. This is in stark contrast to > SEAL (draft-templin-intarea-seal-61) whose protocol machinery requires > 41 pages to describe There is a lot of boiler plate in the draft that is not required to describe the protocol machinery. Plus, there are many things that need to be described in a functional specification beyond just posting a concept in an e-mail thread. > which required 61 draft versions to get right. The best things in life are worth investing the time and energy to get right. Plus, SEAL is a universal format that handles both tunnel- and transport-mode requirements for all manners of existing protocols. If we are going to define a new protocol type, let's define one that addresses everything we are currently struggling with and has the extensibility to address additional requirements moving forward into the future. Thanks - Fred fred.l.templin@boeing.com=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, August 06, 2013 2:58 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > With a protocol as ossified as UDP, I have a hard time imagining all > > middleboxes passing the packets with what they would see as a > corrupted > > length field. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > > Of Ronald Bonica > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > To: C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > Mike, > > > > > > The proposal sounds elegant. I will try to paraphrase it to make > sure > > > that I understand. > > > > > > When originating a UDP datagram, the host always queries it > > underlying > > > IP stack to determine the PMTU for the destination. If the PMTU > > > greater than or equal to the size of the payload plus the UDP > header > > > plus the IP header, plus all IP extension headers, the originating > > > host emits a conventional UDP packet which is characterized as > > follows: > > > > > > - Protocol =3D 17 > > > - Length <=3D L4 length from IP > > > > > > If the PMTU less than the size of the payload plus the UDP header > > plus > > > the IP header, plus all IP extension headers, the originating host > > > emits an unconventional UDP packet which is characterized as > follows: > > > > > > - Protocol =3D 17 > > > - Length > L4 length from IP > > > - Segment Offset, M-bit and Identification fields added to UDP > header > > > before the payload > > > > > > If an unconventional UDP packet arrives a destination that supports > > > unconventional packets, it is reassembled at the transport layer. > If > > > an unconventional UDP packet arrives a destination that does not > > > support unconventional packets, it is discarded. > > > > > > Do I have this much right? > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf > > > Of > > > > C. M. Heard > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > To: IPv6 > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > I agree that C.M. Heard's ideas should be explored in more > > > > > > detail > > > > by > > > > > > the IETF. > > > > > > > > The idea was essentially UDP with segmentation fields, which > would > > > > require a new protocol number. > > > > > > > > In an offline discussion with Mark Smith and I kicked around an > > idea > > > > for an alternate version not requiring a new protocol number, but > > > > relying instead on the redundancy of the UDP Length field. The > UDP > > > > Length field is not actually needed; TCP does not have one but > > > > rather relies on the length reported by the IP layer. Under > > current > > > > standards, the UDP Length field must be at least 8 and cannot > > exceed > > > > the IP payload length minus the combined length of any extension > > > > headers -- let's call this the L4 length from IP. Existing > > > > implementations are supposed to drop UDP datagrams that fail this > > > > check, and all the ones I know of do so. > > > > > > > > The question then arises whether it might reasonably be possible > to > > > re- > > > > purpose the case UDP Length > L4 length from IP to mean a > segmented > > > UDP > > > > datagram. > > > > > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would be > > > > intepreted as a standard unsegmented UDP datagram, as is it now. > > > > That's the case pictured below. Note that if the L4 length > > > > indicated by the IP layer exceeds the UDP Length, then the extra > > > > octets would > > > be > > > > discarded and are not delivered to the application; that is the > > > > behavior of the implementations I know of. > > > > > > > > 0 15 16 > > 31 > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | Source Port | Destination Port > > | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | Length <=3D L4 length from IP | Checksum > > | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | data octets ... > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > Now suppose that we have a long UDP datagram that we want to send > > in > > > > segments. We set the Length and Checksum fields as usual, and > then > > > cut > > > > the datagram into segments, each of which looks like this: > > > > > > > > 0 15 16 > > 31 > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | Source Port | Destination Port > > | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | Length > L4 length from IP | Checksum > > | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | (reserved =3D 0) | Segment Offset > > |Res|M| > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | Identification > > | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+- > +- > > +-+ > > > > | data octets ... > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > We put the same UDP header in each segment, so (if we take some > > care > > > in > > > > how we choose the length of the segments) each one will have a > UDP > > > > Length field that is greater than the IP payload length minus the > > > > combined length of any extension headers. Implementations that > > > conform > > > > to the current specifications should discard these segments, and > so > > > > should not mistakenly consider the segmentation fields as part of > > > > the application data. That should make it possible for segmented > > > > UDP datagrams to safely coexist with conventional unsegmented > one, > > > without > > > > getting a new protocol number. > > > > > > > > Possible downsides: some middleboxes may filter such "erroneous" > > > > datagrams, and some existing erroneous implementations may fail > to > > > > do the checks they should and might mistake these segments for > > > > ordinary UDP datagrams. > > > > > > > > Note that this idea does not work with UDP-lite, which replaces > the > > > > Length field with a Checksum Coverage field. That could easily > be > > > too > > > > short to exceed the L4 length from IP. > > > > > > > > Mike Heard > > > > ----------------------------------------------------------------- > -- > > - > > > > 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 > > > ------------------------------------------------------------------- > - > > >=20 From Fred.L.Templin@boeing.com Tue Aug 6 15:35:52 2013 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 7B5BF21F9EFE for ; Tue, 6 Aug 2013 15:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2vbV6+2bfcL for ; Tue, 6 Aug 2013 15:35:47 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDB421F9E9E for ; Tue, 6 Aug 2013 15:35:47 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76MZivL019923 for ; Tue, 6 Aug 2013 15:35:44 -0700 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76MZij1019918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 6 Aug 2013 15:35:44 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.109]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 15:35:46 -0700 From: "Templin, Fred L" To: Ronald Bonica , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnCAAAXBcIAACeHg Date: Tue, 6 Aug 2013 22:35:45 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 22:35:52 -0000 Ron, One other thing for now is that Mike's proposal doesn't even address the attack vector that 'draft-bonica-6man-frag-deprecate' is concerned about. To address the tiny fragment concern, the protocol must ensure that tiny fragments cannot ever be created. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Tuesday, August 06, 2013 3:07 PM > To: Ronald Bonica; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Hi Ron, >=20 > > -----Original Message----- > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > Sent: Tuesday, August 06, 2013 2:54 PM > > To: Templin, Fred L; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > Fred, > > > > If that's the case, we have a good argument for changing Mike's > > proposal ever so slightly, so that it uses a new protocol ID. But > > still, Mike's proposal is elegant because: > > > > a) It solves the problem at the right layer > > b) It reuses UDP transport machinery. (The only exception is the in > > LENGTH field) > > c) It reuses IP fragmentation machinery (moving it to the transport > > layer) > > d) Aside from b) and c), it introduces no new protocol machinery. So, > > it can be described in a few short pages. This is in stark contrast > to > > SEAL (draft-templin-intarea-seal-61) whose protocol machinery > requires > > 41 pages to describe >=20 > There is a lot of boiler plate in the draft that is not required to > describe the protocol machinery. Plus, there are many things that > need to be described in a functional specification beyond just > posting a concept in an e-mail thread. >=20 > > which required 61 draft versions to get right. >=20 > The best things in life are worth investing the time and energy > to get right. Plus, SEAL is a universal format that handles both > tunnel- and transport-mode requirements for all manners of > existing protocols. >=20 > If we are going to define a new protocol type, let's define one > that addresses everything we are currently struggling with and > has the extensibility to address additional requirements moving > forward into the future. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Ron > > > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Tuesday, August 06, 2013 2:58 PM > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > With a protocol as ossified as UDP, I have a hard time imagining > all > > > middleboxes passing the packets with what they would see as a > > corrupted > > > length field. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf > > > > Of Ronald Bonica > > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > > To: C. M. Heard; IPv6 > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > Mike, > > > > > > > > The proposal sounds elegant. I will try to paraphrase it to make > > sure > > > > that I understand. > > > > > > > > When originating a UDP datagram, the host always queries it > > > underlying > > > > IP stack to determine the PMTU for the destination. If the PMTU > > > > greater than or equal to the size of the payload plus the UDP > > header > > > > plus the IP header, plus all IP extension headers, the > originating > > > > host emits a conventional UDP packet which is characterized as > > > follows: > > > > > > > > - Protocol =3D 17 > > > > - Length <=3D L4 length from IP > > > > > > > > If the PMTU less than the size of the payload plus the UDP header > > > plus > > > > the IP header, plus all IP extension headers, the originating > host > > > > emits an unconventional UDP packet which is characterized as > > follows: > > > > > > > > - Protocol =3D 17 > > > > - Length > L4 length from IP > > > > - Segment Offset, M-bit and Identification fields added to UDP > > header > > > > before the payload > > > > > > > > If an unconventional UDP packet arrives a destination that > supports > > > > unconventional packets, it is reassembled at the transport layer. > > If > > > > an unconventional UDP packet arrives a destination that does not > > > > support unconventional packets, it is discarded. > > > > > > > > Do I have this much right? > > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > > Behalf > > > > Of > > > > > C. M. Heard > > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > > To: IPv6 > > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > > I agree that C.M. Heard's ideas should be explored in more > > > > > > > detail > > > > > by > > > > > > > the IETF. > > > > > > > > > > The idea was essentially UDP with segmentation fields, which > > would > > > > > require a new protocol number. > > > > > > > > > > In an offline discussion with Mark Smith and I kicked around an > > > idea > > > > > for an alternate version not requiring a new protocol number, > but > > > > > relying instead on the redundancy of the UDP Length field. The > > UDP > > > > > Length field is not actually needed; TCP does not have one but > > > > > rather relies on the length reported by the IP layer. Under > > > current > > > > > standards, the UDP Length field must be at least 8 and cannot > > > exceed > > > > > the IP payload length minus the combined length of any > extension > > > > > headers -- let's call this the L4 length from IP. Existing > > > > > implementations are supposed to drop UDP datagrams that fail > this > > > > > check, and all the ones I know of do so. > > > > > > > > > > The question then arises whether it might reasonably be > possible > > to > > > > re- > > > > > purpose the case UDP Length > L4 length from IP to mean a > > segmented > > > > UDP > > > > > datagram. > > > > > > > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would be > > > > > intepreted as a standard unsegmented UDP datagram, as is it > now. > > > > > That's the case pictured below. Note that if the L4 length > > > > > indicated by the IP layer exceeds the UDP Length, then the > extra > > > > > octets would > > > > be > > > > > discarded and are not delivered to the application; that is the > > > > > behavior of the implementations I know of. > > > > > > > > > > 0 15 16 > > > 31 > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | Source Port | Destination Port > > > | > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | Length <=3D L4 length from IP | Checksum > > > | > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | data octets ... > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > > > Now suppose that we have a long UDP datagram that we want to > send > > > in > > > > > segments. We set the Length and Checksum fields as usual, and > > then > > > > cut > > > > > the datagram into segments, each of which looks like this: > > > > > > > > > > 0 15 16 > > > 31 > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | Source Port | Destination Port > > > | > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | Length > L4 length from IP | Checksum > > > | > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | (reserved =3D 0) | Segment Offset > > > |Res|M| > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | Identification > > > | > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+- > +- > > +- > > > +-+ > > > > > | data octets ... > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > > > We put the same UDP header in each segment, so (if we take some > > > care > > > > in > > > > > how we choose the length of the segments) each one will have a > > UDP > > > > > Length field that is greater than the IP payload length minus > the > > > > > combined length of any extension headers. Implementations that > > > > conform > > > > > to the current specifications should discard these segments, > and > > so > > > > > should not mistakenly consider the segmentation fields as part > of > > > > > the application data. That should make it possible for > segmented > > > > > UDP datagrams to safely coexist with conventional unsegmented > > one, > > > > without > > > > > getting a new protocol number. > > > > > > > > > > Possible downsides: some middleboxes may filter such > "erroneous" > > > > > datagrams, and some existing erroneous implementations may fail > > to > > > > > do the checks they should and might mistake these segments for > > > > > ordinary UDP datagrams. > > > > > > > > > > Note that this idea does not work with UDP-lite, which replaces > > the > > > > > Length field with a Checksum Coverage field. That could easily > > be > > > > too > > > > > short to exceed the L4 length from IP. > > > > > > > > > > Mike Heard > > > > > --------------------------------------------------------------- > -- > > -- > > > - > > > > > 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 > > > > ----------------------------------------------------------------- > -- > > - > > > > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dougb@dougbarton.us Tue Aug 6 15:39:47 2013 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 C540321F9346 for ; Tue, 6 Aug 2013 15:39:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLaUjp0JB0wa for ; Tue, 6 Aug 2013 15:39:43 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1011E80EE for ; Tue, 6 Aug 2013 15:39:43 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:538:c54:26c8:7f50] (unknown [IPv6:2001:470:d:5e7:538:c54:26c8:7f50]) by dougbarton.us (Postfix) with ESMTPSA id 46AE622B2A for ; Tue, 6 Aug 2013 22:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1375828782; bh=jq1s6fyD8HWlmNVFrXw3cxkvGTNRlA0j+RKhrS6b3mQ=; h=Date:From:To:Subject:References:In-Reply-To; b=l8/LiR6pV4RqlVCAaQodMzJlbHz2FS7DpRohSauDkXXVgochRfIM56oYOX6KoV9/w eXXE4WgLHqpnVUaFNoz7tDrV3cMvxdnwV+nUYnIdWFFEwEjq+r02H1lmqi8MQO4eXf r/GAgY5RnZ5cGoBhtILiwp3PfzDbV43KrYTrXpNc= Message-ID: <52017B2E.5050703@dougbarton.us> Date: Tue, 06 Aug 2013 15:39:42 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: UDP+Fragmentation References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 06 Aug 2013 22:39:47 -0000 On 08/06/2013 03:07 PM, Templin, Fred L wrote: > If we are going to define a new protocol type, let's define one > that addresses everything we are currently struggling with and > has the extensibility to address additional requirements moving > forward into the future. So in other words let's make all the same mistakes we made with the design of IPv6? :) From Fred.L.Templin@boeing.com Tue Aug 6 15:42:09 2013 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 3E6D821E809B for ; Tue, 6 Aug 2013 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laMQkECJbEkA for ; Tue, 6 Aug 2013 15:42:03 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4258C21E80AB for ; Tue, 6 Aug 2013 15:42:00 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r76Mfxep025162 for ; Tue, 6 Aug 2013 15:41:59 -0700 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r76MfvCl025149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 6 Aug 2013 15:41:58 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-513.sw.nos.boeing.com ([169.254.13.30]) with mapi id 14.02.0328.011; Tue, 6 Aug 2013 15:41:57 -0700 From: "Templin, Fred L" To: Doug Barton , "ipv6@ietf.org" Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOkvXX4SMEeC7qyE6QlR5ihkVRYZmIxhMQ Date: Tue, 6 Aug 2013 22:41:56 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> In-Reply-To: <52017B2E.5050703@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 06 Aug 2013 22:42:09 -0000 > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > If we are going to define a new protocol type, let's define one > > that addresses everything we are currently struggling with and > > has the extensibility to address additional requirements moving > > forward into the future. >=20 > So in other words let's make all the same mistakes we made with the > design of IPv6? :) Not even. This is about fixing and atoning for mistakes; not introducing new ones. Thanks - Fred fred.l.templin@boeing.com From rja.lists@gmail.com Tue Aug 6 17:49:47 2013 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 8C6CC21F8B4E for ; Tue, 6 Aug 2013 17:49:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5kWqgkrqqAQ for ; Tue, 6 Aug 2013 17:49:47 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5911E8105 for ; Tue, 6 Aug 2013 17:49:45 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id k15so596595qcv.12 for ; Tue, 06 Aug 2013 17:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=UsFndrc9jU9PoHA/sqOJeS/lSyRZ8WxIWFdg6Aw/SYA=; b=RWDRWI7GtHmA1dofSnG2jqmSk2nGrkf7Q3UpGj0FhJP40EserMOdkN3mx8Xx0O/4cF 4a7VFimZ+zsrlMqwnNlxzLQvGresc8Rm8FKHFNZst4iPF1sOBZDj1bRXrWHShWzvoFl1 jOV44XNy3ZATJ+rCVuBUSr7kD8a5NbG/hQV2UZUMYGHnWjdxUg4Vov19DyXEz583s7MN DfDwX5PcA5P9KOOrmFv38uedgrml/B55Ka3rlec2TCLLxw4lSi2tbqkuenldUfemDIy3 JX8qZt6Hy2Hu58LFDh1VNn/AZyMxG76RxKRrrWOLe5VGir6h+o5k/hCAuEbyVmdhFz7m 84zg== X-Received: by 10.49.81.146 with SMTP id a18mr935320qey.41.1375836584870; Tue, 06 Aug 2013 17:49:44 -0700 (PDT) Received: from [10.30.20.15] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPSA id q15sm8240739qak.5.2013.08.06.17.49.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 17:49:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: "Deprecate" From: RJ Atkinson In-Reply-To: <2134F8430051B64F815C691A62D983180E085F@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 6 Aug 2013 20:49:58 -0400 Content-Transfer-Encoding: 7bit Message-Id: <086B8FD8-E382-4F17-9130-BEE14135559B@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> <44DD17CB-FC14-4E21-A350-4201AEF1CD78@gmail.com> <2134F8430051B64F815C691A62D983180E085F@XCH-BLV-504.nw.nos.boeing.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) 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, 07 Aug 2013 00:49:47 -0000 On 06 Aug 2013, at 13:21 , Templin, Fred L wrote: >> Tunnel ingress devices already are allowed to fragment >> IPv6 packets by various IETF approved tunnelling >> specifications, as you have agreed. > > Fragmentation of the inner packet before encapsulation > is different from fragmentation of the outer packet after > encapsulation. I've coded this for IPv6. It is the SAME fragmentation code AND the SAME reassembly code for both cases. The operational scenarios can and do vary, but the code path (and the specification for how to perform it) are IDENTICAL - not DIFFERENT. > ... > This discussion is coming full circle... (I agree this sub-thread is looping. So can we please let this rest on grounds that no one has proposed any specification change ? :-) Yours, Ran From rbonica@juniper.net Tue Aug 6 18:45:44 2013 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 E001B21F9B6A for ; Tue, 6 Aug 2013 18:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=0.943, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQnF68NM386h for ; Tue, 6 Aug 2013 18:45:39 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8B89E21F91CE for ; Tue, 6 Aug 2013 18:45:39 -0700 (PDT) Received: from mail183-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE020.bigfish.com (10.243.66.83) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 01:45:36 +0000 Received: from mail183-co1 (localhost [127.0.0.1]) by mail183-co1-R.bigfish.com (Postfix) with ESMTP id D4CF178021B; Wed, 7 Aug 2013 01:45:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail183-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(189002)(199002)(377454003)(24454002)(51704005)(53806001)(76576001)(54356001)(74876001)(76482001)(19580405001)(74502001)(19580395003)(56776001)(16406001)(31966008)(74316001)(83322001)(47736001)(33646001)(4396001)(56816003)(561944002)(19580385001)(79102001)(80022001)(66066001)(74662001)(83072001)(74366001)(65816001)(69226001)(81542001)(81342001)(51856001)(50986001)(54316002)(59766001)(80976001)(76786001)(47446002)(49866001)(77096001)(76796001)(77982001)(63696002)(46102001)(74706001)(47976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB243; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail183-co1 (localhost.localdomain [127.0.0.1]) by mail183-co1 (MessageSwitch) id 1375839935385870_6168; Wed, 7 Aug 2013 01:45:35 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.233]) by mail183-co1.bigfish.com (Postfix) with ESMTP id 58AF558004D; Wed, 7 Aug 2013 01:45:35 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 01:45:34 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 01:45:34 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 01:45:32 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 01:45:32 +0000 From: Ronald Bonica To: "Templin, Fred L" , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnCAAAXBcIAACeHggAAvSpA= Date: Wed, 7 Aug 2013 01:45:32 +0000 Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0931CB1479 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 07 Aug 2013 01:45:45 -0000 Fred, We should probably be clear about which problem we are trying to solve. The= following are possibilities: a) Remove network administrators' motivation for blocking IPv6 fragments. T= o this end, we assume that the network administrators' primary motivation i= s the tiny fragment problem. So, we solve the tiny fragment problem by chan= ging the way that IPv6 fragmentation works. In the new fragmentation scheme= , each fragment contains parsable information regarding the payload protoco= l and port. b) Make UDP-based applications work in a world where network administrators= block IPv6 fragments. We do this by either modifying UDP so that it suppor= ts fragmentation and reassembly of long payloads or creating a new UDP-like= protocol that supports the fragmentation and reassembly of long payloads. Draft-andrews-6man-fragopt solves the problem posed in draft-bonica-6man-fr= ag-deprecate by solving problem a). Mike's proposal solves the problem pose= d in draft-bonica-6man-frag-deprecate by solving problem a). IMHO, both proposals address the problem. We are currently trying to figure= out which will work best. Ron > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, August 06, 2013 6:36 PM > To: Ronald Bonica; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Ron, >=20 > One other thing for now is that Mike's proposal doesn't even address > the attack vector that 'draft-bonica-6man-frag-deprecate' > is concerned about. To address the tiny fragment concern, the protocol > must ensure that tiny fragments cannot ever be created. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of Templin, Fred L > > Sent: Tuesday, August 06, 2013 3:07 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > Sent: Tuesday, August 06, 2013 2:54 PM > > > To: Templin, Fred L; C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > Fred, > > > > > > If that's the case, we have a good argument for changing Mike's > > > proposal ever so slightly, so that it uses a new protocol ID. But > > > still, Mike's proposal is elegant because: > > > > > > a) It solves the problem at the right layer > > > b) It reuses UDP transport machinery. (The only exception is the in > > > LENGTH field) > > > c) It reuses IP fragmentation machinery (moving it to the transport > > > layer) > > > d) Aside from b) and c), it introduces no new protocol machinery. > > > So, it can be described in a few short pages. This is in stark > > > contrast > > to > > > SEAL (draft-templin-intarea-seal-61) whose protocol machinery > > requires > > > 41 pages to describe > > > > There is a lot of boiler plate in the draft that is not required to > > describe the protocol machinery. Plus, there are many things that > need > > to be described in a functional specification beyond just posting a > > concept in an e-mail thread. > > > > > which required 61 draft versions to get right. > > > > The best things in life are worth investing the time and energy to > get > > right. Plus, SEAL is a universal format that handles both > > tunnel- and transport-mode requirements for all manners of existing > > protocols. > > > > If we are going to define a new protocol type, let's define one that > > addresses everything we are currently struggling with and has the > > extensibility to address additional requirements moving forward into > > the future. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Tuesday, August 06, 2013 2:58 PM > > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > With a protocol as ossified as UDP, I have a hard time imagining > > all > > > > middleboxes passing the packets with what they would see as a > > > corrupted > > > > length field. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -----Original Message----- > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > > Behalf > > > > > Of Ronald Bonica > > > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > > > To: C. M. Heard; IPv6 > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > Mike, > > > > > > > > > > The proposal sounds elegant. I will try to paraphrase it to > make > > > sure > > > > > that I understand. > > > > > > > > > > When originating a UDP datagram, the host always queries it > > > > underlying > > > > > IP stack to determine the PMTU for the destination. If the PMTU > > > > > greater than or equal to the size of the payload plus the UDP > > > header > > > > > plus the IP header, plus all IP extension headers, the > > originating > > > > > host emits a conventional UDP packet which is characterized as > > > > follows: > > > > > > > > > > - Protocol =3D 17 > > > > > - Length <=3D L4 length from IP > > > > > > > > > > If the PMTU less than the size of the payload plus the UDP > > > > > header > > > > plus > > > > > the IP header, plus all IP extension headers, the originating > > host > > > > > emits an unconventional UDP packet which is characterized as > > > follows: > > > > > > > > > > - Protocol =3D 17 > > > > > - Length > L4 length from IP > > > > > - Segment Offset, M-bit and Identification fields added to UDP > > > header > > > > > before the payload > > > > > > > > > > If an unconventional UDP packet arrives a destination that > > supports > > > > > unconventional packets, it is reassembled at the transport > layer. > > > If > > > > > an unconventional UDP packet arrives a destination that does > not > > > > > support unconventional packets, it is discarded. > > > > > > > > > > Do I have this much right? > > > > > > > > > > Ron > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > > > Behalf > > > > > Of > > > > > > C. M. Heard > > > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > > > To: IPv6 > > > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > > > I agree that C.M. Heard's ideas should be explored in > more > > > > > > > > detail > > > > > > by > > > > > > > > the IETF. > > > > > > > > > > > > The idea was essentially UDP with segmentation fields, which > > > would > > > > > > require a new protocol number. > > > > > > > > > > > > In an offline discussion with Mark Smith and I kicked around > > > > > > an > > > > idea > > > > > > for an alternate version not requiring a new protocol number, > > but > > > > > > relying instead on the redundancy of the UDP Length field. > > > > > > The > > > UDP > > > > > > Length field is not actually needed; TCP does not have one > but > > > > > > rather relies on the length reported by the IP layer. Under > > > > current > > > > > > standards, the UDP Length field must be at least 8 and cannot > > > > exceed > > > > > > the IP payload length minus the combined length of any > > extension > > > > > > headers -- let's call this the L4 length from IP. Existing > > > > > > implementations are supposed to drop UDP datagrams that fail > > this > > > > > > check, and all the ones I know of do so. > > > > > > > > > > > > The question then arises whether it might reasonably be > > possible > > > to > > > > > re- > > > > > > purpose the case UDP Length > L4 length from IP to mean a > > > segmented > > > > > UDP > > > > > > datagram. > > > > > > > > > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would be > > > > > > intepreted as a standard unsegmented UDP datagram, as is it > > now. > > > > > > That's the case pictured below. Note that if the L4 length > > > > > > indicated by the IP layer exceeds the UDP Length, then the > > extra > > > > > > octets would > > > > > be > > > > > > discarded and are not delivered to the application; that is > > > > > > the behavior of the implementations I know of. > > > > > > > > > > > > 0 15 16 > > > > 31 > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | Source Port | Destination Port > > > > | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | Length <=3D L4 length from IP | Checksum > > > > | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | data octets ... > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > > > > > Now suppose that we have a long UDP datagram that we want to > > send > > > > in > > > > > > segments. We set the Length and Checksum fields as usual, > and > > > then > > > > > cut > > > > > > the datagram into segments, each of which looks like this: > > > > > > > > > > > > 0 15 16 > > > > 31 > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | Source Port | Destination Port > > > > | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | Length > L4 length from IP | Checksum > > > > | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | (reserved =3D 0) | Segment Offset > > > > |Res|M| > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | Identification > > > > | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+- > +- > > +- > > > +- > > > > +-+ > > > > > > | data octets ... > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > > > > > We put the same UDP header in each segment, so (if we take > > > > > > some > > > > care > > > > > in > > > > > > how we choose the length of the segments) each one will have > a > > > UDP > > > > > > Length field that is greater than the IP payload length minus > > the > > > > > > combined length of any extension headers. Implementations > > > > > > that > > > > > conform > > > > > > to the current specifications should discard these segments, > > and > > > so > > > > > > should not mistakenly consider the segmentation fields as > part > > of > > > > > > the application data. That should make it possible for > > segmented > > > > > > UDP datagrams to safely coexist with conventional unsegmented > > > one, > > > > > without > > > > > > getting a new protocol number. > > > > > > > > > > > > Possible downsides: some middleboxes may filter such > > "erroneous" > > > > > > datagrams, and some existing erroneous implementations may > > > > > > fail > > > to > > > > > > do the checks they should and might mistake these segments > for > > > > > > ordinary UDP datagrams. > > > > > > > > > > > > Note that this idea does not work with UDP-lite, which > > > > > > replaces > > > the > > > > > > Length field with a Checksum Coverage field. That could > > > > > > easily > > > be > > > > > too > > > > > > short to exceed the L4 length from IP. > > > > > > > > > > > > Mike Heard > > > > > > ------------------------------------------------------------- > - > > > > > > - > > -- > > > -- > > > > - > > > > > > 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 > > -------------------------------------------------------------------- >=20 From marka@isc.org Tue Aug 6 19:32:29 2013 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 784C921F9E2B for ; Tue, 6 Aug 2013 19:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+G9BPsO20QZ for ; Tue, 6 Aug 2013 19:32:24 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id DEDEB21F9C4E for ; Tue, 6 Aug 2013 19:32:23 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 86770C94D2; Wed, 7 Aug 2013 02:32:08 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375842742; bh=2LW203HkBv1i8qzubcHNhdonPcITQ3e6WVQF8nC0lVw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=seh5CdTqwO8t8hFe2Ovqqt5Ep2gTuVOEWmz8nWjYKndPcaeJsvVQR5lbP1Ko9tpbm lbqHzXAXM/Hf9qR+9/aTa/bjtjaNp/6+vgxFXINhKz/picHagPdgkNNc2GrqJcZvMp iTbbKvD2LGA+cyGQshQXlhe6AL7QU2Pym9SFp89k= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 7 Aug 2013 02:32:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7A311160082; Wed, 7 Aug 2013 02:36:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 132M6gwy6Ei1; Wed, 7 Aug 2013 02:36:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4738616037C; Wed, 7 Aug 2013 02:36:18 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0E50816037A; Wed, 7 Aug 2013 02:36:18 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id DA2ED3813A5F; Wed, 7 Aug 2013 12:31:58 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Tue, 06 Aug 2013 22:41:56 +0000." <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 07 Aug 2013 12:31:58 +1000 Message-Id: <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist 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, 07 Aug 2013 02:32:29 -0000 In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > If we are going to define a new protocol type, let's define one > > > that addresses everything we are currently struggling with and > > > has the extensibility to address additional requirements moving > > > forward into the future. > > > > So in other words let's make all the same mistakes we made with the > > design of IPv6? :) > > Not even. This is about fixing and atoning for mistakes; not > introducing new ones. > > Thanks - Fred > fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- There are several issues with getting fragments through firewalls. My draft addresses one of them. Putting all the headers into the initial fragment is another part of fix / reducing the issue. If you don't do something like that firewall will drop initial fragments because that can't be expected to reassemble unless they are doing DPI. Making fragment sizes more even is yet another part of the issue. Allowing tunnel entry points to re-fragment fragments is yet another part of the solution space. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Wed Aug 7 05:46:13 2013 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 0AD5C21F9808; Wed, 7 Aug 2013 05:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVjHwQieyLoR; Wed, 7 Aug 2013 05:46:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4387311E812A; Wed, 7 Aug 2013 05:46:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70p1 Message-ID: <20130807124608.13420.18517.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2013 05:46:08 -0700 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, 07 Aug 2013 12:46:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-addr-select-opt-11.txt Pages : 11 Date : 2013-08-07 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus to control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Fred.L.Templin@boeing.com Wed Aug 7 07:51:13 2013 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 AF33E11E8139 for ; Wed, 7 Aug 2013 07:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qwbh9bQTU+cJ for ; Wed, 7 Aug 2013 07:51:07 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35811E8138 for ; Wed, 7 Aug 2013 07:50:58 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r77Epe9M028695 for ; Wed, 7 Aug 2013 07:51:40 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r77EpdgN028682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 7 Aug 2013 07:51:39 -0700 Received: from XCH-BLV-207.nw.nos.boeing.com (10.57.37.63) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 07:50:56 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.243]) with mapi id 14.02.0328.011; Wed, 7 Aug 2013 07:50:55 -0700 From: "Templin, Fred L" To: Ronald Bonica , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnCAAAXBcIAACeHggAAvSpCAAODTEA== Date: Wed, 7 Aug 2013 14:50:55 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E16BE@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Aug 2013 14:51:13 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Tuesday, August 06, 2013 6:46 PM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Fred, >=20 > We should probably be clear about which problem we are trying to solve. > The following are possibilities: >=20 > a) Remove network administrators' motivation for blocking IPv6 > fragments. To this end, we assume that the network administrators' > primary motivation is the tiny fragment problem. So, we solve the tiny > fragment problem by changing the way that IPv6 fragmentation works. In > the new fragmentation scheme, each fragment contains parsable > information regarding the payload protocol and port. >=20 > b) Make UDP-based applications work in a world where network > administrators block IPv6 fragments. We do this by either modifying UDP > so that it supports fragmentation and reassembly of long payloads or > creating a new UDP-like protocol that supports the fragmentation and > reassembly of long payloads. >=20 > Draft-andrews-6man-fragopt solves the problem posed in draft-bonica- > 6man-frag-deprecate by solving problem a). Mike's proposal solves the > problem posed in draft-bonica-6man-frag-deprecate by solving problem > a). >=20 > IMHO, both proposals address the problem. We are currently trying to > figure out which will work best. SEAL solves the problem too. Transport-mode SEAL took me 15 minutes to write, and is really just a couple of paragraphs. In addition to providing a universal sublayer that can handle any transport protocol 'X', SEAL also provides an RFC4821 path MTU probing facility. And, if ingress filtering is thought to be a problem, it also provides a data origin authentication facility. It seems Ron that you are trying to avoid a closer examination of SEAL. Thanks - Fred fred.l.templin@boeing.com =20 > Ron >=20 >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, August 06, 2013 6:36 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > Ron, > > > > One other thing for now is that Mike's proposal doesn't even address > > the attack vector that 'draft-bonica-6man-frag-deprecate' > > is concerned about. To address the tiny fragment concern, the > protocol > > must ensure that tiny fragments cannot ever be created. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > > Of Templin, Fred L > > > Sent: Tuesday, August 06, 2013 3:07 PM > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > Hi Ron, > > > > > > > -----Original Message----- > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > Sent: Tuesday, August 06, 2013 2:54 PM > > > > To: Templin, Fred L; C. M. Heard; IPv6 > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > Fred, > > > > > > > > If that's the case, we have a good argument for changing Mike's > > > > proposal ever so slightly, so that it uses a new protocol ID. But > > > > still, Mike's proposal is elegant because: > > > > > > > > a) It solves the problem at the right layer > > > > b) It reuses UDP transport machinery. (The only exception is the > in > > > > LENGTH field) > > > > c) It reuses IP fragmentation machinery (moving it to the > transport > > > > layer) > > > > d) Aside from b) and c), it introduces no new protocol machinery. > > > > So, it can be described in a few short pages. This is in stark > > > > contrast > > > to > > > > SEAL (draft-templin-intarea-seal-61) whose protocol machinery > > > requires > > > > 41 pages to describe > > > > > > There is a lot of boiler plate in the draft that is not required to > > > describe the protocol machinery. Plus, there are many things that > > need > > > to be described in a functional specification beyond just posting a > > > concept in an e-mail thread. > > > > > > > which required 61 draft versions to get right. > > > > > > The best things in life are worth investing the time and energy to > > get > > > right. Plus, SEAL is a universal format that handles both > > > tunnel- and transport-mode requirements for all manners of existing > > > protocols. > > > > > > If we are going to define a new protocol type, let's define one > that > > > addresses everything we are currently struggling with and has the > > > extensibility to address additional requirements moving forward > into > > > the future. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > Sent: Tuesday, August 06, 2013 2:58 PM > > > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > With a protocol as ossified as UDP, I have a hard time > imagining > > > all > > > > > middleboxes passing the packets with what they would see as a > > > > corrupted > > > > > length field. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > -----Original Message----- > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > > > Behalf > > > > > > Of Ronald Bonica > > > > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > > > > To: C. M. Heard; IPv6 > > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > Mike, > > > > > > > > > > > > The proposal sounds elegant. I will try to paraphrase it to > > make > > > > sure > > > > > > that I understand. > > > > > > > > > > > > When originating a UDP datagram, the host always queries it > > > > > underlying > > > > > > IP stack to determine the PMTU for the destination. If the > PMTU > > > > > > greater than or equal to the size of the payload plus the UDP > > > > header > > > > > > plus the IP header, plus all IP extension headers, the > > > originating > > > > > > host emits a conventional UDP packet which is characterized > as > > > > > follows: > > > > > > > > > > > > - Protocol =3D 17 > > > > > > - Length <=3D L4 length from IP > > > > > > > > > > > > If the PMTU less than the size of the payload plus the UDP > > > > > > header > > > > > plus > > > > > > the IP header, plus all IP extension headers, the originating > > > host > > > > > > emits an unconventional UDP packet which is characterized as > > > > follows: > > > > > > > > > > > > - Protocol =3D 17 > > > > > > - Length > L4 length from IP > > > > > > - Segment Offset, M-bit and Identification fields added to > UDP > > > > header > > > > > > before the payload > > > > > > > > > > > > If an unconventional UDP packet arrives a destination that > > > supports > > > > > > unconventional packets, it is reassembled at the transport > > layer. > > > > If > > > > > > an unconventional UDP packet arrives a destination that does > > not > > > > > > support unconventional packets, it is discarded. > > > > > > > > > > > > Do I have this much right? > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On > > > > > Behalf > > > > > > Of > > > > > > > C. M. Heard > > > > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > > > > To: IPv6 > > > > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > > > > I agree that C.M. Heard's ideas should be explored in > > more > > > > > > > > > detail > > > > > > > by > > > > > > > > > the IETF. > > > > > > > > > > > > > > The idea was essentially UDP with segmentation fields, > which > > > > would > > > > > > > require a new protocol number. > > > > > > > > > > > > > > In an offline discussion with Mark Smith and I kicked > around > > > > > > > an > > > > > idea > > > > > > > for an alternate version not requiring a new protocol > number, > > > but > > > > > > > relying instead on the redundancy of the UDP Length field. > > > > > > > The > > > > UDP > > > > > > > Length field is not actually needed; TCP does not have one > > but > > > > > > > rather relies on the length reported by the IP layer. > Under > > > > > current > > > > > > > standards, the UDP Length field must be at least 8 and > cannot > > > > > exceed > > > > > > > the IP payload length minus the combined length of any > > > extension > > > > > > > headers -- let's call this the L4 length from IP. Existing > > > > > > > implementations are supposed to drop UDP datagrams that > fail > > > this > > > > > > > check, and all the ones I know of do so. > > > > > > > > > > > > > > The question then arises whether it might reasonably be > > > possible > > > > to > > > > > > re- > > > > > > > purpose the case UDP Length > L4 length from IP to mean a > > > > segmented > > > > > > UDP > > > > > > > datagram. > > > > > > > > > > > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would b= e > > > > > > > intepreted as a standard unsegmented UDP datagram, as is it > > > now. > > > > > > > That's the case pictured below. Note that if the L4 length > > > > > > > indicated by the IP layer exceeds the UDP Length, then the > > > extra > > > > > > > octets would > > > > > > be > > > > > > > discarded and are not delivered to the application; that is > > > > > > > the behavior of the implementations I know of. > > > > > > > > > > > > > > 0 15 16 > > > > > 31 > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | Source Port | Destination Port > > > > > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | Length <=3D L4 length from IP | Checksum > > > > > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | data octets > ... > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| > ... > > > > > > > > > > > > > > Now suppose that we have a long UDP datagram that we want > to > > > send > > > > > in > > > > > > > segments. We set the Length and Checksum fields as usual, > > and > > > > then > > > > > > cut > > > > > > > the datagram into segments, each of which looks like this: > > > > > > > > > > > > > > 0 15 16 > > > > > 31 > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | Source Port | Destination Port > > > > > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | Length > L4 length from IP | Checksum > > > > > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | (reserved =3D 0) | Segment Offset > > > > > |Res|M| > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | Identification > > > > > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +- > > +- > > > +- > > > > +- > > > > > +-+ > > > > > > > | data octets > ... > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| > ... > > > > > > > > > > > > > > We put the same UDP header in each segment, so (if we take > > > > > > > some > > > > > care > > > > > > in > > > > > > > how we choose the length of the segments) each one will > have > > a > > > > UDP > > > > > > > Length field that is greater than the IP payload length > minus > > > the > > > > > > > combined length of any extension headers. Implementations > > > > > > > that > > > > > > conform > > > > > > > to the current specifications should discard these > segments, > > > and > > > > so > > > > > > > should not mistakenly consider the segmentation fields as > > part > > > of > > > > > > > the application data. That should make it possible for > > > segmented > > > > > > > UDP datagrams to safely coexist with conventional > unsegmented > > > > one, > > > > > > without > > > > > > > getting a new protocol number. > > > > > > > > > > > > > > Possible downsides: some middleboxes may filter such > > > "erroneous" > > > > > > > datagrams, and some existing erroneous implementations may > > > > > > > fail > > > > to > > > > > > > do the checks they should and might mistake these segments > > for > > > > > > > ordinary UDP datagrams. > > > > > > > > > > > > > > Note that this idea does not work with UDP-lite, which > > > > > > > replaces > > > > the > > > > > > > Length field with a Checksum Coverage field. That could > > > > > > > easily > > > > be > > > > > > too > > > > > > > short to exceed the L4 length from IP. > > > > > > > > > > > > > > Mike Heard > > > > > > > ----------------------------------------------------------- > -- > > - > > > > > > > - > > > -- > > > > -- > > > > > - > > > > > > > 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 > > > ------------------------------------------------------------------- > - > > >=20 From Fred.L.Templin@boeing.com Wed Aug 7 07:55:38 2013 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 A119921E813F for ; Wed, 7 Aug 2013 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzE+ZuSmb9Bi for ; Wed, 7 Aug 2013 07:55:34 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 004A821E811F for ; Wed, 7 Aug 2013 07:55:33 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r77EtXSm009033 for ; Wed, 7 Aug 2013 07:55:33 -0700 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r77EtX1W009022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 7 Aug 2013 07:55:33 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.4]) with mapi id 14.02.0328.011; Wed, 7 Aug 2013 07:55:32 -0700 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: "Deprecate" Thread-Topic: "Deprecate" Thread-Index: AQHOkwgKb4hQ1uPQyEGB8hnfCjzuiZmJ1VEw Date: Wed, 7 Aug 2013 14:55:32 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E16EB@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE25127193F1@BY2PRD0511MB428.namprd05.prod.outlook.com> <0DFABCA9-79D3-4287-978E-5F7F7BBC13A8@gmail.com> <245F50A1-B2C3-4E4A-B541-305A84F8298F@employees.org> <1E72280C-8182-47F3-9C79-C557C2A2AAC4@gmail.com> <44DD17CB-FC14-4E21-A350-4201AEF1CD78@gmail.com> <2134F8430051B64F815C691A62D983180E085F@XCH-BLV-504.nw.nos.boeing.com> <086B8FD8-E382-4F17-9130-BEE14135559B@gmail.com> In-Reply-To: <086B8FD8-E382-4F17-9130-BEE14135559B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Aug 2013 14:55:38 -0000 Hi Ran, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > RJ Atkinson > Sent: Tuesday, August 06, 2013 5:50 PM > To: ipv6@ietf.org > Subject: Re: "Deprecate" >=20 >=20 > On 06 Aug 2013, at 13:21 , Templin, Fred L wrote: > >> Tunnel ingress devices already are allowed to fragment > >> IPv6 packets by various IETF approved tunnelling > >> specifications, as you have agreed. > > > > Fragmentation of the inner packet before encapsulation > > is different from fragmentation of the outer packet after > > encapsulation. >=20 > I've coded this for IPv6. It is the SAME fragmentation > code AND the SAME reassembly code for both cases. >=20 > The operational scenarios can and do vary, but the > code path (and the specification for how to perform it) > are IDENTICAL - not DIFFERENT. I have coded fragmentation and reassembly code too. Many of the readers of this list have as well, so I don't know that you can claim to be uniquely qualified to speak on this point. =20 > > ... > > This discussion is coming full circle... >=20 > (I agree this sub-thread is looping. So can we please > let this rest on grounds that no one has proposed any > specification change ? :-) SEAL is proposed. SEAL addresses tunnel and transport mode operation in environments where ICMP PTBs may be absent or untrustworthy. Thanks - Fred fred.l.templin@boeing.com =20 > Yours, >=20 > Ran >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Wed Aug 7 07:57:24 2013 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 4BCCD11E8144 for ; Wed, 7 Aug 2013 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Hk6FldxGGJ for ; Wed, 7 Aug 2013 07:57:19 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 515EB11E8142 for ; Wed, 7 Aug 2013 07:57:19 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r77EvIJm003579 for ; Wed, 7 Aug 2013 07:57:19 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r77EvHLo003566 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 7 Aug 2013 07:57:18 -0700 Received: from XCH-BLV-405.nw.nos.boeing.com (130.247.25.158) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 07:57:17 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-405.nw.nos.boeing.com ([169.254.5.132]) with mapi id 14.02.0328.011; Wed, 7 Aug 2013 07:57:17 -0700 From: "Templin, Fred L" To: Mark Andrews Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOkxZJ4SMEeC7qyE6QlR5ihkVRYZmJ1lUQ Date: Wed, 7 Aug 2013 14:57:16 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> In-Reply-To: <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Aug 2013 14:57:24 -0000 Hi Mark, > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Tuesday, August 06, 2013 7:32 PM > To: Templin, Fred L > Cc: Doug Barton; ipv6@ietf.org > Subject: Re: UDP+Fragmentation >=20 >=20 > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > If we are going to define a new protocol type, let's define one > > > > that addresses everything we are currently struggling with and > > > > has the extensibility to address additional requirements moving > > > > forward into the future. > > > > > > So in other words let's make all the same mistakes we made with the > > > design of IPv6? :) > > > > Not even. This is about fixing and atoning for mistakes; not > > introducing new ones. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > There are several issues with getting fragments through firewalls. > My draft addresses one of them. >=20 > Putting all the headers into the initial fragment is another part > of fix / reducing the issue. If you don't do something like that > firewall will drop initial fragments because that can't be expected > to reassemble unless they are doing DPI. >=20 > Making fragment sizes more even is yet another part of the issue. >=20 > Allowing tunnel entry points to re-fragment fragments is yet another > part of the solution space. In these points, you are making a good case for SEAL. Thanks - Fred fred.l.templin@boeing.com > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mackermann@bcbsm.com Wed Aug 7 10:30:37 2013 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 B9A6C21F9D12 for ; Wed, 7 Aug 2013 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDO0jPK34JhX for ; Wed, 7 Aug 2013 10:30:27 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id C502C21F9F1C for ; Wed, 7 Aug 2013 10:30:24 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 74C099ADA08 for ; Wed, 7 Aug 2013 12:30:18 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 742D39AD9FC; Wed, 7 Aug 2013 12:30:17 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 19D982F0045; Wed, 7 Aug 2013 13:23:03 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id 0D3012F0043; Wed, 7 Aug 2013 13:23:03 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%13]) with mapi id 14.01.0438.000; Wed, 7 Aug 2013 13:30:16 -0400 From: "Ackermann, Michael" To: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: draft-elkins-6man-ipv6-pdm-dest-option-00 Thread-Topic: draft-elkins-6man-ipv6-pdm-dest-option-00 Thread-Index: Ac6Tduii6HBaDHrPTdid+mpYk64vCA== Date: Wed, 7 Aug 2013 17:30:16 +0000 Deferred-Delivery: Wed, 7 Aug 2013 17:30:00 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A7E2A84@PWN401EA160.ent.corp.bcbsm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_" MIME-Version: 1.0 Cc: Bill Jouris 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, 07 Aug 2013 17:30:38 -0000 --_000_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 87 in Berlin, our team presented the Performance and Diagnostic = Metrics (PDM) Option for the DOH Extension Header. This presentation, and = the associated Draft, addressed the need for enhanced diagnostics and = performance information in IPv6, as well as a recommended solution that = would accomplish this. Similar information on this topic was presented to both v6ops and 6man. There were several follow up issues and questions that we will now address = on the Email list. We will be discussing our proposal with a number of other IETF groups = (NTP, IPPM, LMAP) as well as RIPE NCC TTM. We will cross-post the results = of our discussions on the appropriate lists. To summarize our proposal and the outstanding issues/questions:: 1. This Destination Option type is Optional and can be turned on/off = independently at either end. 2. The field called Packet Sequence Number is similar to IPID in = IPv4 and is primarily intended to ease and expedite diagnostics, = particularly at end points. 3. The two Timestamp fields are primarily for network performance = triage and metrics. These fields can also be utilized for: performance = reporting; by security devices; and for any other functions requiring a = highly granular time reference. 4. The 3 new fields can also be utilized together to further enhance = network diagnostics and support, at any point or device in the network path. 5. The 4th field is open to be used by applications and platforms = having =22Special=22 performance or diagnostic needs (e.g. Gaming, = commerce, etc.). 6. As pointed out by Joel after the presentation, having = synchronized time sources in the devices being analyzed is critical for = effective results when using the network performance (timestamps) features = and functions. ANY performance monitoring/measurement solution will = require this -- see, for example, RFC 2679 and RFC2681. We will discuss = this issue with other groups to see how they have dealt with this problem. 7. Both the Packet Sequence number and the Timestamp fields are per = =22FLOW=22. After the presentation it was pointed out that this term was = evidently not meaningful or specific enough. Some would use the words per = =22Session=22, per =22Connection=22 or per =22Socket=22. Regardless of = the term applied, the 5 unique identifiers are IP address and port at each = end point, plus the protocol (e.g. UDP, TCP, etc.). Hopefully that = delineates what was referred to in the presentation as =22Flow=22. 8. In the question and answer period of the presentation, it was = suggested that this solution should work fine in private networks, but = perhaps not on the Internet. It is our assertion that this solution = should work on all networks, as long as the DOH Extension Header is = passed end to end. Since Extension Headers are an intrinsic component of = the IPv6 Architecture, we should be able to assume this to be true. If = Extension Headers are not being passed along any given path (Internet or = otherwise), then that is an issue/problem that is much bigger than this = proposal and needs to be adequately addressed if IPv6 is to be successful. This is the area that we are exploring with other IETF groups. We hope to = collaborate with them and incorporate their expertise and experience to = build a solution which will be useful for the Internet as well as private = networks. We feel that a simple and scalable way to provide accurate and timely = diagnostics and performance measurement is what is needed to further the = usability and promote the growth of the Internet as well as implementation = of IPv6. If other issues or questions exist, relative to this proposal, we look = forward to addressing them. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

At IETF 87 in Berlin, our team presented the Performance and = Diagnostic Metrics (PDM) Option for the DOH Extension = Header.  This presentation, and the associated = Draft, addressed the need for enhanced diagnostics and performance information in IPv6, as well as a recommended solution that would = accomplish this.      

 

Similar information on this topic was presented to both v6ops and = 6man.

 

There were several follow up issues and questions that we will now = address on the Email list.    

 

We will be discussing our proposal with a number of = other IETF groups (NTP, IPPM, LMAP) as well as RIPE NCC TTM.  We will = cross-post the results of our discussions on the appropriate lists.

 

To summarize our proposal and the outstanding = issues/questions::

 

1.     &nb= sp; This Destination Option type is Optional and can be turned on/off independently at either end.

 

2.       The field called Packet = Sequence Number is similar to IPID in IPv4 and is primarily intended = to ease and expedite diagnostics, particularly at end points. 

 

3.       The two = Timestamp fields are primarily for network performance triage and = metrics.  These fields can also be utilized for: performance = reporting; by security devices; and for any other functions requiring a highly = granular time reference. 

 

4.       The 3 new fields can also = be utilized together to further enhance network diagnostics and support, = at any point or device in the network path.

 

5.       The 4th field is open to be used = by applications and platforms having &=238220;Special&=238221; performance or diagnostic needs (e.g. Gaming, commerce, etc.).

 

6.       As pointed out by Joel = after the presentation, having synchronized time sources in the devices = being analyzed is critical for effective results when using the network performance (timestamps) features and = functions.  ANY performance monitoring/measurement solution will = require this -- see, for example, RFC 2679 and RFC2681.   We = will discuss this issue with other groups to see how they have dealt with this problem.

 

7.       Both the Packet Sequence = number and the Timestamp fields are per = &=238220;FLOW&=238221;.   After the presentation it was pointed = out that this term was evidently not meaningful or specific enough.  Some would use the = words per &=238220;Session&=238221;, per &=238220;Connection&=238221; =  or per &=238220;Socket&=238221;.  Regardless of the term = applied, the 5 unique identifiers are IP address and port at each end = point, plus the protocol (e.g. UDP, TCP, etc.).  Hopefully that delineates what was referred to in the presentation as = &=238220;Flow&=238221;. 

 

8.       In the question and = answer period of the presentation, it was suggested that this solution = should work fine in private networks, but perhaps not on the Internet.  It is our assertion that this solution should = work on all networks,  as long as the DOH Extension Header is passed = end to end.  Since Extension Headers are an intrinsic component = of the IPv6 Architecture, we should be able to assume this to be true.  If Extension Headers are not being passed along any = given path (Internet or otherwise), then that is an issue/problem that is = much bigger than this proposal and needs to be adequately addressed if = IPv6 is to be successful. 

 

This is the area that we are exploring with other IETF groups.  = We hope to collaborate with them and incorporate their expertise and = experience to build a solution which will be useful for the Internet as well as private networks.

 

 

We feel that a simple and scalable way to provide accurate and timely = diagnostics and performance measurement is what is needed to further the = usability and promote the growth of the Internet as well as implementation of IPv6.

 

If other issues or questions exist, relative to this proposal, we = look forward to addressing them.

 


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_-- From Fred.L.Templin@boeing.com Wed Aug 7 10:44:52 2013 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 23C5D11E80E2 for ; Wed, 7 Aug 2013 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FngyfLZTiSP for ; Wed, 7 Aug 2013 10:44:43 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 80E1211E8166 for ; Wed, 7 Aug 2013 10:44:37 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r77Hibmr006691 for ; Wed, 7 Aug 2013 10:44:37 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r77HiZ6N006666 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 7 Aug 2013 10:44:35 -0700 Received: from XCH-BLV-408.nw.nos.boeing.com (130.247.25.166) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 10:44:35 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.45]) with mapi id 14.02.0328.011; Wed, 7 Aug 2013 10:44:35 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOkxZJ4SMEeC7qyE6QlR5ihkVRYZmJ1lUQgAAq0lA= Date: Wed, 7 Aug 2013 17:44:34 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E199F@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Aug 2013 17:44:52 -0000 Here's another thing to mention on this subject. Defining a new IP protocol number is great, but might be blocked on paths that only accept legacy protocols such as UDP and TCP (I believe SCTP and DCCP suffer from this issue). So, SEAL provides a UDP encapsulation format and defines a new UDP port number for SEAL. In that case, the transport mode encapsulation for SEAL looks like this: +---------------------+ | IP header | | (Nexthdr =3D UDP) | +---------------------+ | Outer UDP header | | (port =3D SEAL) | +---------------------+ | SEAL Header | | (Nexthdr =3D UDP) | +---------------------+ | Inner UDP header | | (port =3D Application)| +---------------------+ | | ~ Application Data ~ | | +---------------------+ This may seem unsavory to some who prefer a "clean" encapsulation, but may be necessary on some paths. Thanks - Fred fred.l.templin@boeing.com From marka@isc.org Wed Aug 7 14:54:36 2013 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 827C421F997D for ; Wed, 7 Aug 2013 14:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvpdD7XI6pkU for ; Wed, 7 Aug 2013 14:54:32 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2347921F9CDA for ; Wed, 7 Aug 2013 14:54:31 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D8F7AC947E; Wed, 7 Aug 2013 21:54:12 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375912466; bh=qJssB3tkrVcBEUbd/CjTqb0LtnOdNTKbpV3VZuBQhcg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=pwUNfl1FhfN4r9ASJF9AW+vbfPfAwBPo8SYOnlc64s+jmnkarfLtg1rRqFPPjorK5 KtwXZemlbtBDQa9fBlJ1WCS9bB9vURYlv+FV4QI4TRC1LxaCmXeYSBrV7pDfmcSnaO hUc3Gk9F7cPQ1rruwpE49qVGasN7wjS8FM8d7Bh8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 7 Aug 2013 21:54:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5BFDB160386; Wed, 7 Aug 2013 21:58:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LpqgRUS_ZySz; Wed, 7 Aug 2013 21:58:30 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 062ED160387; Wed, 7 Aug 2013 21:58:30 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 93414160386; Wed, 7 Aug 2013 21:58:29 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id F41D0381DFF9; Thu, 8 Aug 2013 07:54:08 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Wed, 07 Aug 2013 14:57:16 +0000." <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 08 Aug 2013 07:54:08 +1000 Message-Id: <20130807215408.F41D0381DFF9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist 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, 07 Aug 2013 21:54:36 -0000 In message <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.co m>, "Templin, Fred L" writes: > Hi Mark, > > > -----Original Message----- > > From: Mark Andrews [mailto:marka@isc.org] > > Sent: Tuesday, August 06, 2013 7:32 PM > > To: Templin, Fred L > > Cc: Doug Barton; ipv6@ietf.org > > Subject: Re: UDP+Fragmentation > >=20 > >=20 > > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > > If we are going to define a new protocol type, let's define one > > > > > that addresses everything we are currently struggling with and > > > > > has the extensibility to address additional requirements moving > > > > > forward into the future. > > > > > > > > So in other words let's make all the same mistakes we made with the > > > > design of IPv6? :) > > > > > > Not even. This is about fixing and atoning for mistakes; not > > > introducing new ones. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > >=20 > > There are several issues with getting fragments through firewalls. > > My draft addresses one of them. > >=20 > > Putting all the headers into the initial fragment is another part > > of fix / reducing the issue. If you don't do something like that > > firewall will drop initial fragments because that can't be expected > > to reassemble unless they are doing DPI. > >=20 > > Making fragment sizes more even is yet another part of the issue. > >=20 > > Allowing tunnel entry points to re-fragment fragments is yet another > > part of the solution space. > > In these points, you are making a good case for SEAL. And all those changes are independent of a SEAL header. They are changes to the fragmentation algorithm. SEAL has a big drawback. SEAL requires then tunnel endpoint / destination node to understand SEAL. My draft does not require any other node to understand the option. You can start sending packets with the option immediately and they should be passed by nodes that are not aware of what it does. Destination nodes can process the fragments without knowning the contents. This is no more dangerous than processing fragmented traffic without the option if you are already passing fragments. The key difference is HEADER vs OPTION. Mark > Thanks - Fred > fred.l.templin@boeing.com > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Fred.L.Templin@boeing.com Wed Aug 7 15:17:28 2013 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 101CD21F9B8D for ; Wed, 7 Aug 2013 15:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRM4Cr623MO9 for ; Wed, 7 Aug 2013 15:17:23 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 55E0511E814D for ; Wed, 7 Aug 2013 15:17:20 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r77MHH5w013448 for ; Wed, 7 Aug 2013 15:17:17 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r77MHGbk013433 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 7 Aug 2013 15:17:16 -0700 Received: from XCH-BLV-208.nw.nos.boeing.com (10.57.37.5) by XCH-NWHT-01.nw.nos.boeing.com (130.247.70.222) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 15:17:18 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.210]) with mapi id 14.02.0328.011; Wed, 7 Aug 2013 15:17:18 -0700 From: "Templin, Fred L" To: Mark Andrews Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOk7ik4SMEeC7qyE6QlR5ihkVRYZmKTGFA Date: Wed, 7 Aug 2013 22:17:17 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> <20130807215408.F41D0381DFF9@drugs.dv.isc.org> In-Reply-To: <20130807215408.F41D0381DFF9@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Aug 2013 22:17:28 -0000 Hi Mark, > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Wednesday, August 07, 2013 2:54 PM > To: Templin, Fred L > Cc: Doug Barton; ipv6@ietf.org > Subject: Re: UDP+Fragmentation >=20 >=20 > In message <2134F8430051B64F815C691A62D983180E170A@XCH-BLV- > 504.nw.nos.boeing.co > m>, "Templin, Fred L" writes: > > Hi Mark, > > > > > -----Original Message----- > > > From: Mark Andrews [mailto:marka@isc.org] > > > Sent: Tuesday, August 06, 2013 7:32 PM > > > To: Templin, Fred L > > > Cc: Doug Barton; ipv6@ietf.org > > > Subject: Re: UDP+Fragmentation > > >=3D20 > > >=3D20 > > > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > > > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > > > If we are going to define a new protocol type, let's define > one > > > > > > that addresses everything we are currently struggling with > and > > > > > > has the extensibility to address additional requirements > moving > > > > > > forward into the future. > > > > > > > > > > So in other words let's make all the same mistakes we made with > the > > > > > design of IPv6? :) > > > > > > > > Not even. This is about fixing and atoning for mistakes; not > > > > introducing new ones. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > ----------------------------------------------------------------- > --- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > ----------------------------------------------------------------- > --- > > >=3D20 > > > There are several issues with getting fragments through firewalls. > > > My draft addresses one of them. > > >=3D20 > > > Putting all the headers into the initial fragment is another part > > > of fix / reducing the issue. If you don't do something like that > > > firewall will drop initial fragments because that can't be expected > > > to reassemble unless they are doing DPI. > > >=3D20 > > > Making fragment sizes more even is yet another part of the issue. > > >=3D20 > > > Allowing tunnel entry points to re-fragment fragments is yet > another > > > part of the solution space. > > > > In these points, you are making a good case for SEAL. >=20 > And all those changes are independent of a SEAL header. They are > changes to the fragmentation algorithm. But, an attacker does not need to implement the changes to the fragmentation algorithm in order to be compliant with the specs. > SEAL has a big drawback. SEAL requires then tunnel endpoint / > destination node to understand SEAL. Right that the destination needs to understand SEAL. > My draft does not require any other node to understand the option. > You can start sending packets with the option immediately and they > should be passed by nodes that are not aware of what it does. > Destination nodes can process the fragments without knowning the > contents. This is no more dangerous than processing fragmented > traffic without the option if you are already passing fragments. But, does it address the tiny fragment attack profile that Ron's draft is concerned with? And will it be robust as more and more operators unconditionally drop IP fragments? > The key difference is HEADER vs OPTION. That's right, but without a new header there is no means to probe the path MTU or even to ping the destination to see if it is up as part of the protocol. Plus, we need a multiple-part solution that not only addresses transport-mode UDP fragmentation but also tunnel-mode operation for tunnels that would otherwise be susceptible to MTU issues. Thanks - Fred fred.l.templin@boeing.com > Mark >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Aug 7 16:55:59 2013 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 8949A11E8178 for ; Wed, 7 Aug 2013 16:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG14flfC-HD7 for ; Wed, 7 Aug 2013 16:55:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1F21F9A43 for ; Wed, 7 Aug 2013 16:55:53 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6597BC9428; Wed, 7 Aug 2013 23:55:36 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375919750; bh=3w1gH3TiCPKnfi6ixeA4t9telPDX1iFt/oXKaFaXOnE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ib63zacmRtdJkj6SWAkYYSXbq4gR7iJqQ8VmVPlGjaCpufqPo+whi8J1ZNa9OsKNS fOoN40IRe4pG7nqeYCg8gVyjX8XvilrsJZXzLsDNJIJpb+qYt7UBmSYep1nB6iw0QU DWycBMCpjkjeL2Q37Gd6bsKB+HeQ3mWoHUdAan5E= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 7 Aug 2013 23:55:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4123E160387; Wed, 7 Aug 2013 23:59:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id cy7lCkAdWUMG; Wed, 7 Aug 2013 23:59:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8A1F716038A; Wed, 7 Aug 2013 23:59:53 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 2F734160389; Wed, 7 Aug 2013 23:59:53 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B250D3821012; Thu, 8 Aug 2013 09:55:31 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> <20130807215408.F41D0381DFF9@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-504.nw.nos.boeing.com> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Wed, 07 Aug 2013 22:17:17 +0000." <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 08 Aug 2013 09:55:31 +1000 Message-Id: <20130807235531.B250D3821012@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist 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, 07 Aug 2013 23:55:59 -0000 In message <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-504.nw.nos.boeing.co m>, "Templin, Fred L" writes: > Hi Mark, > > > -----Original Message----- > > From: Mark Andrews [mailto:marka@isc.org] > > Sent: Wednesday, August 07, 2013 2:54 PM > > To: Templin, Fred L > > Cc: Doug Barton; ipv6@ietf.org > > Subject: Re: UDP+Fragmentation > >=20 > >=20 > > In message <2134F8430051B64F815C691A62D983180E170A@XCH-BLV- > > 504.nw.nos.boeing.co > > m>, "Templin, Fred L" writes: > > > Hi Mark, > > > > > > > -----Original Message----- > > > > From: Mark Andrews [mailto:marka@isc.org] > > > > Sent: Tuesday, August 06, 2013 7:32 PM > > > > To: Templin, Fred L > > > > Cc: Doug Barton; ipv6@ietf.org > > > > Subject: Re: UDP+Fragmentation > > > >=3D20 > > > >=3D20 > > > > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > > > > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > > > > If we are going to define a new protocol type, let's define > > one > > > > > > > that addresses everything we are currently struggling with > > and > > > > > > > has the extensibility to address additional requirements > > moving > > > > > > > forward into the future. > > > > > > > > > > > > So in other words let's make all the same mistakes we made with > > the > > > > > > design of IPv6? :) > > > > > > > > > > Not even. This is about fixing and atoning for mistakes; not > > > > > introducing new ones. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > ----------------------------------------------------------------- > > --- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > ----------------------------------------------------------------- > > --- > > > >=3D20 > > > > There are several issues with getting fragments through firewalls. > > > > My draft addresses one of them. > > > >=3D20 > > > > Putting all the headers into the initial fragment is another part > > > > of fix / reducing the issue. If you don't do something like that > > > > firewall will drop initial fragments because that can't be expected > > > > to reassemble unless they are doing DPI. > > > >=3D20 > > > > Making fragment sizes more even is yet another part of the issue. > > > >=3D20 > > > > Allowing tunnel entry points to re-fragment fragments is yet > > another > > > > part of the solution space. > > > > > > In these points, you are making a good case for SEAL. > >=20 > > And all those changes are independent of a SEAL header. They are > > changes to the fragmentation algorithm. > > But, an attacker does not need to implement the changes to the > fragmentation algorithm in order to be compliant with the specs. > > > SEAL has a big drawback. SEAL requires then tunnel endpoint / > > destination node to understand SEAL. > > Right that the destination needs to understand SEAL. > > > My draft does not require any other node to understand the option. > > You can start sending packets with the option immediately and they > > should be passed by nodes that are not aware of what it does. > > Destination nodes can process the fragments without knowning the > > contents. This is no more dangerous than processing fragmented > > traffic without the option if you are already passing fragments. > > But, does it address the tiny fragment attack profile that Ron's > draft is concerned with? And will it be robust as more and more > operators unconditionally drop IP fragments? Fred, you are missing the point. You don't need a single ominbus draft. One can have multiple drafts that address different points. Your arguement is that it is not a omnibus draft. It didn't set out to be a omnibus draft. Today legitimate IPv6 nodes send fragments no smaller than 1280 unless the first hop is being mapped to IPv4 at the sending node and the IPv4 mtu is less than 1280. 1280 bytes contains the full header chain unless someone is launching a attack. Today firwalls drop fragments that don't have enough information in them to work out if the non-initial fragment can pass without passing all fragments. The initial fragment is dropped because the firewall operator knows it is pointless to send it despite there being enough information. If attackers sends tiny fragments they will continue to be dropped with or without this option as the firewall doesn't have enough information to make the decision in the initial fragment. Legitimate initial fragment however can now be let through as the firewall knows that the other fragments will have the necessary information. Other fragments can be let through with this option as the firewall will pass the legitimate initial fragment. Attackers now have to find the slot/pinhole to send attack traffic through instead of just letting through all fragments. Mark > > The key difference is HEADER vs OPTION. > > That's right, but without a new header there is no means to probe > the path MTU or even to ping the destination to see if it is up > as part of the protocol. Plus, we need a multiple-part solution > that not only addresses transport-mode UDP fragmentation but also > tunnel-mode operation for tunnels that would otherwise be > susceptible to MTU issues. > > Thanks - Fred > fred.l.templin@boeing.com > > > Mark > >=20 > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > Mark > > > > -- > > > > Mark Andrews, ISC > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Fred.L.Templin@boeing.com Thu Aug 8 08:21:59 2013 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 CC04E21F9BCA for ; Thu, 8 Aug 2013 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgXyt0xuouVu for ; Thu, 8 Aug 2013 08:21:43 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6494321F9984 for ; Thu, 8 Aug 2013 08:21:42 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r78FLfEe003619 for ; Thu, 8 Aug 2013 08:21:42 -0700 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r78FLeAB003584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 8 Aug 2013 08:21:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.63]) with mapi id 14.02.0328.011; Thu, 8 Aug 2013 08:21:39 -0700 From: "Templin, Fred L" To: Mark Andrews Subject: RE: UDP+Fragmentation Thread-Topic: UDP+Fragmentation Thread-Index: AQHOk8mZ4SMEeC7qyE6QlR5ihkVRYZmLZxgg Date: Thu, 8 Aug 2013 15:21:38 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E26B8@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> <20130807215408.F41D0381DFF9@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-504.nw.nos.boeing.com> <20130807235531.B250D3821012@drugs.dv.isc.org> In-Reply-To: <20130807235531.B250D3821012@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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: Thu, 08 Aug 2013 15:21:59 -0000 Hi Mark, > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Wednesday, August 07, 2013 4:56 PM > To: Templin, Fred L > Cc: Doug Barton; ipv6@ietf.org > Subject: Re: UDP+Fragmentation >=20 >=20 > In message <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV- > 504.nw.nos.boeing.co > m>, "Templin, Fred L" writes: > > Hi Mark, > > > > > -----Original Message----- > > > From: Mark Andrews [mailto:marka@isc.org] > > > Sent: Wednesday, August 07, 2013 2:54 PM > > > To: Templin, Fred L > > > Cc: Doug Barton; ipv6@ietf.org > > > Subject: Re: UDP+Fragmentation > > >=3D20 > > >=3D20 > > > In message <2134F8430051B64F815C691A62D983180E170A@XCH-BLV- > > > 504.nw.nos.boeing.co > > > m>, "Templin, Fred L" writes: > > > > Hi Mark, > > > > > > > > > -----Original Message----- > > > > > From: Mark Andrews [mailto:marka@isc.org] > > > > > Sent: Tuesday, August 06, 2013 7:32 PM > > > > > To: Templin, Fred L > > > > > Cc: Doug Barton; ipv6@ietf.org > > > > > Subject: Re: UDP+Fragmentation > > > > >=3D3D20 > > > > >=3D3D20 > > > > > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > > > > > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > > > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > > > > > If we are going to define a new protocol type, let's > define > > > one > > > > > > > > that addresses everything we are currently struggling > with > > > and > > > > > > > > has the extensibility to address additional requirements > > > moving > > > > > > > > forward into the future. > > > > > > > > > > > > > > So in other words let's make all the same mistakes we made > with > > > the > > > > > > > design of IPv6? :) > > > > > > > > > > > > Not even. This is about fixing and atoning for mistakes; not > > > > > > introducing new ones. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > ------------------------------------------------------------- > ---- > > > --- > > > > > > IETF IPv6 working group mailing list > > > > > > ipv6@ietf.org > > > > > > Administrative Requests: > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > ------------------------------------------------------------- > ---- > > > --- > > > > >=3D3D20 > > > > > There are several issues with getting fragments through > firewalls. > > > > > My draft addresses one of them. > > > > >=3D3D20 > > > > > Putting all the headers into the initial fragment is another > part > > > > > of fix / reducing the issue. If you don't do something like > that > > > > > firewall will drop initial fragments because that can't be > expected > > > > > to reassemble unless they are doing DPI. > > > > >=3D3D20 > > > > > Making fragment sizes more even is yet another part of the > issue. > > > > >=3D3D20 > > > > > Allowing tunnel entry points to re-fragment fragments is yet > > > another > > > > > part of the solution space. > > > > > > > > In these points, you are making a good case for SEAL. > > >=3D20 > > > And all those changes are independent of a SEAL header. They are > > > changes to the fragmentation algorithm. > > > > But, an attacker does not need to implement the changes to the > > fragmentation algorithm in order to be compliant with the specs. > > > > > SEAL has a big drawback. SEAL requires then tunnel endpoint / > > > destination node to understand SEAL. > > > > Right that the destination needs to understand SEAL. > > > > > My draft does not require any other node to understand the option. > > > You can start sending packets with the option immediately and they > > > should be passed by nodes that are not aware of what it does. > > > Destination nodes can process the fragments without knowning the > > > contents. This is no more dangerous than processing fragmented > > > traffic without the option if you are already passing fragments. > > > > But, does it address the tiny fragment attack profile that Ron's > > draft is concerned with? And will it be robust as more and more > > operators unconditionally drop IP fragments? >=20 > Fred, you are missing the point. You don't need a single ominbus > draft. One can have multiple drafts that address different points. You know, I was thinking pretty much the same thing on my way into work today. SEAL didn't set out to address transport mode, and until the most recent version left it as "out of scope". I'm willing to believe that an incrementally deployable approach such as what you are describing could address transport-specific requirements.=20 > Your arguement is that it is not a omnibus draft. It didn't set > out to be a omnibus draft. OK. > Today legitimate IPv6 nodes send fragments no smaller than 1280 > unless the first hop is being mapped to IPv4 at the sending node > and the IPv4 mtu is less than 1280. 1280 bytes contains the full > header chain unless someone is launching a attack. >=20 > Today firwalls drop fragments that don't have enough information > in them to work out if the non-initial fragment can pass without > passing all fragments. The initial fragment is dropped because the > firewall operator knows it is pointless to send it despite there > being enough information. >=20 > If attackers sends tiny fragments they will continue to be dropped > with or without this option as the firewall doesn't have enough > information to make the decision in the initial fragment. Legitimate > initial fragment however can now be let through as the firewall > knows that the other fragments will have the necessary information. > Other fragments can be let through with this option as the firewall > will pass the legitimate initial fragment. But, is the firewall going to do any bounds checking on the fragmentation offset? Asked another way, is there still an overlapping fragment attack profile to be concerned with? =20 > Attackers now have to find the slot/pinhole to send attack traffic > through instead of just letting through all fragments.=20 > > Mark >=20 > > > The key difference is HEADER vs OPTION. > > > > That's right, but without a new header there is no means to probe > > the path MTU or even to ping the destination to see if it is up > > as part of the protocol. This is one part that still concerns me a bit. Sure, the application can simply fragment everything larger than 1280 but wouldn't it be better to have an assured path MTU so it knows whether it can suspend the fragmentation process? I'm thinking of RFC4821 applied to UDP and/or to specific app's. Thanks - Fred fred.l.templin@boeing.com > > Plus, we need a multiple-part solution > > that not only addresses transport-mode UDP fragmentation but also > > tunnel-mode operation for tunnels that would otherwise be > > susceptible to MTU issues. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Mark > > >=3D20 > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > Mark > > > > > -- > > > > > Mark Andrews, ISC > > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ietf@rozanak.com Thu Aug 8 15:28:17 2013 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 23AA821F9D23 for ; Thu, 8 Aug 2013 15:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7sK+6+SHGXH for ; Thu, 8 Aug 2013 15:28:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1096621F9931 for ; Thu, 8 Aug 2013 15:27:49 -0700 (PDT) Received: from kopoli (g225043090.adsl.alicedsl.de [92.225.43.90]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LwJVO-1WDQBt2vXi-017prD; Thu, 08 Aug 2013 18:27:22 -0400 From: "Hosnieh Rafiee" To: "Keith Moore" , "Andrew Yourtchenko" , "Erik Nordmark" , , "Dave Thaler" , , "Alissa Cooper" , "Fernando Gont" Subject: ra-privacy : new version accomodated all the comments Date: Fri, 9 Aug 2013 00:27:04 +0200 Message-ID: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CE9497.3418B4D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6Ug+E887IGhSMxR1yn9D3f3BAXrw== Content-Language: en-us X-Provags-ID: V02:K0:YEJoLlUbcAupWAs4xVX7KdjEvVp6kUxtLVBZ0JJRzUc /O7RAkvLooACY0HSd1QdOG7U60tksymDHB+gQFJkBpB1iLKNMU 6bxvQhuFoZgll/XRgt3MRC/oJQGJeAx6YmEp+AcUPF0qWmkBUk zWuQCdR6yQImz+dNZkHjAjvk1FqMFH2Wfth7Bhb9UZKp0Q7kjP h6KRM4ihA6JDFkxc1KIUigRxkKTKStGjC0AOm8sepezl+XTkrM GoX7jK7VcgSb4FJTOe56dQ0WeDpuV4s7yU+yIAROWj98unbzaX d3eJzldQTjttMBngkSRPvgdczyMxBojCHRLBkY4akWN7FObMRd Wj2viZ75qtQUMYk5ExXA= 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: Thu, 08 Aug 2013 22:28:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0030_01CE9497.3418B4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello and thank you so much for your comments. I applied your comments and submitted a new version of the ra-privacy draft. I also removed the text concerning the application layer based lifetime from this draft. This draft, thus, just focuses on a few updates to RFC 4941 that address some deficiencies. tools.ietf.org/html/draft-rafiee-6man-ra-privacy According to my discussions with some people during the IETF meetings, some people thought that it would be better to have the discussion about the application layer based lifetime in a separate document as it seems that it is a new mechanism and should not be an update to RFC 4941. In my update to that RFC , I just briefly mentioned that the node "MIGHT" follow the other external policies for the lifetime and "Might" not follow those of RFC 4941. If there are any other issues that I should consider for this draft, please let me know. Thanks, Best, Hosnieh ------=_NextPart_000_0030_01CE9497.3418B4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello and = thank you so much for your comments.

 

I applied = your comments and submitted a new version of the ra-privacy draft. I = also removed the text concerning the application layer based lifetime = from this draft. This draft, thus, just focuses on a few updates to RFC = 4941 that address some deficiencies.

 

tools.ietf.org/html/draft-rafiee-6man-ra-privacy =

 

According to my discussions with some people during = the IETF meetings, some people thought that it would be better to have = the discussion about the application layer based lifetime in a = separate document as it seems that it is a new mechanism and = should not be an update to RFC 4941. In my update to that RFC , I just = briefly mentioned that the node "MIGHT" follow the other = external policies for the lifetime and “Might” not follow = those of RFC 4941.

 

 

If there are = any other issues that I should consider for this draft, please let me = know.

 

Thanks,

Best,

Hosnieh

------=_NextPart_000_0030_01CE9497.3418B4D0-- From internet-drafts@ietf.org Thu Aug 8 15:42:08 2013 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 178C721F9B60; Thu, 8 Aug 2013 15:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OfaaRtByi3D; Thu, 8 Aug 2013 15:42:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78321F9B80; Thu, 8 Aug 2013 15:42:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130808224201.20027.7267.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2013 15:42:01 -0700 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: Thu, 08 Aug 2013 22:42:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A method for Generating Stable Privacy-Enhanced Addresse= s with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-11.txt Pages : 25 Date : 2013-08-08 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Thu Aug 8 16:01:10 2013 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 6DD3D11E80D1 for ; Thu, 8 Aug 2013 16:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRsQdHN8454m for ; Thu, 8 Aug 2013 16:01:10 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CF74421F9EAA for ; Thu, 8 Aug 2013 16:01:09 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.109]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V7ZCT-0003Sm-64; Fri, 09 Aug 2013 01:00:57 +0200 Message-ID: <52042321.4030900@si6networks.com> Date: Thu, 08 Aug 2013 20:00:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : new version accomodated all the comments References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> In-Reply-To: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org, Keith Moore , Erik Nordmark , Andrew Yourtchenko , Dave Thaler , lorenzo@google.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: Thu, 08 Aug 2013 23:01:10 -0000 Hosnieh, Some comments: * In Section 1, you should probably remove some of the general discussion on security and privacy here. For instance, some of your definitions seem incomplete. * Section 6 is fine... but I don't think the rest of the stuff is needed. * Section 7 should probably be removed and just reference draft-6man-cooper-ipv6-addressing-privacy-considerations. Meta comment: If an implementation is going through the burden of implementing this algorithm, it might as well implement a good PRNG, and be done with it (if I understand correctly, the motivation for specifying this algorithm is that you don't have a good PRNG, right?). Thanks, Fernando On 08/08/2013 07:27 PM, Hosnieh Rafiee wrote: > Hello and thank you so much for your comments. > > > > I applied your comments and submitted a new version of the ra-privacy > draft. I also removed the text concerning the application layer based > lifetime from this draft. This draft, thus, just focuses on a few > updates to RFC 4941 that address some deficiencies. > > > > tools.ietf.org/html/draft-rafiee-6man-ra-privacy > > > > According to my discussions with some people during the IETF meetings, > some people thought that it would be better to have the discussion > /_about the application layer based lifetime in a separate document _/as > it seems that it is a new mechanism and should not be an update to RFC > 4941. In my update to that RFC , I just briefly mentioned that the node > "MIGHT" follow the other external policies for the lifetime and “Might” > not follow those of RFC 4941. > > > > > > If there are any other issues that I should consider for this draft, > please let me know. > > > > Thanks, > > Best, > > Hosnieh > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Aug 8 16:12:51 2013 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 A630011E80A2 for ; Thu, 8 Aug 2013 16:12:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0201EpmsnpR for ; Thu, 8 Aug 2013 16:12:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C083611E8161 for ; Thu, 8 Aug 2013 16:12:44 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.109]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V7ZNm-0003hk-RE; Fri, 09 Aug 2013 01:12:39 +0200 Message-ID: <520425E2.7000008@si6networks.com> Date: Thu, 08 Aug 2013 20:12:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-11.txt References: <20130808224201.20027.7267.idtracker@ietfa.amsl.com> In-Reply-To: <20130808224201.20027.7267.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@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, 08 Aug 2013 23:12:51 -0000 Folks, I've posted a rev of this I-D, which addresses the last remaining bits: * The two appendixes have now been moved out of the document, and references to these appendices have been replaced with references to draft-cooper-6man-ipv6-address-generation-privacy * Earlier versions of the document were stated that when doing stable-privacy-addresses, this algorithm should be the sole algorithm used to generate stable identifiers. Dave Thaler noted that while rare, a node could be doing both SLAAC + DHCPv6 addresses, and hence this documenet should govern only SLAAC but not other address generation mechaisms (DHCPv6 or manual configuration). -- I've updated the I-D accordingly. -- It would seem to me that doing both SLAAC + DHCPv6 for addressing is more of a glitch in the spec than a feature.. but might be wrong. And, in any case, that's orthogonal to this document. Yours, Fernando On 08/08/2013 07:42 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) > Author(s) : Fernando Gont > Filename : draft-ietf-6man-stable-privacy-addresses-11.txt > Pages : 25 > Date : 2013-08-08 > > Abstract: > This document specifies a method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC), such that addresses configured using this method are stable > within each subnet, but the Interface Identifier changes when hosts > move from one network to another. This method is meant to be an > alternative to generating Interface Identifiers based on hardware > address (e.g., using IEEE identifiers), such that the benefits of > stable addresses can be achieved without sacrificing the privacy of > users. The method specified in this document applies to all prefixes > a host may be employing, including link-local, global, and unique- > local addresses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka@isc.org Thu Aug 8 16:54:07 2013 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 3B54D11E8176 for ; Thu, 8 Aug 2013 16:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4fvJtUW6o55 for ; Thu, 8 Aug 2013 16:54:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1269A21F9A4A for ; Thu, 8 Aug 2013 16:54:03 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id ECA17C94CD; Thu, 8 Aug 2013 23:53:48 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376006042; bh=khk7ZJDo/xD48fdSSnkRxjF9t8MrT6RKdxkA+D+xnB0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=KbV3x+QD7fzI6JlnRyudCNTKpL9iYLJ3JzJH/ib2F4i8vE73Mo4ZEU31R+yZrCabP +z07v32ThFeU31CojspIZE4Sz1yyq4FIH2txqCdC/evuTFiOxl887lO8/4/NJbPyel p+f+J6DzevLrQ9ksgcOMSg6GAWUZEBdGhYDD8Bhw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 8 Aug 2013 23:53:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2DB5E160390; Thu, 8 Aug 2013 23:58:11 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jYIBEJdhOdSH; Thu, 8 Aug 2013 23:58:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 72D5F160394; Thu, 8 Aug 2013 23:58:09 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0AB40160393; Thu, 8 Aug 2013 23:58:09 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2B936382E6C4; Fri, 9 Aug 2013 09:53:41 +1000 (EST) To: "Templin, Fred L" From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <52017B2E.5050703@dougbarton.us> <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV-504.nw.nos.boeing.com> <20130807023158.DA2ED3813A5F@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E170A@XCH-BLV-504.nw.nos.boeing.com> <20130807215408.F41D0381DFF9@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-504.nw.nos.boeing.com> <20130807235531.B250D3821012@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180E26B8@XCH-BLV-504.nw.nos.boeing.com> Subject: Re: UDP+Fragmentation In-reply-to: Your message of "Thu, 08 Aug 2013 15:21:38 +0000." <2134F8430051B64F815C691A62D983180E26B8@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 09 Aug 2013 09:53:40 +1000 Message-Id: <20130808235341.2B936382E6C4@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist 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: Thu, 08 Aug 2013 23:54:07 -0000 In message <2134F8430051B64F815C691A62D983180E26B8@XCH-BLV-504.nw.nos.boeing.co m>, "Templin, Fred L" writes: > Hi Mark, > > > -----Original Message----- > > From: Mark Andrews [mailto:marka@isc.org] > > Sent: Wednesday, August 07, 2013 4:56 PM > > To: Templin, Fred L > > Cc: Doug Barton; ipv6@ietf.org > > Subject: Re: UDP+Fragmentation > > > > > > In message <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV- > > 504.nw.nos.boeing.co > > m>, "Templin, Fred L" writes: > > > Hi Mark, > > > > > > > -----Original Message----- > > > > From: Mark Andrews [mailto:marka@isc.org] > > > > Sent: Wednesday, August 07, 2013 2:54 PM > > > > To: Templin, Fred L > > > > Cc: Doug Barton; ipv6@ietf.org > > > > Subject: Re: UDP+Fragmentation > > > > > > > > > > > > In message <2134F8430051B64F815C691A62D983180E170A@XCH-BLV- > > > > 504.nw.nos.boeing.co > > > > m>, "Templin, Fred L" writes: > > > > > Hi Mark, > > > > > > > > > > > -----Original Message----- > > > > > > From: Mark Andrews [mailto:marka@isc.org] > > > > > > Sent: Tuesday, August 06, 2013 7:32 PM > > > > > > To: Templin, Fred L > > > > > > Cc: Doug Barton; ipv6@ietf.org > > > > > > Subject: Re: UDP+Fragmentation > > > > > > > > > > > > > > > > > > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > > > > > > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > > > > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > > > > > > If we are going to define a new protocol type, let's > > > > > > > > > define one > > > > > > > > > that addresses everything we are currently struggling > > > > > > > > > with and > > > > > > > > > has the extensibility to address additional requirements > > > > > > > > > moving forward into the future. > > > > > > > > > > > > > > > > So in other words let's make all the same mistakes we made > > > > > > > > with the design of IPv6? :) > > > > > > > > > > > > > > Not even. This is about fixing and atoning for mistakes; not > > > > > > > introducing new ones. > > > > > > > > > > > > > > Thanks - Fred > > > > > > > fred.l.templin@boeing.com > > > > > > > ------------------------------------------------------------- > > ---- > > > > --- > > > > > > > IETF IPv6 working group mailing list > > > > > > > ipv6@ietf.org > > > > > > > Administrative Requests: > > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > ------------------------------------------------------------- > > ---- > > > > --- > > > > > > > > > > > > There are several issues with getting fragments through > > > > > > firewalls. > > > > > > My draft addresses one of them. > > > > > > > > > > > > Putting all the headers into the initial fragment is another > > > > > > part > > > > > > of fix / reducing the issue. If you don't do something like > > > > > > that > > > > > > firewall will drop initial fragments because that can't be > > > > > > expected to reassemble unless they are doing DPI. > > > > > > > > > > > > Making fragment sizes more even is yet another part of the > > > > > > issue. > > > > > > > > > > > > Allowing tunnel entry points to re-fragment fragments is yet > > > > > > another part of the solution space. > > > > > > > > > > In these points, you are making a good case for SEAL. > > > > > > > > And all those changes are independent of a SEAL header. They are > > > > changes to the fragmentation algorithm. > > > > > > But, an attacker does not need to implement the changes to the > > > fragmentation algorithm in order to be compliant with the specs. > > > > > > > SEAL has a big drawback. SEAL requires then tunnel endpoint / > > > > destination node to understand SEAL. > > > > > > Right that the destination needs to understand SEAL. > > > > > > > My draft does not require any other node to understand the option. > > > > You can start sending packets with the option immediately and they > > > > should be passed by nodes that are not aware of what it does. > > > > Destination nodes can process the fragments without knowning the > > > > contents. This is no more dangerous than processing fragmented > > > > traffic without the option if you are already passing fragments. > > > > > > But, does it address the tiny fragment attack profile that Ron's > > > draft is concerned with? And will it be robust as more and more > > > operators unconditionally drop IP fragments? > > > > Fred, you are missing the point. You don't need a single ominbus > > draft. One can have multiple drafts that address different points. > > You know, I was thinking pretty much the same thing on my way > into work today. SEAL didn't set out to address transport mode, > and until the most recent version left it as "out of scope". > I'm willing to believe that an incrementally deployable approach > such as what you are describing could address transport-specific > requirements. > > > Your arguement is that it is not a omnibus draft. It didn't set > > out to be a omnibus draft. > > OK. > > > Today legitimate IPv6 nodes send fragments no smaller than 1280 > > unless the first hop is being mapped to IPv4 at the sending node > > and the IPv4 mtu is less than 1280. 1280 bytes contains the full > > header chain unless someone is launching a attack. > > > > Today firwalls drop fragments that don't have enough information > > in them to work out if the non-initial fragment can pass without > > passing all fragments. The initial fragment is dropped because the > > firewall operator knows it is pointless to send it despite there > > being enough information. > > > > If attackers sends tiny fragments they will continue to be dropped > > with or without this option as the firewall doesn't have enough > > information to make the decision in the initial fragment. Legitimate > > initial fragment however can now be let through as the firewall > > knows that the other fragments will have the necessary information. > > Other fragments can be let through with this option as the firewall > > will pass the legitimate initial fragment. > > But, is the firewall going to do any bounds checking on the > fragmentation offset? Asked another way, is there still an > overlapping fragment attack profile to be concerned with? If you only pass initial fragments which contain a complete header chain RFC 2460 behaviour in the node should be sufficient. The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. > > Attackers now have to find the slot/pinhole to send attack traffic > > through instead of just letting through all fragments. > > > > Mark > > > > > > The key difference is HEADER vs OPTION. > > > > > > That's right, but without a new header there is no means to probe > > > the path MTU or even to ping the destination to see if it is up > > > as part of the protocol. > > This is one part that still concerns me a bit. Sure, the > application can simply fragment everything larger than 1280 > but wouldn't it be better to have an assured path MTU so it > knows whether it can suspend the fragmentation process? I'm > thinking of RFC4821 applied to UDP and/or to specific app's. If it is worth it to the application they can still do it. For things like DNS, PMTUD isn't worth the effort. Just fragment / segment for a 1280 MTU and be done with it. Named does that today though it is still a mess to enable because IPV6_USE_MIN_MTU is not part of POSIX. Named deals with stupid firewalls by sending different sized EDNS UDP buffer sizes in the requests. Named has to deal with a effective MTU of 512 + headers as some firewalls still think DNS/UDP requests can only have a 512 octet payload. Additionally DNS is sometimes anycasted so PTB's can go to the wrong instance. > Thanks - Fred > fred.l.templin@boeing.com > > > > Plus, we need a multiple-part solution > > > that not only addresses transport-mode UDP fragmentation but also > > > tunnel-mode operation for tunnels that would otherwise be > > > susceptible to MTU issues. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > Mark > > > >=20 > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > Mark > > > > > > -- > > > > > > Mark Andrews, ISC > > > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -- > > > > Mark Andrews, ISC > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rbonica@juniper.net Fri Aug 9 04:32:24 2013 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 7E18E21F9E63 for ; Fri, 9 Aug 2013 04:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvhildFl1y9l for ; Fri, 9 Aug 2013 04:32:18 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id CC73221F9BF2 for ; Fri, 9 Aug 2013 04:32:17 -0700 (PDT) Received: from mail40-db8-R.bigfish.com (10.174.8.229) by DB8EHSOBE012.bigfish.com (10.174.4.75) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 11:32:16 +0000 Received: from mail40-db8 (localhost [127.0.0.1]) by mail40-db8-R.bigfish.com (Postfix) with ESMTP id A49EC1C02E7; Fri, 9 Aug 2013 11:32:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: PS1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail40-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(199002)(74876001)(83072001)(31966008)(51856001)(65816001)(69226001)(33646001)(76482001)(53806001)(50986001)(76796001)(74366001)(74316001)(74706001)(81542001)(16406001)(80976001)(4396001)(74662001)(63696002)(80022001)(83322001)(74502001)(66066001)(54356001)(49866001)(47446002)(81686001)(56776001)(81342001)(76786001)(76576001)(56816003)(47736001)(77982001)(46102001)(79102001)(47976001)(59766001)(77096001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB243; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail40-db8 (localhost.localdomain [127.0.0.1]) by mail40-db8 (MessageSwitch) id 137604793481151_22193; Fri, 9 Aug 2013 11:32:14 +0000 (UTC) Received: from DB8EHSMHS030.bigfish.com (unknown [10.174.8.246]) by mail40-db8.bigfish.com (Postfix) with ESMTP id 05CE12E0046; Fri, 9 Aug 2013 11:32:14 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS030.bigfish.com (10.174.4.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 11:32:12 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 11:32:11 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 11:32:11 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 11:32:11 +0000 From: Ronald Bonica To: "Templin, Fred L" , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnCAAAXBcIAACeHggAAvSpCAAODTEIAC6XRg Date: Fri, 9 Aug 2013 11:32:10 +0000 Message-ID: <5d48855b7ab34d6083fb4566366b48d6@BL2PR05MB243.namprd05.prod.outlook.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E16BE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180E16BE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0933E9FD8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 09 Aug 2013 11:32:24 -0000 Fred, Quite to the contrary, I have spent a good deal of time reviewing the SEAL = draft. (Although I am now one version behind. The document is now in versio= n 61.) SEAL attempts to solve many problems. These include: - source address authentication - detection of packet duplication and reordering - fragmentation at a layer above IP - MTU discovery In order to solve all of these problems, SEAL invents good bit of protocol = machinery. Much of this machinery a) already exists at another layer and b)= is not required to solve the problem at hand. This makes SEAL a much more = heavyweight than the simple point solution that we seek. Ron >=20 > SEAL solves the problem too. Transport-mode SEAL took me 15 minutes to > write, and is really just a couple of paragraphs. In addition to > providing a universal sublayer that can handle any transport protocol > 'X', SEAL also provides an RFC4821 path MTU probing facility. And, if > ingress filtering is thought to be a problem, it also provides a data > origin authentication facility. >=20 > It seems Ron that you are trying to avoid a closer examination of SEAL. >=20 >=20 From Fred.L.Templin@boeing.com Fri Aug 9 08:58:00 2013 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 744ED11E81C0 for ; Fri, 9 Aug 2013 08:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSaFvT0jpGJi for ; Fri, 9 Aug 2013 08:57:53 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id B560321F8F67 for ; Fri, 9 Aug 2013 08:50:58 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r79FovVb028285 for ; Fri, 9 Aug 2013 10:50:57 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r79FouFe028253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 9 Aug 2013 10:50:56 -0500 Received: from XCH-BLV-304.nw.nos.boeing.com (130.247.25.216) by XCH-NWHT-08.nw.nos.boeing.com (130.247.25.112) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 9 Aug 2013 08:50:55 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-304.nw.nos.boeing.com ([169.254.4.218]) with mapi id 14.02.0328.011; Fri, 9 Aug 2013 08:50:54 -0700 From: "Templin, Fred L" To: Ronald Bonica , "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOjsXExBsThTTW2kO9nlkD8PFVZ5mAluIAgAb8kICAAPVUoIAABuLggAAsSnCAAAXBcIAACeHggAAvSpCAAODTEIAC6XRggABDYhA= Date: Fri, 9 Aug 2013 15:50:54 +0000 Message-ID: <2134F8430051B64F815C691A62D983180E370E@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E16BE@XCH-BLV-504.nw.nos.boeing.com> <5d48855b7ab34d6083fb4566366b48d6@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: <5d48855b7ab34d6083fb4566366b48d6@BL2PR05MB243.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 09 Aug 2013 15:58:00 -0000 Hi Ron, Glad to hear you have had a look at SEAL, and see below for a few follow-up comments: > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Friday, August 09, 2013 4:32 AM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Fred, >=20 > Quite to the contrary, I have spent a good deal of time reviewing the > SEAL draft. (Although I am now one version behind. The document is now > in version 61.) >=20 > SEAL attempts to solve many problems. These include: >=20 > - source address authentication I suppose it could be considered source address authentication in transport mode, but in tunnel mode it is about data origin authentication. When data origin authentication is enabled, the tunnel egress has a way of knowing when the tunnel ingress is authorized to tunnel a packet with source address S. But, the egress has no way of reaching back to the original source to know if it is authorized to source a packet with source address S. > - detection of packet duplication and reordering Yes, SEAL provides a well-behaved 32-bit packet sequence number which can be used by the tunnel far end to keep track of any duplicate or re-ordered packets. > - fragmentation at a layer above IP It is fragmentation at a layer above the outer IP protocol and below the inner IP protocol. However, cases in which both outer IP fragmentation and SEAL-layer fragmentation will be applied are exceedingly rare and will be tuned out as soon as they are detected. SEAL fragmentation uses the same header footprint as for IPv6 fragmentation, but the idea is that it would be used as a short-term facility to make sure the IPv6 minMTU is honored while arrangements are made to begin sending unfragmented packets. =20 > - MTU discovery More like "MTU assistance". SEAL tries to do as little as possible to make sure that no path MTU black holes are exposed by virtue of tunneling while the original hosts still need to do PMTUD and/or PLPMTUD. SEAL "takes care of the smalls, and lets the bigs take care of themselves"; the original hosts will take care of those. > In order to solve all of these problems, SEAL invents good bit of > protocol machinery. Much of this machinery a) already exists at another > layer I'm not sure I get that. SEAL fragmentation would be used instead of IPv6 fragmentation to make sure that packets no larger than the minMTU make it through to the tunnel far end. SEAL fragmentation is in many ways a simplified version of IPv6 fragmentation and reuses most of the same code while avoiding the tiny fragment, overlapping fragment, etc. issues. =20 > and b) is not required to solve the problem at hand. Wait, which problem are we talking about - transport mode or tunnel mode? I am no longer considering the transport mode case and have returned my focus to tunnel mode. Are you talking about transport mode or tunnel mode? > This makes > SEAL a much more heavyweight than the simple point solution that we > seek. It is no different than GRE plus fragmentation used sparingly and only as necessary. Thanks - Fred fred.l.templin@boeing.com > Ron >=20 >=20 > > > > SEAL solves the problem too. Transport-mode SEAL took me 15 minutes > to > > write, and is really just a couple of paragraphs. In addition to > > providing a universal sublayer that can handle any transport protocol > > 'X', SEAL also provides an RFC4821 path MTU probing facility. And, if > > ingress filtering is thought to be a problem, it also provides a data > > origin authentication facility. > > > > It seems Ron that you are trying to avoid a closer examination of > SEAL. > > > > >=20 >=20 From ietf@rozanak.com Fri Aug 9 13:44:05 2013 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 B663321F9B19 for ; Fri, 9 Aug 2013 13:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvLH+1t+rooa for ; Fri, 9 Aug 2013 13:44:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BBB341F0DA0 for ; Fri, 9 Aug 2013 13:35:41 -0700 (PDT) Received: from kopoli (g226059006.adsl.alicedsl.de [92.226.59.6]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LsU1Q-1W9ng811Sa-012sJa; Fri, 09 Aug 2013 16:35:15 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> In-Reply-To: <52042321.4030900@si6networks.com> Subject: RE: ra-privacy : new version accomodated all the comments Date: Fri, 9 Aug 2013 22:34:55 +0200 Message-ID: <002101ce953f$f0bbc980$d2335c80$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQG+tQfSmHigtWA= Content-Language: en-us X-Provags-ID: V02:K0:1GqYmfcBbxiVp+qqKnpSu38WOFHHLQnNHaKtiHop+sN FA9lcNoWlKpTdOIjOHCGrTasmxAMh2nQU6quENJxa0ATIiBDoA Orx75x7oeAuReP4Bn/atjulnT5qiRN1Gr4PNqGBG0SU69O4BIc Wf7Dv7CAOy/L56tm93+gMdw/r5qo6Bbc+HPiTTYUTMbYc2hH9A SsOfB1W/HwIgkcWuEK+UBdTnhmnjutePf9JrRpM1uATnlRnweO H56lBy2Vc6UeiMUZ35q8T1JTyZYbsAR664gjEdivvt+J6IOL7l dlN2zH0+wASzGt08JpJjuaueNsDMbhImyKrCBMl8OLTMi/eQ2r E8neOU0YPeQRnWdbFUME= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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: Fri, 09 Aug 2013 20:44:05 -0000 Fernando, Thanks for your comments. > * In Section 1, you should probably remove some of the general discussion on > security and privacy here. For instance, some of your definitions seem > incomplete. Ok, I think I just did not want to jump to the topic and have a kind of introduction. Maybe I just refer to cooper's draft. > * Section 6 is fine... but I don't think the rest of the stuff is needed. Ok. I will remove them > * Section 7 should probably be removed and just reference draft-6man-cooper- > ipv6-addressing-privacy-considerations. Ok, I will do it > Meta comment: If an implementation is going through the burden of > implementing this algorithm, it might as well implement a good PRNG, and be > done with it (if I understand correctly, the motivation for specifying this > algorithm is that you don't have a good PRNG, right?). One reason is PRNG and the other reason is in case the node doesn't want to use stable storage. Thanks, Best, Hosnieh From fernando@gont.com.ar Fri Aug 9 14:19:59 2013 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 92A4D21F99FD for ; Fri, 9 Aug 2013 14:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehANdID0QNtn for ; Fri, 9 Aug 2013 14:19:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 38C6021F9AB3 for ; Fri, 9 Aug 2013 14:14:06 -0700 (PDT) Received: from [186.134.1.169] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V7u0V-00014A-Vn; Fri, 09 Aug 2013 23:14:00 +0200 Message-ID: <52055B8E.1020103@gont.com.ar> Date: Fri, 09 Aug 2013 18:13:50 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : new version accomodated all the comments References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> In-Reply-To: <002101ce953f$f0bbc980$d2335c80$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , 'Fernando Gont' , lorenzo@google.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: Fri, 09 Aug 2013 21:19:59 -0000 On 08/09/2013 05:34 PM, Hosnieh Rafiee wrote: > >> * In Section 1, you should probably remove some of the general discussion > on >> security and privacy here. For instance, some of your definitions seem >> incomplete. > > Ok, I think I just did not want to jump to the topic and have a kind of > introduction. Maybe I just refer to cooper's draft. Just focus on the problem you're trying to solve, and provide references where necessary. >> Meta comment: If an implementation is going through the burden of >> implementing this algorithm, it might as well implement a good PRNG, and > be >> done with it (if I understand correctly, the motivation for specifying > this >> algorithm is that you don't have a good PRNG, right?). > > One reason is PRNG and the other reason is in case the node doesn't want to > use stable storage. IMO, reason "1" is void: If an implementer is going through the effort of implementing this document, he/she'd rather implement a god PRNG. Regarding "2", do you realy need stable storage? -- we're talking about 64-bit IIDs here. Besides, there are IPRs on the CGA algorithm... but RFC4941 itself doesn't have any. SO this document would essentially IPR-encumber RFC4941 -- the farther that you can get from that, the better, I'd say. :-) Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ietf@rozanak.com Fri Aug 9 14:33:44 2013 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 E533C21F9BD8 for ; Fri, 9 Aug 2013 14:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UPN08kK4foO for ; Fri, 9 Aug 2013 14:33:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CC05F11E80DC for ; Fri, 9 Aug 2013 14:26:24 -0700 (PDT) Received: from kopoli (g226059006.adsl.alicedsl.de [92.226.59.6]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MLNxy-1V8S9s3tHW-000GBg; Fri, 09 Aug 2013 17:26:07 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> In-Reply-To: <52055B8E.1020103@gont.com.ar> Subject: RE: ra-privacy : new version accomodated all the comments Date: Fri, 9 Aug 2013 23:25:50 +0200 Message-ID: <002201ce9547$0c0c1c60$24245520$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQG+tQfSAU6tIR8BodFp9JhhKmtA Content-Language: en-us X-Provags-ID: V02:K0:gixWX/K+yHA0kJzm8K0plUMaZ1VyUEd3FINwHKQ0xHc dCE2L6JPk1j82EOCbhT8pgg6KeanHVBdDUdwc8NglbylBCkjkE 1CqK5GNE31UjT/ANgZXyw3D62r4exhwionze1VsxOcsjkTfozm RwJvpIPoFCPv71uH/nEQ0br4lVoTGny4297q0kJZ7hyCs1aMD8 Ufn4kVPBTaI35sm0aSnUojwvnLhQCQDB+Qgke98X3cwIBTM1ns Op3HCa7GsooxdMQYxUTkQWntJmkNaJMwPt+7aRktWpRA3Fekjg PTHfW9AZWjtzwoaEsZJbHyCAs/h9rGEiy+wjHp1VpBWm8dnW37 Bc58ySJWqY2Qy496raQE= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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: Fri, 09 Aug 2013 21:33:45 -0000 Hi there, > Just focus on the problem you're trying to solve, and provide references where > necessary. > Ok :-) > > > IMO, reason "1" is void: If an implementer is going through the effort of > implementing this document, he/she'd rather implement a god PRNG. > > Regarding "2", do you realy need stable storage? -- we're talking about 64-bit > IIDs here. > > Besides, there are IPRs on the CGA algorithm... but RFC4941 itself doesn't have > any. SO this document would essentially IPR-encumber > RFC4941 -- the farther that you can get from that, the better, I'd say. :-) CGA has IPR but it does not prevent the implementation of it. So, no worry about that. In addition, this algorithm is pseudo-CGA as I had to change some inputs so nobody can claim about IPR for this algorithm. :-) Thanks again, Best, Hosnieh From fernando@gont.com.ar Fri Aug 9 14:55:14 2013 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 BE53321F9B10 for ; Fri, 9 Aug 2013 14:55:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9rZXod1hXvG for ; Fri, 9 Aug 2013 14:55:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2622C21F84B6 for ; Fri, 9 Aug 2013 14:47:26 -0700 (PDT) Received: from [186.134.1.169] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V7uWm-0001s2-Ht; Fri, 09 Aug 2013 23:47:20 +0200 Message-ID: <52056361.9080508@gont.com.ar> Date: Fri, 09 Aug 2013 18:47:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : new version accomodated all the comments References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> In-Reply-To: <002201ce9547$0c0c1c60$24245520$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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: Fri, 09 Aug 2013 21:55:15 -0000 On 08/09/2013 06:25 PM, Hosnieh Rafiee wrote: >> Besides, there are IPRs on the CGA algorithm... but RFC4941 itself doesn't > have >> any. SO this document would essentially IPR-encumber >> RFC4941 -- the farther that you can get from that, the better, I'd say. > :-) > > CGA has IPR but it does not prevent the implementation of it. So, no worry > about that. I believe your underestimating IPRs, and also think that introduing an IPR to RFC4941 (as this document is indirectly doing) is an extremely bad idea. > In addition, this algorithm is pseudo-CGA as I had to change > some inputs so nobody can claim about IPR for this algorithm. :-) I won't fight this one with you, Hosnieh. You have received my input. It's up to you what you do with it. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ietf@rozanak.com Fri Aug 9 15:03:30 2013 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 18AEB1F0CB2 for ; Fri, 9 Aug 2013 15:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehh5i5CIS4sr for ; Fri, 9 Aug 2013 15:03:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B96651F0D5E for ; Fri, 9 Aug 2013 14:57:32 -0700 (PDT) Received: from kopoli (g226059006.adsl.alicedsl.de [92.226.59.6]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MEG1o-1VNIsG38bw-00FRem; Fri, 09 Aug 2013 17:57:25 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> In-Reply-To: <52056361.9080508@gont.com.ar> Subject: RE: ra-privacy : new version accomodated all the comments Date: Fri, 9 Aug 2013 23:57:08 +0200 Message-ID: <002301ce954b$6b587c50$420974f0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQG+tQfSAU6tIR8BodFp9AG1Yo/NAlkTreWYQL9JwA== Content-Language: en-us X-Provags-ID: V02:K0:QnF892E22rUkJVAUBg/LHgAmAYh6md+sIbPdnhoJmpm 7W6aPnXXrgrSpYgCxfFi+KKuh5CJeY6E9aHgRM81ZE4mhOzvjw dp3slGBUtKtdl0HQisrhCnvCsVmR8l8ZNxppBYFUUQzze6GwzI WZDBu/OTr2UwA2fmX/1Vv6GXQ3226V6GXSoTfIE4qAyY0acZzR ada9b4OG4In3YSxg+jcwtM2ANNilVmMvS9urn7agJ27OfxYz3q rp4q65hJCkH1vJ3XQn8scxzFhsL2KewSCqu6vZZGFPsYp0+EGZ 3Cl9hzzlvc1A4ClWuoYeOrqypn+DPcvEk9OaD2jMcKZEGZlCUF z31Rwj4mhbJDUQVQ3zdE= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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: Fri, 09 Aug 2013 22:03:30 -0000 > > I believe your underestimating IPRs, and also think that introduing an IPR to > RFC4941 (as this document is indirectly doing) is an extremely bad idea. There is no IPR for my algorithm. You can name it Pseudo CGA or xxx. I only used a hash function, i.e., SHA256 that anyone can use a hash function on some inputs. > I won't fight this one with you, Hosnieh. You have received my input. > It's up to you what you do with it. > Check here please: http://datatracker.ietf.org/ipr/138/ b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers Check here if this licensing declaration is limited solely to standards-track IETF documents _X_ ... Thanks, Best, Hosnieh From fgont@si6networks.com Fri Aug 9 15:05:51 2013 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 5AFFD21F9CA4 for ; Fri, 9 Aug 2013 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7joLez5pZdgu for ; Fri, 9 Aug 2013 15:05:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DB89621F9DDC for <6man@ietf.org>; Fri, 9 Aug 2013 14:59:26 -0700 (PDT) Received: from [186.134.1.169] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V7uiT-00026r-5T; Fri, 09 Aug 2013 23:59:25 +0200 Message-ID: <52056638.3010904@si6networks.com> Date: Fri, 09 Aug 2013 18:59:20 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: draft-ietf-6man-stable-privacy-addresses: Document title X-Enigmail-Version: 1.4.6 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: Fri, 09 Aug 2013 22:05:51 -0000 Folks, I has been suggested to me that we might want to change the title of this document, and the chairs have suggested that I comment on this one on-list. The arguemtn, as far as I can tell, is that the current title might be confusing (mostly because of the confusion there is with different terminology on the subject). The current title is: * "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)" It conveys this key information: that the addresses are stable, and that they are privacy-friendly And the titles that have so far been suggested are: 1) ""Stable Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)" Me, I think this one is confusing -- for instance, IEEE-derived addresses are stable, too. 2) "Stable Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) not derived from EUI-64 identifiers" This one doesn't convey the information that these addresses are privacy-friendly. Besides, why whould we assume that every link layer can generate addresses based on EUI-64 ientifiers? (some link layers don't have those) 3) "Underived from EUI-64 Stable Addresses..." Same as "3)". 4) "Amethod for generating stable random addresses" This one is also confusing, since the current scheme used by Windows provide addresses that are random, and stable across networks. Given the above options I'd stick with the current title. Besides, the community has become used to refer to this method as "stable-privacy-addresses".. so changing the title at this point would, IMHO, only contribute to confusion. Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Fri Aug 9 15:30:44 2013 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 67B9111E8145 for ; Fri, 9 Aug 2013 15:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMG+ngNY-qVM for ; Fri, 9 Aug 2013 15:30:44 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 88BAF11E81B2 for ; Fri, 9 Aug 2013 15:23:37 -0700 (PDT) Received: from [186.134.1.169] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V7v5n-0003vC-Bf; Sat, 10 Aug 2013 00:23:31 +0200 Message-ID: <52056BDB.4070802@si6networks.com> Date: Fri, 09 Aug 2013 19:23:23 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : new version accomodated all the comments References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> <002301ce954b$6b587c50$420974f0$@rozanak.com> In-Reply-To: <002301ce954b$6b587c50$420974f0$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , 'Fernando Gont' , lorenzo@google.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: Fri, 09 Aug 2013 22:30:44 -0000 On 08/09/2013 06:57 PM, Hosnieh Rafiee wrote: >> I won't fight this one with you, Hosnieh. You have received my input. >> It's up to you what you do with it. >> > Check here please: > > http://datatracker.ietf.org/ipr/138/ > > b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All > Implementers This is a non-starter for many free-software projects. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Fri Aug 9 15:42:45 2013 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 9C9F211E812D for ; Fri, 9 Aug 2013 15:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odi92c+9aI0D for ; Fri, 9 Aug 2013 15:42:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 323B81F0D10 for ; Fri, 9 Aug 2013 15:34:36 -0700 (PDT) Received: from kopoli (g226059006.adsl.alicedsl.de [92.226.59.6]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MDAEW-1VMBvw1Hzw-00GnW6; Fri, 09 Aug 2013 18:34:27 -0400 From: "Hosnieh Rafiee" To: "'Andrew Yourtchenko'" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <05A9E216-EE11-45D0-BC28-F3897EBB9833@gmail.com> In-Reply-To: <05A9E216-EE11-45D0-BC28-F3897EBB9833@gmail.com> Subject: RE: ra-privacy : new version accomodated all the comments Date: Sat, 10 Aug 2013 00:34:07 +0200 Message-ID: <002701ce9550$97b77cb0$c7267610$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQB5JHP5mILrVEA= Content-Language: en-us X-Provags-ID: V02:K0:FDD8zHaCW/WruoLb36rDAjuT6rllDJIMun+vAM5QGF3 9QFnG4IL6hj+a3yDXrwiY3Q/FGI3+D2khZwGYyvswX47kt+PVq fdHUidKhIdSRlv/XnCssCZMuYQVP7P9RDhoo2MN56LT8CNfEMr 2nPRxsnAlB0ixl8TVhg3p2mY0QlTVAsKZjq2S+nQwk3h0ilnmo VGfUKR9LnHxgHPM2GTTMC1l8k0Un8NRBtdSYFNTU3Rgp9CB/7n Lf48yTKEFHmZtIOBgvl4l244SdtpHZomYmVlfkjq2HtHIVbnhl RGt1KgQmSNWLV0+pOydyWFjOtgzpMV/EC2Td2bkfKBc/sK8txM BsmTeolp4KWCOZwocnj0= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Dave Thaler' , 'Fernando Gont' , lorenzo@google.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: Fri, 09 Aug 2013 22:42:45 -0000 Hi Andrew, Thanks for your comments. >Of three problems that the draft aims to solve, 1st (EUI64 addresses) = does not really seem to be much of a problem as everyone does privacy = addresses today (you saw stats yourself at >ipv6-hackers meeting), the = second (not changing the address) is an implementation choice, so the = third one remains as an open problem, sort of. It has problem because there are some deficiencies with that RFC. This = is the main reason that I wanted to address those problems. The = statistics about Privacy Addresses was more related to the problem that = RFC 4941 makes by generating a public address based on EUI-64. So, it = also responds to request to that as well as using temporary addresses. = This means there is no privacy. So, this update is to that section of = the RFC to ignore the step in order to use other approach to generate = public addresses, i.e., stable addresses.=20 >Now: what's the comparison between the amount of nonvolatile storage = taken by code implementing the algorithm vs code to store IIDs ? It is wording issue and can be interpreted to store all IIDs in a stable = storage. The update might not make any problem to the current = implementations if they did it correctly but would be consider for any = new implementation of this RFC not to store more than the currently = assigned IIDs to the network interfaces.=20 >P.s. I agree with what Fernando wrote as well.=20 As I explained to Fernando, I just named it like that but it does not = mean that I used CGA algorithm as it is different inputs by executing a = hash function on them and the purpose is not like CGA to find a binding = between the IP address and the public key. This means the IPR of CGA is = not considered for this algorithm.=20 Thanks, Best, Hosnieh From ietf@rozanak.com Fri Aug 9 15:46:30 2013 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 D951421F9A0C for ; Fri, 9 Aug 2013 15:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpaww-Mz79Md for ; Fri, 9 Aug 2013 15:46:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 77F3C11E8120 for ; Fri, 9 Aug 2013 15:40:01 -0700 (PDT) Received: from kopoli (g226059006.adsl.alicedsl.de [92.226.59.6]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LngZT-1Vn2Bs1lzb-00hICE; Fri, 09 Aug 2013 18:39:53 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> <002301ce954b$6b587c50$420974f0$@rozanak.com> <52056BDB.4070802@si6networks.com> In-Reply-To: <52056BDB.4070802@si6networks.com> Subject: RE: ra-privacy : new version accomodated all the comments Date: Sat, 10 Aug 2013 00:39:35 +0200 Message-ID: <002801ce9551$59faeeb0$0df0cc10$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQG+tQfSAU6tIR8BodFp9AG1Yo/NAlkTreUBtour6wFEdPb/mCjzrOA= Content-Language: en-us X-Provags-ID: V02:K0:fwjbmZqW6E/0bDPpqqjmzEu5qSTOYZLaCBZ6o+SDbIG YcPQNhjxahNZrXnw3a95VOtPG4tjV1CGPsyQSicQQ/hnyMSySl GgDvyxVwjwS0LHc/P27maMnlwTZv5w28l2AiSRdhabMKzDIj4x 1yoGliFyD4cd8QdCj5tQAgx0A253oyBxN5a4m2fbrqdse7Qpmi +rYdShBll1+ySVJVhBQ5g5z3UUg62brnE4hsPhF9q2PUZ3XWGL zypJIiEmlrXx3oNACBkhhDGaFl2eByWYpU+trg63IXPEgkuzt5 V14t+iF6O1x5+A/4hwnWFq0GmcfZnQlzfS0WT2ndWnOu4jO6kS Aq2Ycmq6l2xVOLITEi7Y= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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: Fri, 09 Aug 2013 22:46:30 -0000 > > Check here please: > > > > http://datatracker.ietf.org/ipr/138/ > > > > b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All > > Implementers > > This is a non-starter for many free-software projects. As I explained before my algorithm is not CGA anyway. But, what I know and had many discussions for my other draft, SSAS, the problem of using CGA is not IPR otherwise without any reason people accepted SSAS and I did not need to put effort to convince people :-). Thanks, Best, Hosnieh From dthaler@microsoft.com Fri Aug 9 16:06:39 2013 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 D497321F9AA8 for ; Fri, 9 Aug 2013 16:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVIOF33N+X52 for ; Fri, 9 Aug 2013 16:06:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3C07E11E816D for <6man@ietf.org>; Fri, 9 Aug 2013 16:01:24 -0700 (PDT) Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BY2PR03MB160.namprd03.prod.outlook.com (10.242.36.22) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 9 Aug 2013 23:01:06 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 9 Aug 2013 23:01:05 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) with mapi id 15.00.0745.000; Fri, 9 Aug 2013 23:01:05 +0000 From: Dave Thaler To: Fernando Gont , "6man@ietf.org" <6man@ietf.org> Subject: RE: draft-ietf-6man-stable-privacy-addresses: Document title Thread-Topic: draft-ietf-6man-stable-privacy-addresses: Document title Thread-Index: AQHOlUzUHrv/yDZKVkmmKPz6rNEXOZmNfcSQ Date: Fri, 9 Aug 2013 23:01:04 +0000 Message-ID: References: <52056638.3010904@si6networks.com> In-Reply-To: <52056638.3010904@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::e3] x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(199002)(189002)(51704005)(252514010)(377454003)(164054003)(59766001)(51856001)(74366001)(65816001)(77982001)(33646001)(76796001)(76786001)(76576001)(19580405001)(19580395003)(83322001)(83072001)(19580385001)(63696002)(50986001)(46102001)(47736001)(49866001)(4396001)(74316001)(79102001)(81542001)(69226001)(74876001)(53806001)(16406001)(77096001)(74706001)(74502001)(80022001)(56776001)(54316002)(54356001)(56816003)(47976001)(47446002)(74662001)(80976001)(81342001)(76482001)(31966008)(81686001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::e3; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e0:ed43::e3 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.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: Fri, 09 Aug 2013 23:06:39 -0000 I will observe that Alissa's term "random per-network" isn't in any of the = possibilities below and the reasons given wouldn't apply if that term were used. Perhaps= that could be used in a title? -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: Friday, August 9, 2013 2:59 PM > To: 6man@ietf.org > Subject: draft-ietf-6man-stable-privacy-addresses: Document title >=20 > Folks, >=20 > I has been suggested to me that we might want to change the title of this > document, and the chairs have suggested that I comment on this one on-lis= t. >=20 > The arguemtn, as far as I can tell, is that the current title might be co= nfusing > (mostly because of the confusion there is with different terminology on t= he > subject). >=20 > The current title is: >=20 > * "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 > Stateless Address Autoconfiguration (SLAAC)" >=20 > It conveys this key information: that the addresses are stable, and that = they > are privacy-friendly >=20 >=20 > And the titles that have so far been suggested are: >=20 > 1) ""Stable Addresses with IPv6 Stateless Address Autoconfiguration (SLAA= C)" >=20 > Me, I think this one is confusing -- for instance, IEEE-derived addresses= are > stable, too. >=20 >=20 > 2) "Stable Addresses with IPv6 Stateless Address Autoconfiguration > (SLAAC) not derived from EUI-64 identifiers" >=20 > This one doesn't convey the information that these addresses are privacy- > friendly. Besides, why whould we assume that every link layer can generat= e > addresses based on EUI-64 ientifiers? (some link layers don't have those) >=20 >=20 > 3) "Underived from EUI-64 Stable Addresses..." >=20 > Same as "3)". >=20 >=20 > 4) "Amethod for generating stable random addresses" >=20 > This one is also confusing, since the current scheme used by Windows > provide addresses that are random, and stable across networks. >=20 >=20 > Given the above options I'd stick with the current title. Besides, the > community has become used to refer to this method as "stable-privacy- > addresses".. so changing the title at this point would, IMHO, only contri= bute to > confusion. >=20 > Thoughts? >=20 > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=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 Aug 9 16:47:32 2013 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 467C821F9D50 for ; Fri, 9 Aug 2013 16:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1ErT90UWxAt for ; Fri, 9 Aug 2013 16:47:31 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB4A21F9B80 for <6man@ietf.org>; Fri, 9 Aug 2013 16:41:28 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so5058332pbb.27 for <6man@ietf.org>; Fri, 09 Aug 2013 16:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Shgh7FFhrRY5Jlpfed+1Bc3vkD7PU3rP+PtWlZUFvMM=; b=Vie5esh4HkwzMRqYjOxWAQEBs+o8bX2T+gDed9yFWlKtcDqET21mxV3JobuYC9/qFu lJdvYq8HJ1vqHDhhq9o5o5PImc7TB6iOJwh/SoxDc1aDIbFsE9eFYs+pCnjUFigeqrbS WA+L6JB2mUwlqehDTKhI3YlXxhDgq0ZH+DG/JCdT/hTykl4xXnMbFkxfc6Ht2at7V1Zu fdIfjrKcmywVUfJimfva9tkuds8uuPUZVRrwTJ9uXMZY+T0P/XHIYckQQxM2Ha3smWQC /e4IX9kd+AHmvl18vd8xUEEMXjZ+8SWIAB6hsdD6LsZUEKaXp8GErq4qqmssiwzzbm/P QHcQ== X-Received: by 10.66.26.194 with SMTP id n2mr3135154pag.151.1376091687904; Fri, 09 Aug 2013 16:41:27 -0700 (PDT) Received: from [192.168.178.20] (205.199.69.111.dynamic.snap.net.nz. [111.69.199.205]) by mx.google.com with ESMTPSA id jf4sm22410410pbb.19.2013.08.09.16.41.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 16:41:26 -0700 (PDT) Message-ID: <52057E26.3070701@gmail.com> Date: Sat, 10 Aug 2013 11:41:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title References: <52056638.3010904@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "6man@ietf.org" <6man@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, 09 Aug 2013 23:47:32 -0000 On 10/08/2013 11:01, Dave Thaler wrote: > I will observe that Alissa's term "random per-network" isn't in any of the possibilities > below and the reasons given wouldn't apply if that term were used. Perhaps that > could be used in a title? Nah. Too complex for a title, and "random" is a bad word - you should always say pseudo-random or (more pedantic) uniformly distributed. IMHO the current title is clearest. Brian > > -Dave > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Fernando Gont >> Sent: Friday, August 9, 2013 2:59 PM >> To: 6man@ietf.org >> Subject: draft-ietf-6man-stable-privacy-addresses: Document title >> >> Folks, >> >> I has been suggested to me that we might want to change the title of this >> document, and the chairs have suggested that I comment on this one on-list. >> >> The arguemtn, as far as I can tell, is that the current title might be confusing >> (mostly because of the confusion there is with different terminology on the >> subject). >> >> The current title is: >> >> * "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 >> Stateless Address Autoconfiguration (SLAAC)" >> >> It conveys this key information: that the addresses are stable, and that they >> are privacy-friendly >> >> >> And the titles that have so far been suggested are: >> >> 1) ""Stable Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)" >> >> Me, I think this one is confusing -- for instance, IEEE-derived addresses are >> stable, too. >> >> >> 2) "Stable Addresses with IPv6 Stateless Address Autoconfiguration >> (SLAAC) not derived from EUI-64 identifiers" >> >> This one doesn't convey the information that these addresses are privacy- >> friendly. Besides, why whould we assume that every link layer can generate >> addresses based on EUI-64 ientifiers? (some link layers don't have those) >> >> >> 3) "Underived from EUI-64 Stable Addresses..." >> >> Same as "3)". >> >> >> 4) "Amethod for generating stable random addresses" >> >> This one is also confusing, since the current scheme used by Windows >> provide addresses that are random, and stable across networks. >> >> >> Given the above options I'd stick with the current title. Besides, the >> community has become used to refer to this method as "stable-privacy- >> addresses".. so changing the title at this point would, IMHO, only contribute to >> confusion. >> >> Thoughts? >> >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> -------------------------------------------------------------------- >> 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 ayourtch@gmail.com Fri Aug 9 15:20:35 2013 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 75D5611E81A9 for ; Fri, 9 Aug 2013 15:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHLOgQ-jCDMY for ; Fri, 9 Aug 2013 15:20:24 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EACE921F9CE7 for ; Fri, 9 Aug 2013 15:14:06 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so3885614wes.7 for ; Fri, 09 Aug 2013 15:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=4SGN2fd7FuAX0zP068BINcIjHbHRcggdvaWPDxR7LwY=; b=CdqaUjPof46SklN91xhvNXMuw+Q/+9AlTi0cTBaePuzKlfhooBEDMgixr1TuJJSTiP orpm6hUDRchhLETZ9PwS4HglMc+ytp9QS8X9nBaI2B9O6tuUb9igWJly47WnGl27tSDJ 6UlXqov6zsIC97DwC/sCA67xo4iMuOa9gYYYlNd6XKaEXlCyiBth/5SLeD9BWr4wjmAD oED52R+fCWTUXvUFjQqlbqiIszA8pWQFnPElNd5QJC6icHIpX671SVC8cAfkgAVhRnIi QEXYQnIQRYorqbBEwsLShnuITga58cHMdYnLPnIfpeIlpsafnj9geWvB3vYEyGzt3cxD FsVA== X-Received: by 10.194.240.129 with SMTP id wa1mr7305461wjc.31.1376086446040; Fri, 09 Aug 2013 15:14:06 -0700 (PDT) Received: from [10.183.199.80] ([213.143.60.220]) by mx.google.com with ESMTPSA id v9sm4900576wiw.8.2013.08.09.15.13.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 15:14:05 -0700 (PDT) References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> In-Reply-To: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-82651D7F-52D8-4515-850C-FA4AE295BB97 Message-Id: <05A9E216-EE11-45D0-BC28-F3897EBB9833@gmail.com> X-Mailer: iPhone Mail (10B329) From: Andrew Yourtchenko Subject: Re: ra-privacy : new version accomodated all the comments Date: Fri, 9 Aug 2013 23:13:54 +0100 To: Hosnieh Rafiee X-Mailman-Approved-At: Fri, 09 Aug 2013 18:35:28 -0700 Cc: "" , Keith Moore , Erik Nordmark , Dave Thaler , Fernando Gont , "" 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, 09 Aug 2013 22:20:36 -0000 --Apple-Mail-82651D7F-52D8-4515-850C-FA4AE295BB97 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hosjieh, Of three problems that the draft aims to solve, 1st (EUI64 addresses) does n= ot really seem to be much of a problem as everyone does privacy addresses to= day (you saw stats yourself at ipv6-hackers meeting), the second (not changi= ng the address) is an implementation choice, so the third one remains as an o= pen problem, sort of. Now: what's the comparison between the amount of nonvolatile storage taken b= y code implementing the algorithm vs code to store IIDs ? I.e. I am still unclear what's the real-world problem this solves.=20 If it is a particular implementation corner case, maybe makes sense to keep i= t as such, not updating the core specs. --a P.s. I agree with what Fernando wrote as well.=20 On 08 Aug 2013, at 23:27, "Hosnieh Rafiee" wrote: > Hello and thank you so much for your comments. > =20 > I applied your comments and submitted a new version of the ra-privacy draf= t. I also removed the text concerning the application layer based lifetime f= rom this draft. This draft, thus, just focuses on a few updates to RFC 4941 t= hat address some deficiencies. > =20 > tools.ietf.org/html/draft-rafiee-6man-ra-privacy > =20 > According to my discussions with some people during the IETF meetings, som= e people thought that it would be better to have the discussion about the ap= plication layer based lifetime in a separate document as it seems that it is= a new mechanism and should not be an update to RFC 4941. In my update to th= at RFC , I just briefly mentioned that the node "MIGHT" follow the other ext= ernal policies for the lifetime and =93Might=94 not follow those of RFC 4941= . > =20 > =20 > If there are any other issues that I should consider for this draft, pleas= e let me know. > =20 > Thanks, > Best, > Hosnieh --Apple-Mail-82651D7F-52D8-4515-850C-FA4AE295BB97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hosjieh,

Of t= hree problems that the draft aims to solve, 1st (EUI64 addresses) does not r= eally seem to be much of a problem as everyone does privacy addresses today (= you saw stats yourself at ipv6-hackers meeting), the second (not changing th= e address) is an implementation choice, so the third one remains as an open p= roblem, sort of.

Now: what's the comparison between= the amount of nonvolatile storage taken by code implementing the algorithm v= s code to store IIDs ?

I.e. I am still unclear what= 's the real-world problem this solves. 

If it i= s a particular implementation corner case, maybe makes sense to keep it as s= uch, not updating the core specs.

--a
P.s. I agree with what Fernando wrote as well. 
<= br>On 08 Aug 2013, at 23:27, "Hosnieh Rafiee" <ietf@rozanak.com> wrote:

Hello and thank you so much for your comments.

 

I applied your c= omments and submitted a new version of the ra-privacy draft. I also removed t= he text concerning the application layer based lifetime from this draft. Thi= s draft, thus, just focuses on a few updates to RFC 4941 that address some d= eficiencies.

 

tools.ietf.org/html/draft-rafiee-6man-ra-privacy

 

Accordi= ng to my discussions with some people during the IETF meetings, some people t= hought that it would be better to have the discussion about the applic= ation layer based lifetime in a separate document as it seems that i= t is a new mechanism and should not be an update to RFC 4941. In my update t= o that RFC , I just briefly mentioned that the node "MIGHT" follow the other= external policies for the lifetime and =E2=80=9CMight=E2=80=9D not follow t= hose of RFC 4941.

 

=

 

If there a= re any other issues that I should consider for this draft, please let me kno= w.

 

Thanks,

Best,

Hosnieh

= --Apple-Mail-82651D7F-52D8-4515-850C-FA4AE295BB97-- From fgont@si6networks.com Fri Aug 9 21:22:33 2013 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 74DC821F9FCE for ; Fri, 9 Aug 2013 21:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULnHrFWzaX9h for ; Fri, 9 Aug 2013 21:22:33 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9D21F9930 for ; Fri, 9 Aug 2013 21:17:22 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V80c7-0004ZP-Uv; Sat, 10 Aug 2013 06:17:16 +0200 Message-ID: <5205B565.4060109@si6networks.com> Date: Sat, 10 Aug 2013 00:37:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : new version accomodated all the comments References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> <002301ce954b$6b587c50$420974f0$@rozanak.com> <52056BDB.4070802@si6networks.com> <002801ce9551$59faeeb0$0df0cc10$@rozanak.com> In-Reply-To: <002801ce9551$59faeeb0$0df0cc10$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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, 10 Aug 2013 04:22:33 -0000 On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote: >>> Check here please: >>> >>> http://datatracker.ietf.org/ipr/138/ >>> >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All >>> Implementers >> >> This is a non-starter for many free-software projects. > > As I explained before my algorithm is not CGA anyway. It looks pretty much like it. And, in any case, it's a complex way of doing something that can be much simpler. > But, what I know and had many discussions for my other draft, SSAS, the > problem of using CGA is not IPR otherwise without any reason people accepted > SSAS and I did not need to put effort to convince people :-). The problem of your scheme is that is an extremely complex way of doing something that can be much simpler. IPRs *are* a problem. If you think you know better, talk to developers. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Sat Aug 10 00:49:34 2013 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 63DC721F9D04 for ; Sat, 10 Aug 2013 00:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV7UBRv0aPZA for ; Sat, 10 Aug 2013 00:49:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 304D411E811E for ; Sat, 10 Aug 2013 00:44:29 -0700 (PDT) Received: from kopoli (f052070159.adsl.alicedsl.de [78.52.70.159]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MLvam-1VDZ5l06Ki-007pgp; Sat, 10 Aug 2013 03:44:16 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" , "Pascal Thubert \(pthubert\)" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> <002301ce954b$6b587c50$420974f0$@rozanak.com> <52056BDB.4070802@si6networks.com> <002801ce9551$59faeeb0$0df0cc10$@rozanak.com> <5205B565.4060109@si6networks.com> In-Reply-To: <5205B565.4060109@si6networks.com> Subject: RE: ra-privacy : new version accomodated all the comments Date: Sat, 10 Aug 2013 09:43:56 +0200 Message-ID: <000301ce959d$66520b20$32f62160$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQG+tQfSAU6tIR8BodFp9AG1Yo/NAlkTreUBtour6wFEdPb/AcqOjpoC4wFRK5gEEIgA Content-Language: en-us X-Provags-ID: V02:K0:fauWdrsG6FG0Pc9QMZ5MWJZL1opPUMeHV8j4mSWgfHx nZbbMoNKkKrRsd5cRWfBfJrEi9bd4K5AsHeIRDWs5iR2U96mKw jBeiLReOctNNeD+f6dV6iDmk0g97NxP4dMDo8zwcUyQWQxRVjE l7/qFdYBridPSW718cWNGBzbzFYtbtSq8jGjxPH1f1Tph3EiKJ I1LQnS0LmEEW3ZTA2uQfC1X5DDMZTGdpIKDeq6xzH4NsHEkJTX CFByAQDkWJJsxzhbgAFrbIh1JGx1lr3Y5wcbUUCzTXpqnZGjLy SoRd+2yVLJtghoNgCl28BFUngDjBppKQc37Dq/t3/tdUsznKcN Y/HDaJZMiHQQ5xr4djnY= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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, 10 Aug 2013 07:49:34 -0000 > On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote: > >>> Check here please: > >>> > >>> http://datatracker.ietf.org/ipr/138/ > >>> > >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to > >>> All Implementers > >> > >> This is a non-starter for many free-software projects. > > > > As I explained before my algorithm is not CGA anyway. > > It looks pretty much like it. And, in any case, it's a complex way of doing > something that can be much simpler. Disagree! Please check RFC 4086. Most of the approaches uses a hash function on some inputs. How you look at the algorithms is pretty like a kind of generalization. So, one might interpret from what you said as follow: "any algorithm in any RFC that uses any hash function is CGA!" However, this interpretation is not true. If you use the same inputs with the same orders, the same hash function and with the same purpose, i.e., your purpose is also binding between the IP address and the public key, then you can call it CGA. But any modifications to this algorithm by using any different inputs and different purpose is not CGA anymore or not included in the IPR of CGA. Probably you know how to apply for a patent. You should be so specific and explain your algorithm in so detail. Just a quick response to show you my algorithms are not complex. Let's compare most IID algorithms in a simple scheme, we also skip how they want to pick up a function for your case like F() or modifier or secret_key, etc: Ra-privacy : R=Sha256(modifier,subnetprefix,timestamp) => IID=64bits(R) RFC4941 : Is_null(history) = true => history= Generate(random_Val)=> R= MD5(history,EUI-64) => Is_Match{Compare_to_reserved_stablestorage(R)}= false (true: repeat_algorithm()) => IID= 64_leftmost_bits(R) and history=64_rightmost_bits(R) SSAS : pubkey,prikey = Generate(keypair) => p1,p2=Split(pubkey) => IID= concatenation(p1,p2); Stable-addresses : RID= F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) => IID=64_leftmost_bits(RID) CGA : Hash1=Sha1(modifier, subnet prefix, collision count, public key) => R=16_LeftMost_byte_By_secval(R) => CompareToZero(R) ?= true (false: Increment(modifier); repeat algorithm) => Hash2= Sha1(modifier, subnet prefix, collision count, public key) => IID= 64leftmostbits(Hash2) Now, as you know, MD5 and SHA256 both are hash functions, often RFC 4086 (randomization) also, as I explained earlier, uses a hash function on inputs. This means that F() also can be a hash function in some implementers as they can pick up any function. So, Are all of these functions (except the last one) complex and CGA? In your own draft (stable addresses) section 3: " F(): A pseudorandom function (PRF) that is not computable from the outside (without knowledge of the secret key), which should produce an output of at least 64 bits. The PRF could be implemented as a cryptographic hash of the concatenation of each of the function parameters." Compare the complexity (you can compare the algorithm yourself): Most complex to least complex CGA>>>SSAS ~= RFC 4941 > stable-addresses ~= ra-privacy So, I don't understand your concerns here. > > But, what I know and had many discussions for my other draft, SSAS, > > the problem of using CGA is not IPR otherwise without any reason > > people accepted SSAS and I did not need to put effort to convince people :-). > > The problem of your scheme is that is an extremely complex way of doing > something that can be much simpler. Complex!?? :-O please read ssas draft. You cannot find simpler than that :-). It might be more straight forward than even your draft. > IPRs *are* a problem. If you think you know better, talk to developers. > I talked with Pascal and others In cisco who developed SeND. Cisco supports SeND modules in some of their routers. It appears that IPR wasn't a problem for them. :-) if so, Pascal can explain this better. @Pascal : Was IPR a problem for you when you developed SeND for cisco routers? Best, Hosnieh From ietf@rozanak.com Sat Aug 10 01:25:54 2013 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 44E2721F9A31 for ; Sat, 10 Aug 2013 01:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byM4rB4zeG6V for ; Sat, 10 Aug 2013 01:25:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9960921E809B for ; Sat, 10 Aug 2013 01:17:50 -0700 (PDT) Received: from kopoli (f052070159.adsl.alicedsl.de [78.52.70.159]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MHoOb-1V8ti20s97-004Mrj; Sat, 10 Aug 2013 04:17:42 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" , "Pascal Thubert \(pthubert\)" Subject: RE: ra-privacy : new version accomodated all the comments Date: Sat, 10 Aug 2013 10:17:22 +0200 Message-ID: <000701ce95a2$1203c2c0$360b4840$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6VofS/0puFYVgqQNyBS7vvAqXU+Q== Content-Language: en-us X-Provags-ID: V02:K0:M8pRpkXjTh5Hkt0181fn90gKfkiN8/nJXh9xY5nNS6Q J1Ta8dKfZSbrzHPkHrbQmd+dcVE4qANkcrzD1pVWMtDTmY+cOK qo3KSZl5XeCFx8MscnzLPCr2r9gj7OitpGto3wVhHMoL2fy6CL xWEPZTSAgmYgw6MHIe0XkuI0Z6ZgYmMcNRvBPbxE472FixMfmi 7rgDeLgJvsosx1+chOlCcxWm/8rqoTAs1UDA05hOyuTe4UJK1B dTbYcfJwJlg/aqQ2B3Pv45i6aI+2Bhm228TaNpL7rv1jyzHWS2 BZ0mxnlGmxjadVk24NonipbqW5J2vGAu7Q72+WWHDi1K/PP13C Ki5bMrhyjy9yekQsWEBU= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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, 10 Aug 2013 08:25:54 -0000 Added key pair to the CGA as well :-) > On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote: > >>> Check here please: > >>> > >>> http://datatracker.ietf.org/ipr/138/ > >>> > >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to > >>> All Implementers > >> > >> This is a non-starter for many free-software projects. > > > > As I explained before my algorithm is not CGA anyway. > > It looks pretty much like it. And, in any case, it's a complex way of doing > something that can be much simpler. Disagree! Please check RFC 4086. Most of the approaches uses a hash function on some inputs. How you look at the algorithms is pretty like a kind of generalization. So, one might interpret from what you said as follow: "any algorithm in any RFC that uses any hash function is CGA!" However, this interpretation is not true. If you use the same inputs with the same orders, the same hash function and with the same purpose, i.e., your purpose is also binding between the IP address and the public key, then you can call it CGA. But any modifications to this algorithm by using any different inputs and different purpose is not CGA anymore or not included in the IPR of CGA. Probably you know how to apply for a patent. You should be so specific and explain your algorithm in so detail. Just a quick response to show you my algorithms are not complex. Let's compare most IID algorithms in a simple scheme, we also skip how they want to pick up a function for your case like F() or modifier or secret_key, etc: Ra-privacy : R=Sha256(modifier,subnetprefix,timestamp) => IID=64_leftmost_bits(R) RFC4941 : Is_null(history) = true => history= Generate(random_Val)=> R= MD5(history,EUI-64) => Is_Match{Compare_to_reserved_stablestorage(R)}= false (true: repeat_algorithm()) => IID= 64_leftmost_bits(R) and history=64_rightmost_bits(R) SSAS : pubkey,prikey = Generate_ECC(keypair) => p1,p2=Split(pubkey) => IID= concatenation(p1,p2); Stable-addresses : RID= F(Prefix, Net_Iface, Network_ID, DAD_Counter,secret_key) => IID=64_leftmost_bits(RID) CGA : pubkey,prikey = Generate_RSA(keypair) =>Hash1=Sha1(modifier, subnet prefix, collision count, pubkey) => R=16_LeftMost_byte_By_secval(R) => CompareToZero(R) ?= true (false: Increment(modifier); repeat algorithm) => Hash2= Sha1(modifier, subnet prefix, collision count, pubkey) => IID= 64leftmostbits(Hash2) Now, as you know, MD5 and SHA256 both are hash functions, often RFC 4086 (randomization) also, as I explained earlier, uses a hash function on inputs. This means that F() also can be a hash function in some implementers as they can pick up any function. So, Are all of these functions (except the last one) complex and CGA? In your own draft (stable addresses) section 3: " F(): A pseudorandom function (PRF) that is not computable from the outside (without knowledge of the secret key), which should produce an output of at least 64 bits. The PRF could be implemented as a cryptographic hash of the concatenation of each of the function parameters." Compare the complexity (you can compare the algorithm yourself): Most complex to least complex CGA>>>SSAS ~= RFC 4941 > stable-addresses ~= ra-privacy So, I don't understand your concerns here. > > But, what I know and had many discussions for my other draft, SSAS, > > the problem of using CGA is not IPR otherwise without any reason > > people accepted SSAS and I did not need to put effort to convince > > people :-). > > The problem of your scheme is that is an extremely complex way of > doing something that can be much simpler. Complex!?? :-O please read ssas draft. You cannot find simpler than that :-). It might be more straight forward than even your draft. > IPRs *are* a problem. If you think you know better, talk to developers. > I talked with Pascal and others In cisco who developed SeND. Cisco supports SeND modules in some of their routers. It appears that IPR wasn't a problem for them. :-) if so, Pascal can explain this better. @Pascal : Was IPR a problem for you when you developed SeND for cisco routers? Best, Hosnieh From fgont@si6networks.com Sat Aug 10 03:54:25 2013 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 6424C21F9A18 for ; Sat, 10 Aug 2013 03:54: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4m+feCR5-pS for ; Sat, 10 Aug 2013 03:54:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 85AD221F9B92 for ; Sat, 10 Aug 2013 03:48:53 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V86iv-0004qA-SZ; Sat, 10 Aug 2013 12:48:42 +0200 Message-ID: <52061A82.7060209@si6networks.com> Date: Sat, 10 Aug 2013 07:48:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : new version accomodated all the comments References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> <002301ce954b$6b587c50$420974f0$@rozanak.com> <52056BDB.4070802@si6networks.com> <002801ce9551$59faeeb0$0df0cc10$@rozanak.com> <5205B565.4060109@si6networks.com> <000301ce959d$66520b20$32f62160$@rozanak.com> In-Reply-To: <000301ce959d$66520b20$32f62160$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Pascal Thubert \(pthubert\)" , ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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, 10 Aug 2013 10:54:25 -0000 Hosnieh, We have already been down this road where I feel you don't seem to listen/read what I say. I won't comment any further, except for one small comment. On 08/10/2013 04:43 AM, Hosnieh Rafiee wrote: >> On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote: >>>>> Check here please: >>>>> >>>>> http://datatracker.ietf.org/ipr/138/ >>>>> >>>>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to >>>>> All Implementers >>>> >>>> This is a non-starter for many free-software projects. [...] > >> IPRs *are* a problem. If you think you know better, talk to developers. >> > > I talked with Pascal and others In cisco who developed SeND. Cisco supports > SeND modules in some of their routers. It appears that IPR wasn't a problem > for them. :-) if so, Pascal can explain this better. Unless IOS has became free software, it looks like you're not reading what I'm writing. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Sat Aug 10 04:33:53 2013 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 DA2BB21F9BDB for ; Sat, 10 Aug 2013 04:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EstbVD-FNqEy for ; Sat, 10 Aug 2013 04:33:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 60A0721F9C0D for ; Sat, 10 Aug 2013 04:27:29 -0700 (PDT) Received: from kopoli (f052070159.adsl.alicedsl.de [78.52.70.159]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MSdem-1VXSFG1wV2-00RcMr; Sat, 10 Aug 2013 07:27:21 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <002f01ce9486$708d4cc0$51a7e640$@rozanak.com> <52042321.4030900@si6networks.com> <002101ce953f$f0bbc980$d2335c80$@rozanak.com> <52055B8E.1020103@gont.com.ar> <002201ce9547$0c0c1c60$24245520$@rozanak.com> <52056361.9080508@gont.com.ar> <002301ce954b$6b587c50$420974f0$@rozanak.com> <52056BDB.4070802@si6networks.com> <002801ce9551$59faeeb0$0df0cc10$@rozanak.com> <5205B565.4060109@si6networks.com> <000301ce959d$66520b20$32f62160$@rozanak.com> <52061A82.7060209@si6networks.com> In-Reply-To: <52061A82.7060209@si6networks.com> Subject: RE: ra-privacy : new version accomodated all the comments Date: Sat, 10 Aug 2013 13:27:00 +0200 Message-ID: <000001ce95bc$9022c0b0$b0684210$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJR9CqDnkgohN3m2WbAOoxcWem4fQG+tQfSAU6tIR8BodFp9AG1Yo/NAlkTreUBtour6wFEdPb/AcqOjpoC4wFRKwGAN25iAWOgAwWX7TpSwA== Content-Language: en-us X-Provags-ID: V02:K0:sbU3dzlnE+biBA+ThuCrVS1dPI6hQ+muXim64aFsGct Vq96y99xqGG1/OoC9QYmqR4CswiV1pn2JjpddEiRLIugF4TUpI ptsb378WXq9ovHtMurXwF65/z3Wh2fCxEDD7dRZtARvdoI+V9r 5nt3FBsyCHveq/uHXRlOR6SpVbyVzv6YqJUikxC1mmY/eli4Qt cJsQD0kuNTA3zlwZ5Jyf1OPGOjblab26U0DDJvqZiY3kNQpKs4 fVpGSqZVKekUW0L2OgTZzCTcziUn8FM4RShOqDdcA6sCF0WKb9 c6h/cr+523O0jh+13jcGXQzf0CIa3GG/yOL9DOTpRyoMyD6D7p Y5TaZDMDz7ECeDIW9yGE= Cc: "'Pascal Thubert \(pthubert\)'" , ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' , lorenzo@google.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, 10 Aug 2013 11:33:53 -0000 My explanation was clear and covered all concerns about my algorithm (as it is not the CGA at all and so no IPR), so I also don't think there is any need to explain more. Otherwise somebody else still has a problem and not convinced. > >> IPRs *are* a problem. If you think you know better, talk to developers. > >> > > > > I talked with Pascal and others In cisco who developed SeND. Cisco > > supports SeND modules in some of their routers. It appears that IPR > > wasn't a problem for them. :-) if so, Pascal can explain this better. > > Unless IOS has became free software, it looks like you're not reading what I'm > writing. > When we bought a cisco router with SeND capabilities, it didn't seem to be free of charge and we had to pay for the module to support SeND (it was extra cost on the router to add a module which supports SeND and other features). I also tried to download the latest IOS of cisco. It appears that it is only possible by a valid contract in my profile. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/pro duct_bulletin_c25-409474.html Thanks, Hosnieh From otroan@employees.org Mon Aug 12 03:32:54 2013 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 58DF511E815B for ; Mon, 12 Aug 2013 03:32:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3S8aCvTiKdH for ; Mon, 12 Aug 2013 03:32:39 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B811E812C for <6man@ietf.org>; Mon, 12 Aug 2013 01:59:54 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-14.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 5AC5E5FE6; Mon, 12 Aug 2013 01:59:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title From: Ole Troan In-Reply-To: <52057E26.3070701@gmail.com> Date: Mon, 12 Aug 2013 10:59:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Dave Thaler 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, 12 Aug 2013 10:33:00 -0000 >>=20 >> I will observe that Alissa's term "random per-network" isn't in any = of the possibilities >> below and the reasons given wouldn't apply if that term were used. = Perhaps that >> could be used in a title? >=20 > Nah. Too complex for a title, and "random" is a bad word - you should = always > say pseudo-random or (more pedantic) uniformly distributed. >=20 > IMHO the current title is clearest. these addresses have the following properties: - stable per link - randomly generated as opposed to based on a MAC address. (making scanning attacks harder, makes tracking across links harder) - intended to replace existing EUI-64 identifiers truth in advertising; given that these addresses are meant to be used = 'in public', what is "privacy enhanced" about them? the use of "privacy" confuses it with RFC4941 addresses, which these = addresses do not replace. "Stable per-network Addresses for IPv6 Stateless Address = Autoconfiguration (SPN-SLAAC)"? no hat, Ole From fgont@si6networks.com Mon Aug 12 03:41:12 2013 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 DE33411E8192 for ; Mon, 12 Aug 2013 03:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaU3eL6wwTS2 for ; Mon, 12 Aug 2013 03:40:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B801B21E80DB for <6man@ietf.org>; Mon, 12 Aug 2013 02:12:31 -0700 (PDT) Received: from [2001:5c0:1000:a::111] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V8oAr-0004p3-Rv; Mon, 12 Aug 2013 11:12:26 +0200 Message-ID: <5208A6DF.6020101@si6networks.com> Date: Mon, 12 Aug 2013 06:11:59 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ole Troan Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org>, Dave Thaler 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, 12 Aug 2013 10:41:14 -0000 Hi, Ole, On 08/12/2013 05:59 AM, Ole Troan wrote: >>> >>> I will observe that Alissa's term "random per-network" isn't in any of the possibilities >>> below and the reasons given wouldn't apply if that term were used. Perhaps that >>> could be used in a title? >> >> Nah. Too complex for a title, and "random" is a bad word - you should always >> say pseudo-random or (more pedantic) uniformly distributed. >> >> IMHO the current title is clearest. > > these addresses have the following properties: > - stable per link > - randomly generated as opposed to based on a MAC address. > (making scanning attacks harder, makes tracking across links harder) > - intended to replace existing EUI-64 identifiers > > truth in advertising; given that these addresses are meant to be used 'in public', what is > "privacy enhanced" about them? One thing is some node using an address to communicate with you. Another thing is that other node being able to learn other information by means of such address. -- e.g, since the IID changes from one network to another, you cannot track the device. > the use of "privacy" confuses it with RFC4941 addresses, which these addresses do not replace. Actually, RFC4941 are called "privacy extensions" (which isn't incorrect), since those temporary addresses have interesting privacy features. Probably, people assumed temporary == privacy because, before stable-privacy-addresses you didn't have any other privacy-enhanced addresses. Both RFC4941 and stable-privacy-addreses are "privacy addresess" -- RFC4941 are temporary, while stable-privacy are stable. > "Stable per-network Addresses for IPv6 Stateless Address Autoconfiguration (SPN-SLAAC)"? An address could be "stable per network" without having any interesting privacy/security features. For instance, traditional slaac addresses are "stable per network", too. Me, I don't care much about the title. However, given that folks have become used to refer to this scheme as "stable-privacy addresses", and that so far alternative titles don't seem to do a much better job, I'd leave the title "as is". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From otroan@employees.org Mon Aug 12 04:27:10 2013 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 6F9E921F841B for ; Mon, 12 Aug 2013 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSyLWakR9OoX for ; Mon, 12 Aug 2013 04:27:02 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3546E21E8196 for <6man@ietf.org>; Mon, 12 Aug 2013 03:32:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADa5CFKQ/khR/2dsb2JhbABagwa/W4EaFnSCJAEBBAF5BQsLDjhXBogdBrYTkAgzB4MbdgORRpdvgx06gSwjAQ X-IronPort-AV: E=Sophos;i="4.89,861,1367971200"; d="scan'208";a="17053308" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 12 Aug 2013 10:31:57 +0000 Received: from dhcp-lys02-vla252-10-147-116-14.cisco.com (dhcp-lys02-vla252-10-147-116-14.cisco.com [10.147.116.14]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7CAVscu001961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Aug 2013 10:31:55 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title From: Ole Troan In-Reply-To: <5208A6DF.6020101@si6networks.com> Date: Mon, 12 Aug 2013 12:31:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> <5208A6DF.6020101@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: "6man@ietf.org" <6man@ietf.org>, Dave Thaler 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, 12 Aug 2013 11:27:10 -0000 Fernando, >>>> I will observe that Alissa's term "random per-network" isn't in any = of the possibilities >>>> below and the reasons given wouldn't apply if that term were used. = Perhaps that >>>> could be used in a title? >>>=20 >>> Nah. Too complex for a title, and "random" is a bad word - you = should always >>> say pseudo-random or (more pedantic) uniformly distributed. >>>=20 >>> IMHO the current title is clearest. >>=20 >> these addresses have the following properties: >> - stable per link >> - randomly generated as opposed to based on a MAC address. >> (making scanning attacks harder, makes tracking across links = harder) >> - intended to replace existing EUI-64 identifiers >>=20 >> truth in advertising; given that these addresses are meant to be used = 'in public', what is >> "privacy enhanced" about them? >=20 > One thing is some node using an address to communicate with you. = Another > thing is that other node being able to learn other information by = means > of such address. >=20 > -- e.g, since the IID changes from one network to another, you cannot > track the device. this brings us to the larger issue of how an application should choose = an address type. if I wanted "privacy" (assuming some suspension of disbelief (that = choice of a particular address results in better privacy)), I would use a temporary address. this draft is about stable addresses. a use case for a stable = address/public address, is to provide a service. that would typically = mean it is published in DNS or available via some form of service = discovery. that is, an address I explicitly don't want to be private. >> the use of "privacy" confuses it with RFC4941 addresses, which these = addresses do not replace. >=20 > Actually, RFC4941 are called "privacy extensions" (which isn't > incorrect), since those temporary addresses have interesting privacy > features. Probably, people assumed temporary =3D=3D privacy because, = before > stable-privacy-addresses you didn't have any other privacy-enhanced > addresses. >=20 > Both RFC4941 and stable-privacy-addreses are "privacy addresess" -- > RFC4941 are temporary, while stable-privacy are stable. as soon as an address is used externally it isn't private anymore. >> "Stable per-network Addresses for IPv6 Stateless Address = Autoconfiguration (SPN-SLAAC)"? >=20 > An address could be "stable per network" without having any = interesting > privacy/security features. For instance, traditional slaac addresses = are > "stable per network", too. true. any other suggestions that does not contain the word "privacy"? I don't want to explain to my dad (substitute with your favourite family = member), why he is still being tracked across web-sites (AppNexus, Bluekai, Brightroll, Facebook = Connect, Google Analytics, Google Adsense, OpenX, Taboola...) when he = explicitly chose to use a privacy enhanced address for the = communication. > Me, I don't care much about the title. However, given that folks have > become used to refer to this scheme as "stable-privacy addresses", and > that so far alternative titles don't seem to do a much better job, I'd > leave the title "as is". "random Network Stable Addresses for IPv6 Stateless Address = Autoconfiguration (NSA-SLAAC)" :-) cheers, Ole= From fgont@si6networks.com Mon Aug 12 04:37:10 2013 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 DF83421F85E6 for ; Mon, 12 Aug 2013 04:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZj7BAbsK4Ms for ; Mon, 12 Aug 2013 04:37:00 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 09AEE21E80CF for <6man@ietf.org>; Mon, 12 Aug 2013 03:53:54 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.156]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V8pkS-00078V-OQ; Mon, 12 Aug 2013 12:53:23 +0200 Message-ID: <5208BE8C.4000007@si6networks.com> Date: Mon, 12 Aug 2013 07:53:00 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ole Troan Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> <5208A6DF.6020101@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org>, Dave Thaler 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, 12 Aug 2013 11:37:11 -0000 On 08/12/2013 07:31 AM, Ole Troan wrote: >> One thing is some node using an address to communicate with you. >> Another thing is that other node being able to learn other >> information by means of such address. >> >> -- e.g, since the IID changes from one network to another, you >> cannot track the device. > > this brings us to the larger issue of how an application should > choose an address type. if I wanted "privacy" (assuming some > suspension of disbelief (that choice of a particular address results > in better privacy)), I would use a temporary address. That depends on a variety of factors, including (but not limited to): * Whether you need stability for your address * Whether temporary addresses are acceptable in your environment (many enterprises disable temporary-addresses, but would benefit from stable-privacy) > this draft is about stable addresses. a use case for a stable > address/public address, is to provide a service. that would typically > mean it is published in DNS or available via some form of service > discovery. that is, an address I explicitly don't want to be > private. Please see above. Besides, receiving incoming connections does not man many of the threats described in are acceptable. >>> the use of "privacy" confuses it with RFC4941 addresses, which >>> these addresses do not replace. >> >> Actually, RFC4941 are called "privacy extensions" (which isn't >> incorrect), since those temporary addresses have interesting >> privacy features. Probably, people assumed temporary == privacy >> because, before stable-privacy-addresses you didn't have any other >> privacy-enhanced addresses. >> >> Both RFC4941 and stable-privacy-addreses are "privacy addresess" >> -- RFC4941 are temporary, while stable-privacy are stable. > > as soon as an address is used externally it isn't private anymore. "privacy" doesn't mean that your address is "unknown". It means that it doesn't leak more info than necessary. >>> "Stable per-network Addresses for IPv6 Stateless Address >>> Autoconfiguration (SPN-SLAAC)"? >> >> An address could be "stable per network" without having any >> interesting privacy/security features. For instance, traditional >> slaac addresses are "stable per network", too. > > true. any other suggestions that does not contain the word > "privacy"? I don't want to explain to my dad (substitute with your > favourite family member), why he is still being tracked across > web-sites (AppNexus, Bluekai, Brightroll, Facebook Connect, Google > Analytics, Google Adsense, OpenX, Taboola...) when he explicitly > chose to use a privacy enhanced address for the communication. Because he didn't use a privacy-enhanced app? He'd be tracked based on the app rather than based on the underlying address. Besides, tracking is just one aspect (see the others in Alissa's document). >> Me, I don't care much about the title. However, given that folks >> have become used to refer to this scheme as "stable-privacy >> addresses", and that so far alternative titles don't seem to do a >> much better job, I'd leave the title "as is". > > "random Network Stable Addresses for IPv6 Stateless Address > Autoconfiguration (NSA-SLAAC)" :-) That's a non-starter name, based on recent "events". ;-)) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From markzzzsmith@yahoo.com.au Mon Aug 12 06:06:26 2013 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 EF9E011E80DE for ; Mon, 12 Aug 2013 06:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi453dxVezMc for ; Mon, 12 Aug 2013 06:06:21 -0700 (PDT) Received: from nm34-vm3.bullet.mail.bf1.yahoo.com (nm34-vm3.bullet.mail.bf1.yahoo.com [72.30.239.75]) by ietfa.amsl.com (Postfix) with ESMTP id 31F3121F962D for <6man@ietf.org>; Mon, 12 Aug 2013 05:57:09 -0700 (PDT) Received: from [66.196.81.173] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 12 Aug 2013 12:57:08 -0000 Received: from [98.139.212.227] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 12 Aug 2013 12:57:08 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 12 Aug 2013 12:57:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 87795.13018.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 57792 invoked by uid 60001); 12 Aug 2013 12:57:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376312227; bh=ATBR3tpnCR2w9YkJewza4+kQBK+dVPfHt1N2wtYWiT0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mHyJQh38jfwkovjOsipWNxfdf+QGvUoS5kbZmdc4pA0lZ9fit3P3xnpYjtQHvZ+z0AkCb8ZQYtBULTgK4aByx4EbHNzBFNUkYj+2d3H44a4cWN2b8pzsMaIxykc4y0LPD2uHC4dEoKKMhlauWz74OGHrG1/JklUfcKSrZuMqVWw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vbv+NH+iiilTx7NILoiMd8Ee89kkbajTFxq8ZF3DQBQeV4VjLdf4WUt7NAxLEEO4p+k7I/3tXuLsSZ2g03WmMsVY2rDe0PxEdsIxyr3ta0X0d36IH73Q0GOCzf22gTAsAK9A0Esq/1DIgL9LLvZKlg9KXkJCU9xDnM/Go+5P+1k=; X-YMail-OSG: NAk8WIsVM1mn_K_s8t_4zHutzFiM2y6Gqzu_9IDXEjom3n2 U7XZcZym1Tc1Mxjsh2L1Lzlx8ELVwPd6f4Fe6d1OsEPalDrxuldJ5btxoedb CjWSD91qqpDDtuahE25Q2cffvqZVT1eFXr0kqvMaMbq5oh5tj0.sTQDHmQNE Yk7OCGWliiAoFJhN4gReMS9PeER5FnC6oYDONAT3xMBnxwIG8E2sSTZ8oPzy BPZiymGCcAJFHZuLsdXB1p7FZJNwBaKoDKN3a5XyK7hsy3vZFupXUu50e5Qw BfGN1km9D4uX7bi5CVXvg56tvCmzD2zdJbMQT419sMqLEO_wyNQwljpi5_P2 WxjHgPDaL..Kbi8ACwp4mlhCxIfesdusLSZqoWyEGts_tf0XSK9FiM5AAzNt 2UVJYg0riVpt3ss195f7kDizM6Ov612qyvN1N9bbA8hNzYx00TBsq1AfMTwh zUSx198GvQ8XAIRCMIPB5GG2AmYY2cocIssBW6My_W0oPBiLzYhQQ_buhso0 mmBAT7JOmvkgJhRijHuYxv7o4NJp2FVQ3Q8DksjIz1NjaLAZxmd48KVjRIXe yQyBbbWlDDkie97UFkd1.ZOgScUtatido4cnhSDqLhAxxHNw- Received: from [118.208.74.180] by web142505.mail.bf1.yahoo.com via HTTP; Mon, 12 Aug 2013 05:57:07 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc.Cj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gQ2M6IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT47ICI2bWFuQGlldGYub3JnIiA8Nm1hbkBpZXRmLm9yZz47IERhdmUgVGhhbGVyIDxkdGhhbGVyQG1pY3Jvc29mdC5jb20.Cj4gU2VudDogTW9uZGF5LCAxMiBBdWd1c3QgMjAxMyA2OjU5IFBNCj4gU3ViamUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> Message-ID: <1376312227.57445.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 12 Aug 2013 05:57:07 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title To: Ole Troan , Brian E Carpenter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 13:06:26 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Ole Troan =0A> To: Brian E Carpenter =0A> Cc: Fe= rnando Gont ; "6man@ietf.org" <6man@ietf.org>; Dave = Thaler =0A> Sent: Monday, 12 August 2013 6:59 PM=0A>= Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title=0A> = =0A>>> =0A>>> I will observe that Alissa's term "random per-network" =0A> = isn't in any of the possibilities=0A>>> below and the reasons given wouldn= 't apply if that term were used.=A0 =0A> Perhaps that=0A>>> could be used = in a title?=0A>> =0A>> Nah. Too complex for a title, and "random" is a bad= word - you =0A> should always=0A>> say pseudo-random or (more pedantic) u= niformly distributed.=0A>> =0A>> IMHO the current title is clearest.=0A> = =0A> these addresses have the following properties:=0A> - stable per link= =0A> - randomly generated as opposed to based on a MAC address.=0A> =A0 (m= aking scanning attacks harder, makes tracking across links harder)=0A> - in= tended to replace existing EUI-64 identifiers=0A> =0A> truth in advertising= ; given that these addresses are meant to be used 'in =0A> public', what is= =0A> "privacy enhanced" about them?=0A> =0A> the use of "privacy" confuses = it with RFC4941 addresses, which these =0A> addresses do not replace.=0A> = =0A> "Stable per-network Addresses for IPv6 Stateless Address Autoconfigura= tion =0A> (SPN-SLAAC)"?=0A>=A0=0A=0AWhy does this method have to be limited= to SLAAC, or rather, wouldn't describing it as SLAAC related imply that th= is or a similar technique can't be used with DHCPv6 or any other address co= nfiguration methods?=0A=0AWhile DHCPv6 assigned addresses are naturally per= -subnet, I'd think the IID generation techniques described should be an opt= ion for DHCPv6 provided addresses e.g., different IIDs are generated for di= fferent subnets by the DHCPv6 server even when the client provides the same= DUID.=0A=0AIt's starting to seem to me that more clearly separating addres= s generation methods from address configuration methods would be worth whil= e. If I statically configure an address that complies with this algorithm (= perhaps because my host doesn't yet implement the SLAAC method of configuri= ng them), is it a "stable privacy address" (or what ever name it ends up wi= th)? In practice I'd probably still call it a "stable privacy address".=0A= =0ARegards,=0AMark.=0A=0A=0A> no hat,=0A> Ole=0A> =0A> --------------------= ------------------------------------------------=0A> IETF IPv6 working grou= p mailing list=0A> ipv6@ietf.org=0A> Administrative Requests: https://www.i= etf.org/mailman/listinfo/ipv6=0A> -----------------------------------------= ---------------------------=0A> From bob.hinden@gmail.com Mon Aug 12 12:59:17 2013 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 7140C21F9DB2 for ; Mon, 12 Aug 2013 12:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVfeI5hZ6wOh for ; Mon, 12 Aug 2013 12:59:12 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF921F9D71 for ; Mon, 12 Aug 2013 12:59:12 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id b20so2412150yha.7 for ; Mon, 12 Aug 2013 12:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/CVFDmNap7Ua4T8THZiftFBVNa7zYP7OdA/ql2iMnyM=; b=U6p79sD9g7ZE2F9sLal/45ZzAifCduHwPHGbb5nq7qHF7BVMj/bGKJaFktm9Ms0dcb 6w29X2WB5eTQePPCVOYXeEDjH0wD3Nifz2nOY5G4zQnrjNhuQPVtNwpU03qPbyBOY9aF 7KVt9cbkD32alqZOZO4aGdBG7NNvrqdmxCmdnInGetqyOUEPEktx/GKCX+nEBELm/EH3 MvyqxN38Um2br1sSI2EfTBjGTngBe0GmxZ5u1wLrhH5YqpFeE6Gv/sfpMZmjelThG41B W/YNKhHStkJmOICzp6VohukpOpKF+69xUZqerqniY5QCSlf91V1TLjMBRwdNSR3/qax7 gJkg== X-Received: by 10.236.147.80 with SMTP id s56mr334522yhj.98.1376337552090; Mon, 12 Aug 2013 12:59:12 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id i45sm8607244yhd.1.2013.08.12.12.59.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 12:59:10 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title From: Bob Hinden In-Reply-To: <1376312227.57445.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 12 Aug 2013 12:59:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> <1376312227.57445.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1508) Cc: IPv6 IPv6 List , Bob Hinden , Dave Thaler 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, 12 Aug 2013 19:59:18 -0000 Mark, > Why does this method have to be limited to SLAAC, or rather, wouldn't = describing it as SLAAC related imply that this or a similar technique = can't be used with DHCPv6 or any other address configuration methods? >=20 > While DHCPv6 assigned addresses are naturally per-subnet, I'd think = the IID generation techniques described should be an option for DHCPv6 = provided addresses e.g., different IIDs are generated for different = subnets by the DHCPv6 server even when the client provides the same = DUID. >=20 > It's starting to seem to me that more clearly separating address = generation methods from address configuration methods would be worth = while. If I statically configure an address that complies with this = algorithm (perhaps because my host doesn't yet implement the SLAAC = method of configuring them), is it a "stable privacy address" (or what = ever name it ends up with)? In practice I'd probably still call it a = "stable privacy address". That's a good point, the same issues apply to SLAAC and DHCPv6 generated = addresses. The next version of Privacy Considerations for IPv6 Address = Generation Mechanisms will hopefully address the issues in DHCP. Regarding the title, of this draft, how about: Stable Temporary Per-Subnet Interface Identifiers My thinking behind this suggestion is that the draft is about a new type = of Interface Identifiers, addresses are somewhat separate. The are = temporary as they are not tied to a hardware token like an IEEE MAC = address. They are stable as they intended to be used for a long while = on the same subnet and don't change per connection/application. It is a = bit of an oxymoron :-) Another choice: Pseudo-Random Per-Subnet Interface Identifiers They are pseudo-random and intended to be used on a single subnet. Personally, I would prefer something like these titles because "privacy" = is once of several characteristics and the privacy characteristic depend = a lot on how they are used and other factors like if they are put in the = DNS, shared at the application layer, the prefix remains constant, etc. Bob =20 From fgont@si6networks.com Mon Aug 12 14:04:48 2013 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 99A8F21F93BA for ; Mon, 12 Aug 2013 14:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIxQTfWFNhA1 for ; Mon, 12 Aug 2013 14:04:48 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8021F9CE7 for ; Mon, 12 Aug 2013 14:04:47 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.156]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V8zIB-0004ZD-S1; Mon, 12 Aug 2013 23:04:44 +0200 Message-ID: <52094DE2.1080909@si6networks.com> Date: Mon, 12 Aug 2013 18:04:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Bob Hinden Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> <1376312227.57445.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 IPv6 List , Dave Thaler 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, 12 Aug 2013 21:04:48 -0000 Hi, Bob, On 08/12/2013 04:59 PM, Bob Hinden wrote: > > Pseudo-Random Per-Subnet Interface Identifiers > > They are pseudo-random and intended to be used on a single subnet. > > Personally, I would prefer something like these titles because > "privacy" is once of several characteristics and the privacy > characteristic depend a lot on how they are used and other factors > like if they are put in the DNS, shared at the application layer, the > prefix remains constant, etc. IMHO, I think we're over-..thinking(?) the title. For instance, the same arguments that have been made about the use of the term "privacy" could be done about terms such as "secret" (in "secret key") -- we shouldn't not be able to say "secret key" because it all depends on whether you disclose or publish the key. In this case, theses addresses have the following properties: * They don't leak information about the underlying NIC manufacturer * They don't disclose information about node identity * They don't disclose any information about patterns employed by IPv6 addresses in the local subnet You might use this addresses for incoming connections without affecting the above properties. And you might set up temporary names (and publish the addresses there) without affecting any of some of the above properties. In any case, if you hurt their privacy properties at any other layer, it's a similar case of someone leaking a secret key above (but we still call them "secret"). The best thing a reader of this document can do is read the I-D we're co-authoring with Dave and Alissa. Whatever title we were to chose won't help the reader avoid the ned to do that. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dthaler@microsoft.com Mon Aug 12 14:33:34 2013 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 A7CD321F9263 for ; Mon, 12 Aug 2013 14:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=1.283, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRyXE-Xp8Ak9 for ; Mon, 12 Aug 2013 14:33:28 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16221F9F9A for ; Mon, 12 Aug 2013 14:33:27 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 12 Aug 2013 21:33:24 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.60]) with mapi id 15.00.0745.000; Mon, 12 Aug 2013 21:33:24 +0000 From: Dave Thaler To: Bob Hinden , Mark ZZZ Smith Subject: RE: draft-ietf-6man-stable-privacy-addresses: Document title Thread-Topic: draft-ietf-6man-stable-privacy-addresses: Document title Thread-Index: AQHOlUzUHrv/yDZKVkmmKPz6rNEXOZmNfcSQgAALjwCAA8B5AIAAQoCAgAB16ICAABkZ8A== Date: Mon, 12 Aug 2013 21:33:24 +0000 Message-ID: <8da4979734ed4f7dac6b38fd7b7770d5@BY2PR03MB269.namprd03.prod.outlook.com> References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> <1376312227.57445.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 09368DB063 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(199002)(189002)(51704005)(77096001)(76796001)(54356001)(79102001)(53806001)(59766001)(16406001)(56816003)(19580395003)(77982001)(63696002)(54316002)(56776001)(33646001)(74316001)(76482001)(83322001)(76576001)(76786001)(19580405001)(81342001)(66066001)(81542001)(80022001)(65816001)(74876001)(69226001)(74706001)(80976001)(4396001)(74366001)(83072001)(49866001)(47976001)(47736001)(74662001)(31966008)(51856001)(46102001)(50986001)(47446002)(81686001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 50.135.4.20 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB269.namprd03.prod.outlook.com Cc: IPv6 IPv6 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: Mon, 12 Aug 2013 21:33:34 -0000 > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Monday, August 12, 2013 12:59 PM > To: Mark ZZZ Smith > Cc: Bob Hinden; Ole Troan; Brian Carpenter; IPv6 IPv6 List; Dave Thaler > Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title >=20 > Mark, >=20 > > Why does this method have to be limited to SLAAC, or rather, wouldn't > describing it as SLAAC related imply that this or a similar technique can= 't be > used with DHCPv6 or any other address configuration methods? > > > > While DHCPv6 assigned addresses are naturally per-subnet, I'd think the= IID > generation techniques described should be an option for DHCPv6 provided > addresses e.g., different IIDs are generated for different subnets by the > DHCPv6 server even when the client provides the same DUID. > > > > It's starting to seem to me that more clearly separating address genera= tion > methods from address configuration methods would be worth while.=20 I agree with all of the above discussion. > If I > statically configure an address that complies with this algorithm (perhap= s > because my host doesn't yet implement the SLAAC method of configuring > them), is it a "stable privacy address" (or what ever name it ends up wit= h)? In > practice I'd probably still call it a "stable privacy address". >=20 > That's a good point, the same issues apply to SLAAC and DHCPv6 generated > addresses. The next version of Privacy Considerations for IPv6 Address > Generation Mechanisms will hopefully address the issues in DHCP. >=20 > Regarding the title, of this draft, how about: >=20 > Stable Temporary Per-Subnet Interface Identifiers "Temporary" definitely doesn't belong in the title because they're not near= ly as temporary as the ones in RFC 4941. >=20 > My thinking behind this suggestion is that the draft is about a new type = of > Interface Identifiers, addresses are somewhat separate. The are temporar= y > as they are not tied to a hardware token like an IEEE MAC address. They = are > stable as they intended to be used for a long while on the same subnet an= d > don't change per connection/application. It is a bit of an oxymoron :-) >=20 > Another choice: >=20 > Pseudo-Random Per-Subnet Interface Identifiers >=20 > They are pseudo-random and intended to be used on a single subnet. I have no problem with the above. > Personally, I would prefer something like these titles because "privacy" = is > once of several characteristics and the privacy characteristic depend a l= ot on > how they are used and other factors like if they are put in the DNS, shar= ed at > the application layer, the prefix remains constant, etc. I agree it would be good to keep the word "Privacy" out of the name of the type of interface identifiers. It should only be in the title if used= in a way that doesn't modify the term "address" or "interface identifier". (By comparison the title of RFC 4941 has Privacy used in a way that doesn't= , and is fine.) -Dave >=20 > Bob From ietf@rozanak.com Mon Aug 12 15:59:08 2013 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 C34C011E80E4 for ; Mon, 12 Aug 2013 15:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFFZ-T7JSLR7 for ; Mon, 12 Aug 2013 15:59:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 11AD911E80E0 for ; Mon, 12 Aug 2013 15:59:04 -0700 (PDT) Received: from kopoli (g226057237.adsl.alicedsl.de [92.226.57.237]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LpbRu-1VoQN22MHm-00eo1N; Mon, 12 Aug 2013 18:58:58 -0400 From: "Hosnieh Rafiee" To: "Andrew Yourtchenko" , "Keith Moore" , "Dave Thaler" , "Erik Nordmark" , Subject: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments Date: Tue, 13 Aug 2013 00:58:46 +0200 Message-ID: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6Xr4ABQEWUqlesSjaPPetZq+4I4Q== Content-Language: en-us X-Provags-ID: V02:K0:BF9Om5GNQbIaFFQpXH5XYLelO9td3fDhksGvQtNU+qQ 1XMGy0px14KYFj4rdnADldYnTNwHOv7C+LMBMWF82OE01S1qV1 maVUIIjeoEDLD6FnZAu4SdV3xhXqscSKi/xbrWrNzVCmM4Sfen iXfo5RoLMewFw2u6MQlBD2qZmksRpMKT6VCQ8GBfWTLDTmUX1X uQQ2Md6XTTbpRksF8pHCp56NFMeaFVB+KOfgcaC3GjKhtKSWTO gCetpqW8Gh2yeJbvUuP+e6Z5y6dIGF58IWlaYtc1bRS7TkADQx qnUWfhhTwltyuH7/soQkxeU0E+paj0Bve0ZCmObpOjJ+72IfJX Nb5xikHaeHSYWqFGOjO0= 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, 12 Aug 2013 22:59:08 -0000 Hi, I applied Fernando's recent comments. I also clarified the usage of the new algorithm to make it clear that is not CGA (for those who interpreted it incorrectly). Now this draft addresses all the deficiencies contained in RFC 4941 so as to prevent node tracking or location tracking attacks that could result from the use of a bad randomization choice for IID generation or because of using EUI-64 in generating public addresses or because there is the possibility that the IIDs will not be changed when the node joins a new network. http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy Please review and share your concerns if there are any. Thank you, Best, Hosnieh From jhw@apple.com Mon Aug 12 17:11:15 2013 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 E762B11E80F2 for ; Mon, 12 Aug 2013 17:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzGwbsWqFG9T for ; Mon, 12 Aug 2013 17:11:09 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3798511E80F0 for <6man@ietf.org>; Mon, 12 Aug 2013 17:11:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MRG00GVD0HDINZ0@mail-out.apple.com> for 6man@ietf.org; Mon, 12 Aug 2013 17:11:08 -0700 (PDT) X-AuditID: 11807165-b7f926d000002c03-9b-5209799c2b9a Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 66.74.11267.C9979025; Mon, 12 Aug 2013 17:11:08 -0700 (PDT) Received: from ba0301b-dhcp213.apple.com ([17.193.15.213]) by chicory.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MRG00ITT0IJXD20@chicory.apple.com> for 6man@ietf.org; Mon, 12 Aug 2013 17:11:07 -0700 (PDT) Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title From: james woodyatt In-reply-to: <52056638.3010904@si6networks.com> Date: Mon, 12 Aug 2013 17:11:06 -0700 Message-id: <6A63F27E-77B8-450C-8FC0-D294D2445947@apple.com> References: <52056638.3010904@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1793.4) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCcrDunkjPIYPEiDouVK+4yOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+31KfaClVwVny8sYm1gXMzRxcjJISFgInG+azErhC0mceHe erYuRi4OIYF+Jom7k59AOfOZJCataGUHqWIW0JJYv/M4UxcjBwevgIHE5wYfkLCwgKvEq7aT zCA2m4CKxLfLd5lAbE4BfYlzWzezgpSzCKhKfJiTCTFFWeLOljZWCFtb4sm7C2A2r4CNxOZt i8BahQT0JE58PgRmiwhoSsx9foQJ4k55ibbfP9kmMArMQnLQLISDZiGZuoCReRWjQFFqTmKl uV5iQUFOql5yfu4mRnDQFabuYGxcbnWIUYCDUYmHN+MjR5AQa2JZcWXuIUYJDmYlEd6TOpxB QrwpiZVVqUX58UWlOanFhxilOViUxHnvf2UJEhJITyxJzU5NLUgtgskycXBKNTAW7ll6tzdl Vf3Lt3V/bHbkbQpULKkz/8aq7tBx61eWlt3DCa53XXz8XJSXlEwpttZMnfVceLlNYEOL2NKu B6L8W97Mq/on/SfyUK1JZNjMoyueHImR5D64Luv+A38t/98nU3fx38oNm5ihwdTw2jhvUqfm l+37w+UfN3TsfKpiO9nlu9f22HtKLMUZiYZazEXFiQBtgTepNgIAAA== Cc: "6man@ietf.org" <6man@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, 13 Aug 2013 00:11:16 -0000 On Aug 9, 2013, at 14:59 , Fernando Gont wrote: > The arguemtn, as far as I can tell, is that the current title might be confusing (mostly because of the confusion there is with different terminology on the subject). Oh yay! Something I'm good at! > Given the above options I'd stick with the current title. Besides, the community has become used to refer to this method as "stable-privacy-addresses".. so changing the title at this point would, > IMHO, only contribute to confusion. Count me in the group who would like to change the title. I propose using the word "opaque" instead: Long Title: "Stateless Automatic IPv6 Address Configuration (SLAAC) with Stable and Semantically Opaque Interface Identifiers" Short Title: "SLAAC with Stable and Opaque IIDs" I propose to use the word "opaque" here because the pseudo-random number generator is an implementation detail. The objective is to remove the semantic content of the EUI-64 formatted MAC address from all the IP addresses that a host needs to use. The privacy consideration is only one of several goals that achieving that objective is meant to address. Another goal is to reduce the likelihood of IID collision. -- james woodyatt core os networking From fgont@si6networks.com Mon Aug 12 20:26:06 2013 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 72E3E11E8109 for ; Mon, 12 Aug 2013 20:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbOKiuwSDNsg for ; Mon, 12 Aug 2013 20:26:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D8D2211E8108 for ; Mon, 12 Aug 2013 20:26:02 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V95Ex-00077O-UF; Tue, 13 Aug 2013 05:25:48 +0200 Message-ID: <5209A733.5050303@si6networks.com> Date: Tue, 13 Aug 2013 00:25:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments References: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> In-Reply-To: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Keith Moore , Erik Nordmark , Andrew Yourtchenko , Dave Thaler 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, 13 Aug 2013 03:26:06 -0000 On 08/12/2013 07:58 PM, Hosnieh Rafiee wrote: > Hi, > I applied Fernando's recent comments. For the record, this document doesn't address my feedback. Most of the I-D is about how to generate a random number. If you need a PRNG, just require implementations to implement one. Your workaround is to get into the same level of complexity to produce a PRNG that wil be employed just by the stack -- if you're ging to implement one, make it available to all apps/functions (rather than reinvent the wheel at every module that needs a PRNG). There's still lots of text that could/should be removed throughout the document -- for instance, you need to get deep into the Abstract to see what the document is trying to solve (I bet you might even get a id-nits warning as a result of the large Abstract?). I won't comment further, but just wanted to note that my comments have not been addressed, since you've stated that they have. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Aug 12 21:15:18 2013 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 E1A8F21F9CE8 for ; Mon, 12 Aug 2013 21:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 834R-mvZqSh9 for ; Mon, 12 Aug 2013 21:15:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 72F8421F9A14 for <6man@ietf.org>; Mon, 12 Aug 2013 21:14:55 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V960L-0008HB-3L; Tue, 13 Aug 2013 06:14:45 +0200 Message-ID: <5209B2B1.90500@si6networks.com> Date: Tue, 13 Aug 2013 01:14:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: james woodyatt Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title References: <52056638.3010904@si6networks.com> <6A63F27E-77B8-450C-8FC0-D294D2445947@apple.com> In-Reply-To: <6A63F27E-77B8-450C-8FC0-D294D2445947@apple.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@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, 13 Aug 2013 04:15:19 -0000 On 08/12/2013 09:11 PM, james woodyatt wrote: >> Given the above options I'd stick with the current title. Besides, >> the community has become used to refer to this method as >> "stable-privacy-addresses".. so changing the title at this point >> would, IMHO, only contribute to confusion. > > Count me in the group who would like to change the title. I knew that starting this thread was asking for trouble :-)) > I propose > using the word "opaque" instead: > > Long Title: "Stateless Automatic IPv6 Address Configuration (SLAAC) > with Stable and Semantically Opaque Interface Identifiers" How about "A method for generating Semantically Opaque Interface Identifiers with Stateless Automatic IPv6 Address Configuration (SLAAC)"? (otherwise it sounds like the Interface IDs are already there when you do SLAAC). > Short Title: "SLAAC with Stable and Opaque IIDs" > > I propose to use the word "opaque" here because the pseudo-random > number generator is an implementation detail. The objective is to > remove the semantic content of the EUI-64 formatted MAC address from > all the IP addresses that a host needs to use. Not just that. Because if you were to replace the EUI-64 with some constant number, the IID would be opaque, but you'd still be subject to e.g. tracking attacks. > The privacy > consideration is only one of several goals that achieving that > objective is meant to address. Another goal is to reduce the > likelihood of IID collision. Me, I see "privacy" as not disclosing more than you're strictly required to communicate. That is, not leak node identity, underlying NIC vendor, etc., etc. IMHO, I wouldn't personally opt for changing the title, since I think it conveys the information it is meant to convey. That say, if we (wg) want to go that path, something along the lines of what I suggested above (essentially *your* suggestion, with a minor mod) would seem to be the best alternative I have so far seen. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Tue Aug 13 00:15:00 2013 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 B18A021E80B9 for ; Tue, 13 Aug 2013 00:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+axuaRT1VnV for ; Tue, 13 Aug 2013 00:14:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0E21E80AD for ; Tue, 13 Aug 2013 00:14:53 -0700 (PDT) Received: from kopoli (g225038152.adsl.alicedsl.de [92.225.38.152]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MWTP0-1VcEO10jiU-00XfHc; Tue, 13 Aug 2013 03:14:35 -0400 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> <5209A733.5050303@si6networks.com> In-Reply-To: <5209A733.5050303@si6networks.com> Subject: RE: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments Date: Tue, 13 Aug 2013 09:14:23 +0200 Message-ID: <003001ce97f4$c3283690$4978a3b0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFcBQmkutUuZtZnhCvvIhIJ6OHxEwIKm8JxmmeDwmA= Content-Language: en-us X-Provags-ID: V02:K0:QjZmubcPLuzkzvpS+NwfUskQzPY1+m5o9sdfDP8t5Cl yaUn4eWKDh/eTGFRxmTJza6Mwj++9PAv19SPRkdHDr0mnu9wNl 6vihegupmG9Kq2IQfBpECZrnI8WJW2VohBTxXwcezkOkiw7+rv DbUz52HL3Obq7FtuMdFnsHqZiqFmJGCn7mkZKGzULoXJYw1ejr EKLGFAPM5AlMmNPrUc6dO5Pi7Q2PRnf36Zw2D1QlkWHJgF5vFf 82s+KKFAc3u6TpwuUfLEk1dubd8EkA13TTQDAP0+PcNf9cviCx 3ivlTK1phURhymGRKYnxYEXL4jUtukXyU0t2G0g8QzM4yFdUVO yGgfVRAIHP0knK14OAOc= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Andrew Yourtchenko' , 'Dave Thaler' 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, 13 Aug 2013 07:15:00 -0000 > For the record, this document doesn't address my feedback. > > Most of the I-D is about how to generate a random number. > > If you need a PRNG, just require implementations to implement one. Your > workaround is to get into the same level of complexity to produce a PRNG that > wil be employed just by the stack -- if you're ging to implement one, make it > available to all apps/functions (rather than reinvent the wheel at every module > that needs a PRNG). JFYI: if you check the algorithm, when stable storage is in use, they also need to implement a PRNG in addition to use a stack. I have already discussed about the complexity in my last email. obtaining timestamp from the system, generating a random number using timestamp as a seed and call it modifier or whatever and then applying SHA256 on (timestamp, prefix, modifier) is not complex. For using a default value in history, the system need to generate random number anyway. While after that it needs stack in RFC 4941, but with my update it only needs that PRNG. Second, I did not say that the implementation cannot use the stable storage. This way is only "RECOMMENDED" but no force to implement this and the implementers can keep their first approach. But, what is clear here is the probability of an attacker to find the history value in order to guess the next IID of the node is more than using my approach which is completely random. This is because I do not need to keep any value anywhere in the node and modifier every time can be new value. > There's still lots of text that could/should be removed throughout the document > -- for instance, you need to get deep into the Abstract to see what the > document is trying to solve (I bet you might even get a id-nits warning as a > result of the large Abstract?). No, I didn't. It passed without any problem! My abstract is explaining what I plan to address in the whole document. There is no problem to shorten it as well. > I won't comment further, but just wanted to note that my comments have not > been addressed, since you've stated that they have. You usually do not apply the comments that you are not convinced about and have already explained your reason as to why you are not agree. This is the same case for your comments on PRNG. To be more clear, here is your comments which I applied: http://www.ietf.org/mail-archive/web/ipv6/current/msg18732.html Thanks, Hosnieh From ayourtch@gmail.com Tue Aug 13 01:15:36 2013 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 0A65F11E80E4 for ; Tue, 13 Aug 2013 01:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIxXwxgm57Wc for ; Tue, 13 Aug 2013 01:15:34 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6BB21E8063 for ; Tue, 13 Aug 2013 01:15:30 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id na10so2235102bkb.28 for ; Tue, 13 Aug 2013 01:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LmuxOIm/iW5C9BvtyP87Iae0AYWI2UQ5qd9Ce6YUQ88=; b=YeLeGIxRedgNAyaEEYlt0S0yQXiWOjTJ3NFQxL3INI5OmZxEEDVvwZ29WI4ReqK7ft AmjtqR1vFjrOBQzuomrbg8peiCuGb4s6aBsrzzyOcQaJoV0WQZl1VZ+/lnE4GhdRZ3tI jcu+iNruZK8fvwp5nRXwHS+eVWWqU6Xt3P7BNrXaJhMclveNEmsrmJwJeRFge4MDLplb WihAXQeeM8avuRJj8RyoOEgVBnTwzPlal+JMaQ0IE3INm39qi4XD6vkiKbJGHNtk5zYt 6j2dJmF8qhiyx/xIbUiF5uqSKxYWZN005loNDxdE54bI7WknJgIJtiAnxlK8FfcseX0s qhpg== MIME-Version: 1.0 X-Received: by 10.205.25.9 with SMTP id rg9mr545132bkb.26.1376381730056; Tue, 13 Aug 2013 01:15:30 -0700 (PDT) Received: by 10.204.226.7 with HTTP; Tue, 13 Aug 2013 01:15:29 -0700 (PDT) In-Reply-To: <003001ce97f4$c3283690$4978a3b0$@rozanak.com> References: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> <5209A733.5050303@si6networks.com> <003001ce97f4$c3283690$4978a3b0$@rozanak.com> Date: Tue, 13 Aug 2013 08:15:29 +0000 Message-ID: Subject: Re: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments From: Andrew Yourtchenko To: Hosnieh Rafiee Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 13 Aug 2013 01:52:41 -0700 Cc: ipv6@ietf.org, Keith Moore , Erik Nordmark , Dave Thaler , Fernando Gont 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, 13 Aug 2013 08:15:36 -0000 "One of the issues with this RFC concerns the wording that is used that allows the implementation to make the choice as to what approach to use, and in so doing, in some cases, the choice made is not the most prudent or best approach, and this thus is not ideal and can lead to some problems." "prudent" and "best" are things that will change overtime. I can see the value in publishing some algorithm to generate IID, and maybe the more of these we have - the better. I see it harmful in marking the core IPv6 specs updated with this algorithm - even http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ does not do that. Now, beyond the philosophical-political comments, a couple of things on the "meat": 1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC. This seems to me that step 6 of algorithm needs to go. 2) the algorithm components R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) it looks to me that it is functionally equivalent of just taking a hash of 16 random bytes and using that as an interface ID ? Why the additional components ? They're trivially guessable (even remotely) and are the same for the nodes on the segment, so they do not add much in terms of entropy. 3) DAD If, after 3 tries, it receives the same result, it will consider this an attack and will start using that IP address. Uh. So if I have a mass of devices on the segment from the same vendor who made a poor implementation of this algorithm there is a plausible race condition where they might start using the same address ? (if the RNG is of bad quality). 4) stable storage. If I read it right, I think the node still must have at least enough storage to keep a single IID. If we are talking this a replacement of EUI64, then, again, why not take a random 64bit value, store that, and just use either that value alone for the IID ? --a On 8/13/13, Hosnieh Rafiee wrote: >> For the record, this document doesn't address my feedback. >> >> Most of the I-D is about how to generate a random number. >> >> If you need a PRNG, just require implementations to implement one. Your >> workaround is to get into the same level of complexity to produce a PRNG > that >> wil be employed just by the stack -- if you're ging to implement one, >> make > it >> available to all apps/functions (rather than reinvent the wheel at every > module >> that needs a PRNG). > > JFYI: if you check the algorithm, when stable storage is in use, they also > need to implement a PRNG in addition to use a stack. > I have already discussed about the complexity in my last email. obtaining > timestamp from the system, generating a random number using timestamp as a > seed and call it modifier or whatever and then applying SHA256 on > (timestamp, prefix, modifier) is not complex. For using a default value in > history, the system need to generate random number anyway. While after that > it needs stack in RFC 4941, but with my update it only needs that PRNG. > Second, I did not say that the implementation cannot use the stable > storage. > This way is only "RECOMMENDED" but no force to implement this and the > implementers can keep their first approach. But, what is clear here is the > probability of an attacker to find the history value in order to guess the > next IID of the node is more than using my approach which is completely > random. This is because I do not need to keep any value anywhere in the > node > and modifier every time can be new value. > > >> There's still lots of text that could/should be removed throughout the > document >> -- for instance, you need to get deep into the Abstract to see what the >> document is trying to solve (I bet you might even get a id-nits warning >> as > a >> result of the large Abstract?). > > No, I didn't. It passed without any problem! My abstract is explaining what > I plan to address in the whole document. There is no problem to shorten it > as well. > >> I won't comment further, but just wanted to note that my comments have >> not >> been addressed, since you've stated that they have. > > You usually do not apply the comments that you are not convinced about and > have already explained your reason as to why you are not agree. This is the > same case for your comments on PRNG. > > To be more clear, here is your comments which I applied: > http://www.ietf.org/mail-archive/web/ipv6/current/msg18732.html > > Thanks, > Hosnieh > > From ietfc@btconnect.com Tue Aug 13 02:19:02 2013 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 952A821E8105 for ; Tue, 13 Aug 2013 02:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1Tr9AoBExnZ for ; Tue, 13 Aug 2013 02:18:50 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id E183721E8104 for <6man@ietf.org>; Tue, 13 Aug 2013 02:18:49 -0700 (PDT) Received: from mail29-db8-R.bigfish.com (10.174.8.249) by DB8EHSOBE035.bigfish.com (10.174.4.98) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 09:18:48 +0000 Received: from mail29-db8 (localhost [127.0.0.1]) by mail29-db8-R.bigfish.com (Postfix) with ESMTP id CFC6C12C00AF; Tue, 13 Aug 2013 09:18:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: PS-18(zzbb2dI62a3I98dI9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz97hz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail29-db8 (localhost.localdomain [127.0.0.1]) by mail29-db8 (MessageSwitch) id 1376385526815467_16959; Tue, 13 Aug 2013 09:18:46 +0000 (UTC) Received: from DB8EHSMHS022.bigfish.com (unknown [10.174.8.235]) by mail29-db8.bigfish.com (Postfix) with ESMTP id C09541EC0046; Tue, 13 Aug 2013 09:18:46 +0000 (UTC) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by DB8EHSMHS022.bigfish.com (10.174.4.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 09:18:46 +0000 Received: from DB3PRD0210HT002.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 13 Aug 2013 09:18:45 +0000 Message-ID: <043c01ce9806$0b4637e0$4001a8c0@gateway.2wire.net> From: t.petch To: Brian E Carpenter , Dave Thaler References: <52056638.3010904@si6networks.com> <52057E26.3070701@gmail.com> Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title Date: Tue, 13 Aug 2013 10:18:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Fernando Gont , 6man@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, 13 Aug 2013 09:19:02 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "Dave Thaler" Cc: "Fernando Gont" ; <6man@ietf.org> Sent: Saturday, August 10, 2013 12:41 AM > On 10/08/2013 11:01, Dave Thaler wrote: > > I will observe that Alissa's term "random per-network" isn't in any of the possibilities > > below and the reasons given wouldn't apply if that term were used. Perhaps that > > could be used in a title? > > Nah. Too complex for a title, and "random" is a bad word - you should always > say pseudo-random or (more pedantic) uniformly distributed. > > IMHO the current title is clearest. I agree; it does the job. I seem to have spent a lot of my working life disentangling identifiers that have been overloaded with technical detail that adds nothing to their use as identifiers and becomes plain misleading further down the line. The namespace here is that set by RFC4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" to which this is an addition/enhancement/alternative and that is what the title should convey, ie the title should be similar, to show that the two are closely related, but different, to highlight what has changed. Adding "stable" does the job. Tom Petch > Brian > > > > > -Dave > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >> Fernando Gont > >> Sent: Friday, August 9, 2013 2:59 PM > >> To: 6man@ietf.org > >> Subject: draft-ietf-6man-stable-privacy-addresses: Document title > >> > >> Folks, > >> > >> I has been suggested to me that we might want to change the title of this > >> document, and the chairs have suggested that I comment on this one on-list. > >> > >> The arguemtn, as far as I can tell, is that the current title might be confusing > >> (mostly because of the confusion there is with different terminology on the > >> subject). > >> > >> The current title is: > >> > >> * "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 > >> Stateless Address Autoconfiguration (SLAAC)" > >> > >> It conveys this key information: that the addresses are stable, and that they > >> are privacy-friendly > >> > >> > >> And the titles that have so far been suggested are: > >> > >> 1) ""Stable Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)" > >> > >> Me, I think this one is confusing -- for instance, IEEE-derived addresses are > >> stable, too. > >> > >> > >> 2) "Stable Addresses with IPv6 Stateless Address Autoconfiguration > >> (SLAAC) not derived from EUI-64 identifiers" > >> > >> This one doesn't convey the information that these addresses are privacy- > >> friendly. Besides, why whould we assume that every link layer can generate > >> addresses based on EUI-64 ientifiers? (some link layers don't have those) > >> > >> > >> 3) "Underived from EUI-64 Stable Addresses..." > >> > >> Same as "3)". > >> > >> > >> 4) "Amethod for generating stable random addresses" > >> > >> This one is also confusing, since the current scheme used by Windows > >> provide addresses that are random, and stable across networks. > >> > >> > >> Given the above options I'd stick with the current title. Besides, the > >> community has become used to refer to this method as "stable-privacy- > >> addresses".. so changing the title at this point would, IMHO, only contribute to > >> confusion. > >> > >> Thoughts? > >> > >> Thanks, > >> -- > >> Fernando Gont > >> SI6 Networks > >> e-mail: fgont@si6networks.com > >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > >> > >> From ietf@rozanak.com Tue Aug 13 02:53:49 2013 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 221F221E80FE for ; Tue, 13 Aug 2013 02:53:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Viu76WKBWUj for ; Tue, 13 Aug 2013 02:53:44 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5817A21E80F9 for ; Tue, 13 Aug 2013 02:53:44 -0700 (PDT) Received: from kopoli (g225038152.adsl.alicedsl.de [92.225.38.152]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MNqnj-1VB8AA0vDH-0078Uw; Tue, 13 Aug 2013 05:53:34 -0400 From: "Hosnieh Rafiee" To: "'Andrew Yourtchenko'" References: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> <5209A733.5050303@si6networks.com> <003001ce97f4$c3283690$4978a3b0$@rozanak.com> In-Reply-To: Subject: RE: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments Date: Tue, 13 Aug 2013 11:53:20 +0200 Message-ID: <000001ce980a$f81da3b0$e858eb10$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFcBQmkutUuZtZnhCvvIhIJ6OHxEwIKm8JxAdVRCb0Czx+Up5pChKRQ Content-Language: en-us X-Provags-ID: V02:K0:MMlF+Ta+M7RIUCnQ5rqso4sKofg4Lv+Luz4p+KWg59p xoNjeodJr9AL335E+JYlCjje+kqECfWVYXF9SBSpsCyeGGNdpC Je/dCjOdk4LCGPnERR0vJbiXIQ20r29/Y2UF2EReD1bqPde/0s t7VSARvdAzPnmbs32RaEyDkvnMSp+3XS1Xs36NOPXqENMjfvjz k0N3om+kJKXtXaJj0tMjS7XptlTshox0RprK9e/7H02aEFSvBZ hbQNKMSeqSjqiC6eaQgIx7xR1BgeVptitB3vHbQw5CEo0kuy16 Fy9sWrbpQEStKpX6XBnrZz4L3qeDu0dWOuQKeHy8dwS5GTKDTE cpdpHJsrGpSV+Cj5hwzg= Cc: ipv6@ietf.org, 'Keith Moore' , 'Erik Nordmark' , 'Dave Thaler' , 'Fernando Gont' 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, 13 Aug 2013 09:53:49 -0000 Hi Andrew, Thanks for your comments. See my response as follow: > "prudent" and "best" are things that will change overtime. I can see the value in > publishing some algorithm to generate IID, and maybe the more of these we > have - the better. > That section is related to the use of word "might" for the use of RFC 4086 in order to pick up a random number. > I see it harmful in marking the core IPv6 specs updated with this algorithm - > even http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ > does not do that. The old version of draft was not like that but I changed it to apply Fernando's comment. How about change it like before : The node must not generate its public address based on any algorithm that uses MAC address. It "MIGHT" generate it based on [stableaddresses] document. Does it address your concern? > Now, beyond the philosophical-political comments, a couple of things on the > "meat": > > 1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC. > This seems to me that step 6 of algorithm needs to go. I did not mention it because that draft relaxed the usage of those bits. So, I thought it would be useful to use all those bits for IID. I can add a reference to that document . > 2) the algorithm components > > R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) > > it looks to me that it is functionally equivalent of just taking a hash of 16 > random bytes and using that as an interface ID ? If I added router prefix , It is only for more randomization and decrease the chance of pick up the same value for other network. It is true that prefix is well known, but timestamp and modifier is not known. Why the additional > components ? They're trivially guessable (even remotely) and are the same for > the nodes on the segment, so they do not add much in terms of entropy. Timestamp : you have to consider clock skew and the CPU cycles so not easily guessable. Modifier: this value is added in case we have the same vendors as you also mentioned. The seed can be any value. One can pick up timestamp. But then based on seed you pick up another number. It is not guessable as well. You have to consider that the attacker is not in the same local link as the node. If he is, he can harm user's privacy based on layer 2 and no need to look for the IP address of this node. Otherwise we have another mechanism to also change the MAC address! Which is out of the scope of this document which talks on layer 3 privacy. However, I think it is currently have a good randomization (because of my reasons) but I also can apply a simple step to increase the randomization, i.e., use any permutation of the s. where s=(modifier||timestamp||prefix) and || is the sign for concatenation. As a result, the node will pick up any different orders of s array of bytes and so the attacker needs to guess on 32 bits and not 16 or 24 bits. Any thoughts? > 3) DAD > > If, after 3 tries, it receives the same > result, it will consider this an attack and will start using that IP > address. > > Uh. So if I have a mass of devices on the segment from the same vendor who > made a poor implementation of this algorithm there is a plausible race > condition where they might start using the same address ? > No, the probability of two nodes pick up the same modifier is really low. Especially if we give a chance for 3 tries. Although they starts at the same time and we say their clock is completely synchronize but the modifier change this value. Any thoughts? > 4) stable storage. > > If I read it right, I think the node still must have at least enough storage to keep > a single IID. If we are talking this a replacement of EUI64, then, again, why not > take a random 64bit value, store that, and just use either that value alone for > the IID ? That is almost the same as my algorithm with a small different step, i.e., you also use stable storage to keep a value while I think there is no need to do so. (they use also a hash function on the concatenation of "history" and EUI-64.). My reason is, as I explained off list, this will increase the chance for the attacker to guess next value generated by the node in case the node is compromised and the attacker access the history once (virus or ...). But using my algorithm, the attacker needs to try different values and he might not have enough time it is because based on that RFC, the node will keep its IID maximum for a week and in most cases for a day. This means an attacker need to try different guessed values in a week (2^24) for the inputs of SHA256 hash function. Thanks, Best, Hosnieh From ietf@rozanak.com Tue Aug 13 02:59:01 2013 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 C81BA21E8097 for ; Tue, 13 Aug 2013 02:59:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G9A-YAYRDEx for ; Tue, 13 Aug 2013 02:58:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1218211E8131 for ; Tue, 13 Aug 2013 02:58:57 -0700 (PDT) Received: from kopoli (g225038152.adsl.alicedsl.de [92.225.38.152]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MZSCr-1VQ2L011x7-00L099; Tue, 13 Aug 2013 05:58:50 -0400 From: "Hosnieh Rafiee" To: "'Andrew Yourtchenko'" References: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> <5209A733.5050303@si6networks.com> <003001ce97f4$c3283690$4978a3b0$@rozanak.com> <000001ce980a$f81da3b0$e858eb10$@rozanak.com> In-Reply-To: <000001ce980a$f81da3b0$e858eb10$@rozanak.com> Subject: RE: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments Date: Tue, 13 Aug 2013 11:58:38 +0200 Message-ID: <000101ce980b$b4fd6290$1ef827b0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFcBQmkutUuZtZnhCvvIhIJ6OHxEwIKm8JxAdVRCb0Czx+UpwHtue4WmjMm2fA= Content-Language: en-us X-Provags-ID: V02:K0:0FybXZesnW9uBFErHXBdszOYtGBwRy/HfCnneosWstd rJ/KIIBSmTlAg+mt1YAeGuY+9CFTKRaBH+S222wIqSRVNDKeP3 fy+N7BWYD8FcZpMC84c2wEGo6YjnFGt3/mmGTx/cWvGrl+/BxA /UJPAES9RVvml6VZUMhI6YjDN++Q0m0nSBGtGhH2pGCg8nzzVI 7OU1xoEycisIIHuY4j0jXhuXJzYg/DuUb5saqUBu18NTdFDmL2 bxxZKUz29PLK7BzImFGubwLlxgaWxV6NRTZQlBzSQbFB3uct5s zHKxWa4IoElCJxBfi3gOS7GlJT94AewSK/Q3uDc6/PVICUMuVI cs7QHyH9rOdOLuiyOJNw= Cc: 'Fernando Gont' , 'Erik Nordmark' , ipv6@ietf.org, 'Keith Moore' , 'Dave Thaler' 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, 13 Aug 2013 09:59:01 -0000 Follow up: Just a mistake... not 32 bits... 32 bytes! Everything in my last email is bytes and not bits... :-) I just got confused... > > Hi Andrew, > > Thanks for your comments. See my response as follow: > > > "prudent" and "best" are things that will change overtime. I can see > > the > value in > > publishing some algorithm to generate IID, and maybe the more of these > > we have - the better. > > > > That section is related to the use of word "might" for the use of RFC 4086 in > order to pick up a random number. > > > I see it harmful in marking the core IPv6 specs updated with this > algorithm - > > even > http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ > > does not do that. > > The old version of draft was not like that but I changed it to apply Fernando's > comment. How about change it like before : The node must not generate its > public address based on any algorithm that uses MAC address. It "MIGHT" > generate it based on [stableaddresses] document. > Does it address your concern? > > > Now, beyond the philosophical-political comments, a couple of things > > on > the > > "meat": > > > > 1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC. > > This seems to me that step 6 of algorithm needs to go. > > I did not mention it because that draft relaxed the usage of those bits. So, I > thought it would be useful to use all those bits for IID. I can add a reference to > that document . > > > 2) the algorithm components > > > > R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) > > > > it looks to me that it is functionally equivalent of just taking a > > hash of > 16 > > random bytes and using that as an interface ID ? > > If I added router prefix , It is only for more randomization and decrease the > chance of pick up the same value for other network. It is true that prefix is well > known, but timestamp and modifier is not known. > > > Why the additional > > components ? They're trivially guessable (even remotely) and are the > > same > for > > the nodes on the segment, so they do not add much in terms of entropy. > > Timestamp : you have to consider clock skew and the CPU cycles so not easily > guessable. > Modifier: this value is added in case we have the same vendors as you also > mentioned. The seed can be any value. One can pick up timestamp. But then > based on seed you pick up another number. It is not guessable as well. > > You have to consider that the attacker is not in the same local link as the node. > If he is, he can harm user's privacy based on layer 2 and no need to look for the > IP address of this node. Otherwise we have another mechanism to also change > the MAC address! Which is out of the scope of this document which talks on > layer 3 privacy. > > However, I think it is currently have a good randomization (because of my > reasons) but I also can apply a simple step to increase the randomization, i.e., > use any permutation of the s. where s=(modifier||timestamp||prefix) and || is > the sign for concatenation. As a result, the node will pick up any different > orders of s array of bytes and so the attacker needs to guess on > 32 bits and not 16 or 24 bits. > > Any thoughts? > > > 3) DAD > > > > If, after 3 tries, it receives the same > > result, it will consider this an attack and will start using that IP > > address. > > > > Uh. So if I have a mass of devices on the segment from the same vendor > > who made a poor implementation of this algorithm there is a plausible > > race condition where they might start using the same address ? > > > No, the probability of two nodes pick up the same modifier is really low. > Especially if we give a chance for 3 tries. Although they starts at the same time > and we say their clock is completely synchronize but the modifier change this > value. > > Any thoughts? > > > 4) stable storage. > > > > If I read it right, I think the node still must have at least enough > storage to keep > > a single IID. If we are talking this a replacement of EUI64, then, > > again, > why not > > take a random 64bit value, store that, and just use either that value > alone for > > the IID ? > > That is almost the same as my algorithm with a small different step, i.e., you > also use stable storage to keep a value while I think there is no need to do so. > (they use also a hash function on the concatenation of "history" > and EUI-64.). My reason is, as I explained off list, this will increase the chance > for the attacker to guess next value generated by the node in case the node is > compromised and the attacker access the history once (virus or ...). But using > my algorithm, the attacker needs to try different values and he might not have > enough time it is because based on that RFC, the node will keep its IID > maximum for a week and in most cases for a day. This means an attacker need > to try different guessed values in a week (2^24) for the inputs of SHA256 hash > function. > > Thanks, > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ayourtch@gmail.com Tue Aug 13 04:00:15 2013 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 4D48311E8131 for ; Tue, 13 Aug 2013 04:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RinMcYorBZDn for ; Tue, 13 Aug 2013 04:00:14 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B883411E8102 for ; Tue, 13 Aug 2013 04:00:13 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id d7so2567301bkh.12 for ; Tue, 13 Aug 2013 04:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bnq81u0vyfV0BFx+Tjm2UmbzAkFsAYQ5t35RWzkyj7A=; b=fdn21nltaTTYD7w2Tndfl4IxPHvbb8HTmj/Uu0B35rxaQp70w9DnMwnKm0Vu9SwCdU qZOlFM9YpRYn66bB6bgOlAIfKpXnkCfKPjwacoJmB7Pci3/1vMDK74PkQ3pYe3ZIWvi7 lqOn89bYq/NTJtkDuYJV1DbYvW+HNrP+WO3BE+os74+bl6Ajh15ffHozsOEv2zU9qTKN noR4Ew+6b1rdD4UCY29ReEMLUDQVRG/K80Cq99dSs0ZH9CjhX0cI370xafETKgmblWQD N6RPyJUqmhUs3FG6RC4gONbO+3FOjJA4LaK63m4JOuxQs8Td8FoWSYUM2opnFfxZiegr VjvQ== MIME-Version: 1.0 X-Received: by 10.204.225.12 with SMTP id iq12mr2563656bkb.4.1376391612699; Tue, 13 Aug 2013 04:00:12 -0700 (PDT) Received: by 10.204.226.7 with HTTP; Tue, 13 Aug 2013 04:00:12 -0700 (PDT) In-Reply-To: <000001ce980a$f81da3b0$e858eb10$@rozanak.com> References: <002c01ce97af$8639f7e0$92ade7a0$@rozanak.com> <5209A733.5050303@si6networks.com> <003001ce97f4$c3283690$4978a3b0$@rozanak.com> <000001ce980a$f81da3b0$e858eb10$@rozanak.com> Date: Tue, 13 Aug 2013 11:00:12 +0000 Message-ID: Subject: Re: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments From: Andrew Yourtchenko To: Hosnieh Rafiee Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 13 Aug 2013 05:08:11 -0700 Cc: ipv6@ietf.org, Keith Moore , Erik Nordmark , Dave Thaler , Fernando Gont 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, 13 Aug 2013 11:00:15 -0000 Hi Hosnieh, On 8/13/13, Hosnieh Rafiee wrote: > Hi Andrew, > > Thanks for your comments. See my response as follow: > >> "prudent" and "best" are things that will change overtime. I can see the > value in >> publishing some algorithm to generate IID, and maybe the more of these we >> have - the better. >> > > That section is related to the use of word "might" for the use of RFC 4086 > in order to pick up a random number. Yes, I think "might" is correct. I assert that not all stacks need the privacy and sometimes there is a tradeoff. My temperature measurement node at home with 2K of code space and 0.5Kb of RAM running IPv6 does not have the requirement for privacy. Servers running HTTP services do not have the requirement for privacy. The application of a standard is very wide, and such a broad stroke that is in the text is simply wrong. > >> I see it harmful in marking the core IPv6 specs updated with this > algorithm - >> even > http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ >> does not do that. > > The old version of draft was not like that but I changed it to apply > Fernando's comment. How about change it like before : The node must not > generate its public address based on any algorithm that uses MAC address. > It > "MIGHT" generate it based on [stableaddresses] document. > Does it address your concern? Not it does not. As I said - this may not be applicable for all of the hosts on the internet. > >> Now, beyond the philosophical-political comments, a couple of things on > the >> "meat": >> >> 1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC. >> This seems to me that step 6 of algorithm needs to go. > > I did not mention it because that draft relaxed the usage of those bits. > So, > I thought it would be useful to use all those bits for IID. I can add a > reference to that document . Your step 6 from http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-06 reads: 6. Take the 64 leftmost bits from the resulting output of step 5 (SHA2 digest) and set bits u and g (bits 7 and 8) to one and call this the IID. So it looks like it's the opposite of what you just said, or there is a hidden revision that I haven't seen :-) > >> 2) the algorithm components >> >> R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) >> >> it looks to me that it is functionally equivalent of just taking a hash >> of > 16 >> random bytes and using that as an interface ID ? > > If I added router prefix , It is only for more randomization and decrease > the chance of pick up the same value for other network. It is true that > prefix is well known, but timestamp and modifier is not known. > If you have A and B taken from random generators, either they are random enough to not collide, or they aren't. The need to "make them more random" means you have a poor RNG assumption ? How poor ? What is the math that dictates the necessity to even mix something in ? > > Why the additional >> components ? They're trivially guessable (even remotely) and are the same > for >> the nodes on the segment, so they do not add much in terms of entropy. > > Timestamp : you have to consider clock skew and the CPU cycles so not > easily > guessable. Clock skew? CPU cycles ? Your definition of timestamp, from the text: "3. Obtain the nodes' current time and convert it to a timestamp. The timestamp field consists of a 64-bit, unsigned integer field containing a timestamp whose value is computed from the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point" the timestamp is in *seconds*. Today's hosts are synced with NTP or similar, so this will be *trivially* predictable in my opinion. > Modifier: this value is added in case we have the same vendors as you also > mentioned. The seed can be any value. One can pick up timestamp. But then > based on seed you pick up another number. It is not guessable as well. two times timestamp ? Then maybe the algorithm should be more generic and shorter: "take as many of random-looking elements that you can find on your host and a counter, feed them to a crypto hash function, take 64 bits of that and use as IID, increment the counter up to 3 until DAD stops failing and use that as an address till the next reboot" ? > > You have to consider that the attacker is not in the same local link as the > node. If he is, he can harm user's privacy based on layer 2 and no need to > look for the IP address of this node. Otherwise we have another mechanism > to > also change the MAC address! Which is out of the scope of this document > which talks on layer 3 privacy. I think we need to roll back and see again which problem we're solving. As I wrote you in my first reply - the problem of privacy for the clients is a *solved* problem, *today*. You then said it was to prevent scanning ? In case the node has no stable memory ? Putting it into a *short* (about 1/5th of the current size) abstract would help make the discussion better. > > However, I think it is currently have a good randomization (because of my > reasons) but I also can apply a simple step to increase the randomization, > i.e., use any permutation of the s. where s=(modifier||timestamp||prefix) > and || is the sign for concatenation. As a result, the node will pick up > any > different orders of s array of bytes and so the attacker needs to guess on > 32 bits and not 16 or 24 bits. > > Any thoughts? Your first step is: 1. Generate a 16 byte random number called modifier. To generate this modifier, implementations SHOULD use a random seed to aid in the randomization of this number. If your RNG is good enough, the buck stops there. guessing 16 random bytes is hard. > >> 3) DAD >> >> If, after 3 tries, it receives the same >> result, it will consider this an attack and will start using that IP >> address. >> >> Uh. So if I have a mass of devices on the segment from the same vendor >> who >> made a poor implementation of this algorithm there is a plausible race >> condition where they might start using the same address ? >> > No, the probability of two nodes pick up the same modifier is really low. Based on what ? It seems the entirety of the algorithm is trying to cater to the situation from here: http://xkcd.com/221/ If it is the case, what's the guarantee that the modifier is "really random" ? And if it is really random - why adding complexity by making it more random ? > Especially if we give a chance for 3 tries. Although they starts at the > same > time and we say their clock is completely synchronize but the modifier > change this value. > > Any thoughts? I see magic manipulations all over, I am not enough qualified to comment on that :-) I could reason more if I saw math that the assertions/logic are based on. > >> 4) stable storage. >> >> If I read it right, I think the node still must have at least enough > storage to keep >> a single IID. If we are talking this a replacement of EUI64, then, again, > why not >> take a random 64bit value, store that, and just use either that value > alone for >> the IID ? > > That is almost the same as my algorithm with a small different step, i.e., > you also use stable storage to keep a value while I think there is no need > to do so. (they use also a hash function on the concatenation of "history" > and EUI-64.). My reason is, as I explained off list, this will increase the > chance for the attacker to guess next value generated by the node in case > the node is compromised and the attacker access the history once (virus or If the node is compromised, this is *GAME OVER*. No, honestly. Your credit card and CVV are gone and attacker is buying the luxury goods with that, your email does not work anymore because the attacker has changed the passwords on there, your iDevices have been wiped clean. Do you give a beep about the address anymore ? ;-) > ...). But using my algorithm, the attacker needs to try different values > and > he might not have enough time it is because based on that RFC, the node > will > keep its IID maximum for a week and in most cases for a day. This means an > attacker need to try different guessed values in a week (2^24) for the > inputs of SHA256 hash function. Based on the *real-world* implementations, they change the IID every time they reconnect to the network. Which is, let me repeat, the *real-world* "large scale privacy problem" is solved today with *existing* code. If you like, you can even see the demo for that - just ask someone with an iPhone on an IPv6 network to flip the airplane mode and back. Seriously, I think the best way forward is to rewrite the problem statement in a more conscise way so we can better argue about what problem is being solved. --a > > Thanks, > Best, > Hosnieh > > From internet-drafts@ietf.org Tue Aug 13 12:41:21 2013 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 EAC0E11E81CF; Tue, 13 Aug 2013 12:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVOTQWZsvKTS; Tue, 13 Aug 2013 12:41:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 439DE11E81C4; Tue, 13 Aug 2013 12:41:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 12:41:20 -0700 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, 13 Aug 2013 19:41:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Implications of Oversized IPv6 Header Chains Author(s) : Fernando Gont Vishwas Manral Ronald P. Bonica Filename : draft-ietf-6man-oversized-header-chain-04.txt Pages : 13 Date : 2013-08-13 Abstract: The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header-chain-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Tue Aug 13 13:13:50 2013 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 DBBF921E817F for ; Tue, 13 Aug 2013 13:13: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0OvkCkq5w0q for ; Tue, 13 Aug 2013 13:13:50 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC4221E8177 for ; Tue, 13 Aug 2013 13:13:47 -0700 (PDT) Received: from gomlefisk.homewrt.org (unknown [195.159.143.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id D9AE55F45; Tue, 13 Aug 2013 13:13:45 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Tue, 13 Aug 2013 22:13:43 +0200 Message-Id: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@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: Tue, 13 Aug 2013 20:13:51 -0000 All, This message starts the second two week 6MAN Working Group on advancing: Title : Implications of Oversized IPv6 Header Chains Author(s) : F. Gont, V. Manral, R. Bonica Filename : draft-ietf-6man-oversized-header-chain-04 Pages : 13 Date : 2013-08-13 = http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-04 = =20 as a Proposed Standard. 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 August 27, 2013. The chairs would like to solicit one or two people in the working group = to do a detailed review of the document. We would also encourage = volunteers to act as document shepherds. Please contact the chairs = directly. Regards, Bob Hinden & Ole Tr=F8an= From huitema@microsoft.com Tue Aug 13 13:31:16 2013 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 4752011E80A2 for ; Tue, 13 Aug 2013 13:31:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GheL+hiTJ34K for ; Tue, 13 Aug 2013 13:31:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id F039221F943C for <6man@ietf.org>; Tue, 13 Aug 2013 13:31:09 -0700 (PDT) Received: from BLUPR03CA030.namprd03.prod.outlook.com (10.141.30.23) by BLUPR03MB004.namprd03.prod.outlook.com (10.255.208.38) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 13 Aug 2013 19:45:56 +0000 Received: from BY2FFO11FD023.protection.gbl (2a01:111:f400:7c0c::26) by BLUPR03CA030.outlook.office365.com (2a01:111:e400:879::23) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Tue, 13 Aug 2013 19:45:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Tue, 13 Aug 2013 19:45:56 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.86]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Tue, 13 Aug 2013 19:44:39 +0000 From: Christian Huitema To: james woodyatt , Fernando Gont Subject: RE: draft-ietf-6man-stable-privacy-addresses: Document title Thread-Topic: draft-ietf-6man-stable-privacy-addresses: Document title Thread-Index: AQHOlUzCXFxkwKyo9kyRUpPT185NkZmSSJsAgAFHiZA= Date: Tue, 13 Aug 2013 19:44:38 +0000 Message-ID: References: <52056638.3010904@si6networks.com> <6A63F27E-77B8-450C-8FC0-D294D2445947@apple.com> In-Reply-To: <6A63F27E-77B8-450C-8FC0-D294D2445947@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(189002)(199002)(16406001)(69226001)(74876001)(561944002)(79102001)(63696002)(50986001)(20776003)(47776003)(47736001)(49866001)(81542001)(4396001)(81342001)(31966008)(47446002)(74662001)(74502001)(76482001)(54316002)(80976001)(56776001)(54356001)(53806001)(74706001)(56816003)(77096001)(46406003)(50466002)(66066001)(80022001)(65816001)(55846006)(77982001)(59766001)(74366001)(51856001)(6806004)(23726002)(47976001)(46102001)(83072001)(76796001)(44976005)(33656001)(76786001)(83322001)(81686001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB004; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0937FB07C5 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BY2FFO11FD023.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB004.namprd03.prod.outlook.com Cc: "6man@ietf.org" <6man@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, 13 Aug 2013 20:31:16 -0000 > Long Title: "Stateless Automatic IPv6 Address Configuration (SLAAC) with = Stable and Semantically Opaque Interface Identifiers" > > Short Title: "SLAAC with Stable and Opaque IIDs" > > I propose to use the word "opaque" here because the pseudo-random number = generator is an implementation detail. The objective is to remove the=20 > semantic content of the EUI-64 formatted MAC address from all the IP addr= esses that a host needs to use. The privacy consideration is only one of=20 > several goals that achieving that objective is meant to address. Another= goal is to reduce the likelihood of IID collision. I like this proposal: "SLAAC with Stable and Opaque IIDs" -- Christian Huitema From brian.e.carpenter@gmail.com Tue Aug 13 13:51:14 2013 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 DF2B511E8171 for ; Tue, 13 Aug 2013 13:51:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7gV7n2LDz5g for ; Tue, 13 Aug 2013 13:51:13 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E490411E814F for ; Tue, 13 Aug 2013 13:51:11 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so9394641pad.37 for ; Tue, 13 Aug 2013 13:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CWOBm286qFyMLPbuNYKZ1FHhYMl7VRMrlxu5ibX44JE=; b=GxCXXTAF/prTVaosWa3nbxqB13bTH0sIRpci2NBj1OtyRq55TH4cKFAdux452G4rEJ bjNC4S3n3lHZgleGCXt3KL7Ckfa1EUqhm5E5HeuSIilAh58gM8sopK2tCLAft/MhVzgE AFxIk6vwqnbREQx+PpaBn52szzx/Whc3LyWFTAvRNIzk60c4U7nnKSf8KQ/TRRWqgrW8 Tm/kN8nm9a3nrpwyBWQk05pAr/Ge9zZnVQHmZD2pBa5VsvWx3G8LXT4SsfkGb9LOaIgF tdw2TTHp/KiNVtBlcB/JtIA2/JLXeF+zQ5M6mZCw/wYtvjrCYmEOkXEzQJp0ayTMj7YW YlOw== X-Received: by 10.68.232.225 with SMTP id tr1mr6185656pbc.143.1376427071603; Tue, 13 Aug 2013 13:51:11 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id yo2sm7399054pab.8.2013.08.13.13.51.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 13:51:10 -0700 (PDT) Message-ID: <520A9C41.6090709@gmail.com> Date: Wed, 14 Aug 2013 08:51:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt References: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> In-Reply-To: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 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, 13 Aug 2013 20:51:14 -0000 > Currently, six extension header types are defined. [RFC2460] Not true. Please see Section 4 of draft-ietf-6man-ext-transmit for a complete list including references. I make it eleven, if you include experimental values, without counting "No Next Header". Regards Brian From rbonica@juniper.net Tue Aug 13 14:01:41 2013 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 4BBC821E8167 for ; Tue, 13 Aug 2013 14:01:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhmqDajJ40jx for ; Tue, 13 Aug 2013 14:01:25 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id B466621E80C3 for ; Tue, 13 Aug 2013 14:01:19 -0700 (PDT) Received: from mail158-db8-R.bigfish.com (10.174.8.251) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 21:01:18 +0000 Received: from mail158-db8 (localhost [127.0.0.1]) by mail158-db8-R.bigfish.com (Postfix) with ESMTP id 9B551200232; Tue, 13 Aug 2013 21:01:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail158-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(199002)(377454003)(13464003)(56816003)(77096001)(74366001)(47446002)(74502001)(76786001)(76576001)(76796001)(83072001)(31966008)(74662001)(19580405001)(19580385001)(83322001)(19580395003)(54316002)(76482001)(33646001)(59766001)(77982001)(56776001)(81342001)(46102001)(81542001)(66066001)(74316001)(80022001)(65816001)(63696002)(53806001)(54356001)(74706001)(69226001)(74876001)(51856001)(79102001)(50986001)(47976001)(4396001)(47736001)(16406001)(49866001)(81686001)(80976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB241; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail158-db8 (localhost.localdomain [127.0.0.1]) by mail158-db8 (MessageSwitch) id 1376427676541471_1940; Tue, 13 Aug 2013 21:01:16 +0000 (UTC) Received: from DB8EHSMHS028.bigfish.com (unknown [10.174.8.228]) by mail158-db8.bigfish.com (Postfix) with ESMTP id 770C13E0031; Tue, 13 Aug 2013 21:01:16 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS028.bigfish.com (10.174.4.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 21:01:13 +0000 Received: from BL2PR05MB241.namprd05.prod.outlook.com (10.242.198.139) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 13 Aug 2013 21:01:09 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB241.namprd05.prod.outlook.com (10.242.198.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 21:01:07 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 21:01:07 +0000 From: Ronald Bonica To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt Thread-Topic: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt Thread-Index: AQHOmF1L99eMJ/+sLkuzvpcIgvf7wpmTnPaAgAAB7+A= Date: Tue, 13 Aug 2013 21:01:06 +0000 Message-ID: <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> References: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> <520A9C41.6090709@gmail.com> In-Reply-To: <520A9C41.6090709@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0937FB07C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 13 Aug 2013 21:01:41 -0000 Brian, Good point. I will add MIPv6, Shim6 and 2 for experimental use in the next = version. But is "No Next Header" really a header? For the purposes of this document,= I don't think that it is. Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Tuesday, August 13, 2013 4:51 PM > To: ipv6@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt >=20 > > Currently, six extension header types are defined. [RFC2460] >=20 > Not true. Please see Section 4 of draft-ietf-6man-ext-transmit for a > complete list including references. I make it eleven, if you include > experimental values, without counting "No Next Header". >=20 > Regards >=20 > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From brian.e.carpenter@gmail.com Tue Aug 13 14:08:54 2013 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 5FEDD21E8183 for ; Tue, 13 Aug 2013 14:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM5hFjPmxBcJ for ; Tue, 13 Aug 2013 14:08:54 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id A988D21F90DC for ; Tue, 13 Aug 2013 14:08:52 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so5441674pdj.21 for ; Tue, 13 Aug 2013 14:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EjMxEjATy1gU9nvPxJuhVgP0++huMUAjq+DpCGz2Lfc=; b=a4YMDz2clqp2FrjtqxDt3qOYUNdQ2fgjZWuVN+/wttWU0EGpzhsdfRVv1TMB6IoPZP Xu8C/7kt/un3E9z8OJcNQgUxPsrWOkfYCTnK5Q9b8I+qF8jTmgZPVSNYmMF9Y4HM56JU Lf2/X4vliBRucoRgp/+z3ywyWDJgEjwn6tn7tvV+rFjGkQ1mUos35nA4qdLkx0y4QFgR jx9bCQ3O3o/eA97DRSds0GidrhCNYnAi2ffHNLhgRS0fsLJqpPaeeZs2b3nrTl5ADuBE hyDj0ewTaCcjBwp0v2RDG6LRovtpLLlww0ZYLQFT2voL6HF87Lk7wgxN8NbZHTY8qjwK kcrw== X-Received: by 10.68.242.105 with SMTP id wp9mr6356073pbc.153.1376428131952; Tue, 13 Aug 2013 14:08:51 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id xl3sm45972398pbb.17.2013.08.13.14.08.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 14:08:51 -0700 (PDT) Message-ID: <520AA066.60506@gmail.com> Date: Wed, 14 Aug 2013 09:08:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt References: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> <520A9C41.6090709@gmail.com> <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 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, 13 Aug 2013 21:08:57 -0000 On 14/08/2013 09:01, Ronald Bonica wrote: > Brian, > > Good point. I will add MIPv6, Shim6 and 2 for experimental use in the next version. And HIP. > But is "No Next Header" really a header? For the purposes of this document, I don't think that it is. I agree (and that is why I took it out of the list in ext-transmit. Brian > Ron > > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Brian E Carpenter >> Sent: Tuesday, August 13, 2013 4:51 PM >> To: ipv6@ietf.org >> Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt >> >>> Currently, six extension header types are defined. [RFC2460] >> Not true. Please see Section 4 of draft-ietf-6man-ext-transmit for a >> complete list including references. I make it eleven, if you include >> experimental values, without counting "No Next Header". >> >> Regards >> >> Brian >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > From fgont@si6networks.com Tue Aug 13 14:29:14 2013 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 455D921E8188 for ; Tue, 13 Aug 2013 14:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA4gORB0PE4Y for ; Tue, 13 Aug 2013 14:29:05 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8016221E8187 for <6man@ietf.org>; Tue, 13 Aug 2013 14:29:02 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V9M97-0006tG-9k; Tue, 13 Aug 2013 23:28:53 +0200 Message-ID: <520AA510.8050409@si6networks.com> Date: Tue, 13 Aug 2013 18:28:48 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: Detailed review of draft-ietf-6man-ext-transmit-02 X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-ext-transmit@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: Tue, 13 Aug 2013 21:29:15 -0000 Folks, I've volunteered to provide a detailed review of this document, in response to the 6man wg chairs' request. Overall, I believe that this is a very useful document, and I support its publication as an RFC. However, I think it would be great if the technical comments below could be addressed before we ship it. *** Technical **** * Section 1: > Thus, new extension headers > could be introduced progressively, used only by hosts that have been > updated to create and interpret them. You should probably reference RFC6564 here. I believe it's an important piece that enables progressive introduction of new extension headers. * Section 1: > Unfortunately, experience has showed that as a result, > the network is not transparent to IPv6 extension headers. I'd probably rephrase this sentence. A firewall's goal is, for instance, to police packets. So that lack of "transparency" is actually a goal they have (whether we like it or not). * Section 1: > Unfortunately, because not all > IPv6 extension headers follow a uniform TLV format, this process is > clumsy and requires knowledge of each extension header's format. You should probably note that the upper-layer header might not even be there, and reference draft-ietf-6man-oversized-header-chain. * Section 1: > If they encounter an unrecognised extension header type, some > firewalls treat the packet as suspect and drop it. Unfortunately, it > is an established fact that several widely used firewalls do not > recognise some or all of the extension headers standardised since RFC > 2460. Is it that they don't recognize them? Or is it rather that they default to "drop packets with extension headers"? Or maybe that they are sloppy enough that they consider whatever follows the IPv6 header to be the "upper-layer header" (and hence a "pass tcp" wouldn't work as expected if the packet contains an extension header). * Section 1: > This applies in particular to firewalls > that attempt to inspect packets statelessly at very high speed, since > they cannot take the time to reassemble fragmented packets, > especially when under a denial of service attack. This would be a form of stateful inspection rather than stateless: a stateless firewall wouldn't try to reassemble a packet, since that requires state. * Section 1: > This will alleviate concerns > that stateless firewalls cannot handle a complete header chain as > required by the present document. The problem for stateless firewalls is two-fold: 1) Being able to find the upper-layer information -- this is addressed by draft-ietf-6man-oversized-header-chain 2) Being able to process the header chain with decent performance -- this one still needs to be addressed. * Section 2.1: > > Any forwarding node along an IPv6 packet's path, which forwards the > packet for any reason, SHOULD do so regardless of any extension > headers that are present, as required by RFC 2460. I find this particular requirement a bit troublesome. Truth is that many devices violate this requirement, and will always will. OTOH, the rest of the document is perfectly fine in this respect -- it acknowledges that some devices will look at the extension headers, and provides advice on what to do (e.g., "you should have an explicit policy regarding what to do with extension headers"). I guess I could live with a SHOULD (at least, it's not a "MUST") -- however, in the light of reality, I'd probably relax this requirement. * Section 2.1: > > The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD > NOT be used. However, as specified in [RFC5095], this does not mean > that the IPv6 Routing Header can be unconditionally dropped by > forwarding nodes. I don't think you need the "SHOULD NOT" above - RFC5095 should be taking are of that. As an aside, and in the light of e.g. bringing HBH to the real world, I think that requiring nodes to inspect the contents of RHT0 is unrealistic. I would align this with the processing of HBH extension headers. And in doing so, this document should update RFC5095. * Section 4: > > This list excludes both type 59, No Next Header, [RFC2460], which is > not an extension header as such, and type 139, HIP, [RFC5201], which > is experimental. If RFC5201 specifies an extension header, why shouldn't it be listed in the registry? (Disclaimer: I haven't even looked at RFC5201... so I might be missing something). **** Nits **** * Section 1: > It has also been observed that certain firewalls do not even > handle all the extension headers standardised in RFC 2460, including > the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental > problems of connectivity. I'd probably s/connectivity/interoperability/ * Section 1: > It cannot be widely deployed, because > existing middleboxes will render large parts of the Internet opaque > to it. I'm not sure this conveys the information that those packets will be dropped. Maybe rephrase? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Aug 13 14:31:38 2013 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 869C221E816E for ; Tue, 13 Aug 2013 14:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PctkYgd1BVhf for ; Tue, 13 Aug 2013 14:31:36 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 168C021F9EA3 for ; Tue, 13 Aug 2013 14:31:35 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V9MBi-00070W-41; Tue, 13 Aug 2013 23:31:34 +0200 Message-ID: <520AA5B2.6090809@si6networks.com> Date: Tue, 13 Aug 2013 18:31:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt References: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> <520A9C41.6090709@gmail.com> <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> X-Enigmail-Version: 1.4.6 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: Tue, 13 Aug 2013 21:31:38 -0000 On 08/13/2013 06:01 PM, Ronald Bonica wrote: > Brian, > > Good point. I will add MIPv6, Shim6 and 2 for experimental use in the next version. > > But is "No Next Header" really a header? For the purposes of this document, I don't think that it is. Why not just avoid counting, note that some "ext headers were specified in [RFC2460] and others in subsequent RFCs", and point to the corresponding (upcoming) IANA registry for ext headers? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rbonica@juniper.net Tue Aug 13 15:08:21 2013 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 F394411E813B for ; Tue, 13 Aug 2013 15:08:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lmX1kUgraCm for ; Tue, 13 Aug 2013 15:08:15 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE011E80E8 for ; Tue, 13 Aug 2013 15:08:15 -0700 (PDT) Received: from mail90-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE028.bigfish.com (10.243.66.91) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 22:08:15 +0000 Received: from mail90-co1 (localhost [127.0.0.1]) by mail90-co1-R.bigfish.com (Postfix) with ESMTP id D88892800E7; Tue, 13 Aug 2013 22:08:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail90-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(24454002)(199002)(189002)(377454003)(479174003)(13464003)(47446002)(56816003)(74366001)(74502001)(77096001)(76786001)(76576001)(77982001)(83072001)(76796001)(31966008)(74662001)(19580405001)(19580385001)(83322001)(81686001)(54316002)(76482001)(33646001)(59766001)(46102001)(81342001)(74316001)(80022001)(63696002)(81542001)(65816001)(19580395003)(53806001)(74706001)(69226001)(74876001)(51856001)(54356001)(47736001)(16406001)(49866001)(47976001)(50986001)(66066001)(56776001)(80976001)(79102001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail90-co1 (localhost.localdomain [127.0.0.1]) by mail90-co1 (MessageSwitch) id 1376431655228275_26474; Tue, 13 Aug 2013 22:07:35 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.244]) by mail90-co1.bigfish.com (Postfix) with ESMTP id 2F652180047; Tue, 13 Aug 2013 22:07:35 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 22:07:34 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 13 Aug 2013 22:07:34 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 22:07:33 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 22:07:33 +0000 From: Ronald Bonica To: Brian E Carpenter Subject: RE: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt Thread-Topic: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt Thread-Index: AQHOmF1L99eMJ/+sLkuzvpcIgvf7wpmTnPaAgAAB7+CAAAMCAIAAEFgQ Date: Tue, 13 Aug 2013 22:07:32 +0000 Message-ID: References: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> <520A9C41.6090709@gmail.com> <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> <520AA066.60506@gmail.com> In-Reply-To: <520AA066.60506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0937FB07C5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 13 Aug 2013 22:08:21 -0000 YWNrDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJw ZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNk YXksIEF1Z3VzdCAxMywgMjAxMyA1OjA5IFBNDQo+IFRvOiBSb25hbGQgQm9uaWNhDQo+IENjOiBp cHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4t b3ZlcnNpemVkLWhlYWRlci1jaGFpbi0wNC50eHQNCj4gDQo+IE9uIDE0LzA4LzIwMTMgMDk6MDEs IFJvbmFsZCBCb25pY2Egd3JvdGU6DQo+ID4gQnJpYW4sDQo+ID4NCj4gPiBHb29kIHBvaW50LiBJ IHdpbGwgYWRkIE1JUHY2LCBTaGltNiBhbmQgMiBmb3IgZXhwZXJpbWVudGFsIHVzZSBpbiB0aGUN Cj4gbmV4dCB2ZXJzaW9uLg0KPiANCj4gQW5kIEhJUC4NCj4gDQo+ID4gQnV0IGlzICJObyBOZXh0 IEhlYWRlciIgcmVhbGx5IGEgaGVhZGVyPyBGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMNCj4gZG9j dW1lbnQsIEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBpcy4NCj4gDQo+IEkgYWdyZWUgKGFuZCB0aGF0 IGlzIHdoeSBJIHRvb2sgaXQgb3V0IG9mIHRoZSBsaXN0IGluIGV4dC10cmFuc21pdC4NCj4gDQo+ ICAgIEJyaWFuDQo+IA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJvbg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gRnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXB2Ni1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYNCj4gPj4gT2YgQnJpYW4gRSBDYXJwZW50ZXINCj4gPj4gU2VudDog VHVlc2RheSwgQXVndXN0IDEzLCAyMDEzIDQ6NTEgUE0NCj4gPj4gVG86IGlwdjZAaWV0Zi5vcmcN Cj4gPj4gU3ViamVjdDogUmU6IEktRCBBY3Rpb246DQo+ID4+IGRyYWZ0LWlldGYtNm1hbi1vdmVy c2l6ZWQtaGVhZGVyLWNoYWluLTA0LnR4dA0KPiA+Pg0KPiA+Pj4gQ3VycmVudGx5LCBzaXggZXh0 ZW5zaW9uIGhlYWRlciB0eXBlcyBhcmUgZGVmaW5lZC4gW1JGQzI0NjBdDQo+ID4+IE5vdCB0cnVl LiBQbGVhc2Ugc2VlIFNlY3Rpb24gNCBvZiBkcmFmdC1pZXRmLTZtYW4tZXh0LXRyYW5zbWl0IGZv ciBhDQo+ID4+IGNvbXBsZXRlIGxpc3QgaW5jbHVkaW5nIHJlZmVyZW5jZXMuIEkgbWFrZSBpdCBl bGV2ZW4sIGlmIHlvdSBpbmNsdWRlDQo+ID4+IGV4cGVyaW1lbnRhbCB2YWx1ZXMsIHdpdGhvdXQg Y291bnRpbmcgIk5vIE5leHQgSGVhZGVyIi4NCj4gPj4NCj4gPj4gUmVnYXJkcw0KPiA+Pg0KPiA+ PiAgICAgIEJyaWFuDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IElFVEYgSVB2NiB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdA0KPiA+PiBpcHY2QGlldGYub3JnDQo+ID4+IEFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4g Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPg0KPiA+DQo+ID4NCj4gDQoNCg== From wwwrun@rfc-editor.org Tue Aug 13 15:17:39 2013 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 6E28521E8167; Tue, 13 Aug 2013 15:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.4 X-Spam-Level: X-Spam-Status: No, score=-100.4 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TTMTf+p1x82; Tue, 13 Aug 2013 15:17:38 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DED5821E8051; Tue, 13 Aug 2013 15:17:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AEA1AB1E003; Tue, 13 Aug 2013 15:13:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery From: rfc-editor@rfc-editor.org Message-Id: <20130813221321.AEA1AB1E003@rfc-editor.org> Date: Tue, 13 Aug 2013 15:13:21 -0700 (PDT) Cc: drafts-update-ref@iana.org, 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: Tue, 13 Aug 2013 22:17:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6980 Title: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Author: F. Gont Status: Standards Track Stream: IETF Date: August 2013 Mailbox: fgont@si6networks.com Pages: 10 Characters: 20850 Updates: RFC 3971, RFC 4861 I-D Tag: draft-ietf-6man-nd-extension-headers-05.txt URL: http://www.rfc-editor.org/rfc/rfc6980.txt This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. 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/search/rfc_search.php 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 rbonica@juniper.net Tue Aug 13 15:31:11 2013 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 8C18921E816E for ; Tue, 13 Aug 2013 15:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftzUn5D-B6+x for ; Tue, 13 Aug 2013 15:31:05 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id DE71A21F8FF8 for ; Tue, 13 Aug 2013 15:31:04 -0700 (PDT) Received: from mail42-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 22:31:03 +0000 Received: from mail42-am1 (localhost [127.0.0.1]) by mail42-am1-R.bigfish.com (Postfix) with ESMTP id C80F36009A; Tue, 13 Aug 2013 22:31:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI62a3I98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail42-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(252514010)(199002)(189002)(24454002)(479174003)(13464003)(377454003)(51704005)(80022001)(74316001)(81542001)(65816001)(63696002)(19580395003)(59766001)(81342001)(46102001)(56776001)(66066001)(4396001)(80976001)(79102001)(69226001)(54356001)(51856001)(74876001)(53806001)(74706001)(49866001)(16406001)(47736001)(50986001)(47976001)(77982001)(31966008)(83322001)(19580405001)(74662001)(83072001)(76796001)(76576001)(76786001)(56816003)(47446002)(77096001)(74502001)(74366001)(54316002)(33646001)(76482001)(81686001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail42-am1 (localhost.localdomain [127.0.0.1]) by mail42-am1 (MessageSwitch) id 1376433061940940_21736; Tue, 13 Aug 2013 22:31:01 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.234]) by mail42-am1.bigfish.com (Postfix) with ESMTP id D88B4440047; Tue, 13 Aug 2013 22:31:01 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 22:31:01 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 13 Aug 2013 22:30:45 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 22:30:45 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 22:30:44 +0000 From: Ronald Bonica To: Fernando Gont Subject: RE: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt Thread-Topic: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt Thread-Index: AQHOmF1L99eMJ/+sLkuzvpcIgvf7wpmTnPaAgAAB7+CAAAlTAIAADP6Q Date: Tue, 13 Aug 2013 22:30:44 +0000 Message-ID: <98e8db85d1ea4fe78e4b5047d91a4c92@BL2PR05MB243.namprd05.prod.outlook.com> References: <20130813194120.10078.48990.idtracker@ietfa.amsl.com> <520A9C41.6090709@gmail.com> <74133f80bf6c4fe5a6f29bf529d1d56c@BL2PR05MB243.namprd05.prod.outlook.com> <520AA5B2.6090809@si6networks.com> In-Reply-To: <520AA5B2.6090809@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0937FB07C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 13 Aug 2013 22:31:11 -0000 Or more specifically,=20 OLD>=20 Extension Header: Extension Headers are defined in Section 4 of [RFC2460]. Currently, six extension header types are defined. [RFC2460] defines the Hop-by-Hop, Routing, Fragment and Destination Options extension header types. [RFC4302] defines the Authentication Header (AH) type and [RFC4303] defines the Encapsulating Security Payload (ESP) header type. Extension Header: Extension Headers are defined in Section 4 of [RFC2460]. [IANA.ProtocolNumbers] provides a list of assigned Internet=20 Protocol Numbers and designates which of those protocol numbers also represent extension headers.=20 -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Tuesday, August 13, 2013 5:32 PM > To: Ronald Bonica > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt >=20 > On 08/13/2013 06:01 PM, Ronald Bonica wrote: > > Brian, > > > > Good point. I will add MIPv6, Shim6 and 2 for experimental use in the > next version. > > > > But is "No Next Header" really a header? For the purposes of this > document, I don't think that it is. >=20 > Why not just avoid counting, note that some "ext headers were specified > in [RFC2460] and others in subsequent RFCs", and point to the > corresponding (upcoming) IANA registry for ext headers? >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 >=20 From brian.e.carpenter@gmail.com Tue Aug 13 21:29:11 2013 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 E383921F9A27 for ; Tue, 13 Aug 2013 21:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMjpcgZW7iih for ; Tue, 13 Aug 2013 21:29:11 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EF56C21F826B for <6man@ietf.org>; Tue, 13 Aug 2013 21:29:10 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so6891178pac.31 for <6man@ietf.org>; Tue, 13 Aug 2013 21:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AIFiSpWmiz/1kYd+rOKgXMEwSqfGu9ez4t74ppi/e3M=; b=h8A9LDrWvJRH2L+CrWjhgGbuSr+lPvbQ2yNM3n3cLCXUbr6IBtFgQ8g8iT3GpEzPV+ QHbFwspZEH6kX3aa45grivKVERNrftCgQ7IQ1aCHUqsj3FY/LF6DxN+qdytnYP3mWHvw NVeBsyaY5Tsg5c1xU26HxYxwzAfVmEEuRiJuYwkz8dxN3J44MhOhwjKFiYtRCB69bh8K Zxwdcqh7uoEW6iXajf0cIwb3EbUvtdaXUl8/aGuNwkOYnUVh1p1ZX+eNoIaFphPhc+DL cfaM2GB3uJkuy8ljv6q8iH+xbLwypout6EF3YNEkVcD3CDwE2FK8h+KBRsgegDvfiefZ vI6A== X-Received: by 10.68.131.3 with SMTP id oi3mr7888957pbb.35.1376454549550; Tue, 13 Aug 2013 21:29:09 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id ot4sm50487662pac.17.2013.08.13.21.29.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 21:29:08 -0700 (PDT) Message-ID: <520B0794.3010003@gmail.com> Date: Wed, 14 Aug 2013 16:29:08 +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: Detailed review of draft-ietf-6man-ext-transmit-02 References: <520AA510.8050409@si6networks.com> In-Reply-To: <520AA510.8050409@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-ext-transmit@tools.ietf.org, "6man@ietf.org" <6man@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, 14 Aug 2013 04:29:12 -0000 Fernando, Thanks for the careful review. Most of your comments lead to fairly obvious fixes, which we'll apply in the next version. Just a few points below which may need discussion: On 14/08/2013 09:28, Fernando Gont wrote: ... > * Section 1: >> Unfortunately, experience has showed that as a result, >> the network is not transparent to IPv6 extension headers. > > I'd probably rephrase this sentence. A firewall's goal is, for instance, > to police packets. So that lack of "transparency" is actually a goal > they have (whether we like it or not). True, but it's unfortunate from the point of view of the design of IPv6. Speaking for myself only, I think the sentence is accurate - see the next point. ... > * Section 2.1: >> Any forwarding node along an IPv6 packet's path, which forwards the >> packet for any reason, SHOULD do so regardless of any extension >> headers that are present, as required by RFC 2460. > > I find this particular requirement a bit troublesome. Truth is that many > devices violate this requirement, and will always will. Yes, but the IPv6 design really does require this. I think the SHOULD is right, because RFC 2119 says that it means "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." That is a perfectly reasonable choice for the person managing a firewall to make, but it doesn't change the IPv6 design assumption. > > OTOH, the rest of the document is perfectly fine in this respect -- it > acknowledges that some devices will look at the extension headers, and > provides advice on what to do (e.g., "you should have an explicit policy > regarding what to do with extension headers"). > > I guess I could live with a SHOULD (at least, it's not a "MUST") -- > however, in the light of reality, I'd probably relax this requirement. ... > * Section 4: >> This list excludes both type 59, No Next Header, [RFC2460], which is >> not an extension header as such, and type 139, HIP, [RFC5201], which >> is experimental. > > If RFC5201 specifies an extension header, why shouldn't it be listed in > the registry? (Disclaimer: I haven't even looked at RFC5201... so I > might be missing something). This is a bit tricky. If HIP was a standards-track protocol it would be easy, but since it's experimental, it really doesn't seem realistic to hint that firewalls should allow it by default. Maybe we should change the IANA registry to include the experimental ones, but with a special tag? (Extension headers 253 and 254 are also tricky, because they are experimental values defined by a standards track RFC. Go figure!) Brian From stephen.nadas@ericsson.com Tue Aug 13 15:28:19 2013 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 D09F411E80D2; Tue, 13 Aug 2013 15:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIe4-Kv+ZyJZ; Tue, 13 Aug 2013 15:28:11 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8228621E816E; Tue, 13 Aug 2013 15:28:08 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-81-520ab2f716b9 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 13.E5.31362.7F2BA025; Wed, 14 Aug 2013 00:28:07 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 13 Aug 2013 18:28:06 -0400 From: Stephen Nadas To: "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" , "ietf@ietf.org" Subject: RE: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Thread-Topic: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Thread-Index: AQHOmHMLv+csr4kx2UygNsGxX3IOGpmTt9wF Date: Tue, 13 Aug 2013 22:28:05 +0000 Message-ID: <0BDF8C6F58AEFA45A013C71E4ADEB4AF02F2046A@eusaamb101.ericsson.se> References: <20130813221321.AEA1AB1E003@rfc-editor.org> In-Reply-To: <20130813221321.AEA1AB1E003@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0BDF8C6F58AEFA45A013C71E4ADEB4AF02F2046Aeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPlO73TVxBBvc61Sxu/Whkt7h3Zjqb xbON81ksXp59z2SxYuJRNoum/V/ZHNg8euQ9liz5yeTR0HaMNYA5issmJTUnsyy1SN8ugStj /rmb7AW9jhXnWm8yNjC2WnQxcnJICJhI9K/qZIewxSQu3FvP1sXIxSEkcJRRov/iZ2YIZzmj xJHuG4wgVWwCBhL/e5awgNgiAv2MEn03uEGKmAVmMkrM+/6QDSQhLJAs8W33KkaIohSJjUcO QjUYSSzr2c4EYrMIqEr0Hp3EDGLzCvhKbL99GcwWEjCXOLXlJFgvp4CFxJfDG1lBbEag876f WgPWyywgLnHryXwmiLMFJJbsOc8MYYtKvHz8jxWiJl9i/62PjBDzBSVOznzCMoFRZBaS9llI ymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsYOUqLU8ty040MNzEC4+2YBJvj DsYFnywPMUpzsCiJ827QOxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHpbPfz0cfDqw4e 0j4icf7L7qoAjw3brlwVXzMnVCFu57SjbWGXXryLZmVgq1Jdcm7Cd8+Lt3Jlleoufq/L4T9f aBT9b/O7aZfjratKNRcJvSzj/MSqezXu9tFmwWvmYRP38Z/i47pUa/r4wJqCjHVKsQZrTpvc XmBzw8Z4h/mnCQ63uwPPKf1VYinOSDTUYi4qTgQA9jWvgoUCAAA= X-Mailman-Approved-At: Tue, 13 Aug 2013 23:26:46 -0700 Cc: "drafts-update-ref@iana.org" , "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: Tue, 13 Aug 2013 22:28:19 -0000 --_000_0BDF8C6F58AEFA45A013C71E4ADEB4AF02F2046Aeusaamb101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok. I assume this should be for FT? Or just something to get started? Steve -----Original Message----- From: rfc-editor@rfc-editor.org [rfc-editor@rfc-editor.org] Received: Tuesday, 13 Aug 2013, 18:18 To: ietf-announce@ietf.org [ietf-announce@ietf.org]; rfc-dist@rfc-editor.or= g [rfc-dist@rfc-editor.org] CC: drafts-update-ref@iana.org [drafts-update-ref@iana.org]; ipv6@ietf.org = [ipv6@ietf.org]; rfc-editor@rfc-editor.org [rfc-editor@rfc-editor.org] Subject: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 = Neighbor Discovery A new Request for Comments is now available in online RFC libraries. RFC 6980 Title: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Author: F. Gont Status: Standards Track Stream: IETF Date: August 2013 Mailbox: fgont@si6networks.com Pages: 10 Characters: 20850 Updates: RFC 3971, RFC 4861 I-D Tag: draft-ietf-6man-nd-extension-headers-05.txt URL: http://www.rfc-editor.org/rfc/rfc6980.txt This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated. This document is a product of the IPv6 Maintenance Working Group of the IET= F. This is now a Proposed Standard. 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/search/rfc_sear= ch.php 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 --_000_0BDF8C6F58AEFA45A013C71E4ADEB4AF02F2046Aeusaamb101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ok. I assume this should be for FT? Or just something to g= et started?
Steve

-----Original Message-----
From: rfc-editor@rfc-editor.org [rfc-editor@rfc-editor.org]
Received: Tuesday, 13 Aug 2013, 18:18
To: ietf-announce@ietf.org [ietf-announce@ietf.org]; rfc-dist@rfc-ed= itor.org [rfc-dist@rfc-editor.org]
CC: drafts-update-ref@iana.org [drafts-update-ref@iana.org]; ipv6@ie= tf.org [ipv6@ietf.org]; rfc-editor@rfc-editor.org [rfc-editor@rfc-editor.or= g]
Subject: RFC 6980 on Security Implications of IPv6 Fragmentation wit= h IPv6 Neighbor Discovery

A new Request for Comments is now available in onl= ine RFC libraries.

       
        RFC 6980

        Title:    &n= bsp; Security Implications of IPv6 Fragmentation
            &nb= sp;       with IPv6 Neighbor Discovery
        Author:     = F. Gont
        Status:     = Standards Track
        Stream:     = IETF
        Date:    &nb= sp;  August 2013
        Mailbox:    fgont= @si6networks.com
        Pages:    &n= bsp; 10
        Characters: 20850
        Updates:    RFC 3= 971, RFC 4861

        I-D Tag:    draft= -ietf-6man-nd-extension-headers-05.txt

        URL:    &nbs= p;   http:/= /www.rfc-editor.org/rfc/rfc6980.txt

This document analyzes the security implications of employing IPv6
fragmentation with Neighbor Discovery (ND) messages.  It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in
all Neighbor Discovery messages, thus allowing for simple and
effective countermeasures for Neighbor Discovery attacks.  Finally, it discusses the security implications of using IPv6 fragmentation
with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971
to provide advice regarding how the aforementioned security
implications can be mitigated.

This document is a product of the IPv6 Maintenance Working Group of the IET= F.

This is now a Proposed Standard.

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/search/rfc_search.php
For downloading RFCs, see ht= tp://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.  Unles= s
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC
 --_000_0BDF8C6F58AEFA45A013C71E4ADEB4AF02F2046Aeusaamb101erics_-- From fgont@si6networks.com Wed Aug 14 00:43:49 2013 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 4627411E812B for ; Wed, 14 Aug 2013 00:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHTLvOoRhKbz for ; Wed, 14 Aug 2013 00:43:48 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0314011E8107 for <6man@ietf.org>; Wed, 14 Aug 2013 00:43:48 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V9Vk7-0006G3-R6; Wed, 14 Aug 2013 09:43:44 +0200 Message-ID: <520B3529.80802@si6networks.com> Date: Wed, 14 Aug 2013 04:43:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: Detailed review of Significance of IPv6 Interface Identifiers X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-ext-transmit@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: Wed, 14 Aug 2013 07:43:49 -0000 Folks, I've volunteered to provide a detailed review of this document, in response to the 6man wg chairs' request. Overall, I believe that this is a very useful document, and I support its publication as an RFC. However, I think it would be great if the technical comments below could be addressed before we ship it. **** Technical ***** * Abstract: > This document clarifies that those bits apply only to interface > identifiers that are derived from an IEEE link-layer address. It > updates RFC 4291 accordingly. This para seems confusing. -- not sure what "those bits only apply means" - for instance, given an address, it's not really possible to tell how the address was generated. That aside, the text would read better as "link-layer address, and updates RFC 4291 accordingly". * Section 1: > IPv6 unicast addresses consist of a subnet prefix followed by an > Interface Identifier (IID), the latter supposedly unique on the > links reached by routing to that prefix. The Addressing Architecture refers to Global Routing Prefix (GRP) and subnet ID -- so I'd probably tweak the text accordingly. Besides, the latter part of the sentence is a bit confusing -- why not just say that the IID, when combined with the GRP and subnet ID is supposed to result in a unique address? * Section 1: > > In an IID, this bit is in position 6, i.e., position 70 in the > complete IPv6 address. and: > In an IID, this bit is in position 7, i.e., position 71 in the > complete IPv6 address. Since you're referring to position numbers rather than bits.. do you start with position 0 or one? from left or right? (yes, {you, we} know that... the reader might not) * Section 2: > These cases illustrate that the statement quoted above from RFC 4291 > requiring "Modified EUI-64 format" is rather meaningless when > applied to forms of IID that are not in fact based on an underlying > EUI-64 address. I'm not sure I'd say "meaningless" -- i.e., all the cited examples implicitly follow RFC4291's assertion that e.g. an operator wouldn't set the u/g bits by mistake (because low-byte IIDs are typically used). I do agree, of course, that bothering everyone else according to *one* possible underlying link-layer technology doesn't make much sense. And of course in those cases such bits will have no significance. * Section 2: > > However, this has not so far proved to be the case. Also, there is > evidence from the field that IEEE MAC addresses with universal scope > are sometime incorrectly assigned to multiple MAC interfaces. I recall some folk mentioned that, from an IEEE std point of view, this is not incorrect. -- Just me relaying some comment (on v6ops?).. I don't recall of the top of my head of what the relevant IEEE std says. You might want to reference this presentation, which comments on duplicate MAC addresses: [HDMoore] HD Moore, "The Wild West", Louisville, Kentucky, U.S.A. September 25-29, 2012, . * Section 3: > To the extent that each method of IID creation specifies the values > of the "u" and "g" bits, and that each new method is carefully > designed in the light of its predecessors, these bits tend to reduce > the chances of duplicate IIDs. Not sure what you mean. Do you mean that *if* each IID-generation method were to use a different combination of "ug", colisions between them would be avoided? If so, I'd argue that since there's no coordination of which combinations should be used for which method, that's unfeasible. For instance, traditional SLAAC uses all combinations (modulo "illegal/unused" combinations of ug). * Section 4: > > As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is > able to detect any case where a collision of two IIDs on the same > link leads to a duplicated IPv6 address. The scope of DAD may be > extended to a set of links by a DAD proxy [RFC6957] or by Neighbor > Discovery Optimization [RFC6775]. Since DAD is mandatory for all > nodes, there will be no case in which an IID collision, however > unlikely it may be, is not detected. I have not experienced it myself, but I wouldn't be surprised if DAD were to fail on a wireless network. So I'd probably wouldn't say "there will be no case" (i.e., relax the text a bit). * Section 4: > It is out of scope of most existing specifications to define the > recovery action after a DAD failure, which is an implementation > issue. Me, I think that there's a gap in the specs in this respect. They specify an algorithm to follow, and algorithm to detect collisions, but no algorithm to recover (and, obviously, you cannot recover by reusing the same algorithm that led to the collision). Note: I don't expect changes in response to this comment (text is fine) -- just me thinking out loud. * Section 5: > The EUI-64 to IID transformation defined in the IPv6 addressing > architecture [RFC4291] MUST be used for all cases where an IPv6 IID > is derived from an IEEE MAC or EUI-64 address. With any other form > of link layer address, an equivalent transformation SHOULD be used. I'd remove this paragraph altogether. Here's my rationale: 1) You're just clarifying the u/g bits. *Which* method is used for generating addresses with SLAAC is kind of out of the scpe of this document. 2) If we end up deprecating IEE-MAC-based addresses (and it looks like we're heading there), this document will have to be updated, too. * Security Considerations: Since this document allows address generation methods to use the ug bits in any way they want, that allows for extra entropy when IIDs are generated in such a way that they are unpredictable (e.g., as in draft-ietf-6man-stable-privacy-addresses). Besides, and while *this* document does *not* introduce any new issues, you should probably briefly comment on the implications of EUI-64 based IIDs. Alissa's document and/or draft-ietf-opsec-ipv6-host-scanning and/or draft-ietf-6man-stable-privacy-addresses might be good references to include along with whatever text you craft on the subject. * Last, but not least.... Should we do anything about RFC2526? -- It currently requires specific semantics for u/g... but without any explicit motivation for doing so. **** Editorial **** * Abstract: > This document clarifies that the bits in an interface identifier have > no generic meaning and that the identifier should be treated as an > opaque value. Shouldn't this be "universal" rather than "generic"? * Section 5: > Specifications of other forms of 64-bit IID MUST specify how all 64 > bits are set, but need not treat the "u" and "g" bits in any special > way. A general semantic meaning for these bits MUST NOT be defined. > However, the method of generating IIDs for specific link types MAY > define some local significance for certain bits. > > In all cases, the bits in an IID have no general semantics; in other > words, they have opaque values. In fact, the whole IID value MUST be > viewed as an opaque bit string by third parties, except possibly in > the local context. Maybe "universal" is a better than "generic" and "general"? **** Nits **** * Section 1: > Thus the specification assumes that that the normal case is to > transform an Ethernet-style address into an IID, but in practice, > there are various methods of forming such an interface identifier. s/that that/that/ * Section 1 > Finally it updates RFC 4291 accordingly. Missing comma right after "Finally". * Section 2: > If not, the problem will be detected by duplicate address detection > [RFC4862], [RFC6775], but such an error can usually only be resolved > by human intervention. Please remove the comma between "[RFC4862]" and "[RFC6775]". * Section 2: > Additionally, the "u" and the "g" bits are both meaningless in the > format of an IPv6 multicast group ID [RFC3306], [RFC3307]. Please remove the comma between "[RFC3306]" and "[RFC3307]". Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Aug 14 00:59:38 2013 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 6D00621F9798 for ; Wed, 14 Aug 2013 00:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7gz2qcDUGh4 for ; Wed, 14 Aug 2013 00:59:37 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id AE80421F996A for <6man@ietf.org>; Wed, 14 Aug 2013 00:59:37 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V9VzU-0006bj-7s; Wed, 14 Aug 2013 09:59:36 +0200 Message-ID: <520B38E2.3090307@si6networks.com> Date: Wed, 14 Aug 2013 04:59:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Detailed review of draft-ietf-6man-ext-transmit-02 References: <520AA510.8050409@si6networks.com> <520B0794.3010003@gmail.com> In-Reply-To: <520B0794.3010003@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-ext-transmit@tools.ietf.org, "6man@ietf.org" <6man@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, 14 Aug 2013 07:59:38 -0000 Hi, Brian, On 08/14/2013 01:29 AM, Brian E Carpenter wrote: > > ... >> * Section 2.1: >>> Any forwarding node along an IPv6 packet's path, which forwards the >>> packet for any reason, SHOULD do so regardless of any extension >>> headers that are present, as required by RFC 2460. >> >> I find this particular requirement a bit troublesome. Truth is that many >> devices violate this requirement, and will always will. > > Yes, but the IPv6 design really does require this. That's my point: is that a sensible requirement? For instance, for the time being (Flow Label not used), there's no other way to identify flows than to break this reuirement. > I think the > SHOULD is right, because RFC 2119 says that it means "there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." That is > a perfectly reasonable choice for the person managing a firewall > to make, but it doesn't change the IPv6 design assumption. I have no issues with this. -- Although I'd note that this text gives the idea that processing the extesion header chain is more an exception than a rule. >> * Section 4: >>> This list excludes both type 59, No Next Header, [RFC2460], which is >>> not an extension header as such, and type 139, HIP, [RFC5201], which >>> is experimental. >> >> If RFC5201 specifies an extension header, why shouldn't it be listed in >> the registry? (Disclaimer: I haven't even looked at RFC5201... so I >> might be missing something). > > This is a bit tricky. If HIP was a standards-track protocol it would > be easy, but since it's experimental, it really doesn't seem realistic > to hint that firewalls should allow it by default. So the question here is: 1) Are we creating an IANA registry for Ext Headers or, 2) Are we creating a registry for ext headers that, by default, should be passed? If the former, HIP should be in. If the latter, it shouldn't. Besides, if we imply that HIP should be filtered but they use some specific "Next Header" value (as opposed to 253 or 254), then whatever value is currently used for the HIP ext header will be unusable on the public Internet even if the the document eventually becomes a Proposed Standard. > Maybe we should > change the IANA registry to include the experimental ones, but with > a special tag? (Extension headers 253 and 254 are also tricky, because > they are experimental values defined by a standards track RFC. Go figure!) I think we might be able to do both "1)" and "2)" above by adding a tag along the lines of "not expected in the public Internet"? (with the implication that "it's okay to filter"). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Wed Aug 14 12:29:33 2013 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 70B5121F9223 for ; Wed, 14 Aug 2013 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLc7QFt-oJR5 for ; Wed, 14 Aug 2013 12:29:32 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CC21F93E4 for <6man@ietf.org>; Wed, 14 Aug 2013 12:29:30 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so9667847pbc.31 for <6man@ietf.org>; Wed, 14 Aug 2013 12:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4LDtLhufw4YV0HFTT3XdCNcfnAukVnLh79bdAWMRi4A=; b=w0ot+OprvGKmwK/53qFA7Kdxb8JHypWzHlR0dTh/pPWCFqtrBJT7rZRaU+U+/V4Fkq KPjVlqOPn8FjjVtMIV8ubu17UUpKID3FTdgO5zBwzm5LPmq7+BvQngSGhjFserrkt6kF DcpFqlCPDkTTcScwboICAPJApkB2gkiOUc5cD07drwy+kstg06XmIcZEF9yyPhhRPq8t kQ52rZV3HvC7J2oNv2By/OMF+RwAFcoFVGk+iqN+aUrQCn+Xx1c91SWjumLwgfNwJOPF H3ZIBlEsj1d9mIXnB3hRdl1O0CqosPUjtVRT62qRrrRI5ScU+/YcO11eU2j/BBGmuts3 xmiA== X-Received: by 10.66.154.162 with SMTP id vp2mr11475577pab.126.1376508570272; Wed, 14 Aug 2013 12:29:30 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id ll5sm55144515pab.19.2013.08.14.12.29.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 12:29:29 -0700 (PDT) Message-ID: <520BDA9A.1030108@gmail.com> Date: Thu, 15 Aug 2013 07:29:30 +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: Detailed review of draft-ietf-6man-ext-transmit-02 References: <520AA510.8050409@si6networks.com> <520B0794.3010003@gmail.com> <520B38E2.3090307@si6networks.com> In-Reply-To: <520B38E2.3090307@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-ext-transmit@tools.ietf.org, "6man@ietf.org" <6man@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, 14 Aug 2013 19:29:33 -0000 On 14/08/2013 19:59, Fernando Gont wrote: > Hi, Brian, > > On 08/14/2013 01:29 AM, Brian E Carpenter wrote: >> ... >>> * Section 2.1: >>>> Any forwarding node along an IPv6 packet's path, which forwards the >>>> packet for any reason, SHOULD do so regardless of any extension >>>> headers that are present, as required by RFC 2460. >>> I find this particular requirement a bit troublesome. Truth is that many >>> devices violate this requirement, and will always will. >> Yes, but the IPv6 design really does require this. > > That's my point: is that a sensible requirement? For instance, for the > time being (Flow Label not used), there's no other way to identify flows > than to break this reuirement. Which is indeed why I worked hard to get RFC 6437 written. But changing this aspect of IPv6 design would be a *really* big discussion. > > >> I think the >> SHOULD is right, because RFC 2119 says that it means "there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course." That is >> a perfectly reasonable choice for the person managing a firewall >> to make, but it doesn't change the IPv6 design assumption. > > I have no issues with this. -- Although I'd note that this text gives > the idea that processing the extesion header chain is more an exception > than a rule. > > > >>> * Section 4: >>>> This list excludes both type 59, No Next Header, [RFC2460], which is >>>> not an extension header as such, and type 139, HIP, [RFC5201], which >>>> is experimental. >>> If RFC5201 specifies an extension header, why shouldn't it be listed in >>> the registry? (Disclaimer: I haven't even looked at RFC5201... so I >>> might be missing something). >> This is a bit tricky. If HIP was a standards-track protocol it would >> be easy, but since it's experimental, it really doesn't seem realistic >> to hint that firewalls should allow it by default. > > So the question here is: > 1) Are we creating an IANA registry for Ext Headers or, > 2) Are we creating a registry for ext headers that, by default, should > be passed? > > If the former, HIP should be in. If the latter, it shouldn't. > > Besides, if we imply that HIP should be filtered but they use some > specific "Next Header" value (as opposed to 253 or 254), then whatever > value is currently used for the HIP ext header will be unusable on the > public Internet even if the the document eventually becomes a Proposed > Standard. > > > >> Maybe we should >> change the IANA registry to include the experimental ones, but with >> a special tag? (Extension headers 253 and 254 are also tricky, because >> they are experimental values defined by a standards track RFC. Go figure!) > > I think we might be able to do both "1)" and "2)" above by adding a tag > along the lines of "not expected in the public Internet"? (with the > implication that "it's okay to filter"). Something like that, yes. We'll try some words in the next version. Brian > > > Cheers, From fgont@si6networks.com Wed Aug 14 13:09:03 2013 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 56BF821E80DD for ; Wed, 14 Aug 2013 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmOuEr8wWFl for ; Wed, 14 Aug 2013 13:08:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B433E21E808C for <6man@ietf.org>; Wed, 14 Aug 2013 13:08:53 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.156]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V9hN8-0006hh-6Y; Wed, 14 Aug 2013 22:08:46 +0200 Message-ID: <520BE3C8.10808@si6networks.com> Date: Wed, 14 Aug 2013 17:08:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Detailed review of draft-ietf-6man-ext-transmit-02 References: <520AA510.8050409@si6networks.com> <520B0794.3010003@gmail.com> <520B38E2.3090307@si6networks.com> <520BDA9A.1030108@gmail.com> In-Reply-To: <520BDA9A.1030108@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-ext-transmit@tools.ietf.org, "6man@ietf.org" <6man@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, 14 Aug 2013 20:09:03 -0000 Hi, Brian, On 08/14/2013 04:29 PM, Brian E Carpenter wrote: >>>> * Section 2.1: >>>>> Any forwarding node along an IPv6 packet's path, which forwards the >>>>> packet for any reason, SHOULD do so regardless of any extension >>>>> headers that are present, as required by RFC 2460. >>>> I find this particular requirement a bit troublesome. Truth is that many >>>> devices violate this requirement, and will always will. >>> Yes, but the IPv6 design really does require this. >> >> That's my point: is that a sensible requirement? For instance, for the >> time being (Flow Label not used), there's no other way to identify flows >> than to break this reuirement. > > Which is indeed why I worked hard to get RFC 6437 written. But changing > this aspect of IPv6 design would be a *really* big discussion. I'm fully in favor of RFC6437. My point is that host implementations still not use or o weird stuff with the Flow Label -- hence it's not dependable for anything. This means that in the short of near term there's no better option than following the IPv6 header chain (not that I like it but... that doesn't change the facts). >>> Maybe we should >>> change the IANA registry to include the experimental ones, but with >>> a special tag? (Extension headers 253 and 254 are also tricky, because >>> they are experimental values defined by a standards track RFC. Go figure!) >> >> I think we might be able to do both "1)" and "2)" above by adding a tag >> along the lines of "not expected in the public Internet"? (with the >> implication that "it's okay to filter"). > > Something like that, yes. We'll try some words in the next version. Great. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Wed Aug 14 14:27:45 2013 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 2444911E8198 for ; Wed, 14 Aug 2013 14:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDpPUo6QLPud for ; Wed, 14 Aug 2013 14:27:44 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2A11E8189 for <6man@ietf.org>; Wed, 14 Aug 2013 14:27:43 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id f4so14080513iea.9 for <6man@ietf.org>; Wed, 14 Aug 2013 14:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=odX7ZzLuDB3lqUaIAwz+DheXb1fGkk5FponwSK0sKT4=; b=nPzSQ84RGas7Eztzrj40x1/LJv9qsONBqkFseygeqZW6TLlgPWqZA4/Ctbml+AtIFP /2peXn3UFnBKo+wN8Lcf5sGxOya9Fb7QMTh8kRk4fu291nqPGgNr0VnwDbQZY40sOa+Z Yr9Uq2pUtBheAH05BrWEutt9zUhrRgKIVlV72z04UD0EWc9/7F22OaLhrqrcvbFBQcbl jbvGCsNnPgYXDPmZcYwtXQz5ECfFWEQbj6yJXv3J6kjaKCfb5WaiZU776xT+yHPxrnuv ecKb7kVQjC17b4pznlKy+FSAu2Za24lhFLRN9KcXb/oy2iJ8KSbH8AoFMXIzSi5tEEyu Dkjw== X-Received: by 10.50.60.2 with SMTP id d2mr7381199igr.52.1376515663509; Wed, 14 Aug 2013 14:27:43 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id ri10sm5645765igc.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 14:27:42 -0700 (PDT) Message-ID: <520BF653.8060603@gmail.com> Date: Thu, 15 Aug 2013 09:27:47 +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: Detailed review of Significance of IPv6 Interface Identifiers References: <520B3529.80802@si6networks.com> In-Reply-To: <520B3529.80802@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-ug@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: Wed, 14 Aug 2013 21:27:45 -0000 Hi Fernando, Thanks once again! We'll make corresponding updates in the next version. Just a few discussion points below: On 14/08/2013 19:43, Fernando Gont wrote: =2E.. > * Section 2: >> However, this has not so far proved to be the case. Also, there is=20 >> evidence from the field that IEEE MAC addresses with universal scope=20 >> are sometime incorrectly assigned to multiple MAC interfaces. >=20 > I recall some folk mentioned that, from an IEEE std point of view, this= > is not incorrect. -- Just me relaying some comment (on v6ops?).. I don'= t > recall of the top of my head of what the relevant IEEE std says. 802.1 section 9.2.2 makes it clear that the U bit is intended to make the address universally unique: "The method that an assignee uses to ensure that no two of its devices ca= rry the same address will, of course, depend on the assignment or manufacturing process, the nature of the orga= nization, and the organization=E2=80=99s philosophy. However, the users of networks worldwide expect to have uniqu= e addresses. The ultimate responsibility for assuring that user expectations and requirements are m= et, therefore, lies with the organization offering such devices." >=20 > You might want to reference this presentation, which comments on > duplicate MAC addresses: >=20 > [HDMoore] HD Moore, "The Wild West", Louisville, Kentucky, U.S.A. > September 25-29, 2012, > = =2E We have references to that and to http://enterpriseadmins.org/blog/scripting/virtual-machines-with-duplicat= e-mac-addresses commented out in the source file. In general the RFC Editor doesn't much = like conference or blog URLs because they tend to disappear. >=20 >=20 > * Section 3: >> To the extent that each method of IID creation specifies the values=20 >> of the "u" and "g" bits, and that each new method is carefully=20 >> designed in the light of its predecessors, these bits tend to reduce=20 >> the chances of duplicate IIDs. >=20 > Not sure what you mean. Do you mean that *if* each IID-generation metho= d > were to use a different combination of "ug", colisions between them > would be avoided? If so, I'd argue that since there's no coordination o= f > which combinations should be used for which method, that's unfeasible. > For instance, traditional SLAAC uses all combinations (modulo > "illegal/unused" combinations of ug). The argument is fuzzy and the sentence needs to be rewritten. (I would actually suggest that in a pseudo-random method, now that we are clear that the bits have no meaning, it would be best to use them to provide two more bits of entropy rather than giving them fixed values.) =2E.. > * Section 5: >> The EUI-64 to IID transformation defined in the IPv6 addressing=20 >> architecture [RFC4291] MUST be used for all cases where an IPv6 IID=20 >> is derived from an IEEE MAC or EUI-64 address. With any other form=20 >> of link layer address, an equivalent transformation SHOULD be used. >=20 > I'd remove this paragraph altogether. Here's my rationale: >=20 > 1) You're just clarifying the u/g bits. *Which* method is used for > generating addresses with SLAAC is kind of out of the scpe of this docu= ment. Well, I believe we have broadened the scope a bit. What this text is tryi= ng to do is clarify the wording in 4291, which really is written as if Modified EUI-64 is the *only* kind of IID. >=20 > 2) If we end up deprecating IEE-MAC-based addresses (and it looks like > we're heading there), this document will have to be updated, too. No, because it only applies when EUI-64 is used. If we drop EUI-64 completely (which would amaze me) the words would be irrelevant but not harmful. So personally I don't think we should change this. >=20 > * Security Considerations: >=20 > Since this document allows address generation methods to use the ug bit= s > in any way they want, that allows for extra entropy when IIDs are > generated in such a way that they are unpredictable (e.g., as in > draft-ietf-6man-stable-privacy-addresses). It's true (see above comment on fuzzy text). > Besides, and while *this* document does *not* introduce any new issues,= > you should probably briefly comment on the implications of EUI-64 based= > IIDs. Alissa's document and/or draft-ietf-opsec-ipv6-host-scanning > and/or draft-ietf-6man-stable-privacy-addresses might be good reference= s > to include along with whatever text you craft on the subject. Actually we decided that the whole privacy issue was orthogonal, partly because there are several drafts and having a bunch of "work in progress" references is quite annoying to the reader. How about just adding a general comment that the method of IID generation has privacy implications but they are considered out of scope for the document? >=20 > * Last, but not least.... > Should we do anything about RFC2526? -- It currently requires specific > semantics for u/g... but without any explicit motivation for doing so. That's also orthogonal IMHO. Separate thread? Thanks again, Brian From fred@cisco.com Wed Aug 14 15:56:21 2013 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 DB87021E80B6 for ; Wed, 14 Aug 2013 15:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCgIUQkYPz95 for ; Wed, 14 Aug 2013 15:56:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6F11E81BE for <6man@ietf.org>; Wed, 14 Aug 2013 15:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1348; q=dns/txt; s=iport; t=1376520976; x=1377730576; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ssdkH5+d+z4eLaAXVgLTzDdBKuiyDWroAg06p0gWUWY=; b=Es6+bfqZnPtKJygWxQHG0kDTNkv/UQfdqBD/xxuulR3EtfdBTN4Kpphe BQwDCsc9/GzCkV0uqTAvmZvRLIvpMEYhJtGRDLS6b2+7GXseCXZ1W9nWC el6/cHOe0RnGwE06f895N9o2PUEirFvAN5cvnDPOWled9m0wA2brnGtpk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABYKDFKtJV2d/2dsb2JhbABbgwaBBb8jgSAWdIIlAQEBAzo/EAIBCCIUECERJQIEDgUIh3YDD7A4DYhejVWCSAIxB4MbdwOVe44UhSeDG4Iq X-IronPort-AV: E=Sophos;i="4.89,880,1367971200"; d="scan'208";a="247267377" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 14 Aug 2013 22:56:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7EMuG82025717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 22:56:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 17:56:15 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Subject: Re: Detailed review of Significance of IPv6 Interface Identifiers Thread-Topic: Detailed review of Significance of IPv6 Interface Identifiers Thread-Index: AQHOmMIUTRP1UB+py0q//B44aVYR8JmVjIuAgAAYtAA= Date: Wed, 14 Aug 2013 22:56:14 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9979F5@xmb-rcd-x09.cisco.com> References: <520B3529.80802@si6networks.com> <520BF653.8060603@gmail.com> In-Reply-To: <520BF653.8060603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C43E13BD4716543952B37182B4724E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Fernando Gont , "6man@ietf.org" <6man@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, 14 Aug 2013 22:56:22 -0000 On Aug 14, 2013, at 2:27 PM, Brian E Carpenter wrote: >> * Section 3: >>> To the extent that each method of IID creation specifies the values=20 >>> of the "u" and "g" bits, and that each new method is carefully=20 >>> designed in the light of its predecessors, these bits tend to reduce=20 >>> the chances of duplicate IIDs. >>=20 >> Not sure what you mean. Do you mean that *if* each IID-generation method >> were to use a different combination of "ug", colisions between them >> would be avoided? If so, I'd argue that since there's no coordination of >> which combinations should be used for which method, that's unfeasible. >> For instance, traditional SLAAC uses all combinations (modulo >> "illegal/unused" combinations of ug). >=20 > The argument is fuzzy and the sentence needs to be rewritten. >=20 > (I would actually suggest that in a pseudo-random method, now that we > are clear that the bits have no meaning, it would be best to use them to > provide two more bits of entropy rather than giving them fixed values.) Good grief. If the bits don't mean anything - and they never did, since nob= ody ever interpreted them except in IETF dancing-on-heads-of-pins discussio= ns - could we simply say that they are as random in value as any of the oth= er bits in the IID are?= From brian.e.carpenter@gmail.com Wed Aug 14 20:32:02 2013 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 8E9A911E81C8 for ; Wed, 14 Aug 2013 20:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVV438ssiVCm for ; Wed, 14 Aug 2013 20:32:02 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2224911E81C4 for <6man@ietf.org>; Wed, 14 Aug 2013 20:32:02 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so344100pad.23 for <6man@ietf.org>; Wed, 14 Aug 2013 20:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rXfi8KaUu/9iFHZ6y9I19olgK9VfEs6FBcNU8mWBrJY=; b=mGTHMkww6TIfwkQN1gA0f630jzCMwWFe3fqvS2LMqUn9ow7oX/rYHC0iAAxWBptXRm X5bxg704HCUcyc2VorBysFe+W+9dX5TXlREYt+nHx9ihIz5623uu/970T2HZToOPUO0N okuccmmZzUWN/h7sCT0aYeegC1K5hKHdBkzZaOgUJYZNwWy+xgE6FNbgMnGYGMfvj/6Q jhJKsoYBBokSrs3x6MwiXvDgLkfI0drvqIUmm4laAIp84tiI7Nrc3ViH8lYl0uzDyHzW 5aeO7HzjFHMLbAqym0+oVs0SZ/v+vgURYqYIw1pH8ddCJVyNZbssWKvxniDyHJMrkZYL KRSw== X-Received: by 10.66.189.98 with SMTP id gh2mr13466352pac.60.1376537521862; Wed, 14 Aug 2013 20:32:01 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id hk3sm12472924pbb.3.2013.08.14.20.31.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 20:32:01 -0700 (PDT) Message-ID: <520C4BB2.4050500@gmail.com> Date: Thu, 15 Aug 2013 15:32:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: Detailed review of Significance of IPv6 Interface Identifiers References: <520B3529.80802@si6networks.com> <520BF653.8060603@gmail.com> <8C48B86A895913448548E6D15DA7553B9979F5@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9979F5@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "6man@ietf.org" <6man@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, 15 Aug 2013 03:32:02 -0000 On 15/08/2013 10:56, Fred Baker (fred) wrote: > On Aug 14, 2013, at 2:27 PM, Brian E Carpenter wrote: > >>> * Section 3: >>>> To the extent that each method of IID creation specifies the values >>>> of the "u" and "g" bits, and that each new method is carefully >>>> designed in the light of its predecessors, these bits tend to reduce >>>> the chances of duplicate IIDs. >>> Not sure what you mean. Do you mean that *if* each IID-generation method >>> were to use a different combination of "ug", colisions between them >>> would be avoided? If so, I'd argue that since there's no coordination of >>> which combinations should be used for which method, that's unfeasible. >>> For instance, traditional SLAAC uses all combinations (modulo >>> "illegal/unused" combinations of ug). >> The argument is fuzzy and the sentence needs to be rewritten. >> >> (I would actually suggest that in a pseudo-random method, now that we >> are clear that the bits have no meaning, it would be best to use them to >> provide two more bits of entropy rather than giving them fixed values.) > > Good grief. If the bits don't mean anything - and they never did, since nobody ever interpreted them except in IETF dancing-on-heads-of-pins discussions - could we simply say that they are as random in value as any of the other bits in the IID are? Yes, I believe future IID formats could do that. We can try to make that clear in the next version. Brian From randy@psg.com Wed Aug 14 20:35:16 2013 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 326B611E81D2 for ; Wed, 14 Aug 2013 20:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8NCayrzlo5c for ; Wed, 14 Aug 2013 20:35:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35A21F9B18 for <6man@ietf.org>; Wed, 14 Aug 2013 20:35:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1V9oL2-0000SQ-QQ; Thu, 15 Aug 2013 03:35:05 +0000 Date: Thu, 15 Aug 2013 12:35:03 +0900 Message-ID: From: Randy Bush To: "Fred Baker (fred)" Subject: Re: Detailed review of Significance of IPv6 Interface Identifiers In-Reply-To: <8C48B86A895913448548E6D15DA7553B9979F5@xmb-rcd-x09.cisco.com> References: <520B3529.80802@si6networks.com> <520BF653.8060603@gmail.com> <8C48B86A895913448548E6D15DA7553B9979F5@xmb-rcd-x09.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Fernando Gont , "6man@ietf.org" <6man@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, 15 Aug 2013 03:35:16 -0000 >> (I would actually suggest that in a pseudo-random method, now that we >> are clear that the bits have no meaning, it would be best to use them to >> provide two more bits of entropy rather than giving them fixed values.) > > Good grief. If the bits don't mean anything - and they never did, > since nobody ever interpreted them except in IETF > dancing-on-heads-of-pins discussions - could we simply say that they > are as random in value as any of the other bits in the IID are? uh, the effective semantics of these two paragraphs are the same two more bits of entropy == as random in value as any of the other bits in the IID randy From heard@pobox.com Sun Aug 18 18:15:03 2013 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 93CE811E80E8 for ; Sun, 18 Aug 2013 18:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8MJCf6wgPIE for ; Sun, 18 Aug 2013 18:14:59 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C2A11E818A for ; Sun, 18 Aug 2013 18:14:56 -0700 (PDT) Received: (qmail 23384 invoked from network); 18 Aug 2013 18:14:49 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Aug 2013 18:14:49 -0700 Date: Sun, 18 Aug 2013 18:14:49 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") In-Reply-To: Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 19 Aug 2013 01:15:03 -0000 Greetings, Chiming in a bit late, I have a few things to add to the thread: 1.) Ron's paraphrase below captures my intent precisely. 2.) As Fred points out (and as I mentioned in my original post), it is possible that some middleboxes will filter UDP datagrams with UDP Length > L4 length from IP. However, it would not be difficult to code up some test scaffolding to get at least some empirical data on how frequent this might be. I am thinking now of something along the lines of the data in Section 5.3 of http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf for IP fragment filtering. Are any operators out there interested in commissioning/supporting such an effort? 3.) If it turns out that such filtering is common, I agree with Ron that using a new protocol number is the right way to go. In that case I would further modify the proposal to make the transport header format the same in all cases, in order to simplify implementations (and thereby make them more reliable). 4.) Assuming that such filtering is not common, there are some aspects of the proposal sketched below that may be worthy of further discussion and comment: a.) Segments with partial overlap should not be allowed, for reasons that are well known to readers of this list (and implementors of IPv4 fragmentation). A complete overlap can happen if the network duplicates a segment and should probably be allowed. b.) A datagram that gets segmented in the manner proposed below would need to have at least 16 transport data bytes pushed into the second and succeeding segments, in order to ensure that the initial segment has UDP Length > L4 length from IP. c.) It would need to be clearly specified whether Segment Offset does or does not include headers. For definiteness I assume henceforth that it refers to transport data bytes only. d.) If padding beyond UDP Length is disallowed in segmented datagrams, then the More Segments bit (M) is not needed, since in that case the condition UDP Length = (Segment Offset)*8 + (L4 length from IP - 8) is equivalent to M=0. In any case this condition must be satisfied when M=0. Note that padding cannot be allowed in segments with M=1 (as is the case with all TCP segments). e.) We may want to re-consider whether to allow padding beyond UDP Length in non-segmented datagrams. Existing UDP implementations known to me are liberal on this score -- they ignore padding -- but it may be desirable to eliminate the potential covert channel. Note that specifying this behavior for non-segmented datagrams would be an update to RFC 768 and RFC 1122, which are silent on the matter. f.) Having the datagram length in every segment tells the receiver how big a reassembly buffer to allocate, even in the presence of segment reordering. This has the potential to simplify the implementation and could partially mitigate certain classes of reassembly buffer exhaustion attacks. Mike Heard On Tue, 6 Aug 2013, Ronald Bonica wrote: > Fred, > > If that's the case, we have a good argument for changing Mike's > proposal ever so slightly, so that it uses a new protocol ID. But > still, Mike's proposal is elegant because: > > a) It solves the problem at the right layer > b) It reuses UDP transport machinery. (The only exception is the in LENGTH field) > c) It reuses IP fragmentation machinery (moving it to the transport layer) > d) Aside from b) and c), it introduces no new protocol machinery. So, it > can be described in a few short pages. This is in stark contrast to SEAL > (draft-templin-intarea-seal-61) whose protocol machinery requires 41 pages > to describe which required 61 draft versions to get right. > > Ron > > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, August 06, 2013 2:58 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > With a protocol as ossified as UDP, I have a hard time imagining all > > middleboxes passing the packets with what they would see as a corrupted > > length field. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > > Of Ronald Bonica > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > To: C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > Mike, > > > > > > The proposal sounds elegant. I will try to paraphrase it to make sure > > > that I understand. > > > > > > When originating a UDP datagram, the host always queries it underlying > > > IP stack to determine the PMTU for the destination. If the PMTU > > > greater than or equal to the size of the payload plus the UDP header > > > plus the IP header, plus all IP extension headers, the originating > > > host emits a conventional UDP packet which is characterized as follows: > > > > > > - Protocol = 17 > > > - Length <= L4 length from IP > > > > > > If the PMTU less than the size of the payload plus the UDP header plus > > > the IP header, plus all IP extension headers, the originating host > > > emits an unconventional UDP packet which is characterized as follows: > > > > > > - Protocol = 17 > > > - Length > L4 length from IP > > > - Segment Offset, M-bit and Identification fields added to UDP header > > > before the payload > > > > > > If an unconventional UDP packet arrives a destination that supports > > > unconventional packets, it is reassembled at the transport layer. If > > > an unconventional UDP packet arrives a destination that does not > > > support unconventional packets, it is discarded. > > > > > > Do I have this much right? > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > > > C. M. Heard > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > To: IPv6 > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > I agree that C.M. Heard's ideas should be explored in more detail > > > > > > by the IETF. > > > > > > > > The idea was essentially UDP with segmentation fields, which would > > > > require a new protocol number. > > > > > > > > In an offline discussion with Mark Smith and I kicked around an idea > > > > for an alternate version not requiring a new protocol number, but > > > > relying instead on the redundancy of the UDP Length field. The UDP > > > > Length field is not actually needed; TCP does not have one but rather > > > > relies on the length reported by the IP layer. Under current > > > > standards, the UDP Length field must be at least 8 and cannot exceed > > > > the IP payload length minus the combined length of any extension > > > > headers -- let's call this the L4 length from IP. Existing > > > > implementations are supposed to drop UDP datagrams that fail this > > > > check, and all the ones I know of do so. > > > > > > > > The question then arises whether it might reasonably be possible to re- > > > > purpose the case UDP Length > L4 length from IP to mean a segmented UDP > > > > datagram. > > > > > > > > In that case 8 <= UDP Length <= L4 length from IP would be intepreted > > > > as a standard unsegmented UDP datagram, as is it now. > > > > That's the case pictured below. Note that if the L4 length indicated > > > > by the IP layer exceeds the UDP Length, then the extra octets would be > > > > discarded and are not delivered to the application; that is the > > > > behavior of the implementations I know of. > > > > > > > > 0 15 16 31 > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | Source Port | Destination Port | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | Length <= L4 length from IP | Checksum | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | data octets ... > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > Now suppose that we have a long UDP datagram that we want to send in > > > > segments. We set the Length and Checksum fields as usual, and then cut > > > > the datagram into segments, each of which looks like this: > > > > > > > > 0 15 16 31 > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | Source Port | Destination Port | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | Length > L4 length from IP | Checksum | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | (reserved = 0) | Segment Offset |Res|M| > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | Identification | > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > | data octets ... > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > We put the same UDP header in each segment, so (if we take some care in > > > > how we choose the length of the segments) each one will have a UDP > > > > Length field that is greater than the IP payload length minus the > > > > combined length of any extension headers. Implementations that conform > > > > to the current specifications should discard these segments, and so > > > > should not mistakenly consider the segmentation fields as part of the > > > > application data. That should make it possible for segmented UDP > > > > datagrams to safely coexist with conventional unsegmented one, without > > > > getting a new protocol number. > > > > > > > > Possible downsides: some middleboxes may filter such "erroneous" > > > > datagrams, and some existing erroneous implementations may fail to do > > > > the checks they should and might mistake these segments for ordinary > > > > UDP datagrams. > > > > > > > > Note that this idea does not work with UDP-lite, which replaces the > > > > Length field with a Checksum Coverage field. That could easily be too > > > > short to exceed the L4 length from IP. > > > > > > > > Mike Heard > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > > From heard@pobox.com Sun Aug 18 19:57:46 2013 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 B449621F9CA6 for ; Sun, 18 Aug 2013 19:57:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI1MsohWXQ0C for ; Sun, 18 Aug 2013 19:57:41 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C24D21F9D04 for ; Sun, 18 Aug 2013 19:57:41 -0700 (PDT) Received: (qmail 22083 invoked from network); 18 Aug 2013 19:57:37 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Aug 2013 19:57:37 -0700 Date: Sun, 18 Aug 2013 19:57:37 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") In-Reply-To: <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 19 Aug 2013 02:57:46 -0000 On Tue, 6 Aug 2013, Templin, Fred L wrote: > One other thing for now is that Mike's proposal doesn't even > address the attack vector that 'draft-bonica-6man-frag-deprecate' > is concerned about. To address the tiny fragment concern, the > protocol must ensure that tiny fragments cannot ever be created. That is incorrect, or at least a red herring. As draft-bonica-6man-frag-deprecate Section 2.3 points out, tiny IP-layer fragments are a problem because thsy can be crafted so that the L4 header, or a significant part thereof, does not appear in the initial IP fragment. In the proposal I floated (or variants thereof, like a UDP replacement with a new protocol number) where L4 segments are used _instead_ of IP fragments that cannot happen, because the L4 header appears in front of _each_ segment -- just as with TCP. Tiny transport layer _segments_ have not been identified as a problem. //cmh From jiangsheng@huawei.com Sun Aug 18 20:43:33 2013 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 264AC11E81A7; Sun, 18 Aug 2013 20:43:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJDSVHA9qm+l; Sun, 18 Aug 2013 20:43:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8E11E80D1; Sun, 18 Aug 2013 20:43:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWD36529; Mon, 19 Aug 2013 03:43:27 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 04:42:42 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 04:43:26 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.66]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Mon, 19 Aug 2013 11:43:19 +0800 From: Sheng Jiang To: Fred Baker , "v6ops@ietf.org" Subject: RE: [v6ops] draft-taylor-v6ops-fragdrop WGLC Thread-Topic: [v6ops] draft-taylor-v6ops-fragdrop WGLC Thread-Index: AQHOnDzVcyHroPwXkkimHplb/XQgn5mb4oOA Date: Mon, 19 Aug 2013 03:43:18 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACF4BEA@nkgeml512-mbx.china.huawei.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> In-Reply-To: <201308181800.r7II06mv003294@irp-view13.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 19 Aug 2013 03:43:33 -0000 UmVhZGluZyB0aGlzIGRvY3VtZW50IG1hZGUgbWUgYmVsaWV2ZSB0aGF0IGZyYWdtZW50IHNob3Vs ZCBOT1QgYmUgZGVwcmVjYXRlZCBhbmQgdGhlIHN1cHBvcnQgZm9yIGZyYWdtZW50IHdvdWxkIGJl IGJldHRlciBpbiBsb25nLXRlcm0uIEkgcGVyc29uYWxseSBhZ3JlZSBvbiBzdWNoIG9ic2VydmF0 aW9ucyBhbmQgY29uY2x1c2lvbnMuIEkgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gVGhhbmtzIGF1dGhvcnMgZm9yIGdhdGhlciB0aGVzZSB2YWx1ZSBpbmZvcm1hdGlv bi4NCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogdjZvcHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPk9mIEZyZWQgQmFrZXINCj5TZW50OiBNb25kYXksIEF1Z3VzdCAxOSwgMjAxMyAyOjAwIEFN DQo+VG86IHY2b3BzQGlldGYub3JnDQo+U3ViamVjdDogW3Y2b3BzXSBkcmFmdC10YXlsb3ItdjZv cHMtZnJhZ2Ryb3AgV0dMQw0KPg0KPlRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvZg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRheWxvci12Nm9wcy1mcmFnZHJvcC4gIFBsZWFzZSByZWFkIGl0IG5vdy4NCj5JZiB5b3UgZmlu ZCBuaXRzDQo+KHNwZWxsaW5nIGVycm9ycywgbWlub3Igc3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdl cywgZXRjKSwgY29tbWVudCB0byB0aGUNCj5hdXRob3JzOyBpZiB5b3UgZmluZCBncmVhdGVyIGlz c3Vlcywgc3VjaCBhcyBkaXNhZ3JlZWluZyB3aXRoIGENCj5zdGF0ZW1lbnQgb3IgZmluZGluZyBh ZGRpdGlvbmFsIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkLA0KPnBsZWFzZSBwb3N0 IHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+DQo+V2UgYXJlIGxvb2tpbmcgc3BlY2lmaWNh bGx5IGZvciBjb21tZW50cyBvbiB0aGUgaW1wb3J0YW5jZSBvZiB0aGUNCj5kb2N1bWVudCBhcyB3 ZWxsIGFzIGl0cyBjb250ZW50LiBJZiB5b3UgaGF2ZSByZWFkIHRoZSBkb2N1bWVudCBhbmQNCj5i ZWxpZXZlIGl0IHRvIGJlIG9mIG9wZXJhdGlvbmFsIHV0aWxpdHksIHRoYXQgaXMgYWxzbyBhbiBp bXBvcnRhbnQNCj5jb21tZW50IHRvIG1ha2UuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From internet-drafts@ietf.org Mon Aug 19 01:58:27 2013 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 384AA11E8217; Mon, 19 Aug 2013 01:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGSrhuC7JScb; Mon, 19 Aug 2013 01:58:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBF411E821E; Mon, 19 Aug 2013 01:57:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819085731.7668.22312.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 01:57:31 -0700 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, 19 Aug 2013 08:58:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A Method for Generating Semantically Opaque Interface Id= entifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-12.txt Pages : 25 Date : 2013-08-19 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Mon Aug 19 02:11:10 2013 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 E2C2311E8215 for ; Mon, 19 Aug 2013 02:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwYaQheDX7yQ for ; Mon, 19 Aug 2013 02:11:04 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 77E5521F9962 for ; Mon, 19 Aug 2013 02:11:04 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-178.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 8704B5F95; Mon, 19 Aug 2013 02:11:02 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Mon, 19 Aug 2013 11:11:00 +0200 Message-Id: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@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: Mon, 19 Aug 2013 09:11:10 -0000 All, This message starts the second two week 6MAN Working Group on advancing: Title : A Method for Generating Semantically Opaque = Interface Identifiers with IPv6 Stateless Address Autoconfiguration = (SLAAC) Author(s) : F. Gont Filename : draft-ietf-6man-stable-privacy-addresses-12 Pages : 25 Date : 2013-08-19 = http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-12 as a Proposed Standard. 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 September 2, 2013. The chairs would like to solicit one or two people in the working group = to do a detailed review of the document. We would also encourage = volunteers to act as document shepherds. Please contact the chairs = directly. Regards, Bob Hinden & Ole Tr=F8an= From otroan@employees.org Mon Aug 19 02:25:09 2013 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 18E4A11E8223 for ; Mon, 19 Aug 2013 02:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRU2mbyBfpyo for ; Mon, 19 Aug 2013 02:25:04 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 397DE11E821E for ; Mon, 19 Aug 2013 02:25:04 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-178.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 340E45F57 for ; Mon, 19 Aug 2013 02:25:03 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN - active documents Message-Id: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> Date: Mon, 19 Aug 2013 11:25:01 +0200 To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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, 19 Aug 2013 09:25:09 -0000 In working group last call: draft-ietf-6man-oversized-header-chain-04 (ending August 27th) draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd) *** We are awaiting document reviewer volunteers for these two. Please = contact the chairs. (No prizes, but we might offer a beer for the first two! ;-)) Awaiting new revision: draft-ietf-6man-ext-transmit-02 (WGLC ended August 1st) draft-ietf-6man-ug-02 (WGLC ended August 1st) Documents in the pipeline: draft-ietf-6man-resilient-rs-01 (Ready for WGLC) draft-gont-6man-ipv6-smurf-amplifier-03 (Ready for Call for adoption) For other documents we try to keep the document status at https://datatracker.ietf.org/wg/6man/ up to date. Best regards, Ole & Bob= From ek@google.com Mon Aug 19 02:40:40 2013 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 EF24221F871B for ; Mon, 19 Aug 2013 02:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb+48GTbMgVZ for ; Mon, 19 Aug 2013 02:40:39 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id DA35711E8232 for ; Mon, 19 Aug 2013 02:40:37 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id cy11so958277qeb.38 for ; Mon, 19 Aug 2013 02:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Nh0qrckRADIVXAzmo/UA4qFFZLTwIgApOOFy2lfICE=; b=e/C78wJn3TCQd8BTl7+b4uYG7jzHoAQeHqHmOzIkw+CXelLAWi4P0OAIkEAPKtqbIF CUSYoh4AHcgeCcttIo1GaBtwISmxQCJ5KxWhCWqUBCtMn+u9CICCCXe2VwD3FXoAY4AX J/VMi6zPHm0Pg+rbiFjtaduZ3k91wniRDh44DJ/AdwxkNSin3OpHLZ+eMidWhOpiI6yD dQRHG2DH+VtC01iphM7v2M2cysgTrIBf9pHjTzcLUmR7mqiPfUI9ztve6buco59YmPR+ AHr1T7wZir6Z0xkQGvs7z0HvC8pj0Gug0KquEKEQtxDIPrbbFHV2mZSHAk+BYl8xeNfY QwhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2Nh0qrckRADIVXAzmo/UA4qFFZLTwIgApOOFy2lfICE=; b=mO2x4J+nRq2swBKy5cTDKM3VtBmtl8LMyf3S/lkJDGcuw5/bXn26h3rt6/qliYrZMD 46Zfymt3wJNkNAdM8cPkWdBKK/OqZe8ewmJO2UzTByPf5SAaPuQrTfH2l/yYbaYTA0F0 q4KWI21SVmD6FDOps7xoy3GgWxcnoV/hCeSlYEbES17YXBwf8bAxMrULsylsT878gmdh ruV7ExPf8s99he9CRBF3OKyqgzeSMSiZhlvij84DJfe+yHpvL6iqh7RXTfXPB+AayZAp dVP6HCKQT1RfcHiY1LlIbHPH+CSChR4DkwYftV4Q4SFUIe2QQ2EQYDpTTa4ibrW5Yvwx 0n9Q== X-Gm-Message-State: ALoCoQleu7kclimyq25gtW5pNuGg3WA/+1rDWM0Ik0z38bDoYCTEUoiMnM6v3jhEnVF2hX09UbrjJ/15HmtQr+LwPeasBVsbRRlewUp9cSBaE/An0ArSopB69M/zI9BW40NbBvf9wtLMUxPTIPPguTqkHpr669ipq2nQw24vf7TRUgcYSRfQAs7/6AWS/KWzn7FljscQWBsY X-Received: by 10.224.12.146 with SMTP id x18mr116630qax.110.1376905236076; Mon, 19 Aug 2013 02:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.73 with HTTP; Mon, 19 Aug 2013 02:40:15 -0700 (PDT) In-Reply-To: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> From: Erik Kline Date: Mon, 19 Aug 2013 18:40:15 +0900 Message-ID: Subject: Re: 6MAN WG Last Call: To: Ole Troan Content-Type: text/plain; charset=UTF-8 Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG 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, 19 Aug 2013 09:40:40 -0000 I pre-apologize, as always, for my ignorance, but...is there an implementation of this? Specifically, I'm mildly concerned about this for link-local addresses. Compliant implementations cannot even begin any IPv6 link-local operations until the secret key has been loaded from stable storage. They also should load the DAD_Counter from non-volatile memory before starting link-local operations. And they MUST NOT fallback to other link-local autoconfig implementations (last paragraph of section 4). I agree that this all seems fine in theory. Are we collectively convinced this will not lead to tragically (IPv6-)orphaned machines in certain scenarios? From fgont@si6networks.com Mon Aug 19 02:57:31 2013 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 841A011E8223 for ; Mon, 19 Aug 2013 02:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGEuO-XVKPXj for ; Mon, 19 Aug 2013 02:57:31 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C147711E8211 for ; Mon, 19 Aug 2013 02:57:30 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.156]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VBMDD-00048x-Pp; Mon, 19 Aug 2013 11:57:25 +0200 Message-ID: <5211EBFD.2000403@si6networks.com> Date: Mon, 19 Aug 2013 06:57:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Erik Kline Subject: Re: 6MAN WG Last Call: References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG 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, 19 Aug 2013 09:57:31 -0000 Erik, On 08/19/2013 06:40 AM, Erik Kline wrote: > I pre-apologize, as always, for my ignorance, but...is there an > implementation of this? Specifically, I'm mildly concerned about this > for link-local addresses. > > Compliant implementations cannot even begin any IPv6 link-local > operations until the secret key has been loaded from stable storage. > They also should load the DAD_Counter from non-volatile memory before > starting link-local operations. And they MUST NOT fallback to other > link-local autoconfig implementations (last paragraph of section 4). > > I agree that this all seems fine in theory. Are we collectively > convinced this will not lead to tragically (IPv6-)orphaned machines in > certain scenarios? Sorry, what are the scenarios you have in mind? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From markzzzsmith@yahoo.com.au Mon Aug 19 04:19:53 2013 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 34BC911E80D5 for ; Mon, 19 Aug 2013 04:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBrkUzhZkSsW for ; Mon, 19 Aug 2013 04:19:48 -0700 (PDT) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3746411E80DC for ; Mon, 19 Aug 2013 04:19:47 -0700 (PDT) Received: from [66.196.81.174] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 19 Aug 2013 11:19:47 -0000 Received: from [98.139.212.214] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 19 Aug 2013 11:19:47 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 19 Aug 2013 11:19:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 161942.37238.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 48526 invoked by uid 60001); 19 Aug 2013 11:19:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376911187; bh=73hMe6DuYOCJOdi2rTQ8y8KJaLV4knT8tCwJUs3nHsE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RgMM7JzIdaeAPIRz+O2dQGAnP4UZ62hm89V11waZpiLEA25dgS74B5tiIstFqK+V1MYWgKIk55W46R0RgQ7oylL3pACpZHaBCt8UVc3DuocfS7mykh8peGqGy4xjkH3jXgkIK19ZTc3RBAKklBaLnFSrOglmOsG463HsirStx9I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MkliBaUoeU2L0xIJyWo8F7GS3S/5TgTEgMOBrXX8m9euif+WP2yKCTHxmMssD0G48271b1rEWVqvZiOkOIBkZdtazTuQDLRHqQzaxApWfCiSVBp7ZLv4LtMcLC46YA1pDJiakyzSqKFGm6ql7AertCN3BQYRP5bEH8qAl3chbMg=; X-YMail-OSG: 55.LBwkVM1k2VJrz1UoL7Vek_EgLbZIagATajb6bDFlOsjv y8bleXvYJVwzNOZeX0wAFQQkuC2M4vmwsuQaJi0231aqm4Z493ILtIdKjFc5 Cyhpq33yMm2BhbC5lwfKCTQ0Ig.4z2TqYSW.Zse8bjhtERk8E6ztlRIRor.y O50Ba_U47sSH6UVVTj_WfM3x.3ZPv.ZlxJeVg0CMyY6dO_oXea9L49j5jxkX IzKTAf5kDB07pHtvk3TFgjRAmI6YFFuY_Im8B0xLBRcdmcFUG6BdC0gySAmg 9u7snzpSq462VssV3.OJipCkzt3ZgYcUqOP_OAC.YECncLuBDjOQvMvb7U1V y5Kvz7ss6Twb03sueV61lvHFUsuEAKQDYYrSSbouY9HEYFVPECMLbHAQRDEC uwNtQOIy27CLHLnBQ6I.GqqM2wmPdNtoP0XcyaVUIDX7hkPA40LQ.R5wgYqJ pOhA3e8nZ_sYQbQPKUFOuv8abdANqoTaNQU1qd1mlDMX5qxGD5NEmYU82Ath tnTl_0xOhrkocBZGI4MJvLx6gsMH50q8qugcIMVVU9y03cvAi0XDeghE_JLC S8sw4BV1Fz19sRQ_55mi4yFTJCwn3WsT1BkrXpzEM77TwbZo0oA-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 19 Aug 2013 04:19:46 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpHb2luZyBieSB0aGUgdGl0bGUsIGl0IHNlZW1zIG15IGNvbW1lbnQgd2FzIG1pc3NlZCBhYm91dCBub3QgaW1wbHlpbmcgdGhhdCB0aGlzIGFkZHJlc3MgZ2VuZXJhdGlvbiB0ZWNobmlxdWUgaXMgbGltaXRlZCB0byBTTEFBQyBzbGFjayBzY2VuYXJpb3MsIGJ1dCBjb3VsZCBiZSB1c2VmdWwgd2l0aCBhbnkgYWRkcmVzcyBjb25maWd1cmF0aW9uIG1ldGhvZCAoaS5lLCBTTEFBQywgREhDUHY2LCBzdGF0aWMsICtmdXR1cmUuKSBUaGVyZSBzZWVtZWQgdG8gYmUgc29tZSBzdXBwb3J0IGZvciBkZWNvdXABMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> Message-ID: <1376911186.35364.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 19 Aug 2013 04:19:46 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Ole Troan , 6man WG In-Reply-To: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:19:53 -0000 Hi,=0A=0AGoing by the title, it seems my comment was missed about not imply= ing that this address generation technique is limited to SLAAC slack scenar= ios, but could be useful with any address configuration method (i.e, SLAAC,= DHCPv6, static, +future.) There seemed to be some support for decoupling t= he concepts of address generation from address configuration.=0A=0AHere's m= y original email:=0A=0Ahttps://www.ietf.org/mail-archive/web/ipv6/current/m= sg18758.html=0A=0A=0A=0ARegards,=0AMark.=0A=0A=0A----- Original Message ---= --=0A> From: Ole Troan =0A> To: 6man WG =0A> Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>= =0A> Sent: Monday, 19 August 2013 7:11 PM=0A> Subject: 6MAN WG Last Call: <= draft-ietf-6man-stable-privacy-addresses-12>=0A> =0A> All,=0A> =0A> This me= ssage starts the second two week 6MAN Working Group on advancing:=0A> =0A> = =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : A Method for Generating Semantically = Opaque Interface =0A> Identifiers with=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 IPv6 Stateless Address Autoconfiguration (SLAAC)=0A> = =A0=A0=A0 Author(s)=A0 =A0 : F. Gont=0A> =A0=A0=A0 Filename=A0 =A0 : draft-= ietf-6man-stable-privacy-addresses-12=0A> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 : = 25=0A> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 : 2013-08-19=0A> =0A> =A0 =A0 =A0 = http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-12=0A> = =0A> as a Proposed Standard.=A0 Substantive comments and statements of supp= ort for =0A> advancing this document should be directed to the mailing list= . Editorial =0A> suggestions can be sent to the authors.=A0 This last call = will end on September 2, =0A> 2013.=0A> =0A> The chairs would like to solic= it one or two people in the working group to do a =0A> detailed review of t= he document. We would also encourage volunteers to act as =0A> document she= pherds. Please contact the chairs directly.=0A> =0A> Regards,=0A> =0A> Bob = Hinden & Ole Tr=F8an=0A> --------------------------------------------------= ------------------=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.o= rg=0A> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= =0A> --------------------------------------------------------------------= =0A> From heard@pobox.com Mon Aug 19 17:58:13 2013 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 3562F11E8180 for ; Mon, 19 Aug 2013 17:58:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H6gbyZDz5dK for ; Mon, 19 Aug 2013 17:58:09 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAD411E811F for ; Mon, 19 Aug 2013 17:58:08 -0700 (PDT) Received: (qmail 32465 invoked from network); 19 Aug 2013 17:58:04 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2013 17:58:04 -0700 Date: Mon, 19 Aug 2013 17:58:04 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: 6MAN WG Last Call: In-Reply-To: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> Message-ID: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-31421571-1376952960=:20395" Content-ID: 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, 20 Aug 2013 00:58:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---2133786286-31421571-1376952960=:20395 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: Greetings, My main question is why this draft is not better integrated with draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, which have overlapping or at least related subject matter. The thrust of draft-ietf-6man-oversized-header-chain is to require that all extension headers and the upper layer header appear in the first IPv6 fragment and to define an ICMPv6 error message that may be sent when that condtion is violated (type = Parameter Problem, code = IPv6 first-fragment has incomplete IPv6 header chain). The thrust of draft-wkumari-long-headers-01 is the claim that operators have a requirement to filter at Layer 3 and Layer 4, at line rate, in the network, and that in order to be able to do that, the entire header chain needs to appear within a relatively short initial segment of the IPv6 datagram -- the draft suggests 128 bytes. This is MUCH shorter that the "within the first fragment" constraint specified by draft-ietf-6man-oversized-header-chain. There is also a strong hint (though not an explicit statement) in draft-wkumari-long-headers-01 that entities that do in-network line-rate filtering need to see layer 3 and 4 information in ALL datagrams, which is at the heart of the subject matter of draft-bonica-6man-frag-deprecate. In my view, draft-ietf-6man-oversized-header-chain should not go to the IESG until: 1.) This WG decides what to do with draft-bonica-6man-frag-deprecate. If the decision is to admit that IPv6 frgmentation works so poorly in pratice that new protocols must not use it and existing protocols should try not to use it, then a stronger recommendation than just confining the header chain to the initial fragment is probably in order -- perhaps something like what's in draft-wkumari-long-headers. 2.) This WG decides whether the ideas in draft-wkumari-long-headers are basically sound. If so, then it would make sense (to me, anyway) to merge it with draft-ietf-6man-oversized-header-chain. The two drafts already agree (with admirable precision) on the definition of what a complete IPv6 header chain is. One way to merge the documents would be to add a section to draft-ietf-6man-oversized-header-chain recognizing that there are likely to be stringent limits on the size of a header chain that an implementation can process and defining an ICMPv6 error message that may be sent when these limits are exceeded (type = Parameter Problem, code = IPv6 header chain exceeds implementation's capacity). A recommendation on the minimum size header chain that an implementation should support would then be in order. Thanks, Mike Heard On Tue, 13 Aug 2013, Ole Troan wrote: > All, > > This message starts the second two week 6MAN Working Group on advancing: > > Title : Implications of Oversized IPv6 Header Chains > Author(s) : F. Gont, V. Manral, R. Bonica > Filename : draft-ietf-6man-oversized-header-chain-04 > Pages : 13 > Date : 2013-08-13 > > http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-04 > > as a Proposed Standard. 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 August 27, 2013. > > The chairs would like to solicit one or two people in the working > group to do a detailed review of the document. We would also > encourage volunteers to act as document shepherds. Please contact > the chairs directly. > > Regards, > > Bob Hinden & Ole Trøan ---2133786286-31421571-1376952960=:20395-- From fgont@si6networks.com Mon Aug 19 21:03:37 2013 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 7667111E81A4 for ; Mon, 19 Aug 2013 21:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V5I4oMgXDsS for ; Mon, 19 Aug 2013 21:03:37 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CF2E411E815C for ; Mon, 19 Aug 2013 21:03:35 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VBdAB-00062L-7N; Tue, 20 Aug 2013 06:03:23 +0200 Message-ID: <5212EA72.2090608@si6networks.com> Date: Tue, 20 Aug 2013 01:02:58 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "C. M. Heard" Subject: Re: 6MAN WG Last Call: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 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, 20 Aug 2013 04:03:37 -0000 Hi, Mike On 08/19/2013 09:58 PM, C. M. Heard wrote: > > My main question is why this draft is not better integrated with > draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, > which have overlapping or at least related subject matter. Because what's in draft-ietf-6man-oversized-header-chain is what the wg agreed upon over time. For instance, some earlier version of draft-ietf-6man-oversized-header-chain enforced an upper limit t the size of the extension header length (1280 bytes, at the time) but such limit was removed from the document in responses to wg consensus. > The thrust of draft-wkumari-long-headers-01 is the claim that > operators have a requirement to filter at Layer 3 and Layer 4, at > line rate, in the network, and that in order to be able to do that, > the entire header chain needs to appear within a relatively short > initial segment of the IPv6 datagram -- the draft suggests 128 > bytes. This is MUCH shorter that the "within the first fragment" > constraint specified by draft-ietf-6man-oversized-header-chain. And it was agred by this wg that this limit would be an operational BCP, but not a protocol update. That's thy these items are kept in different documents. > There is also a strong hint (though not an explicit statement) in > draft-wkumari-long-headers-01 that entities that do in-network > line-rate filtering need to see layer 3 and 4 information in ALL > datagrams, which is at the heart of the subject matter of > draft-bonica-6man-frag-deprecate. The wg discussed this, and I seem to recall that the outcome was that we were not ready to ban the use of fragmentation, but rather that we should move away from it. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Mon Aug 19 21:23:51 2013 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 0925511E81AF for ; Mon, 19 Aug 2013 21:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d52S-Lf1RUcR for ; Mon, 19 Aug 2013 21:23:50 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC511E80F9 for ; Mon, 19 Aug 2013 21:23:50 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id u16so1042395iet.22 for ; Mon, 19 Aug 2013 21:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AOeFKdQpjJ6Epb7+EUTBCJXM3LE8EwfjXreIGBo18WI=; b=E167ITUE9E5hcH7k8pbx0xTyobyTy6mvezs0UNgAMXQNRammvvBTgsWOkHQL58bVpb A+iLay8Az8EyXd4mikUAAiFwiz0FIptLU6940Oh0KAXu9GSwg0a8fhpMV32/YbGKh7aa MbIZMjS87u5r86/cQZn1s6bSzoNKfXEWe2qwQKrKqnkwb/i9xEYQ+/kOfwVhWC0kRgm2 NxzIHJRhpzhHeE5W1l42TJW/ePUnVj5znB1pAKeBUcQkFRk75DpKvRzy8v4JC2+75vmx uk0TUDhQR55TogcZqla7m1RlxxvMbmGX0J/JunJQ0ucDmPiDJUWEPWhDVbGjOXjSipIj EV7A== X-Received: by 10.50.67.37 with SMTP id k5mr5105525igt.21.1376972629887; Mon, 19 Aug 2013 21:23:49 -0700 (PDT) Received: from [192.168.178.20] (204.200.69.111.dynamic.snap.net.nz. [111.69.200.204]) by mx.google.com with ESMTPSA id vf9sm13833893igb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 21:23:49 -0700 (PDT) Message-ID: <5212EF57.4030307@gmail.com> Date: Tue, 20 Aug 2013 16:23:51 +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: 6MAN WG Last Call: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5212EA72.2090608@si6networks.com> In-Reply-To: <5212EA72.2090608@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 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, 20 Aug 2013 04:23:51 -0000 On 20/08/2013 16:02, Fernando Gont wrote: > Hi, Mike > > On 08/19/2013 09:58 PM, C. M. Heard wrote: >> My main question is why this draft is not better integrated with >> draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, >> which have overlapping or at least related subject matter. > > Because what's in draft-ietf-6man-oversized-header-chain is what the wg > agreed upon over time. And because taking baby steps when playing with such a basic aspect of the protocol seems wiser. I don't think the topics overlap; saying that the header chain must not be fragmented seems straightforward and non-controversial. The other drafts are more contentious. Brian > For instance, some earlier version of > draft-ietf-6man-oversized-header-chain enforced an upper limit t the > size of the extension header length (1280 bytes, at the time) but such > limit was removed from the document in responses to wg consensus. > > >> The thrust of draft-wkumari-long-headers-01 is the claim that >> operators have a requirement to filter at Layer 3 and Layer 4, at >> line rate, in the network, and that in order to be able to do that, >> the entire header chain needs to appear within a relatively short >> initial segment of the IPv6 datagram -- the draft suggests 128 >> bytes. This is MUCH shorter that the "within the first fragment" >> constraint specified by draft-ietf-6man-oversized-header-chain. > > And it was agred by this wg that this limit would be an operational BCP, > but not a protocol update. That's thy these items are kept in different > documents. > > > > >> There is also a strong hint (though not an explicit statement) in >> draft-wkumari-long-headers-01 that entities that do in-network >> line-rate filtering need to see layer 3 and 4 information in ALL >> datagrams, which is at the heart of the subject matter of >> draft-bonica-6man-frag-deprecate. > > The wg discussed this, and I seem to recall that the outcome was that we > were not ready to ban the use of fragmentation, but rather that we > should move away from it. > > Cheers, From heard@pobox.com Mon Aug 19 21:26:20 2013 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 A3A4C11E81BE for ; Mon, 19 Aug 2013 21:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miA6q0wQxv+E for ; Mon, 19 Aug 2013 21:26:16 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B3C11E80F9 for ; Mon, 19 Aug 2013 21:26:14 -0700 (PDT) Received: (qmail 979 invoked from network); 19 Aug 2013 21:26:10 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2013 21:26:10 -0700 Date: Mon, 19 Aug 2013 21:26:10 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: draft-andrews-6man-fragopt updated In-Reply-To: <20130806011402.769C1380908C@drugs.dv.isc.org> Message-ID: References: <20130806011402.769C1380908C@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 20 Aug 2013 04:26:20 -0000 On Tue, 6 Aug 2013, Mark Andrews wrote: > http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt This is an interesting draft and I see that it attempts to offer a fairly complete solution, covering not just TCP and UDP but ICMP and tunneled IPv4 and IPv6. The idea is to put L4 information missing in 2nd and subsequent framgments into IPv6 options, thereby making it readily available to stateless filtering devices, load balancers, and the like. One significant concern that jumps out at me is that the option(s) defined in this draft are hop-by-hop options. Quoting from draft-ietf-6man-ext-transmit Section 2.2: However, it is to be expected that high performance routers will either ignore it, or assign packets containing it to a slow processing path. Designers planning to use a Hop-by-Hop option need to be aware of this likely behaviour. To me it seems highly undesirable to risk putting one's traffic on the slow path of a core router, especially when the L4 information is probably not needed there, but in middleboxes closer to the edge. However, I don't see any reason why these options could not go into a destination options header. The standard order in RFC 2460 (excluding Mobility and Shim6 headers) would work, IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header though "note 1" would need to be changed as follows: note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header or by forwarding nodes needing to inspect options containing layer 4 header information. There is precedent for refinement to the placement of Destination Options headers; see, e.g., RFC 6275 and the Home Address Option. In answer to to the open questions, I would suggest using a single option code and making the protocol explicit. The strategy of leaving the protcol implicit leads to ambigiuities (e.g., between TCP, UDP, and UDP-lite). I would also suggest judicious use of padding to align 4 and 8 bytes quantities on natural boundaries. Mike Heard From swmike@swm.pp.se Tue Aug 20 01:32:37 2013 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 1693111E81C5 for ; Tue, 20 Aug 2013 01:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Jdj1i-I+IO for ; Tue, 20 Aug 2013 01:32:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 214B811E80F7 for ; Tue, 20 Aug 2013 01:32:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 39DDA9C; Tue, 20 Aug 2013 10:32:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2E4669A; Tue, 20 Aug 2013 10:32:32 +0200 (CEST) Date: Tue, 20 Aug 2013 10:32:32 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan , fgont@si6networks.com Subject: Re: 6MAN - active documents In-Reply-To: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> Message-ID: References: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man WG 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, 20 Aug 2013 08:32:37 -0000 On Mon, 19 Aug 2013, Ole Troan wrote: > In working group last call: > draft-ietf-6man-oversized-header-chain-04 (ending August 27th) I have read this document and found no problem with it, and I support its progression. > draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd) -------------------------------------------------------------------- NIT: F(): A pseudorandom function (PRF) that is not computable from the outside (without knowledge of the secret key), which should produce an output of at least 64 bits.The PRF could be implemented as a cryptographic hash of the concatenation of each of the function parameters. Missing space in the middle line. ------------------------------------------------------------------- secret_key: A secret key that is not known by the attacker. The secret key MUST be initialized at operating system installation time to a pseudo-random number (see [RFC4086] for randomness requirements for security). An implementation MAY provide the means for the the system administrator to change or display the secret key. I think the text here should be that i MUST be initialized when the functionality is enabled (or equivalent). I haven't re-installed my operating system for 8 years, I have just upgraded it. Also, this functionality might be a later add-on to an existing version of the operating system, and the functionality might be an add-on to the connection manager, completely independent of the operating system. ------------------------------------------------------------------- There are numerous references to DAD. Isn't DAD attacks handled in other documents that can be referenced, does this document really need to outline this behaviour, perhaps even in conflict with other documents? I don't remember where I read about this though, perhaps someone else knows? It was discussed in SAVI anyway. I think it would be good to reference SAVI-WG documents on first-hop security instead of writing new text on the subject. People seem to like SEND, but I see send as hard to deploy in most scenarios because one entity doesn't control both router and device. I prefer the network protecting using filtering instead of trying to cryptographically assure that the RAs seen is from the router. http://datatracker.ietf.org/wg/savi/ RFC 6620 would be one document to reference in this case. Network_ID mentions SSID. What if I have an ethernet Interface and I move my computer around, should it identify a new set of /64 network address and/or gateway MAC address as a new network as well? I think some text on this would be good guidance for implementors. -- Mikael Abrahamsson email: swmike@swm.pp.se From ek@google.com Tue Aug 20 01:56:16 2013 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 5D5F811E81B0 for ; Tue, 20 Aug 2013 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aTiOUoQrini for ; Tue, 20 Aug 2013 01:56:16 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id CE20311E80ED for ; Tue, 20 Aug 2013 01:56:15 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id k5so59478qej.22 for ; Tue, 20 Aug 2013 01:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xzJLLyfy+2ZasETqN+fXFDNpPS8pd9XzTePwAm7qXp8=; b=TXl24626IyelfMtF3ARHjyN8gWUZNjqV1RsVR+reaCSspnMwIrZERCpWm8h5JD2VVm pVFeGqMhuFApwaBdiy19IrV/e6KoB40WRP2R5ZQ9EESdYyKQqo7UPIEuCxT4IjehW5Xt tJbcparY/lo4E73T1vxQz+IT12DWCphMsMU6CcSvScYtHV2D+Y8MbE/rOu910aJuYiin DIgtsnxHUXl8ZJRIf1zjEhUVP+5ijSvESWDX8z9XwRWtvTjFrKlqnBhIULM9uhwcBv60 Q/T9uaWALkou/bZcmu03kBgUsRb7I9ZhH0SIafjDkNSSOY/JQeIKKYucDahaFgEmRg5l dOOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xzJLLyfy+2ZasETqN+fXFDNpPS8pd9XzTePwAm7qXp8=; b=C4ECdVwDvE39MnxLXmNZkfoWDaAEBJlzxAWUQ352NPkvcNlejaDKtOOrFCitc05FCU 7lGSBJuQtFsTG5HjY8WlLyu2MUyhL8te/yC1pBMgtCmYDp52vXIuMH7VtA9li4yehEhg 62zZE7G/TGe7X26pYP5HBPfLenHde1yW9k1a6v1yckYS7uPD8xVd5HMIRGGDUYr2tqds y1b3J07q+Cw7AvwqoCJg+RBKzKHZbFK9qsuDImX760aUgKg2oOTyNH6MTqAcoPm6XhNm BW+UxA9IY+eY8/3KQ2ZC+VXq+ahhS4aEdDlQPc16Sq0cGEqxOGnMPEBu3fWMOG7BuKge BQYA== X-Gm-Message-State: ALoCoQlCGrj6pBX2HQhTlc0F3cEN1X+t6K6bmD2JltXPSGRf52e809DfSTZbK+ZgXNBLcdBgg94hK1xKtHAu02WeEHYi2/xrdKyW1IOQRf6clGpKp6ElMr7DZO5B9uZuKuGDvoz2+6NAQRoVuz4/5BRYgjWNpM8cen4s3gWfQPf0lzLJ7/+Wi3ZvZl45ohbQjpqnuLbF5SE5 X-Received: by 10.224.46.202 with SMTP id k10mr2485992qaf.63.1376988975171; Tue, 20 Aug 2013 01:56:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.73 with HTTP; Tue, 20 Aug 2013 01:55:54 -0700 (PDT) In-Reply-To: <5211EBFD.2000403@si6networks.com> References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <5211EBFD.2000403@si6networks.com> From: Erik Kline Date: Tue, 20 Aug 2013 17:55:54 +0900 Message-ID: Subject: Re: 6MAN WG Last Call: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG 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, 20 Aug 2013 08:56:16 -0000 On 19 August 2013 18:57, Fernando Gont wrote: > Erik, > > On 08/19/2013 06:40 AM, Erik Kline wrote: >> I pre-apologize, as always, for my ignorance, but...is there an >> implementation of this? Specifically, I'm mildly concerned about this >> for link-local addresses. >> >> Compliant implementations cannot even begin any IPv6 link-local >> operations until the secret key has been loaded from stable storage. >> They also should load the DAD_Counter from non-volatile memory before >> starting link-local operations. And they MUST NOT fallback to other >> link-local autoconfig implementations (last paragraph of section 4). >> >> I agree that this all seems fine in theory. Are we collectively >> convinced this will not lead to tragically (IPv6-)orphaned machines in >> certain scenarios? > > Sorry, what are the scenarios you have in mind? Well, I guess first I wasn't 100% sure I could think of all the link-local uses and how they would interact with needing to load parameters before starting essential functions for higher layer IPv6 and application things. However, as I said I can't see a problem with it in theory. It's one more thing to wait for before waiting for DAD to complete. No theoretical change; fine. But secondly, how would you implement this in, say, Linux? Right now link-local IPv6 things can begin as soon as the module is loaded or as soon as an interface becomes active if it's already loaded. To support this scheme as I understand it, the Linux kernel ipv6 code would need to take some module parameters at boot or load time, so as to force it to not do link-layer-derived link-local autoconfig but instead load up the required parameters from non-volatile storage. Is my understanding correct? If so, has anyone written this and gotten feedback from net maintainers? I guess I just think that all of the concerns about addresses raised in draft-cooper-6man-ipv6-address-generation-privacy *don't* meaningfully apply to link-local addresses. That document's section 4.2.2 says that the addresses are basically available to an on-link adversary anyway. So I guess I don't see the point of "fixing" something that I don't think is actually broken in this specific context (speaking of link-local use case specifically). From rbonica@juniper.net Tue Aug 20 06:33:44 2013 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 6019621F9950 for ; Tue, 20 Aug 2013 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.974 X-Spam-Level: X-Spam-Status: No, score=-104.974 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncJ-EAqHA4jh for ; Tue, 20 Aug 2013 06:33:39 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 351B221F9590 for ; Tue, 20 Aug 2013 06:33:39 -0700 (PDT) Received: from mail202-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 20 Aug 2013 13:33:38 +0000 Received: from mail202-co9 (localhost [127.0.0.1]) by mail202-co9-R.bigfish.com (Postfix) with ESMTP id 9B187C008B; Tue, 20 Aug 2013 13:33:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zz98dI9371Ic89bh936eI542I1432Ic3eeM4015Ib73dMzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail202-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(501584002)(13464003)(469094003)(24454002)(51704005)(377424004)(199002)(189002)(164054003)(50986001)(74366001)(66066001)(59766001)(76576001)(31966008)(80976001)(80022001)(47976001)(47446002)(74662001)(63696002)(76786001)(83072001)(74316001)(74502001)(4396001)(33646001)(54316002)(74706001)(46102001)(69226001)(53806001)(81342001)(81542001)(81816001)(83322001)(56776001)(81686001)(47736001)(54356001)(76482001)(15202345003)(77982001)(56816003)(51856001)(76796001)(19580385001)(79102001)(19580395003)(77096001)(65816001)(74876001)(19580405001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail202-co9 (localhost.localdomain [127.0.0.1]) by mail202-co9 (MessageSwitch) id 1377005617286609_16274; Tue, 20 Aug 2013 13:33:37 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.234]) by mail202-co9.bigfish.com (Postfix) with ESMTP id 40E6BB40047; Tue, 20 Aug 2013 13:33:37 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 20 Aug 2013 13:33:35 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 20 Aug 2013 13:33:35 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 20 Aug 2013 13:33:33 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Tue, 20 Aug 2013 13:33:33 +0000 From: Ronald Bonica To: "C. M. Heard" , IPv6 Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHA= Date: Tue, 20 Aug 2013 13:33:32 +0000 Message-ID: <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09443CAA7E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 20 Aug 2013 13:33:44 -0000 Hi Mike, Thanks for your review of all three documents. The following is some gentle= pushback.=20 At IETF 87, the 6man WG was pretty clear that they are not ready to depreca= te IPv6 fragmentation. So, within the next few weeks, I will update that do= cument so that it makes only the following points: - IPv6 fragmentation doesn't work well because fragments are blocked on man= y paths - The IETF should not standardize any new protocols that rely on IPv6 fragm= entation - Some legacy protocols can break their reliance on fragmentation, others c= annot. Legacy protocols that can break their reliance on fragmentation shou= ld consider doing so. - Legacy protocols and implementations thereof will continue to send fragme= nts for a long time to come. Since fragmentation will be with us for a while, we need to deal with its i= ssues. Currently, we see two issues: - the tiny fragment problem - the long header problem The two problems are orthogonal to one another. It is possible for a packet= to display either problem without displaying the other.=20 Also, there is a very concrete solution for the tiny fragment problem. This= solution constitutes an UPDATE to RFC 2460 regarding sending and handling = tiny fragments. Since we are updating 2460, we need to publish a PS documen= t. There is no real solution to the long header problem. The best that we can = do is to put a stake in the ground, saying that implementations should forw= ard packets with header chains up to X bytes. There is no need to UPDATE RF= C 2460, or to publish a PS document. A BCP is good enough. I hope that this helps. Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Monday, August 19, 2013 8:58 PM > To: IPv6 > Subject: Re: 6MAN WG Last Call: chain-04> >=20 > Greetings, >=20 > My main question is why this draft is not better integrated with > draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, > which have overlapping or at least related subject matter. >=20 > The thrust of draft-ietf-6man-oversized-header-chain is to require that > all extension headers and the upper layer header appear in the first > IPv6 fragment and to define an ICMPv6 error message that may be sent > when that condtion is violated (type =3D Parameter Problem, code =3D IPv6 > first-fragment has incomplete IPv6 header chain). >=20 > The thrust of draft-wkumari-long-headers-01 is the claim that operators > have a requirement to filter at Layer 3 and Layer 4, at line rate, in > the network, and that in order to be able to do that, the entire header > chain needs to appear within a relatively short initial segment of the > IPv6 datagram -- the draft suggests 128 bytes. This is MUCH shorter > that the "within the first fragment" > constraint specified by draft-ietf-6man-oversized-header-chain. >=20 > There is also a strong hint (though not an explicit statement) in > draft-wkumari-long-headers-01 that entities that do in-network line- > rate filtering need to see layer 3 and 4 information in ALL datagrams, > which is at the heart of the subject matter of draft-bonica-6man-frag- > deprecate. >=20 > In my view, draft-ietf-6man-oversized-header-chain should not go to the > IESG until: >=20 > 1.) This WG decides what to do with draft-bonica-6man-frag-deprecate. > If the decision is to admit that IPv6 frgmentation works so > poorly in pratice that new protocols must not use it and > existing protocols should try not to use it, then a stronger > recommendation than just confining the header chain to the > initial fragment is probably in order -- perhaps something like > what's in draft-wkumari-long-headers. >=20 > 2.) This WG decides whether the ideas in draft-wkumari-long-headers > are basically sound. If so, then it would make sense (to me, > anyway) to merge it with draft-ietf-6man-oversized-header-chain. > The two drafts already agree (with admirable precision) on the > definition of what a complete IPv6 header chain is. One way to > merge the documents would be to add a section to > draft-ietf-6man-oversized-header-chain recognizing that there > are likely to be stringent limits on the size of a header chain > that an implementation can process and defining an ICMPv6 error > message that may be sent when these limits are exceeded (type =3D > Parameter Problem, code =3D IPv6 header chain exceeds > implementation's capacity). A recommendation on the minimum > size header chain that an implementation should support would > then be in order. >=20 > Thanks, >=20 > Mike Heard >=20 > On Tue, 13 Aug 2013, Ole Troan wrote: > > All, > > > > This message starts the second two week 6MAN Working Group on > advancing: > > > > Title : Implications of Oversized IPv6 Header Chains > > Author(s) : F. Gont, V. Manral, R. Bonica > > Filename : draft-ietf-6man-oversized-header-chain-04 > > Pages : 13 > > Date : 2013-08-13 > > > > http://tools.ietf.org/html/draft-ietf-6man-oversized-header- > chain-04 > > > > as a Proposed Standard. 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 August 27, 2013. > > > > The chairs would like to solicit one or two people in the working > > group to do a detailed review of the document. We would also > encourage > > volunteers to act as document shepherds. Please contact the chairs > > directly. > > > > Regards, > > > > Bob Hinden & Ole Tr=F8an From internet-drafts@ietf.org Tue Aug 20 12:33:46 2013 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 C76D611E8152; Tue, 20 Aug 2013 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oukelZ11IQR9; Tue, 20 Aug 2013 12:33:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F3321F92E7; Tue, 20 Aug 2013 12:33:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-multicast-scopes-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130820193337.31978.27705.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2013 12:33:37 -0700 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, 20 Aug 2013 19:33:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : IPv6 Multicast Address Scopes Author(s) : Ralph Droms Filename : draft-ietf-6man-multicast-scopes-00.txt Pages : 4 Date : 2013-08-20 Abstract: This document updates the definitions of IPv6 multicast scopes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-scopes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-multicast-scopes-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Tue Aug 20 13:16:58 2013 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 DCF5C11E8289 for ; Tue, 20 Aug 2013 13:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYIedpoaLYNl for ; Tue, 20 Aug 2013 13:16:57 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F3D3E11E8287 for ; Tue, 20 Aug 2013 13:16:56 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so866328pdj.29 for ; Tue, 20 Aug 2013 13:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OdMTfXKEK6TgC2qFgw8e2PMHNauIuLHboAa4H/x8M+Q=; b=f+IwfucCCE0kpeAZzdu4Bn30XwBDqRBUrLnFnUgXX8BBU961QZC4p29p3rDYpMNL3V g97lTFtqY4PmwyX9eFo6MWtADCC5hK5nWNPI3JXz6xhuvQiU1191hK4s7L0ebNOYp8MZ 1tKMrRf8mgh+RSksxxrRvdy+h3Ax1GYA+nBtc1/1BN1JBtnWgEFgQ2NqcU53ANiPYcKw KgXZ8JfblxcLgx6AcGnXd/Hsx1Z8p1joevZWVPa5POjW/jTSrDchPwQYObvEA8URJYef G5dM2YCyB48GU/Xst0WRfs1D1TifHIv+bgYKfclHpaTfoNR67phVHMWA4FZ+/Os1aEcv WyVw== X-Received: by 10.66.218.226 with SMTP id pj2mr5773995pac.62.1377029816573; Tue, 20 Aug 2013 13:16:56 -0700 (PDT) Received: from [192.168.178.20] (20.199.69.111.dynamic.snap.net.nz. [111.69.199.20]) by mx.google.com with ESMTPSA id oc10sm60525pbb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 13:16:55 -0700 (PDT) Message-ID: <5213CEBC.3040008@gmail.com> Date: Wed, 21 Aug 2013 08:17:00 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: 6MAN WG Last Call: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , IPv6 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, 20 Aug 2013 20:16:58 -0000 Hi Ron, On 21/08/2013 01:33, Ronald Bonica wrote: > Hi Mike, > > Thanks for your review of all three documents. The following is some gentle pushback. ... > There is no real solution to the long header problem. The best that we can do is to put a stake in the ground, saying that implementations should forward packets with header chains up to X bytes. There is no need to UPDATE RFC 2460, or to publish a PS document. A BCP is good enough. Architecturally, we have (I think) decided to say that header chains MUST NOT be fragmented (this draft) and SHOULD be forwarded (draft-ietf-6man-ext-transmit). I'm still a bit leery about making X bytes a rule rather than a health warning - who knows when someone might come up with a silicon-based solution that doesn't have an X bytes limitation? A carefully worded BCP that makes it clear that X bytes is a current engineering limit rather than an architectural limit seems about right. Keeping the documents separate provides flexibility for the future, too. Brian From fgont@si6networks.com Tue Aug 20 19:59:37 2013 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 D544D11E836C for ; Tue, 20 Aug 2013 19:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWGLfnb4MZQa for ; Tue, 20 Aug 2013 19:59:37 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F011E835F for ; Tue, 20 Aug 2013 19:59:36 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VBydv-0005nT-Ts; Wed, 21 Aug 2013 04:59:32 +0200 Message-ID: <52142D0E.4050906@si6networks.com> Date: Tue, 20 Aug 2013 23:59:26 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: 6MAN - active documents References: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man WG 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, 21 Aug 2013 02:59:38 -0000 Hi, Mikael, Thanks so much for your feedback! -- Please find my comments in-line... On 08/20/2013 05:32 AM, Mikael Abrahamsson wrote: >> draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd) > > -------------------------------------------------------------------- > NIT: > > F(): > A pseudorandom function (PRF) that is not computable from the > outside (without knowledge of the secret key), which should > produce an output of at least 64 bits.The PRF could be > implemented as a cryptographic hash of the concatenation of > each of the function parameters. > > Missing space in the middle line. Will fix this in the next rev. > ------------------------------------------------------------------- > > secret_key: > A secret key that is not known by the attacker. The secret > key MUST be initialized at operating system installation time > to a pseudo-random number (see [RFC4086] for randomness > requirements for security). An implementation MAY provide the > means for the the system administrator to change or display > the secret key. > > I think the text here should be that i MUST be initialized when the > functionality is enabled (or equivalent). I see you point. I guess something like "...initialized when this method is installed (e.g. at operating system installation time)" would do? > ------------------------------------------------------------------- > > There are numerous references to DAD. Isn't DAD attacks handled in other > documents that can be referenced, does this document really need to > outline this behaviour, perhaps even in conflict with other documents? I > don't remember where I read about this though, perhaps someone else > knows? It was discussed in SAVI anyway. This document discusses how to recover from DAD failures -- *this* is not discussed elsewhere. > I think it would be good to reference SAVI-WG documents on first-hop > security instead of writing new text on the subject. Where, specifically? > People seem to like > SEND, but I see send as hard to deploy in most scenarios because one > entity doesn't control both router and device. +1 -- and there's the PKI issue, etc. > Network_ID mentions SSID. What if I have an ethernet Interface and I > move my computer around, should it identify a new set of /64 network > address and/or gateway MAC address as a new network as well? I think > some text on this would be good guidance for implementors. That's left unspecified, since it might be tricky: there's might be more than one local router, for redundancy purposes -- but since it's the same network, you'd want your addresses to be stable. That's why in the SSID example we use the SSID, and not the router's MAC address or the like. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From swmike@swm.pp.se Tue Aug 20 20:16:45 2013 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 2AFA911E836D for ; Tue, 20 Aug 2013 20:16:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrWzEWZ-XtWL for ; Tue, 20 Aug 2013 20:16:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 89BA411E836A for ; Tue, 20 Aug 2013 20:16:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A3D869C; Wed, 21 Aug 2013 05:16:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 420E69A; Wed, 21 Aug 2013 05:16:41 +0200 (CEST) Date: Wed, 21 Aug 2013 05:16:41 +0200 (CEST) From: Mikael Abrahamsson To: Fernando Gont Subject: Re: 6MAN - active documents In-Reply-To: <52142D0E.4050906@si6networks.com> Message-ID: References: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> <52142D0E.4050906@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: 6man WG 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, 21 Aug 2013 03:16:45 -0000 On Tue, 20 Aug 2013, Fernando Gont wrote: >> ------------------------------------------------------------------- >> >> There are numerous references to DAD. Isn't DAD attacks handled in other >> documents that can be referenced, does this document really need to >> outline this behaviour, perhaps even in conflict with other documents? I >> don't remember where I read about this though, perhaps someone else >> knows? It was discussed in SAVI anyway. > > This document discusses how to recover from DAD failures -- *this* is > not discussed elsewhere. I've seen this discussion in SAVI a few years back. I can't find any documents now though so I don't know if it actually ended up anywhere. >> I think it would be good to reference SAVI-WG documents on first-hop >> security instead of writing new text on the subject. > > Where, specifically? Under 7 where ra-guard is mentioned. Oh, btw, the paragraph on RA-guard is missing a trailing ".". >> Network_ID mentions SSID. What if I have an ethernet Interface and I >> move my computer around, should it identify a new set of /64 network >> address and/or gateway MAC address as a new network as well? I think >> some text on this would be good guidance for implementors. > > That's left unspecified, since it might be tricky: there's might be more > than one local router, for redundancy purposes -- but since it's the > same network, you'd want your addresses to be stable. > > That's why in the SSID example we use the SSID, and not the router's MAC > address or the like. If it's tricky, doesn't that specifically warrant more text on the subject? -- Mikael Abrahamsson email: swmike@swm.pp.se From fgont@si6networks.com Tue Aug 20 20:52:14 2013 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 677C211E81B2 for ; Tue, 20 Aug 2013 20:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShA0U9gFTJt7 for ; Tue, 20 Aug 2013 20:52:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D91CD11E8150 for ; Tue, 20 Aug 2013 20:52:13 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VBzSm-0007Go-EV; Wed, 21 Aug 2013 05:52:04 +0200 Message-ID: <5214395B.20900@si6networks.com> Date: Wed, 21 Aug 2013 00:51:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: 6MAN - active documents References: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> <52142D0E.4050906@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man WG 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, 21 Aug 2013 03:52:14 -0000 On 08/21/2013 12:16 AM, Mikael Abrahamsson wrote: > >>> I think it would be good to reference SAVI-WG documents on first-hop >>> security instead of writing new text on the subject. >> >> Where, specifically? > > Under 7 where ra-guard is mentioned. Oh, btw, the paragraph on RA-guard > is missing a trailing ".". Does SAVI prevnt forged RAs? -- Because that's why RA-Guard is being referenced. >>> Network_ID mentions SSID. What if I have an ethernet Interface and I >>> move my computer around, should it identify a new set of /64 network >>> address and/or gateway MAC address as a new network as well? I think >>> some text on this would be good guidance for implementors. >> >> That's left unspecified, since it might be tricky: there's might be more >> than one local router, for redundancy purposes -- but since it's the >> same network, you'd want your addresses to be stable. >> >> That's why in the SSID example we use the SSID, and not the router's MAC >> address or the like. > > If it's tricky, doesn't that specifically warrant more text on the subject? The Network_ID parameter is optional. If you can come up with a Network_ID for your network, you can use it. However, in the case of Ethernet I don't think there's an obvious candidate. So I'd persoanlly leave the text as is. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Aug 20 20:52:41 2013 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 4696311E81A0 for ; Tue, 20 Aug 2013 20:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbhLcJhmdyIG for ; Tue, 20 Aug 2013 20:52:40 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id AA08C11E80FF for ; Tue, 20 Aug 2013 20:52:40 -0700 (PDT) Received: from ol128-236.fibertel.com.ar ([24.232.236.128] helo=[192.168.1.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VBzTH-0007H0-6s; Wed, 21 Aug 2013 05:52:36 +0200 Message-ID: <52140368.9010907@si6networks.com> Date: Tue, 20 Aug 2013 21:01:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Erik Kline Subject: Re: 6MAN WG Last Call: References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <5211EBFD.2000403@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG 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, 21 Aug 2013 03:52:41 -0000 Hi, Erik, On 08/20/2013 05:55 AM, Erik Kline wrote: >>> I agree that this all seems fine in theory. Are we collectively >>> convinced this will not lead to tragically (IPv6-)orphaned machines in >>> certain scenarios? >> >> Sorry, what are the scenarios you have in mind? > > Well, I guess first I wasn't 100% sure I could think of all the > link-local uses and how they would interact with needing to load > parameters before starting essential functions for higher layer IPv6 > and application things. Well, at the point you're going to load v6, you certainly had plenty of chances of loading any "parameters". For instance, you probably have a kernel running, already (which requires many more parameters than just a secret). > However, as I said I can't see a problem with > it in theory. It's one more thing to wait for before waiting for DAD > to complete. No theoretical change; fine. > > But secondly, how would you implement this in, say, Linux? Right now > link-local IPv6 things can begin as soon as the module is loaded or as > soon as an interface becomes active if it's already loaded. Please see above. I'm not that savvy in Linux internals. I'd note, though, that besides the above comment, BSD people didn't find any issues. > To support this scheme as I understand it, the Linux kernel ipv6 code > would need to take some module parameters at boot or load time, so as > to force it to not do link-layer-derived link-local autoconfig but > instead load up the required parameters from non-volatile storage. Is > my understanding correct? You need to have some secret available before you configure IPv6 addresses. Most likely, you'd get this secret from some config file -- but that's up to the implementation. > If so, has anyone written this and gotten > feedback from net maintainers? Not written, yet. But there have been a number of develeopers that have looked at this, and didn't find this "load a secret" thing a show-stopper. > I guess I just think that all of the concerns about addresses raised > in draft-cooper-6man-ipv6-address-generation-privacy *don't* > meaningfully apply to link-local addresses. That's assuming such IPv6 addresses will not leak out -- which I think you cannot guarantee. Stupid example (certainly not the best): your node contacting an MTA with a link local address, which leaks in the mail headers. (again, not the best example, but simply a proof of how addresses can leak, no matter whether they are link-local). > That document's section > 4.2.2 says that the addresses are basically available to an on-link > adversary anyway. So I guess I don't see the point of "fixing" > something that I don't think is actually broken in this specific > context (speaking of link-local use case specifically). Please see above. Moral of the story: be proactive. A bad idea is... a bad idea. So if you don't find a scenario where a bad idea can be harmful, that doesn't mean attacker won't find it, or that such scenario doesn't exist. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From swmike@swm.pp.se Tue Aug 20 21:17:31 2013 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 DC8AB11E818E for ; Tue, 20 Aug 2013 21:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM-QK-op0d15 for ; Tue, 20 Aug 2013 21:17:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1260C11E8166 for ; Tue, 20 Aug 2013 21:17:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B90E19C; Wed, 21 Aug 2013 06:17:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B07DC9A; Wed, 21 Aug 2013 06:17:17 +0200 (CEST) Date: Wed, 21 Aug 2013 06:17:17 +0200 (CEST) From: Mikael Abrahamsson To: Fernando Gont Subject: Re: 6MAN - active documents In-Reply-To: <5214395B.20900@si6networks.com> Message-ID: References: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> <52142D0E.4050906@si6networks.com> <5214395B.20900@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man WG 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, 21 Aug 2013 04:17:32 -0000 On Wed, 21 Aug 2013, Fernando Gont wrote: > Does SAVI prevnt forged RAs? -- Because that's why RA-Guard is being > referenced. Well, yes, it's within the charter anyway. http://datatracker.ietf.org/wg/savi/charter/ SAVI-WG aims to solve all kinds of first hop security problems. Unfortunately there has been too little atention on SAVI lately. -- Mikael Abrahamsson email: swmike@swm.pp.se From suresh.krishnan@ericsson.com Tue Aug 20 21:39:01 2013 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 6DE0A11E8173 for ; Tue, 20 Aug 2013 21:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcVBuGdiGcXK for ; Tue, 20 Aug 2013 21:38:55 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3411E8188 for ; Tue, 20 Aug 2013 21:38:54 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-e9-5214445ddaa4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8D.A9.03458.D5444125; Wed, 21 Aug 2013 06:38:53 +0200 (CEST) Received: from [164.48.125.52] (147.117.188.135) by smtps-am.internal.ericsson.com (147.117.188.90) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 21 Aug 2013 00:38:52 -0400 Message-ID: <521443B5.30307@ericsson.com> Date: Wed, 21 Aug 2013 00:36:05 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: 6MAN - active documents References: <91749D01-2330-47D7-963C-36CEF4B6014B@employees.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.135] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyuXRPlG6si0iQwaKXxhZPVr1hs3h59j2T xeS2FUDW0q1sDiweB499ZPRYsuQnk8eHQz3sHn8nPWQKYInisklJzcksSy3St0vgyug8c5O5 YCNLxcY1i5kbGPcydzFyckgImEicbDnPCGGLSVy4t56ti5GLQ0jgKKPE8rtfWCGc7YwSOzav YgKp4hXQlPjc94oNxGYRUJWYP/0fmM0GNGnDzs9gNaICYRL3zx2CqheUODnzCQuILQLUu3H7 BrB6ZoEIiX03P7CC2MICKhKfVn4Fs4UEyiWu/7jBDmJzCjhLdM+5wg5xnaTEtkXH2CF69SSm XG1hhLDlJba/ncMM0aspsXXNd6A5HED1yhI7ZiROYBSeheSKWUi6ZyHpXsDIvIqRo7Q4tSw3 3chwEyMw2I9JsDnuYFzwyfIQozQHi5I47wa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GM0/s8i+nyKrKH3CcM6U2wGvlOf9nxmi//9C1ZGIf8vUorYrXN6/cbnGV9FsBrkVV6z2y5eX 755bIfPNK0TigMNclQ93smpezWM3+HfxyTKN5fuUI6qWqU/f11bf9mjD2SkS896FNve6TN6i c8lb55fmEoXT6pUSosErkmf+ENqdmlftuUHI21iJpTgj0VCLuag4EQCQkH01RAIAAA== Cc: fgont@si6networks.com, 6man WG 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, 21 Aug 2013 04:39:01 -0000 Hi Fernando/Mike, On 08/20/2013 04:32 AM, Mikael Abrahamsson wrote: > > Network_ID mentions SSID. What if I have an ethernet Interface and I > move my computer around, should it identify a new set of /64 network > address and/or gateway MAC address as a new network as well? I think > some text on this would be good guidance for implementors. RFC6059 is targeted at this problem (identifying attachment to a new network). It does require changes to host data structures but there are concepts there you can refer to/reuse. Thanks Suresh From suresh.krishnan@ericsson.com Tue Aug 20 21:42:08 2013 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 15F9511E8173 for ; Tue, 20 Aug 2013 21:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX7sqNHtA-Z0 for ; Tue, 20 Aug 2013 21:42:03 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EEB7211E8199 for ; Tue, 20 Aug 2013 21:42:02 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-c5-521445194f34 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A5.4B.09414.91544125; Wed, 21 Aug 2013 06:42:02 +0200 (CEST) Received: from [164.48.125.52] (147.117.188.134) by smtps-am.internal.ericsson.com (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 21 Aug 2013 00:42:01 -0400 Message-ID: <52144475.9020101@ericsson.com> Date: Wed, 21 Aug 2013 00:39:17 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: ayourtch Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd review References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.134] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyuXRPiK6Uq0iQwZQJfBZfm+exWbw8+57J YsHypSwWn17vZ7OYMeUdowOrx5TfG1k9liz5yeSxcfs6lgDmKC6blNSczLLUIn27BK6MaTca WAv+MFes/raepYFxBnMXIyeHhICJRN/NO0wQtpjEhXvr2boYuTiEBI4yStxuf8YE4WxnlPjc cAqog4ODV0BbYv67LJAGFgFViSObnrCA2GxAgzbs/Aw2SFQgTOL+uUNgNq+AoMTJmRA1IgKK EtN2/GUDGcMsUCWxY4otSFhYwEFi2aUFLCBhIQE7ieu/zUHCnAL2ErMmdLJCnCYpsW3RMXYQ m1lAT2LK1RZGCFteYvvbOWCvCAloSmxd8x2qXlni37sVLBMYhWchOWIWkvZZSNoXMDKvYuQo LU4ty003MtjECAz0YxJsujsY97y0PMQozcGiJM67Su9MoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQZGk5kCna25bqfZeCOMY9Y8VObav+H115lTn+/bqevnO09bKzhpzfsbakHJbiHZ6jqi UziTe3Penlw2NTVWsOMi30u7vV05oknNZXtDXP4IHfsYZxzZHRISdPKe4spmpqtM+t73i1km K6fvYt92hzONQ830wzL+K2cKVUN4uLYHuz2qjYqee12JpTgj0VCLuag4EQCjPrhlQgIAAA== Cc: nordmark@cisco.com, ipv6@ietf.org, pthubert@cisco.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: Wed, 21 Aug 2013 04:42:08 -0000 Hi Andrew, On 08/05/2013 06:51 AM, ayourtch wrote: > The RS sending mechanism will be resilient, I assume, such that the node > does get RA even in a high-loss environments, right ? Maybe useful to > include a paragraph or two on the unreliability of this mechanism. I > think Suresh said he had something on this, probably worth referencing. Here is the draft I was talking about. The draft will go to WGLC soon. http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01 Thanks Suresh From swmike@swm.pp.se Tue Aug 20 22:36:04 2013 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 9231B11E81AD for ; Tue, 20 Aug 2013 22:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANnkuwi0Xpt3 for ; Tue, 20 Aug 2013 22:35:58 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3679A11E80F2 for ; Tue, 20 Aug 2013 22:35:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C255BA1; Wed, 21 Aug 2013 07:35:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DB3499C; Wed, 21 Aug 2013 07:35:51 +0200 (CEST) Date: Wed, 21 Aug 2013 07:35:51 +0200 (CEST) From: Mikael Abrahamsson To: Erik Kline Subject: Re: 6MAN WG Last Call: In-Reply-To: Message-ID: References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <5211EBFD.2000403@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man WG 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, 21 Aug 2013 05:36:04 -0000 On Tue, 20 Aug 2013, Erik Kline wrote: > To support this scheme as I understand it, the Linux kernel ipv6 code > would need to take some module parameters at boot or load time, so as to > force it to not do link-layer-derived link-local autoconfig but instead > load up the required parameters from non-volatile storage. Is my > understanding correct? If so, has anyone written this and gotten > feedback from net maintainers? Actually this would be good if it was fixed because the way it was done caused other problems. It's really hard to make a linux (debian 6.0 for instance) come up and *not* do RS and then create EUI64 based addresses. I have this in sysctl.conf: net.ipv6.conf.default.accept_ra=0 net.ipv6.conf.eth0.accept_ra=0 net.ipv6.conf.eth1.accept_ra=0 net.ipv6.conf.eth2.accept_ra=0 net.ipv6.conf.eth3.accept_ra=0 net.ipv6.conf.eth4.accept_ra=0 At least in debian 6.0 this didn't kick in until too late in the boot process, the kernel had already brought up the interfaces and done RS and created addresses and routing. It didn't listen to RAs after that, the manual static config kicked in, and I had to use "ip -6 address delete" to get rid of the EUI64 based addresses and privacy addresses. Actually I upgraded to debian 7.0 the other week and I don't remember having to delete the EUI64 based addresses, so this might have been fixed, or I just forgot to check and they timed out after a while when the kernel ignored RAs after the above config kicked in. -- Mikael Abrahamsson email: swmike@swm.pp.se From heard@pobox.com Tue Aug 20 23:04:27 2013 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 BF5A311E80FD for ; Tue, 20 Aug 2013 23:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc0+7vBgqgEr for ; Tue, 20 Aug 2013 23:04:22 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D8B11E8163 for ; Tue, 20 Aug 2013 23:04:22 -0700 (PDT) Received: (qmail 24252 invoked from network); 20 Aug 2013 23:04:18 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Aug 2013 23:04:18 -0700 Date: Tue, 20 Aug 2013 23:04:18 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: 6MAN WG Last Call: In-Reply-To: <5213CEBC.3040008@gmail.com> Message-ID: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 21 Aug 2013 06:04:27 -0000 On Wed, 21 Aug 2013, Brian E Carpenter wrote: > Hi Ron, > > On 21/08/2013 01:33, Ronald Bonica wrote: > > Hi Mike, > > > > Thanks for your review of all three documents. The following is some gentle pushback. > > ... > > > There is no real solution to the long header problem. The best > > that we can do is to put a stake in the ground, saying that > > implementations should forward packets with header chains up to > > X bytes. There is no need to UPDATE RFC 2460, or to publish a PS > > document. A BCP is good enough. > > Architecturally, we have (I think) decided to say that header chains MUST NOT > be fragmented (this draft) and SHOULD be forwarded (draft-ietf-6man-ext-transmit). > I'm still a bit leery about making X bytes a rule rather than a health > warning - who knows when someone might come up with a silicon-based solution > that doesn't have an X bytes limitation? A carefully worded BCP that makes > it clear that X bytes is a current engineering limit rather than an > architectural limit seems about right. > > Keeping the documents separate provides flexibility for the future, too. > A contrary point of view is that standards-track specs, above everything else, are instructions to implementors, and other things being equal, having things in fewer places rather than more simplifies life for the implementor. I say this from the perspective of one who (many years ago) came late to the IPv4 party and found it a struggle to ferret out the necessary information. I agree that advice like "be prepared to handle header chains of at least X bytes" should be a health warning rather than a normative rule, and for that alone a BCP would be fine. But if we acknowledge that for the present, some implementations have a limit to the size of header chains that they can process, would it not be reasonable to provide guidance -- which I think would need to be in a standards track spec -- as to what kind of ICMPv6 message is appropriate if their limit is hit? (I previously suggested type = Parameter Problem, code = IPv6 header chain exceeds implementation's capacity; I neglected to say anything about the pointer; it should probably point to the first header byte that could not be processed.) All that being said, it is certainly possible to get our work done with separate documents (of whatever type). Incidentally, I could not find guidance in draft-ietf-6man-oversized-header-chain-04 as to how the set the pointer field of an ICMPv6 message sent when a first-fragment with an incomplete header chain is descarded. Left to my own devices I would probably make it point to the Payload Length in the IPv6 header, but it would be best for the spec to spell this out. Thanks, Mike Heard P.S. Thanks for keeping the pushback gentle :-) From ayourtch@cisco.com Wed Aug 21 02:36:50 2013 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 5D9AF11E81B0 for ; Wed, 21 Aug 2013 02:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alHOmD6k8QH3 for ; Wed, 21 Aug 2013 02:36:46 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C611E81C3 for ; Wed, 21 Aug 2013 02:36:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7L9ae0E003896 for ; Wed, 21 Aug 2013 18:36:41 +0900 (JST) Received: from [10.61.200.187] ([10.61.200.187]) by bonfire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7L9aDxr006846; Wed, 21 Aug 2013 02:36:19 -0700 (PDT) Date: Wed, 21 Aug 2013 10:36:08 +0100 (WEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Suresh Krishnan Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd review In-Reply-To: <52144475.9020101@ericsson.com> Message-ID: References: <52144475.9020101@ericsson.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 21 Aug 2013 04:29:10 -0700 Cc: nordmark@cisco.com, ipv6@ietf.org, pthubert@cisco.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: Wed, 21 Aug 2013 09:36:50 -0000 Hi Suresh, On Wed, 21 Aug 2013, Suresh Krishnan wrote: > Hi Andrew, > > On 08/05/2013 06:51 AM, ayourtch wrote: >> The RS sending mechanism will be resilient, I assume, such that the node >> does get RA even in a high-loss environments, right ? Maybe useful to >> include a paragraph or two on the unreliability of this mechanism. I >> think Suresh said he had something on this, probably worth referencing. > > Here is the draft I was talking about. The draft will go to WGLC soon. > > http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01 This is a much needed work, awesome, thanks! I hope we see all hosts doing it soon. (I've a couple of Qs on the resilient RS, I'll unicast them, to avoid the thread pollution). --a > > Thanks > Suresh > From rbonica@juniper.net Wed Aug 21 05:47:46 2013 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 58B7811E8394 for ; Wed, 21 Aug 2013 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNHTJbykhHFU for ; Wed, 21 Aug 2013 05:47:40 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7611E8386 for ; Wed, 21 Aug 2013 05:47:39 -0700 (PDT) Received: from mail221-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 12:47:38 +0000 Received: from mail221-tx2 (localhost [127.0.0.1]) by mail221-tx2-R.bigfish.com (Postfix) with ESMTP id C89C11201EB; Wed, 21 Aug 2013 12:47:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail221-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(33646001)(77096001)(69226001)(81342001)(81816001)(47736001)(81686001)(56776001)(49866001)(81542001)(74706001)(54316002)(65816001)(46102001)(51856001)(76796001)(79102001)(74876001)(4396001)(76482001)(54356001)(77982001)(56816003)(83322001)(80022001)(80976001)(47976001)(31966008)(59766001)(50986001)(53806001)(66066001)(76786001)(76576001)(74366001)(83072001)(74502001)(63696002)(74662001)(74316001)(47446002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB244; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail221-tx2 (localhost.localdomain [127.0.0.1]) by mail221-tx2 (MessageSwitch) id 1377089255909429_24485; Wed, 21 Aug 2013 12:47:35 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.242]) by mail221-tx2.bigfish.com (Postfix) with ESMTP id D107D6C0041; Wed, 21 Aug 2013 12:47:35 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 12:47:33 +0000 Received: from BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 21 Aug 2013 12:47:32 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB244.namprd05.prod.outlook.com (10.242.198.152) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 21 Aug 2013 12:47:26 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Wed, 21 Aug 2013 12:47:26 +0000 From: Ronald Bonica To: "C. M. Heard" , IPv6 Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHCAAHgGAIAApBcAgABuikA= Date: Wed, 21 Aug 2013 12:47:26 +0000 Message-ID: <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0945B0CC72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 21 Aug 2013 12:47:46 -0000 Mike, Good point! The pointer field in the ICMPv6 Parameter Problem Message needs= to carry some value. My first guess would be to point at the first byte of the Fragment Header, = because the packet is improperly fragmented. I would not point at the Paylo= ad Length in the IPv6 header, because the Payload Length is correct. Does that work for everybody? Ron >=20 > Incidentally, I could not find guidance in > draft-ietf-6man-oversized-header-chain-04 as to how the set the pointer > field of an ICMPv6 message sent when a first-fragment with an > incomplete header chain is descarded. Left to my own devices I would > probably make it point to the Payload Length in the IPv6 header, but it > would be best for the spec to spell this out. >=20 From heard@pobox.com Wed Aug 21 07:29:28 2013 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 E399911E80F1 for ; Wed, 21 Aug 2013 07:29: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHcAbnBnFRHu for ; Wed, 21 Aug 2013 07:29:23 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6021F9B97 for ; Wed, 21 Aug 2013 07:29:23 -0700 (PDT) Received: (qmail 8390 invoked from network); 21 Aug 2013 07:29:21 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Aug 2013 07:29:21 -0700 Date: Wed, 21 Aug 2013 07:29:21 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: RE: 6MAN WG Last Call: In-Reply-To: <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> Message-ID: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 21 Aug 2013 14:29:29 -0000 The reason I didn't suggest pointing at the Fragment Header is because it would carry the same information that it would in a correctly fragmented packet, namely M=1 and Fragment Offset=0 (the signature of an initial fragment). The Payload Length field is what indicates that the fragment is too short to contain all the extension headers and the upper layer header; its value would have to be different in a legitimate packet. Hence my suggestion to point there. //cmh On Wed, 21 Aug 2013, Ronald Bonica wrote: > Mike, > > Good point! The pointer field in the ICMPv6 Parameter Problem > Message needs to carry some value. > > My first guess would be to point at the first byte of the Fragment > Header, because the packet is improperly fragmented. I would not > point at the Payload Length in the IPv6 header, because the > Payload Length is correct. > > Does that work for everybody? > > Ron > > > > > > Incidentally, I could not find guidance in > > draft-ietf-6man-oversized-header-chain-04 as to how the set the pointer > > field of an ICMPv6 message sent when a first-fragment with an > > incomplete header chain is descarded. Left to my own devices I would > > probably make it point to the Payload Length in the IPv6 header, but it > > would be best for the spec to spell this out. > > > From otroan@employees.org Wed Aug 21 07:36:50 2013 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 8E06611E8210 for ; Wed, 21 Aug 2013 07:36: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtO1oYgmvfqb for ; Wed, 21 Aug 2013 07:36:44 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E011E81C9 for ; Wed, 21 Aug 2013 07:36:44 -0700 (PDT) Received: from dhcp-10-61-97-232.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 81BBA5E9D; Wed, 21 Aug 2013 07:36:43 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_17E2E200-CF4D-4836-ADC9-4A491F8402E5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: Date: Wed, 21 Aug 2013 16:36:40 +0200 Message-Id: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> To: C. M. Heard X-Mailer: Apple Mail (2.1508) Cc: IPv6 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, 21 Aug 2013 14:36:50 -0000 --Apple-Mail=_17E2E200-CF4D-4836-ADC9-4A491F8402E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The reason I didn't suggest pointing at the Fragment Header is=20 > because it would carry the same information that it would in a=20 > correctly fragmented packet, namely M=3D1 and Fragment Offset=3D0 (the=20= > signature of an initial fragment). The Payload Length field is what=20= > indicates that the fragment is too short to contain all the=20 > extension headers and the upper layer header; its value would have=20 > to be different in a legitimate packet. Hence my suggestion to=20 > point there. or set the pointer field to 0? given that there really isn't an octet = offset where an error has been detected. cheers, Ole --Apple-Mail=_17E2E200-CF4D-4836-ADC9-4A491F8402E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSFNB5AAoJEFuJXizso86gWTkH/3Nzz3tVcbSmmBKCC7fi33B3 M5RcUS/z2u/cPK09gAUxRZXm8kvqujfrVejJzgWGrdgbgNxq1KhowhemrpENPnd3 M7FeGEzrRy4XgobKXR2do6TbW1kzgqm14Kv111RN2dkDpgbo3g9PpwrKKI6vXqAK aW8tX5hIWgkQm88SlrzwKOGhMSOWEkrtOPXoJycHSyFH+moZh/QlCwY00VdCQeJo gbCVAweTzXoT6ZxCfTFFne091D9QVRyPjeF+IsNuHw3wAL+hVE9Fga3878nXwNCi tWZdzcPN+WdOZZ5s68mvLdWmzL4tAuR9yhKRzlqUJ/GVCO0Q7b8sIum7R0fudrs= =8YDT -----END PGP SIGNATURE----- --Apple-Mail=_17E2E200-CF4D-4836-ADC9-4A491F8402E5-- From rbonica@juniper.net Wed Aug 21 07:39:16 2013 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 7534C21F9962 for ; Wed, 21 Aug 2013 07:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.016 X-Spam-Level: X-Spam-Status: No, score=-104.016 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qro+FaSkRUgU for ; Wed, 21 Aug 2013 07:39:11 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id EC10B21F999E for ; Wed, 21 Aug 2013 07:39:10 -0700 (PDT) Received: from mail112-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 14:39:10 +0000 Received: from mail112-ch1 (localhost [127.0.0.1]) by mail112-ch1-R.bigfish.com (Postfix) with ESMTP id EF8694400C1; Wed, 21 Aug 2013 14:39:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail112-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(13464003)(199002)(189002)(24454002)(377454003)(66066001)(47736001)(74316001)(33646001)(77982001)(76482001)(74502001)(83072001)(19580405001)(51856001)(74706001)(54316002)(56776001)(46102001)(74876001)(69226001)(80976001)(80022001)(31966008)(81342001)(63696002)(50986001)(47976001)(74662001)(19580385001)(83322001)(4396001)(81542001)(49866001)(19580395003)(47446002)(59766001)(65816001)(81686001)(76576001)(77096001)(56816003)(54356001)(76786001)(79102001)(53806001)(76796001)(81816001)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB243; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail112-ch1 (localhost.localdomain [127.0.0.1]) by mail112-ch1 (MessageSwitch) id 1377095947343961_21568; Wed, 21 Aug 2013 14:39:07 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail112-ch1.bigfish.com (Postfix) with ESMTP id 4E9BD420031; Wed, 21 Aug 2013 14:39:07 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 14:39:06 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 21 Aug 2013 14:39:05 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 21 Aug 2013 14:39:04 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Wed, 21 Aug 2013 14:39:04 +0000 From: Ronald Bonica To: "C. M. Heard" , IPv6 Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHCAAHgGAIAApBcAgABuikCAAB6SgIAAAjxg Date: Wed, 21 Aug 2013 14:39:03 +0000 Message-ID: <12fcf9ec47f143838bc5a422f830a07b@BL2PR05MB243.namprd05.prod.outlook.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0945B0CC72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 21 Aug 2013 14:39:16 -0000 Mike, I can see the argument both ways. Does anybody else have an opinion? Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Wednesday, August 21, 2013 10:29 AM > To: IPv6 > Subject: RE: 6MAN WG Last Call: chain-04> >=20 > The reason I didn't suggest pointing at the Fragment Header is because > it would carry the same information that it would in a correctly > fragmented packet, namely M=3D1 and Fragment Offset=3D0 (the signature of > an initial fragment). The Payload Length field is what indicates that > the fragment is too short to contain all the extension headers and the > upper layer header; its value would have to be different in a > legitimate packet. Hence my suggestion to point there. >=20 > //cmh >=20 > On Wed, 21 Aug 2013, Ronald Bonica wrote: > > Mike, > > > > Good point! The pointer field in the ICMPv6 Parameter Problem Message > > needs to carry some value. > > > > My first guess would be to point at the first byte of the Fragment > > Header, because the packet is improperly fragmented. I would not > point > > at the Payload Length in the IPv6 header, because the Payload Length > > is correct. > > > > Does that work for everybody? > > > > Ron > > > > > > > > > > Incidentally, I could not find guidance in > > > draft-ietf-6man-oversized-header-chain-04 as to how the set the > > > pointer field of an ICMPv6 message sent when a first-fragment with > > > an incomplete header chain is descarded. Left to my own devices I > > > would probably make it point to the Payload Length in the IPv6 > > > header, but it would be best for the spec to spell this out. > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From rbonica@juniper.net Wed Aug 21 07:40:59 2013 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 823B121F996A for ; Wed, 21 Aug 2013 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.956 X-Spam-Level: X-Spam-Status: No, score=-103.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orbL2H12iqZc for ; Wed, 21 Aug 2013 07:40:37 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3874D21F999E for ; Wed, 21 Aug 2013 07:40:37 -0700 (PDT) Received: from mail57-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 14:40:36 +0000 Received: from mail57-ch1 (localhost [127.0.0.1]) by mail57-ch1-R.bigfish.com (Postfix) with ESMTP id 275C62E0170; Wed, 21 Aug 2013 14:40:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail57-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(13464003)(199002)(189002)(377454003)(66066001)(47736001)(74316001)(33646001)(77982001)(76482001)(74502001)(83072001)(19580405001)(51856001)(74706001)(54316002)(56776001)(46102001)(74876001)(69226001)(80976001)(80022001)(31966008)(81342001)(63696002)(50986001)(47976001)(74662001)(83322001)(4396001)(81542001)(49866001)(19580395003)(47446002)(59766001)(65816001)(81686001)(76576001)(77096001)(56816003)(54356001)(76786001)(79102001)(53806001)(76796001)(81816001)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB243; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail57-ch1 (localhost.localdomain [127.0.0.1]) by mail57-ch1 (MessageSwitch) id 1377096028674200_4152; Wed, 21 Aug 2013 14:40:28 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail57-ch1.bigfish.com (Postfix) with ESMTP id 1BCAE440048; Wed, 21 Aug 2013 14:40:28 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 14:40:26 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 21 Aug 2013 14:40:25 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 21 Aug 2013 14:40:24 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Wed, 21 Aug 2013 14:40:24 +0000 From: Ronald Bonica To: Ole Troan , C.M.Heard Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHCAAHgGAIAApBcAgABuikCAAB6SgIAAAgsAgAAAuxA= Date: Wed, 21 Aug 2013 14:40:23 +0000 Message-ID: <0ed0fcc2f9334d299226dc7fc59bba6f@BL2PR05MB243.namprd05.prod.outlook.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0945B0CC72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 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, 21 Aug 2013 14:40:59 -0000 This works, too. But now we have three participants in the discussion and t= hree opinions! Let's just pick one! Does anybody have a coin? Ron > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ole Troan > Sent: Wednesday, August 21, 2013 10:37 AM > To: C.M.Heard > Cc: IPv6 > Subject: Re: 6MAN WG Last Call: chain-04> >=20 > > The reason I didn't suggest pointing at the Fragment Header is > because > > it would carry the same information that it would in a correctly > > fragmented packet, namely M=3D1 and Fragment Offset=3D0 (the signature = of > > an initial fragment). The Payload Length field is what indicates > that > > the fragment is too short to contain all the extension headers and > the > > upper layer header; its value would have to be different in a > > legitimate packet. Hence my suggestion to point there. >=20 > or set the pointer field to 0? given that there really isn't an octet > offset where an error has been detected. >=20 > cheers, > Ole From otroan@employees.org Wed Aug 21 07:56:29 2013 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 4911611E80D9 for ; Wed, 21 Aug 2013 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrpPDWcCaJUR for ; Wed, 21 Aug 2013 07:56:10 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2F011E8234 for ; Wed, 21 Aug 2013 07:56:10 -0700 (PDT) Received: from dhcp-10-61-97-232.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 114B75E61; Wed, 21 Aug 2013 07:56:05 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_61B1A296-C480-47CF-BE71-85DED106313C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: <0ed0fcc2f9334d299226dc7fc59bba6f@BL2PR05MB243.namprd05.prod.outlook.com> Date: Wed, 21 Aug 2013 16:56:02 +0200 Message-Id: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> <0ed0fcc2f9334d299226dc7fc59bba6f@BL2PR05MB243.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1508) Cc: "C.M.Heard" , IPv6 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, 21 Aug 2013 14:56:30 -0000 --Apple-Mail=_61B1A296-C480-47CF-BE71-85DED106313C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > This works, too. But now we have three participants in the discussion = and three opinions! >=20 > Let's just pick one! Does anybody have a coin? who calls "edge"? ;-) cheers, Ole >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of >> Ole Troan >> Sent: Wednesday, August 21, 2013 10:37 AM >> To: C.M.Heard >> Cc: IPv6 >> Subject: Re: 6MAN WG Last Call: > chain-04> >>=20 >>> The reason I didn't suggest pointing at the Fragment Header is >> because >>> it would carry the same information that it would in a correctly >>> fragmented packet, namely M=3D1 and Fragment Offset=3D0 (the = signature of >>> an initial fragment). The Payload Length field is what indicates >> that >>> the fragment is too short to contain all the extension headers and >> the >>> upper layer header; its value would have to be different in a >>> legitimate packet. Hence my suggestion to point there. >>=20 >> or set the pointer field to 0? given that there really isn't an octet >> offset where an error has been detected. >>=20 >> cheers, >> Ole >=20 --Apple-Mail=_61B1A296-C480-47CF-BE71-85DED106313C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSFNUDAAoJEFuJXizso86gS6EIAJP09I4F7jo0nzr07Eo5liR+ tuIgjWzzoRYwTARzXL4IVhtidAJ8DUCNag/1fRXia85tNoy+dGnGoz9PUhHVeud5 HzL1bt2Sz2YnzTWIX46cJflKpoExyDSXvGl4Gqe0dF9PCeqgBMsBFFdDtas2XZNE 6zdcII8T2Kg3mfTk7fI/iNQnVHRdSwGssETV+l4R71xpB05q+KmgG3CGon1w2AX6 D1LJ/PL5yvGtPzVr0hF/Dsqt0uKvdRACDKFHQ8XklJ4qJ8kGPntRbyj4WgRSv441 O7QP6F78SFYl+z2N/Fy5Gq3jfoKYseJnDqqpI7bXRLDKFm2S3usUciwTMYUB1Zs= =F3wz -----END PGP SIGNATURE----- --Apple-Mail=_61B1A296-C480-47CF-BE71-85DED106313C-- From rbonica@juniper.net Wed Aug 21 08:05:01 2013 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 0700011E821F for ; Wed, 21 Aug 2013 08:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.912 X-Spam-Level: X-Spam-Status: No, score=-103.912 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH+3-wg8BWdr for ; Wed, 21 Aug 2013 08:04:54 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id B769711E8103 for ; Wed, 21 Aug 2013 08:04:54 -0700 (PDT) Received: from mail102-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 15:04:54 +0000 Received: from mail102-co1 (localhost [127.0.0.1]) by mail102-co1-R.bigfish.com (Postfix) with ESMTP id 446059401C3; Wed, 21 Aug 2013 15:04:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail102-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(189002)(199002)(51704005)(377454003)(81342001)(76796001)(46102001)(79102001)(83072001)(74366001)(47976001)(77096001)(81542001)(76786001)(50986001)(77982001)(59766001)(47736001)(80022001)(56816003)(49866001)(66066001)(74316001)(81686001)(47446002)(31966008)(74706001)(51856001)(76482001)(54356001)(54316002)(74502001)(74662001)(19580405001)(19580395003)(63696002)(83322001)(74876001)(56776001)(4396001)(53806001)(65816001)(81816001)(80976001)(76576001)(69226001)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB242; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail102-co1 (localhost.localdomain [127.0.0.1]) by mail102-co1 (MessageSwitch) id 1377097492663747_6567; Wed, 21 Aug 2013 15:04:52 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.252]) by mail102-co1.bigfish.com (Postfix) with ESMTP id 94131300034; Wed, 21 Aug 2013 15:04:52 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 15:04:49 +0000 Received: from BL2PR05MB242.namprd05.prod.outlook.com (10.242.198.141) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 21 Aug 2013 15:04:45 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB242.namprd05.prod.outlook.com (10.242.198.141) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 21 Aug 2013 15:04:45 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Wed, 21 Aug 2013 15:04:45 +0000 From: Ronald Bonica To: Ole Troan Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHCAAHgGAIAApBcAgABuikCAAB6SgIAAAgsAgAAAuxCAAASuAIAAAjhw Date: Wed, 21 Aug 2013 15:04:43 +0000 Message-ID: <6e42266d78964c3c8683e1188de3d026@BL2PR05MB243.namprd05.prod.outlook.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> <0ed0fcc2f9334d299226dc7fc59bba6f@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0945B0CC72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "C.M.Heard" , IPv6 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, 21 Aug 2013 15:05:01 -0000 I am happy to set the pointer field to 0 if Mike agrees. Ron > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Wednesday, August 21, 2013 10:56 AM > To: Ronald Bonica > Cc: C.M.Heard; IPv6 > Subject: Re: 6MAN WG Last Call: chain-04> >=20 > > This works, too. But now we have three participants in the discussion > and three opinions! > > > > Let's just pick one! Does anybody have a coin? >=20 > who calls "edge"? ;-) >=20 > cheers, > Ole >=20 > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > >> Of Ole Troan > >> Sent: Wednesday, August 21, 2013 10:37 AM > >> To: C.M.Heard > >> Cc: IPv6 > >> Subject: Re: 6MAN WG Last Call: >> chain-04> > >> > >>> The reason I didn't suggest pointing at the Fragment Header is > >> because > >>> it would carry the same information that it would in a correctly > >>> fragmented packet, namely M=3D1 and Fragment Offset=3D0 (the signatur= e > >>> of an initial fragment). The Payload Length field is what > indicates > >> that > >>> the fragment is too short to contain all the extension headers and > >> the > >>> upper layer header; its value would have to be different in a > >>> legitimate packet. Hence my suggestion to point there. > >> > >> or set the pointer field to 0? given that there really isn't an > octet > >> offset where an error has been detected. > >> > >> cheers, > >> Ole > > From heard@pobox.com Wed Aug 21 09:00:55 2013 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 04A3D11E80E3 for ; Wed, 21 Aug 2013 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdvf9df1pX5N for ; Wed, 21 Aug 2013 09:00:50 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6A611E822E for ; Wed, 21 Aug 2013 09:00:47 -0700 (PDT) Received: (qmail 14619 invoked from network); 21 Aug 2013 09:00:44 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Aug 2013 09:00:44 -0700 Date: Wed, 21 Aug 2013 09:00:44 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Ronald Bonica Subject: RE: 6MAN WG Last Call: In-Reply-To: <6e42266d78964c3c8683e1188de3d026@BL2PR05MB243.namprd05.prod.outlook.com> Message-ID: References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> <0ed0fcc2f9334d299226dc7fc59bba6f@BL2PR05MB243.namprd05.prod.outlook.com> <6e42266d78964c3c8683e1188de3d026@BL2PR05MB243.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPv6 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, 21 Aug 2013 16:00:55 -0000 Works for me. //cmh On Wed, 21 Aug 2013, Ronald Bonica wrote: > I am happy to set the pointer field to 0 if Mike agrees. > > Ron > > > > -----Original Message----- > > From: Ole Troan [mailto:otroan@employees.org] > > Sent: Wednesday, August 21, 2013 10:56 AM > > To: Ronald Bonica > > Cc: C.M.Heard; IPv6 > > Subject: Re: 6MAN WG Last Call: > chain-04> > > > > > This works, too. But now we have three participants in the discussion > > and three opinions! > > > > > > Let's just pick one! Does anybody have a coin? > > > > who calls "edge"? ;-) > > > > cheers, > > Ole > > > > > > > >> -----Original Message----- > > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > >> Of Ole Troan > > >> Sent: Wednesday, August 21, 2013 10:37 AM > > >> To: C.M.Heard > > >> Cc: IPv6 > > >> Subject: Re: 6MAN WG Last Call: > >> chain-04> > > >> > > >>> The reason I didn't suggest pointing at the Fragment Header is > > >> because > > >>> it would carry the same information that it would in a correctly > > >>> fragmented packet, namely M=1 and Fragment Offset=0 (the signature > > >>> of an initial fragment). The Payload Length field is what > > indicates > > >> that > > >>> the fragment is too short to contain all the extension headers and > > >> the > > >>> upper layer header; its value would have to be different in a > > >>> legitimate packet. Hence my suggestion to point there. > > >> > > >> or set the pointer field to 0? given that there really isn't an > > octet > > >> offset where an error has been detected. > > >> > > >> cheers, > > >> Ole > > > > > > From rbonica@juniper.net Wed Aug 21 09:03:27 2013 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 678FA11E80E3 for ; Wed, 21 Aug 2013 09:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.877 X-Spam-Level: X-Spam-Status: No, score=-103.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzOHbHJLo93m for ; Wed, 21 Aug 2013 09:03:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id AAE5C11E8100 for ; Wed, 21 Aug 2013 09:03:20 -0700 (PDT) Received: from mail98-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 16:03:19 +0000 Received: from mail98-am1 (localhost [127.0.0.1]) by mail98-am1-R.bigfish.com (Postfix) with ESMTP id 2D22E2602A2; Wed, 21 Aug 2013 16:03:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail98-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(13464003)(189002)(199002)(51704005)(377454003)(76796001)(81342001)(46102001)(79102001)(83072001)(47976001)(77096001)(81542001)(76786001)(50986001)(77982001)(59766001)(47736001)(80022001)(56816003)(66066001)(49866001)(74316001)(81686001)(47446002)(31966008)(74706001)(51856001)(76482001)(54356001)(54316002)(74502001)(74662001)(19580405001)(74876001)(63696002)(19580395003)(83322001)(56776001)(4396001)(53806001)(65816001)(81816001)(80976001)(69226001)(74366001)(76576001)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB242; H:BL2PR05MB243.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1 (MessageSwitch) id 1377100997340093_952; Wed, 21 Aug 2013 16:03:17 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.228]) by mail98-am1.bigfish.com (Postfix) with ESMTP id 4685420035; Wed, 21 Aug 2013 16:03:17 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 16:03:16 +0000 Received: from BL2PR05MB242.namprd05.prod.outlook.com (10.242.198.141) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 21 Aug 2013 16:03:14 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com (10.242.198.148) by BL2PR05MB242.namprd05.prod.outlook.com (10.242.198.141) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 21 Aug 2013 16:03:13 +0000 Received: from BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) by BL2PR05MB243.namprd05.prod.outlook.com ([169.254.8.111]) with mapi id 15.00.0731.000; Wed, 21 Aug 2013 16:03:13 +0000 From: Ronald Bonica To: "C. M. Heard" Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHCAAHgGAIAApBcAgABuikCAAB6SgIAAAgsAgAAAuxCAAASuAIAAAjhwgAAP3ACAAACkkA== Date: Wed, 21 Aug 2013 16:03:13 +0000 Message-ID: <3ba7fca5a0d74c54abf70c6997b3e982@BL2PR05MB243.namprd05.prod.outlook.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> <5213CEBC.3040008@gmail.com> <46c1bed43b904b92ae6f12cd1e788202@BL2PR05MB243.namprd05.prod.outlook.com> <0ed0fcc2f9334d299226dc7fc59bba6f@BL2PR05MB243.namprd05.prod.outlook.com> <6e42266d78964c3c8683e1188de3d026@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0945B0CC72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: IPv6 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, 21 Aug 2013 16:03:27 -0000 Then 0 it is! Ron > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Wednesday, August 21, 2013 12:01 PM > To: Ronald Bonica > Cc: Ole Troan; IPv6 > Subject: RE: 6MAN WG Last Call: chain-04> >=20 > Works for me. >=20 > //cmh >=20 > On Wed, 21 Aug 2013, Ronald Bonica wrote: > > I am happy to set the pointer field to 0 if Mike agrees. > > > > Ron > > > > > > > -----Original Message----- > > > From: Ole Troan [mailto:otroan@employees.org] > > > Sent: Wednesday, August 21, 2013 10:56 AM > > > To: Ronald Bonica > > > Cc: C.M.Heard; IPv6 > > > Subject: Re: 6MAN WG Last Call: > > chain-04> > > > > > > > This works, too. But now we have three participants in the > > > > discussion > > > and three opinions! > > > > > > > > Let's just pick one! Does anybody have a coin? > > > > > > who calls "edge"? ;-) > > > > > > cheers, > > > Ole > > > > > > > > > > >> -----Original Message----- > > > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > > >> Behalf Of Ole Troan > > > >> Sent: Wednesday, August 21, 2013 10:37 AM > > > >> To: C.M.Heard > > > >> Cc: IPv6 > > > >> Subject: Re: 6MAN WG Last Call: > > > >> > > >> chain-04> > > > >> > > > >>> The reason I didn't suggest pointing at the Fragment Header is > > > >> because > > > >>> it would carry the same information that it would in a > correctly > > > >>> fragmented packet, namely M=3D1 and Fragment Offset=3D0 (the > > > >>> signature of an initial fragment). The Payload Length field is > > > >>> what > > > indicates > > > >> that > > > >>> the fragment is too short to contain all the extension headers > > > >>> and > > > >> the > > > >>> upper layer header; its value would have to be different in a > > > >>> legitimate packet. Hence my suggestion to point there. > > > >> > > > >> or set the pointer field to 0? given that there really isn't an > > > octet > > > >> offset where an error has been detected. > > > >> > > > >> cheers, > > > >> Ole > > > > > > > > > > >=20 From wesley.george@twcable.com Wed Aug 21 13:17:11 2013 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 40F9C11E8146 for ; Wed, 21 Aug 2013 13:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM2OG7n40fSO for ; Wed, 21 Aug 2013 13:17:07 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id D58B011E8161 for ; Wed, 21 Aug 2013 13:17:06 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,929,1367985600"; d="scan'208";a="39864965" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Aug 2013 16:16:47 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 21 Aug 2013 16:16:58 -0400 From: "George, Wes" To: Ronald Bonica , "C. M. Heard" , IPv6 Date: Wed, 21 Aug 2013 16:16:56 -0400 Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHOmGHT01yYfbYisUqiqY5khd4MapmdT+IAgADLyHCAAgXNAA== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439DF8177@PRVPEXVS15.corp.twcable.com> References: <16C5EFD5-A633-4C71-BC6A-0175F8334794@employees.org> <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.com> In-Reply-To: <5f80ba1b808749958cf40e31cd7e9ffa@BL2PR05MB243.namprd05.prod.outlook.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: "V6ops Chairs \(v6ops-chairs@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: Wed, 21 Aug 2013 20:17:11 -0000 Ron, et. Al: I made a similar observation to Mike's about the amount of overlap between = the drafts in v6ops this AM (http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg17431.html) So how does draft-taylor-v6ops-fragdrop fit into this ? And for that matter= , draft-andrews-6man-fragopt? Apologies for not making the linkage on the first message, order of operati= ons problem as I slogged through mail... Could the authors (many of which also overlap) and WG chairs of one or both= groups get together and sort out what is going where to address the issues= , and map it to the (to be updated) drafts, identify to be abandoned drafts= , etc? One cannot solve a problem of too many layers of abstraction with an= other layer of abstraction, and I fear we're headed in that direction with = this group of drafts and all of the voluminous email threads discussing thi= s set of problems all in one mass, across 2 WGs. I vote for consolidating down to as few drafts as possible within the confi= nes of the need to keep standards/protocol changes in 6man and address othe= r procedural minutae. Thanks, Wes George > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, August 20, 2013 9:34 AM > To: C. M. Heard; IPv6 > Subject: RE: 6MAN WG Last Call: 04> > > Hi Mike, > > Thanks for your review of all three documents. The following is some > gentle pushback. > > At IETF 87, the 6man WG was pretty clear that they are not ready to > deprecate IPv6 fragmentation. So, within the next few weeks, I will > update that document so that it makes only the following points: > > - IPv6 fragmentation doesn't work well because fragments are blocked on > many paths > - The IETF should not standardize any new protocols that rely on IPv6 > fragmentation > - Some legacy protocols can break their reliance on fragmentation, > others cannot. Legacy protocols that can break their reliance on > fragmentation should consider doing so. > - Legacy protocols and implementations thereof will continue to send > fragments for a long time to come. > > Since fragmentation will be with us for a while, we need to deal with > its issues. Currently, we see two issues: > > - the tiny fragment problem > - the long header problem > > The two problems are orthogonal to one another. It is possible for a > packet to display either problem without displaying the other. > > Also, there is a very concrete solution for the tiny fragment problem. > This solution constitutes an UPDATE to RFC 2460 regarding sending and > handling tiny fragments. Since we are updating 2460, we need to publish > a PS document. > > There is no real solution to the long header problem. The best that we > can do is to put a stake in the ground, saying that implementations > should forward packets with header chains up to X bytes. There is no > need to UPDATE RFC 2460, or to publish a PS document. A BCP is good > enough. > > I hope that this helps. > > Ron > > > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > > C. M. Heard > > Sent: Monday, August 19, 2013 8:58 PM > > To: IPv6 > > Subject: Re: 6MAN WG Last Call: > chain-04> > > > > Greetings, > > > > My main question is why this draft is not better integrated with > > draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, > > which have overlapping or at least related subject matter. > > > > The thrust of draft-ietf-6man-oversized-header-chain is to require > that > > all extension headers and the upper layer header appear in the first > > IPv6 fragment and to define an ICMPv6 error message that may be sent > > when that condtion is violated (type =3D Parameter Problem, code =3D IP= v6 > > first-fragment has incomplete IPv6 header chain). > > > > The thrust of draft-wkumari-long-headers-01 is the claim that > operators > > have a requirement to filter at Layer 3 and Layer 4, at line rate, in > > the network, and that in order to be able to do that, the entire > header > > chain needs to appear within a relatively short initial segment of the > > IPv6 datagram -- the draft suggests 128 bytes. This is MUCH shorter > > that the "within the first fragment" > > constraint specified by draft-ietf-6man-oversized-header-chain. > > > > There is also a strong hint (though not an explicit statement) in > > draft-wkumari-long-headers-01 that entities that do in-network line- > > rate filtering need to see layer 3 and 4 information in ALL datagrams, > > which is at the heart of the subject matter of draft-bonica-6man-frag- > > deprecate. > > > > In my view, draft-ietf-6man-oversized-header-chain should not go to > the > > IESG until: > > > > 1.) This WG decides what to do with draft-bonica-6man-frag-deprecate. > > If the decision is to admit that IPv6 frgmentation works so > > poorly in pratice that new protocols must not use it and > > existing protocols should try not to use it, then a stronger > > recommendation than just confining the header chain to the > > initial fragment is probably in order -- perhaps something like > > what's in draft-wkumari-long-headers. > > > > 2.) This WG decides whether the ideas in draft-wkumari-long-headers > > are basically sound. If so, then it would make sense (to me, > > anyway) to merge it with draft-ietf-6man-oversized-header-chain. > > The two drafts already agree (with admirable precision) on the > > definition of what a complete IPv6 header chain is. One way to > > merge the documents would be to add a section to > > draft-ietf-6man-oversized-header-chain recognizing that there > > are likely to be stringent limits on the size of a header chain > > that an implementation can process and defining an ICMPv6 error > > message that may be sent when these limits are exceeded (type =3D > > Parameter Problem, code =3D IPv6 header chain exceeds > > implementation's capacity). A recommendation on the minimum > > size header chain that an implementation should support would > > then be in order. > > > > Thanks, > > > > Mike Heard > > Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From markzzzsmith@yahoo.com.au Wed Aug 21 13:55:52 2013 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 6C29411E813F for ; Wed, 21 Aug 2013 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdcCDT2AItdB for ; Wed, 21 Aug 2013 13:55:46 -0700 (PDT) Received: from nm44-vm9.bullet.mail.bf1.yahoo.com (nm44-vm9.bullet.mail.bf1.yahoo.com [216.109.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 182AF11E8144 for <6man@ietf.org>; Wed, 21 Aug 2013 13:55:42 -0700 (PDT) Received: from [66.196.81.171] by nm44.bullet.mail.bf1.yahoo.com with NNFMP; 21 Aug 2013 20:55:42 -0000 Received: from [98.139.212.243] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 21 Aug 2013 20:55:42 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 21 Aug 2013 20:55:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 548964.32362.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 16504 invoked by uid 60001); 21 Aug 2013 20:55:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1377118542; bh=zKMgltEaoa+Ej8q50x0jWX8oO6aEjRt6z6RjRN4cMB0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5pKtH4keAIs+er5lQUQP3V2cw6kIJdGQxfClwMIqCP943yjhtEogzgq+XOzn6zMylXFVhjr8mA6IFpVjxI6/oYKFz5L3rZI/IEwSXgEh0rotkNQEQseWK1QWYT7n70KmX2eOIQwC5lHsJinDkA4omC6JecEjHZ0LO8qYNOuv/dk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ebF6cgPeaMWwCN1cDQLkRVebBnRVNM5e+d0u3o55DsKB+jxVl+v+fD06TgZHHlAxBVF/JJPe93vtfItJBHvn5CaXyfScu6HmkUSoqqohOHpIom+Kfv77eKkq64Gv1dJgjK86pyTa0TvJ/H/FhLckBDVv2s16ikgNVMAf7D/ZT6Y=; X-YMail-OSG: CXxNOlkVM1l56_Pv3tAUp36bN7ykek.zArBXtPqs0sAiO6W jDI1TZKbKnlWMY1GOUDLL0xZb3pRuozJGSaVGMBOUe6o_mb1mmuWVx_0CtJy VlpC.R0YV0oZE2_Y7nIJmVrOrVANVsgkrVqpBrdTWmJYUMQ5dtGQZa8WYWLY kPPgHSOAtY2208i7R.Vr3F44Tftn7d7Oz6lABJgOPm30SF9Key5LhFZwHxjU aAwAZ_xMaixciHpwq8F2SEqFKXKaZb7AXIq7ba3r_wd14NlvxHRRmk5objaq 1jmFbAAEQ17mBc7dqqYWYmYK9Rx1vgeC1Or0y4a_IZe4fphlpwOFqCSwJ2p_ dTqK9GjId7ct6YkZxFA3jbkhbRXXQ_EBS5H6k9N_zfNMsbGgbc51QLMbKUD. .GQ2m.TvWg2b9EKYZ5m6xteFCdGCCshzIjvc6QYaa8F0eYCIvTwpCHTcfQcm h4tnOfg2FfiIHPwNYW1RgbWhZ8EVu9WWA0wxUQM3wLcC1cIyQmodeNeP7UxD 4kQ87_hH5R1NRkJHIkYpjtsFLy4u.RK26JU0z5jRt0fPB878YfF7eXjp2uC9 x3cPP4kNQRMYbMFiJ1cLMMsSz9XHutpW3BFmeGwEhvYs0PGU- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 21 Aug 2013 13:55:42 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpJIGhhdmVuJ3QgaGFkIGEgY2hhbmNlIHRvIGRvIGEgdGhvcm91Z2ggcmVhZCB0aG91Z2gsIGhvd2V2ZXIgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kIHdoZXJlIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW9zIGlzIGRlYWx0IHdpdGguwqAKCkluIGEgcHVyZSBlbmVyZ3kgZWZmaWNpZW50IHNjZW5hcmlvLCBzYXkgdGhlcmUgYXJlIHR3byBORUFSIHJvdXRlcnMgb24gdGhlIGxpbmsgKE5FQVIxLCBORUFSMikuIEFuIEVBSCBob3N0IChFQUgxKSBhdCBib290c3RyYXAgY2hvb3NlcyBORUFSMSwgcmVnaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: Message-ID: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 21 Aug 2013 13:55:42 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted To: Samita Chakrabarti , "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Erik Nordmark \(nordmark@acm.org\)" , "pthubert@cisco.com" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 20:55:52 -0000 Hi,=0A=0AI haven't had a chance to do a thorough read though, however I hav= en't been able to find where the following scenarios is dealt with.=A0=0A= =0AIn a pure energy efficient scenario, say there are two NEAR routers on t= he link (NEAR1, NEAR2). An EAH host (EAH1) at bootstrap chooses NEAR1, regi= sters its addresses and uses NEAR1 as its egress router for off-link traffi= c. For the return traffic (i.e, off-link traffic coming onto the energy eff= icient segment), what occurs if the upstream network chooses to use NEAR2 t= o try to forward traffic to EAH1, as the upstream network considers NEAR2 r= ather than NEAR1 to be closer to EAH1 e.g, because of a smaller IGP metric,= or the traffic source link is directly attached to NEAR2?=0A=0AIn my under= standing, NEAR2 wouldn't have knowledge of EAH1, because EAH1 has only been= registered with NEAR1. So it would seem that currently the only choice is = for NEAR2 to drop those packets.=0A=0AFurther to this two or more NEAR scen= ario, even if the upstream network always considers NEAR1 to be the closer = to the EAHs, if the NEARs are protected by a redundancy protocol such as VR= RP, when VRRP switches from using NEAR1 to NEAR2, how does NEAR2 acquire ad= dress registration information? Would it be considered a EAH bootstrap even= t, so that all of the EAHs have to go through selection and then registrati= on of a NEAR? While I think that would work, it would seem to be defeating = the purpose of having a redundancy protocol like VRRP which tries to make s= witching over between routers nearly if not ideally transparent to downstre= am hosts.=0A=0ARegards,=0AMark.=0A From kevin.lahey@oracle.com Wed Aug 21 18:11:08 2013 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 8EC7F21F999D for ; Wed, 21 Aug 2013 18:11:08 -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, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQThKRfJiMgj for ; Wed, 21 Aug 2013 18:11:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 206FE21F963F for <6man@ietf.org>; Wed, 21 Aug 2013 18:11:01 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7M1AxEk015207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 01:11:00 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7M1Auq4003700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 01:10:57 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7M1Aua2019702; Thu, 22 Aug 2013 01:10:56 GMT Received: from dhcp-santaclara18-3fl-west-10-132-146-215.usdhcp.oraclecorp.com (/10.132.146.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 18:10:56 -0700 Subject: Re: Detailed review of draft-ietf-6man-ext-transmit-02 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Kevin Lahey In-Reply-To: <520BE3C8.10808@si6networks.com> Date: Wed, 21 Aug 2013 18:10:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4A9A0575-7540-468D-AA64-43783D116A50@oracle.com> References: <520AA510.8050409@si6networks.com> <520B0794.3010003@gmail.com> <520B38E2.3090307@si6networks.com> <520BDA9A.1030108@gmail.com> <520BE3C8.10808@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: draft-ietf-6man-ext-transmit@tools.ietf.org, "6man@ietf.org" <6man@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, 22 Aug 2013 01:11:08 -0000 On Aug 14, 2013, at 1:08 PM, Fernando Gont wrote: > On 08/14/2013 04:29 PM, Brian E Carpenter wrote: >>> >>> That's my point: is that a sensible requirement? For instance, for the >>> time being (Flow Label not used), there's no other way to identify flows >>> than to break this reuirement. >> >> Which is indeed why I worked hard to get RFC 6437 written. But changing >> this aspect of IPv6 design would be a *really* big discussion. > > I'm fully in favor of RFC6437. My point is that host implementations > still not use or o weird stuff with the Flow Label -- hence it's not > dependable for anything. This means that in the short of near term > there's no better option than following the IPv6 header chain (not that > I like it but... that doesn't change the facts). As an implementor, I'd far rather hear, "Get on the ball implementing flowlabels, and until you do, any packets you originate might suffer re-ordering via ECMP because we can't reliably get to the L4 info," rather than, "Tell your customers that they can't send fragments over IPv6 (or use any other IPv6 options)." Kevin kevin.lahey@oracle.com From internet-drafts@ietf.org Wed Aug 21 20:38:37 2013 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 A258411E81D0; Wed, 21 Aug 2013 20:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJR5s8N7Dacg; Wed, 21 Aug 2013 20:38:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB35811E821D; Wed, 21 Aug 2013 20:38:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ext-transmit-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822033827.13552.68008.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 20:38:27 -0700 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: Thu, 22 Aug 2013 03:38:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Transmission and Processing of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-03.txt Pages : 9 Date : 2013-08-21 Abstract: Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ext-transmit-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Wed Aug 21 20:44:15 2013 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 B7BED11E81D2 for ; Wed, 21 Aug 2013 20:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsS-3Km2HzYc for ; Wed, 21 Aug 2013 20:44:15 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3F20C11E8179 for ; Wed, 21 Aug 2013 20:44:15 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so1579313pab.26 for ; Wed, 21 Aug 2013 20:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=sPZF3cvV7mkMOohNYIQDmjH+dQb1Y3q5H50Ihz/NY3A=; b=dpNhmTWNXAAPWBvlhYqebmlKwtoLstSOredZPyUmH8+AShUGQuqZWdanuPz1sXwovD Zip55kKaBCONLH45kfW5HaLt1RWX5uTmYGGaGH8B07FY1DLBNssMwc4jgQT+nT8Ln6Tl znigP8GKvTNACFa/Q+ZDuQvem0mg9XvflE5ZHwDcKsKbKzHUiqsQIUElMbSr+yVgVkwL mGPsBZ/PcP6Lyt7Pg+F/PoPEhoQK7yv7/S/igInxgZ50I1foJ4w1hhiJ+o1IS2Bjcn0T 9ECOyk9XVKD8nTSxxUMa7HERibIe7j7kkKkZxx94gr7sR+E6i2xBhSTlCA8vadV++Bqv o+Mg== X-Received: by 10.66.150.41 with SMTP id uf9mr3098437pab.108.1377143054944; Wed, 21 Aug 2013 20:44:14 -0700 (PDT) Received: from [192.168.178.20] (56.201.69.111.dynamic.snap.net.nz. [111.69.201.56]) by mx.google.com with ESMTPSA id fl3sm13646139pad.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Aug 2013 20:44:14 -0700 (PDT) Message-ID: <52158917.9060001@gmail.com> Date: Thu, 22 Aug 2013 15:44:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-ext-transmit-03.txt] 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: Thu, 22 Aug 2013 03:44:15 -0000 This version is updated following the detailed review by Fernando Gont. The biggest change is new text and IANA considerations for experimental header types. There are some other clarifications and minor corrections. Brian & Sheng -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-ext-transmit-03.txt Date: Wed, 21 Aug 2013 20:38:27 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Transmission and Processing of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ext-transmit-03.txt Pages : 9 Date : 2013-08-21 Abstract: Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Thu Aug 22 04:39:53 2013 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 4DBF711E819E for ; Thu, 22 Aug 2013 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_40=-0.185, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmHrkDK6TKU1 for ; Thu, 22 Aug 2013 04:39:47 -0700 (PDT) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3724B11E80F4 for ; Thu, 22 Aug 2013 04:39:47 -0700 (PDT) Received: from [98.139.212.149] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 22 Aug 2013 11:39:38 -0000 Received: from [98.139.212.243] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 22 Aug 2013 11:39:38 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 22 Aug 2013 11:39:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 767449.25359.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 84598 invoked by uid 60001); 22 Aug 2013 11:39:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1377171578; bh=MUvLCXVCwYyIwwUSUVzJC+hUMBqFb0zR4Q3JsBEm6Es=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XqHpnAWy8woP/oA1G3cLbCwWUtoRzIwcus3az0r/+oEEuln+giR75qjZvAwUhBNGX4COhETNdhbH/z9qXgmMDOqmRrUQDHTNMz6N9/Tl2ibfcvd8LomZSO/ZSHjZYNyYSA3vXOvtBU2Pp1QjYqAuLKGmpB3gDTpGU0ghCTmd0kE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wgNdXsI1k6mHPRvCNHMUW/ofDTcTClWSmLslboeTvOIDevaQt0z+SGwLx4I0aP46LBKScSMVdOI+aKaiYpuQoyfKMaeIGTzgBmTLjRdbysHUwN9mYMpkKbolzXkjhJ94nr9dCs8klzBwgcKxhPP1RmVJ8bE8ZOg+QgtC/wmREP0=; X-YMail-OSG: S5Qqg2oVM1kjltER8UQ5bONMUqkMwAv67fdn71J.Cr.3viO EKiPHPfveDv.cYReLRtiz6cOGvgg9IV.Q3SdlOocqGNGbI8y0lIVykEHBhEu s7EI44hUy73VeIbCe4hEfyUx8WXvSQlfYyNLTO4vnrQlfMRGUeoudECnubLO P20JbI4e47w5GNGjxB6g1Cv7Taw4OZwbS8jF2mSwxeuFeF0.M7xoOH4o4CK5 EDy67qnVYaJpf6kR.WkCKrosB.lDkUUh1_TVV8WBnD68r4qL5GLkN5SH4jTc p8ISFRwdzPLQ._SkBF8j96bAW1FwRGB.ndOLl.Ks2Bhi2MT5zo.nNNbpIAdb 1I33OCbtmwk5Aq0kqN7CjCwNID6RHP_KvsuWcgpBWCwmneMnyi5wy6K0.Xka 2w9VHUs.6_C.n77C0zzYHh4nIL7QvC_RsMlGu829FUwIdHcvYPlXrHBJqHqQ JHXRRxTxG11aJsRIqzthTAWFPbJ3LV7o2ozzgZu9JTLW97W_q5OM2aUHimLH RS02Go1GV5MXFjeigxZJf5K67rHNSVrIxXeI4qjvaDz8pfjBH59RSv9BoCo7 YKzgflwOSj1tNTcKSxyNyq5yVmEEffsY3TDVQN24CoKSwWrnSYZDlDGWyq2x elbTxjUEhx_Vr4dnySNdX2o2rtCQc31SdAt7n6SwZ000- Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Thu, 22 Aug 2013 04:39:38 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gVG86IEVyaWsgS2xpbmUgPGVrQGdvb2dsZS5jb20.Cj4gQ2M6IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc.Cj4gU2VudDogV2VkbmVzZGF5LCAyMSBBdWd1c3QgMjAxMyAzOjM1IFBNCj4gU3ViamVjdDogUmU6IDZNQU4gV0cgTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi02bWFuLXN0YWJsZS1wcml2YWN5LWFkZHJlc3Nlcy0xMj4KPiAKPiBPbiBUdWUsIDIwIEF1ZyAyMDEzLCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <5211EBFD.2000403@si6networks.com> Message-ID: <1377171578.84555.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Thu, 22 Aug 2013 04:39:38 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Mikael Abrahamsson , Erik Kline In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 11:39:53 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mikael Abrahamsson =0A> To: Erik Kline =0A> Cc: 6man WG =0A> Sent: Wednesday, 21 August 2013 3:35 PM=0A> Subject: Re: 6MAN WG = Last Call: =0A> =0A> On Tue, 2= 0 Aug 2013, Erik Kline wrote:=0A> =0A>> To support this scheme as I unders= tand it, the Linux kernel ipv6 code =0A>> would need to take some module p= arameters at boot or load time, so as to =0A>> force it to not do link-lay= er-derived link-local autoconfig but instead =0A>> load up the required pa= rameters from non-volatile storage.=A0 Is my =0A>> understanding correct?= =A0 If so, has anyone written this and gotten =0A>> feedback from net main= tainers?=0A> =0A> Actually this would be good if it was fixed because the w= ay it was done =0A> caused other problems. It's really hard to make a linux= (debian 6.0 for =0A> instance) come up and *not* do RS and then create EUI= 64 based addresses.=0A> =0A> I have this in sysctl.conf:=0A> =0A> net.ipv6.= conf.default.accept_ra=3D0=0A> net.ipv6.conf.eth0.accept_ra=3D0=0A> net.ipv= 6.conf.eth1.accept_ra=3D0=0A> net.ipv6.conf.eth2.accept_ra=3D0=0A> net.ipv6= .conf.eth3.accept_ra=3D0=0A> net.ipv6.conf.eth4.accept_ra=3D0=0A>=A0=0A=0AR= As are necessary to indicate prefix on-link or off-link status, as per RFC5= 942. If you want to stop hosts using PIO announced prefixes to generate SLA= AC addresses, you'd switch off the A bit in the PIO option.=0A=0A> At least= in debian 6.0 this didn't kick in until too late in the boot =0A> process,= the kernel had already brought up the interfaces and done RS and =0A> crea= ted addresses and routing. It didn't listen to RAs after that, the =0A> man= ual static config kicked in, and I had to use "ip -6 address =0A> delete" t= o =0A> get rid of the EUI64 based addresses and privacy addresses.=0A> =0A>= Actually I upgraded to debian 7.0 the other week and I don't remember =0A>= having to delete the EUI64 based addresses, so this might have been fixed,= =0A> or I just forgot to check and they timed out after a while when the k= ernel =0A> ignored RAs after the above config kicked in.=0A> =0A> -- =0A> M= ikael Abrahamsson=A0 =A0 email: swmike@swm.pp.se=0A> ----------------------= ----------------------------------------------=0A> IETF IPv6 working group = mailing list=0A> ipv6@ietf.org=0A> Administrative Requests: https://www.iet= f.org/mailman/listinfo/ipv6=0A> -------------------------------------------= -------------------------=0A> From fgont@si6networks.com Thu Aug 22 14:59:06 2013 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 8F56411E812B for ; Thu, 22 Aug 2013 14:59:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa8JLwJ4b6VF for ; Thu, 22 Aug 2013 14:59:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 01E5B21F9A44 for ; Thu, 22 Aug 2013 14:59:05 -0700 (PDT) Received: from [186.134.0.127] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VCcu8-0000VD-L8; Thu, 22 Aug 2013 23:58:56 +0200 Message-ID: <52168999.8070002@si6networks.com> Date: Thu, 22 Aug 2013 18:58:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <1376911186.35364.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1376911186.35364.YahooMailNeo@web142501.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG 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, 22 Aug 2013 21:59:06 -0000 X-List-Received-Date: Thu, 22 Aug 2013 21:59:06 -0000 On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote: > > Going by the title, it seems my comment was missed about not implying > that this address generation technique is limited to SLAAC slack > scenarios, but could be useful with any address configuration method > (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some > support for decoupling the concepts of address generation from > address configuration. How about something like: "While the method specified in this document is meant to be used with SLAAC, this doesn not preclude the same algorithm from being used with other address configuration mechanisms, such as DHCPv6 or static address confguration" at the end of Section 1, right before the "terminology" paragraph? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From markzzzsmith@yahoo.com.au Thu Aug 22 20:57:45 2013 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 ED15B21F9C70 for ; Thu, 22 Aug 2013 20:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.315 X-Spam-Level: X-Spam-Status: No, score=0.315 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRirJSnvnoK6 for ; Thu, 22 Aug 2013 20:57:39 -0700 (PDT) Received: from nm48-vm2.bullet.mail.bf1.yahoo.com (nm48-vm2.bullet.mail.bf1.yahoo.com [216.109.115.157]) by ietfa.amsl.com (Postfix) with ESMTP id B576721F85F5 for ; Thu, 22 Aug 2013 20:57:38 -0700 (PDT) Received: from [66.196.81.174] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 03:57:35 -0000 Received: from [98.139.212.210] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 03:57:35 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 03:57:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 103350.74710.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 63821 invoked by uid 60001); 23 Aug 2013 03:57:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1377230255; bh=7Ch0/07+giXAsiIywyRU5XHoR8W7jMwp0+X2h7bjFGk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l7n1swpchmCT22dbX4G/HbPDl83OsEqqha/0BxsetwK7eWMmMkLJUOC8wvJ1ChFngeLL5RGF51I3r2UHytkrR1ztwPlvbTTfpWBisk2XeusMFtopH3AXA3QEiZfy8Q07grjYBs7yueP7T5bLO9LRNO5bwfHgvt80zZ7qbVAO8QU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QyJPigSLLQ9653QlBMf+UHF8KRWE1y8mkgfFOOE0eiuN9N0BjdQ/e/+qQwn8wG32PWzrxNdXeqUclcPiQUh17xwpFuVnLYDAY9c1NgVu57jAHtgF0jP2NEEdEp/GiMDdsj2zgpkYBHkpNgo8ttBhdRVB2P8TH/fByQWQDiiIQRw=; X-YMail-OSG: FQQqPdMVM1leyXWySiPXQWZ22.oFMVI0PWVEanOd1kvvUfq 7XgNNF1BZa3_klNu._4rG Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 22 Aug 2013 20:57:35 PDT X-Rocket-MIMEInfo: 002.001, SGkgRmVybmFuZG8sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6IE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc.OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgIjZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnIENoYWlycyIgPDZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnPgo.IFNlbnQ6IEZyaWRheSwgMjMgQXUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <1376911186.35364.YahooMailNeo@web142501.mail.bf1.yahoo.com> <52168999.8070002@si6networks.com> Message-ID: <1377230255.61248.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 22 Aug 2013 20:57:35 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Fernando Gont In-Reply-To: <52168999.8070002@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 03:57:45 -0000 Hi Fernando,=0A=0A=0A----- Original Message -----=0A> From: Fernando Gont <= fgont@si6networks.com>=0A> To: Mark ZZZ Smith = =0A> Cc: Ole Troan ; 6man WG ; "6man-c= hairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>=0A> Sent: Friday,= 23 August 2013 7:58 AM=0A> Subject: Re: 6MAN WG Last Call: =0A> =0A> On 08/19/2013 08:19 AM, Mark ZZZ Sm= ith wrote:=0A>> =0A>> Going by the title, it seems my comment was missed a= bout not implying=0A>> that this address generation technique is limited t= o SLAAC slack=0A>> scenarios, but could be useful with any address configu= ration method=0A>> (i.e, SLAAC, DHCPv6, static, +future.) There seemed to = be some=0A>> support for decoupling the concepts of address generation fro= m=0A>> address configuration.=0A> =0A> How about something like:=0A> =0A> = "While the method specified in this document is meant to be used with=0A> S= LAAC, this doesn not preclude the same algorithm from being used with=0A> o= ther address configuration mechanisms, such as DHCPv6 or static address=0A>= confguration"=0A> =0A> at the end of Section 1, right before the "terminol= ogy" paragraph?=0A>=A0=0A=0AHappy with that.=0A=0ARegards,=0AMark.=0A=0A> T= hanks!=0A> =0A> Cheers,=0A> -- =0A> Fernando Gont=0A> SI6 Networks=0A> e-ma= il: fgont@si6networks.com=0A> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C= 4 AE25 0D55 1D4E 7492=0A> From otroan@employees.org Fri Aug 23 00:53:39 2013 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 898E421F9F34 for ; Fri, 23 Aug 2013 00:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6oHP+A+n-s6 for ; Fri, 23 Aug 2013 00:53:34 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 45ACA21F9B11 for ; Fri, 23 Aug 2013 00:53:34 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-91.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 98A555FB4; Fri, 23 Aug 2013 00:53:32 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Fri, 23 Aug 2013 09:53:30 +0200 Message-Id: To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@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: Fri, 23 Aug 2013 07:53:39 -0000 All, This message starts the second two week 6MAN Working Group on advancing: Title : Packet loss resiliency for Router = Solicitations Author(s) : S. Krishnan, D. Anipko, D. Thaler Filename : draft-ietf-6man-resilient-rs-01 Pages : 6 Date : 2013-05-06 http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01 as a Proposed Standard. 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 September 6, 2013. The chairs would like to solicit one or two people in the working group = to do a detailed review of the document. We would also encourage = volunteers to act as document shepherds. Please contact the chairs = directly. Regards, Bob Hinden & Ole Tr=F8an= From otroan@employees.org Fri Aug 23 00:56:01 2013 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 332301F0D60 for ; Fri, 23 Aug 2013 00:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+YPTReMCw14 for ; Fri, 23 Aug 2013 00:55:55 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id CD4D021F9F34 for ; Fri, 23 Aug 2013 00:55:55 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-91.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 3611A5F87; Fri, 23 Aug 2013 00:55:55 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN Adoption call on Date: Fri, 23 Aug 2013 09:55:53 +0200 Message-Id: <2FC4000A-0AC1-455B-8FD5-D54D51883D99@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@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: Fri, 23 Aug 2013 07:56:01 -0000 All, This message starts a one week 6MAN Working Group call on adopting: Title : Security Implications of IPv6 Options of Type = 10xxxxxx Author(s) : F. Gont, W. Liu Filename : draft-gont-6man-ipv6-smurf-amplifier-03 Pages : 12 Date : 2013-03-21 http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-03 The call ends on August 30th, 2013. Regards, Bob Hinden & Ole Tr=F8an= From otroan@employees.org Fri Aug 23 01:15:07 2013 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 DF70921F9D50 for ; Fri, 23 Aug 2013 01:15:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK2FX6VJVqfC for ; Fri, 23 Aug 2013 01:15:02 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 16D6E21F9C40 for ; Fri, 23 Aug 2013 01:15:02 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-91.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A3CAA5FAF; Fri, 23 Aug 2013 01:15:00 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_04DBC4C4-2E9A-4696-AB5A-68671A1FE3EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Ole Troan In-Reply-To: Date: Fri, 23 Aug 2013 10:14:58 +0200 Message-Id: <9CD168F1-7BD3-48E9-9CE6-8E8ECA9642A9@employees.org> References: To: 6man WG X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@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: Fri, 23 Aug 2013 08:15:08 -0000 --Apple-Mail=_04DBC4C4-2E9A-4696-AB5A-68671A1FE3EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 all, short and sweet document; a few comments if I may. - this new behaviour is supposed to be implemented by all hosts, right? = shouldn't this document then update rfc4861? - "AP" isn't defined section 1. - section 1 bullet b. couldn't you argue that turning off periodic RAs = is a configuration error? - section 1 bullet c. If a link isn't multicast capable, you couldn't = send RS in the general case either. ISATAP has special provisions for that. = could you make c) more general? - section 2.1. "=85results in a default route". is awkward. this is the = function we call "router discovery" in rfc4861, where the host discovers a "default router". = perhaps just copy or reference rfc4861 verbatim: "Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Responses to solicited advertisements may contain more information than unsolicited advertisements." Best regards, Ole --Apple-Mail=_04DBC4C4-2E9A-4696-AB5A-68671A1FE3EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSFxoCAAoJEFuJXizso86gHJsIAID4zC2dQOvzQdh2XoUL+7CQ Uczl7XUMz4gI6IiN15hN+YRppgTXx/EXEbSVBFzBHlePvaHxoLnDr/jMCM1vo/2+ spoatPJqhHMI6c6Ek9N1VLzb7sk3uUvxdCF5i/AlSHmk9QnLTE6VFyc7SbpELXPD wOzNm6dcC5qhYhvRZ2HShCFILl5R4DPrmLMkuGfTetgW3Al5M3+ziYlsqn8SSd3i gaW7+Ikz9xFS9ngVeXtLCDUSy81Qobs7C+Azg6Lrspl5N5OdkNmqSGQZgbBD+5Ve lNrDTs/FaZ4JF0i5WqqFh+Z46MmunyTjAsjiYHlFqIlo6cwDOtFwpjvP7udWGcU= =v1N6 -----END PGP SIGNATURE----- --Apple-Mail=_04DBC4C4-2E9A-4696-AB5A-68671A1FE3EA-- From tjc@ecs.soton.ac.uk Fri Aug 23 03:56:46 2013 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 8716011E81C6 for ; Fri, 23 Aug 2013 03:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+En6IrXci2J for ; Fri, 23 Aug 2013 03:56:45 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1C11E819B for ; Fri, 23 Aug 2013 03:56:44 -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 r7NAuZwX013340; Fri, 23 Aug 2013 11:56:35 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r7NAuZwX013340 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1377255396; bh=o2ZBCxFDq7+eeRuGdTiI4h2oyj4=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=aYUElFtjNtlOGgP/3XPBxekt+pz10F6ZqtjwFAnq+Wks5WxLWGrsasHV3pmeXSB3l QDNHiWMWjo+2RxsvzFWNRhCz88E9IsleKxmdBYZcifcbs+htGvmRc+4eLgFYe/kS/X A8qhzEcWfXvjBDxZX94elKW49ZYKu/9AdujVWC+U= 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 (valid=N/A) id p7MBuZ0544541298YE ret-id none; Fri, 23 Aug 2013 11:56:36 +0100 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r7NAu9rF019625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 11:56:10 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: 6MAN WG Last Call: From: Tim Chown In-Reply-To: <52168999.8070002@si6networks.com> Date: Fri, 23 Aug 2013 11:56:09 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <1376911186.35364.YahooMailNeo@web142501.mail.bf1.yahoo.com> <52168999.8070002@si6networks.com> <5123DF40-4D13-486D-A599-0A307C36C26F@ecs.soton.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p7MBuZ054454129800; tid=p7MBuZ0544541298YE; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r7NAuZwX013340 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG 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, 23 Aug 2013 10:56:46 -0000 On 22 Aug 2013, at 22:58, Fernando Gont wrote: > On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote: >>=20 >> Going by the title, it seems my comment was missed about not implying >> that this address generation technique is limited to SLAAC slack >> scenarios, but could be useful with any address configuration method >> (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some >> support for decoupling the concepts of address generation from >> address configuration. >=20 > How about something like: >=20 > "While the method specified in this document is meant to be used with > SLAAC, this doesn not preclude the same algorithm from being used with > other address configuration mechanisms, such as DHCPv6 or static = address > confguration" >=20 > at the end of Section 1, right before the "terminology" paragraph? I think that fits well with the advice in 5177 and its replacement to = not use sequential IPs from a DHCP pool. The difference for DHCP is perhaps that there may be some reason the = pool is not the whole /64, in which case it would still be prudent to = randomise from within the pool. I think Mark's point though is that an address may be used for the = initiation of incoming and/or outgoing communications, and how the = address is generated should not necessarily be tied to how it is used. I = would certainly agree with that. I'm not sure what you mean by static address configuration in this = context. Tim= From pthubert@cisco.com Fri Aug 23 04:01:55 2013 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 3247111E82D6; Fri, 23 Aug 2013 04:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKzfh-RNHkka; Fri, 23 Aug 2013 04:01:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 953CC11E82DD; Fri, 23 Aug 2013 04:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2482; q=dns/txt; s=iport; t=1377255709; x=1378465309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q8gLXeCTEEzsmpZMUVlnX0+6i4Q7A3ZX7JyhxZb3ATY=; b=KM/EtaQHeW5u9HqAUzakmPIZYFWTx8egJCxDgBej8F03MCDX7pyy1gs3 U5TWBj1kl8cZdCIkf6MT3PO/Nr/xnljWvKoXVk7PIWg8LwGf2AeS7Qmj0 5oVUij3Eb5ngYEc07RRLd7ZmZYYWWX/y5k8Yn8/j1n7RzVoejqPoqE6BY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAIRAF1KtJV2b/2dsb2JhbABagweBBr9+gR8WdIIkAQEBBHkMBAIBCBEEAQELHQcyFAkIAgQBDQUIh3YDD7cPjW2CSDEHBoMVewOIdo0LjhaFKYMfgis X-IronPort-AV: E=Sophos;i="4.89,940,1367971200"; d="scan'208";a="250845815" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 23 Aug 2013 11:01:49 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7NB1nav014227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 11:01:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 06:01:48 -0500 From: "Pascal Thubert (pthubert)" To: Mark ZZZ Smith , Samita Chakrabarti , "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: RE: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Thread-Index: AQHOnrDNzYro94LYFUqkXUi086JfIZmioVZQ Date: Fri, 23 Aug 2013 11:01:47 +0000 Deferred-Delivery: Fri, 23 Aug 2013 11:01:00 +0000 Message-ID: References: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.24] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Nordmark \(nordmark@acm.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, 23 Aug 2013 11:01:55 -0000 Hello Mark: There is a need for a protocol between the 6LBRs/NEAR routers to exchange t= heir state. This could be achieved by an extension on ND for proxy operations as descri= bed in dratf-thubert-6lowpan-backbone-router, a similar extension to a rout= ing protocol running on the backbone or a richer extension to IPv6 NDP allo= wing some degree of pub/sub as well. We are in the process of writing a personal submission describing the latte= r, I hope we can publish soon. Cheers,=20 Pascal -----Original Message----- From: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au]=20 Sent: mercredi 21 ao=FBt 2013 22:56 To: Samita Chakrabarti; 6man@ietf.org; 6lo@ietf.org Cc: Erik Nordmark (nordmark@acm.org); Pascal Thubert (pthubert) Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Hi, I haven't had a chance to do a thorough read though, however I haven't been= able to find where the following scenarios is dealt with.=A0 In a pure energy efficient scenario, say there are two NEAR routers on the = link (NEAR1, NEAR2). An EAH host (EAH1) at bootstrap chooses NEAR1, registe= rs its addresses and uses NEAR1 as its egress router for off-link traffic. = For the return traffic (i.e, off-link traffic coming onto the energy effici= ent segment), what occurs if the upstream network chooses to use NEAR2 to t= ry to forward traffic to EAH1, as the upstream network considers NEAR2 rath= er than NEAR1 to be closer to EAH1 e.g, because of a smaller IGP metric, or= the traffic source link is directly attached to NEAR2? In my understanding, NEAR2 wouldn't have knowledge of EAH1, because EAH1 ha= s only been registered with NEAR1. So it would seem that currently the only= choice is for NEAR2 to drop those packets. Further to this two or more NEAR scenario, even if the upstream network alw= ays considers NEAR1 to be the closer to the EAHs, if the NEARs are protecte= d by a redundancy protocol such as VRRP, when VRRP switches from using NEAR= 1 to NEAR2, how does NEAR2 acquire address registration information? Would = it be considered a EAH bootstrap event, so that all of the EAHs have to go = through selection and then registration of a NEAR? While I think that would= work, it would seem to be defeating the purpose of having a redundancy pro= tocol like VRRP which tries to make switching over between routers nearly i= f not ideally transparent to downstream hosts. Regards, Mark. From markzzzsmith@yahoo.com.au Fri Aug 23 05:15:27 2013 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 C8AAC11E80F4 for ; Fri, 23 Aug 2013 05:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtTTJn+jp7Ki for ; Fri, 23 Aug 2013 05:15:20 -0700 (PDT) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99611E811D for ; Fri, 23 Aug 2013 05:15:20 -0700 (PDT) Received: from [98.139.212.152] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 12:15:19 -0000 Received: from [98.139.212.246] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 12:15:19 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 12:15:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 489458.6031.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 75103 invoked by uid 60001); 23 Aug 2013 12:15:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1377260119; bh=BoShsOwcitbZCMn5kR2g9aA7PlmBrzI7EDycUU9d97Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l7ed01FxHhBqViYbmNdLEI0+lLRnPY3h7RNbunWJWcahJE3084i71XJniSD+sqaC6F2DuV6NeNnSugOQPNmtlmorMOHnfeo/7fGysTt6nPTvSDuTDLyofFRHKqMVNYAp8ejHPhCZlFoX3BWHxiuuRLHG9kbc6z223nN0mk3jCWg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=21FQe487Bwp+raguHrrLEFEKIYXo6MdzpIVavkpSCG08EYYaIetewsaz5KpAeUb8Fmm+1svru2uZ0uGo9HbTxt/39yc1VjBLmRO/C++jeX6WahdRt9D4/RmjKi7KOj4Ws0/+PNZA0IJ0RgrX+hZ4zaLW7JHh5HWYRwTNbYESWz0=; X-YMail-OSG: 2QxJ_zwVM1nE73_Ydfprz5QRmJZrZyhwzeykYOuOP8VPClj i4rwzc8OgtWCui2DAa11QnQxNoUsya9rD4syDl0Wfkkymk64mXN3OS6E3aEg bzmpWuWPRkLvUi8bohv9uHQM8YG7yzRNqrdji2wVxONsisbWQuZ4JGunc0Mp q3t3wPpehG2lvRuCuGY6usx3PICrEhC_R4JR43y6kerIgMRipEuSJinoHcPo AMmsYi1Xd_2SePSDXULo5bHi7futWkHSFxjaDfBjvONX1HQ0E194fzVYgDK5 Dlm5zdLl4tp_AFWk2oXhqKtXPNb_EZbXjaciwCUe6a3cN_r_LGjjgGwaF0Q. 5cEHmapLFPdDwYiFRYd1ifqjuevYCj5z48EeleNAVOSJ6_AsnT3lzLZVhv2J T3aUUVNCCfnvKe2HmXx8SC9pRggqc2rTO9oOki2Nj8ttf75FwLfliiYylqsE u2E5tTjB3HCwTOI4USKq2T.9wTXGopMXxau5x6qIj7UjNaeq6xhhQDKdPutj UYHITxZXVJZ.VkXYH5IJhD5lAH2UOQ237XP0sj9kayDFnHI62pqqW6k.SdZv i0x4kmxMVt.FrRBHiRjNaZBS.M0NtV1xuetwxQVHvGftD5g-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Fri, 23 Aug 2013 05:15:19 PDT X-Rocket-MIMEInfo: 002.001, SGkgVGltLAoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBUaW0gQ2hvd24gPHRqY0BlY3Muc290b24uYWMudWs.Cj4gVG86IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4KPiBDYzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyAiNm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgQ2hhaXJzIiA8Nm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc.OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPgo.IFNlbnQ6IEZyaWRheSwgMjMgQXVndXN0IDIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <590BF0E3-3BA0-4210-B84E-D703711C6C23@employees.org> <1376911186.35364.YahooMailNeo@web142501.mail.bf1.yahoo.com> <52168999.8070002@si6networks.com> <5123DF40-4D13-486D-A599-0A307C36C26F@ecs.soton.ac.uk> Message-ID: <1377260119.74593.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 23 Aug 2013 05:15:19 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: Tim Chown , Fernando Gont In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:15:27 -0000 Hi Tim,=0A=0A=0A----- Original Message -----=0A> From: Tim Chown =0A> To: Fernando Gont =0A> Cc: Mark ZZZ = Smith ; "6man-chairs@tools.ietf.org Chairs" <6ma= n-chairs@tools.ietf.org>; 6man WG =0A> Sent: Friday, 23 Augu= st 2013 8:56 PM=0A> Subject: Re: 6MAN WG Last Call: =0A> =0A> On 22 Aug 2013, at 22:58, Fernando Gont wrote:=0A> =0A>> On 08/19/2013 08:19 AM, Mark ZZZ Smi= th wrote:=0A>>> =0A>>> Going by the title, it seems my comment was missed = about not implying=0A>>> that this address generation technique is limited= to SLAAC slack=0A>>> scenarios, but could be useful with any address conf= iguration method=0A>>> (i.e, SLAAC, DHCPv6, static, +future.) There seemed= to be some=0A>>> support for decoupling the concepts of address generatio= n from=0A>>> address configuration.=0A>> =0A>> How about something like:= =0A>> =0A>> "While the method specified in this document is meant to be us= ed with=0A>> SLAAC, this doesn not preclude the same algorithm from being = used with=0A>> other address configuration mechanisms, such as DHCPv6 or s= tatic address=0A>> confguration"=0A>> =0A>> at the end of Section 1, righ= t before the "terminology" =0A> paragraph?=0A> =0A> I think that fits well = with the advice in 5177 and its replacement to not use =0A> sequential IPs = from a DHCP pool.=0A> =0A> The difference for DHCP is perhaps that there ma= y be some reason the pool is not =0A> the whole /64, in which case it would= still be prudent to randomise from within =0A> the pool.=0A> =0A> I think = Mark's point though is that an address may be used for the =0A> initiation = of incoming and/or outgoing communications, and how the address is =0A> gen= erated should not necessarily be tied to how it is used. I would certainly = =0A> agree with that.=0A>=A0=0A=0ANot quite.=0A=0AI'm more coming from the = point of view that generally address generation methods are or should be se= parate from address configuration methods (although influenced by them if n= ecessary or useful), and neither of the methods should influence address ex= piry - IPv6 preferred and valid lifetimes are for that.=0A=0AThe reason I'v= e been thinking about this is the recent identified behaviour in Windows wh= ere when the M bit was switched off in an RA, the Windows machine would tea= r down stateful DHCPv6 and immediately expire the IPv6 addresses that were = configured by it, even though the addresses themselves still had non-zero v= alid and preferred lifetimes. This behaviour would prevent a smooth transit= ion on a link from SLAAC address configuration to stateful DHCPv6 and vice-= versa.=0A=0ASo it has seemed to me there are really 3 separate addressing r= elated functions:=0A=0A- address generation methods (e.g., derived from IEE= E address, the method described in this ID, or others)=0A=0A- address confi= guration methods, that configure addresses and their preferred and valid li= fetime values (currently SLAAC, stateful DHCPv6 or static)=0A=0A- the addre= ss expiring/aging method, using the preferred and valid lifetimes, but shou= ld not influenced by the method used to configure them (if you want to forc= e address expiry, use your chosen address configuration method to set the p= referred and valid lifetimes to their expiry values and then let the addres= ses immediately age out)=0A=0ABy keeping the address expiring/aging method = independent from the address configuration method, it would then be possibl= e to fairly smoothly transition between different address configuration met= hods, rather than the current disruption that would be suffered with Window= s (and perhaps other OSes) today.=0A=0AThe above text is motivated by the i= dea that the addresses generated by the method described in the draft shoul= d be possible to configure using SLAAC, stateful DHCPv6 or manual static co= nfiguration, or any other future address configuration methods. This draft = is describing both an address generation method and how the generated addre= sses can be configured using SLAAC. The proposed text leaves room to descri= be how the address generation method could be used with stateful DHCPv6 or = just applied with static configuration if the addresses are generated manua= lly (using a script, spreadsheet etc.). Off-list I suggested rather than a = future draft specifying how to use the provided address generation method w= ith DHCPv6, have a future draft called something like "A Generalised Method= for Generating Semantically Opaque IPv6 Interface Identifiers", which migh= t discuss how they can be used with DHCPv6 as a configuration method, but h= opefully general enough that if there are future address configuration methods, they don't need to specify= how=A0=A0Semantically Opaque IPv6 Interface Identifiers are configured wit= h them.=0A=0A> I'm not sure what you mean by static address configuration i= n this context.=0A>=A0=0A=0AIs it clearer now?=0A=0ARegards,=0AMark.=0A=0A>= Tim=0A> From Freek.Dijkstra@surfsara.nl Fri Aug 23 06:23:49 2013 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 2C6FB11E80FF for ; Fri, 23 Aug 2013 06:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVcFV8SwWssE for ; Fri, 23 Aug 2013 06:23:48 -0700 (PDT) Received: from govert.macfreek.nl (govert.macfreek.nl [IPv6:2a01:238:43ed:a300:ea00:54c2:fb7a:7e66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E81D11E80D2 for ; Fri, 23 Aug 2013 06:23:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by govert.macfreek.nl (Postfix) with ESMTP id 547C864A0F2 for ; Fri, 23 Aug 2013 15:23:46 +0200 (CEST) Received: from govert.macfreek.nl ([127.0.0.1]) by localhost (govert.macfreek.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOdzzZf0gd0O for ; Fri, 23 Aug 2013 15:23:46 +0200 (CEST) Received: from saramac0003.local (unknown [IPv6:2001:610:108:2000:8009:ff67:3ad9:6ddb]) by govert.macfreek.nl (Postfix) with ESMTPSA id 0E5A664A001 for ; Fri, 23 Aug 2013 15:23:45 +0200 (CEST) Message-ID: <52176261.6020607@surfsara.nl> Date: Fri, 23 Aug 2013 15:23:45 +0200 From: Freek Dijkstra Organization: SURFsara User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Benchmarking RFC 5180 IPv6 allocation X-Enigmail-Version: 1.5.2 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: Fri, 23 Aug 2013 13:25:04 -0000 What's the Benchmarking IPv6 allocation made by RFC 5180? The RFC and IANA registry seem to mismatch. http://tools.ietf.org/html/rfc5180#section-8 lists: > The IANA has allocated 2001:0200::/48 for IPv6 benchmarking, which is > a 48-bit prefix from the RFC 4773 pool. http://www.iana.org/assignments/iana-ipv6-special-registry and http://www.iana.org/assignments/ipv6-unicast-address-assignments list: > 2001:2::/48 Benchmarking [RFC5180] However, 2001:2::/48 expands to 2001:0002::/48, not 2001:0200::/48. Freek From Freek.Dijkstra@surfsara.nl Fri Aug 23 13:22:37 2013 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 01DE421F9473 for ; Fri, 23 Aug 2013 13:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjTl6nML21ms for ; Fri, 23 Aug 2013 13:22:34 -0700 (PDT) Received: from govert.macfreek.nl (govert.macfreek.nl [IPv6:2a01:238:43ed:a300:ea00:54c2:fb7a:7e66]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD021F9E28 for ; Fri, 23 Aug 2013 13:22:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by govert.macfreek.nl (Postfix) with ESMTP id 22A1364A0F1 for ; Fri, 23 Aug 2013 22:22:31 +0200 (CEST) Received: from govert.macfreek.nl ([127.0.0.1]) by localhost (govert.macfreek.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX4MTE6h4Y0r for ; Fri, 23 Aug 2013 22:22:31 +0200 (CEST) Received: from lampje.macfreek.nl (home.macfreek.nl [145.99.1.68]) by govert.macfreek.nl (Postfix) with ESMTPSA id CB40264A001 for ; Fri, 23 Aug 2013 22:22:30 +0200 (CEST) Message-ID: <5217C484.6040104@surfsara.nl> Date: Fri, 23 Aug 2013 22:22:28 +0200 From: Freek Dijkstra Organization: SURFsara User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Benchmarking RFC 5180 IPv6 allocation References: <52176261.6020607@surfsara.nl> In-Reply-To: <52176261.6020607@surfsara.nl> X-Enigmail-Version: 1.5.2 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: Fri, 23 Aug 2013 20:22:37 -0000 On 23-08-2013 15:23, Freek Dijkstra wrote: > What's the Benchmarking IPv6 allocation made by RFC 5180? > > The RFC and IANA registry seem to mismatch. > > http://tools.ietf.org/html/rfc5180#section-8 lists: > >> The IANA has allocated 2001:0200::/48 for IPv6 benchmarking, which is >> a 48-bit prefix from the RFC 4773 pool. > > http://www.iana.org/assignments/iana-ipv6-special-registry and > http://www.iana.org/assignments/ipv6-unicast-address-assignments list: > >> 2001:2::/48 Benchmarking [RFC5180] > > However, 2001:2::/48 expands to 2001:0002::/48, not 2001:0200::/48. FYI, the correct allocation is 2001:0002::/48. The RFC has a typo, which was already listed in the errata (which I missed before): http://www.rfc-editor.org/errata_search.php?rfc=5180 Freek From mcr@sandelman.ca Mon Aug 26 06:46:45 2013 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 8262611E819D; Mon, 26 Aug 2013 06:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR-P7Sll-V1F; Mon, 26 Aug 2013 06:46:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3C911E8194; Mon, 26 Aug 2013 06:46:39 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.252.140]) by relay.sandelman.ca (Postfix) with ESMTPS id 693B42207C; Mon, 26 Aug 2013 09:46:38 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AB092CA0D2; Sun, 25 Aug 2013 20:37:09 -0400 (EDT) From: Michael Richardson To: "6man\@ietf.org" <6man@ietf.org>, "6lo\@ietf.org" <6lo@ietf.org> Subject: 6lowpan-backbone-router-03 In-reply-to: References: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Fri, 23 Aug 2013 11:01:47 -0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 25 Aug 2013 20:37:09 -0400 Message-ID: <4756.1377477429@sandelman.ca> Sender: mcr@sandelman.ca 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, 26 Aug 2013 13:46:45 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > There is a need for a protocol between the 6LBRs/NEAR routers to > exchange their state. This could be achieved by an extension on ND f= or > proxy operations as described in dratf-thubert-6lowpan-backbone-route= r, > a similar extension to a routing protocol running on the backbone or a > richer extension to IPv6 NDP allowing some degree of pub/sub as well. Are the wired part of the 6LBRs always located on the same link? I'm asking because it seems like this is an important assumption. I read 6lowpan-backbone-router-03. Please number the figure in section 3. I'll call it "Figure Plan Network" I don't like the term backbone, and backbone router. What I see are three areas of a DAG connected by a heterogeneous layer-2. The "BBR" are just RPL routers. I don't know why a new protocol is necessary for the mesh-over case.=20 Perhaps the MESH-under case has some requirements, but I'd rather just pretend that it's four links (an ethernet link, and three mesh-under links) connected together to form a single mesh-over network. It seems to me that you are inventing a protocol to solve the MESH-under problem, but that we already have such a protocol. =2D-=20 Michael Richardson =2Dat the cottage- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSGqMxAAoJEKD0KQ7Gj3P24V0H/3dDSOItFKY8V4+5stjvpXo5 avh53TZX8zM6DxbyXLWPsjBHZfZUk2MRki/FPNOZD00v1n63ssbmAnFH1rqEWHu6 YVdvgSDJLVKBrzMbyAqNerEIvUT6tYQPoJ72gcvGfNBvcY2t5diMywSmy/4+0+gv X7QOohl9j6IyycpCWRoY2rv+u2N4gXEgZ/ZJLGbS2CI3pX2emj4asOlQabqL+Jm5 PHjJZHCMmkYvPwmn92jKMrWyWIIiUQgMgY1BG8xy1mqT8epLTU/uvD9xTFBRjwkM EleL8Kj46+XRrgQTxEUaiMo3iA7DMaL7jj13G6XbEvhO35EkMfjsVO59i/z5htc= =rJl/ -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Mon Aug 26 13:03:52 2013 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 CCF8021F991F; Mon, 26 Aug 2013 13:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQkjghMOPSif; Mon, 26 Aug 2013 13:03:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 622D821F93C4; Mon, 26 Aug 2013 13:03:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ug-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130826200352.2034.93896.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2013 13:03:52 -0700 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, 26 Aug 2013 20:03:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-03.txt Pages : 11 Date : 2013-08-26 Abstract: The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no generic meaning and that the identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in interface identifiers that are derived from an IEEE link-layer address, and updates RFC 4291 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ug There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ug-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ug-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Mon Aug 26 13:15:27 2013 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 D242C21F9D33 for ; Mon, 26 Aug 2013 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx97xUxKms6u for ; Mon, 26 Aug 2013 13:15:25 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 246E521F997B for ; Mon, 26 Aug 2013 13:15:23 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so3863376pbc.31 for ; Mon, 26 Aug 2013 13:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=LWACZ9DRN4GfRZhs0IWEeSkaCqtkrDoIli1l6bLeO3M=; b=wNy0m741zKk7MqUESgMlVVN1HXwoUyhmDIwdUA5VWyG/VM3ye201ooFgMPnZzqxUou Lv2wRIPL9LVX8sck6LwhQcTvQ/eq2rVybzLBWvYaa2bH0TwA3uOVQUR98yf/shG/MEMf FlnYtxlltyARaV/kn7aIKq9V7mjyITNCq2m201iYO/Iu8lZ/2IiejIX10AhCo+ixPvvR 8OYJSa/i1/hwmXkyiZys3/g6QG/BZXWvaA9/F0WzHGeiLug99vSO9av1Q1HkVG4wArPJ +zkbz9uw0coD/L7owWjBJgrmsL3On/nH+zDRSBjApJ+md3yPMk8tqRWDQB9BxMnH0qz8 8FYA== X-Received: by 10.66.176.143 with SMTP id ci15mr4859233pac.146.1377548122348; Mon, 26 Aug 2013 13:15:22 -0700 (PDT) Received: from [192.168.178.20] (33.196.69.111.dynamic.snap.net.nz. [111.69.196.33]) by mx.google.com with ESMTPSA id fl3sm21950937pad.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 13:15:21 -0700 (PDT) Message-ID: <521BB753.10805@gmail.com> Date: Tue, 27 Aug 2013 08:15:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-ug-03.txt] 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: Mon, 26 Aug 2013 20:15:27 -0000 Hi, This version responds to Fernando's review, as discussed in http://www.ietf.org/mail-archive/web/ipv6/current/msg18789.html We did not delete the paragraph in Section 5 as Fernando suggested, because we think it's a necessary clarification. Brian + Sheng -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-ug-03.txt Date: Mon, 26 Aug 2013 13:03:52 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Significance of IPv6 Interface Identifiers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-ug-03.txt Pages : 11 Date : 2013-08-26 Abstract: The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no generic meaning and that the identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in interface identifiers that are derived from an IEEE link-layer address, and updates RFC 4291 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ug There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ug-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ug-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From heard@pobox.com Mon Aug 26 16:08:10 2013 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 E251B11E80FF for ; Mon, 26 Aug 2013 16:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIzH-SfDiviE for ; Mon, 26 Aug 2013 16:08:05 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DFF11E80FE for ; Mon, 26 Aug 2013 16:08:04 -0700 (PDT) Received: (qmail 5694 invoked from network); 26 Aug 2013 16:08:00 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Aug 2013 16:08:00 -0700 Date: Mon, 26 Aug 2013 16:08:00 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: draft-andrews-6man-fragopt updated In-Reply-To: Message-ID: References: <20130806011402.769C1380908C@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 26 Aug 2013 23:08:10 -0000 On Mon, 19 Aug 2013, C. M. Heard wrote: > On Tue, 6 Aug 2013, Mark Andrews wrote: > > http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt ... > In answer to to the open questions, I would suggest using a single > option code and making the protocol explicit. The strategy of > leaving the protcol implicit leads to ambigiuities (e.g., between > TCP, UDP, and UDP-lite). I would also suggest judicious use of > padding to align 4 and 8 bytes quantities on natural boundaries. It occurs to me that instead of having a different option format for every single upper-layer protocol, one could instead just package the portion of the header chain (extension headers, if any, and upper-layer header) that appears after the fragmentation header in the initial fragment. That would require only a single option code, would apply to all present and future upper-layer protocols, and would provide the requisite upper-layer information in a form that those who want it must already know how to parse. The option would look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1| (TBD) | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Portion of header chain following offset=0 fragment header + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type would be chosen to indicate that the option is mutable and is to be skipped if it is not recognized. The alignment requirement would be 8n+6, since the upper-layer header and any preceding extension headers always are aligned on 8-octet boundaries. Here are some other suggestions: - Make this a destination option that appears before the fragmentation header, not a hop-by-hop option, as discussed in a previous e-mail in this thread. - This option MUST NOT appear in an initial fragment (or in an unfragmented fatagram). That avoids the possibiity that a middlebox will interpret a datagram differently from an end system (or another middlebox). - New end-system implementations MUST have the capability to insert this option in non-initial fragments. That capability MUST be configurable, and the default SHOULD be to insert the option. - If a forwarding node discards a packet containing this option, it MUST be the result of a configurable policy, and not just the result of a failure to recognize the option. By default, the policy SHOULD be the same that the node would apply to an initial fragment with the same header chain that is in the option, and that in turn SHOULD be the same policy that the node would apply to an unfragmented datagram with the same header chain (less the fragmentation header). - A forwarding node that rewrites the flow label MAY use the information available in this option for that purpose. - An end system is not required to process this option. However, if it does, it SHOULD ensure that the copies the upper-layer in the various fragments match what appears in the initial fragment, and that the option does not appear in an initial fragment (or in an unfragmented datagram). [Define codes and pointers for an ICMPv6 Parameter Problem message that indicates these situations.] Acknowledgments to draft-ietf-6man-ext-transmit-03 for some stolen text. Item for discussion: does it really matter whether or not this option is marked as mutable? It would not be covered by an Authetication Header in any case since "AH is applied only to whole IP datagrams (not to IP fragments)" [RFC 2402] and this option is inserted only after fragmentation. A NAT does not respect immutability (as defined in RFC 2402), so the possibility of a NAT being on the path does not seem like a good reason to mark it mutable. On the other hand, what benefit could there be from marking it as immutable? Mike Heard From marka@isc.org Mon Aug 26 16:42:46 2013 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 59BA721E804E for ; Mon, 26 Aug 2013 16:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nNM+ac5jWrR for ; Mon, 26 Aug 2013 16:42:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 00BD511E8261 for ; Mon, 26 Aug 2013 16:42:42 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6DAC6C9473; Mon, 26 Aug 2013 23:42:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377560561; bh=u2PoFVSwPswDoglPjZxIFKp441mmwuuVvQ49NLBWWJw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=XrHWjy+RJXJG+WjVVyC+J48i4Xh4KesqxGmDO6mKoXlXvZOGn0FPPQo7uvACZnGBI Nx33P1Y8Gqc21kkq+KilPg8JHRc8+wQmqed6myIEhkGhYhGofBXrzX53JHUDyC2Ujx mKnsU05Tc7OKp1sEYlELMdsumMH95oAXMo7jEXZo= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 26 Aug 2013 23:42:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6C50016043C; Mon, 26 Aug 2013 23:43:03 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 145431602D3; Mon, 26 Aug 2013 23:43:03 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id CDC3E38E3CF7; Tue, 27 Aug 2013 09:42:23 +1000 (EST) To: "C. M. Heard" From: Mark Andrews References: <20130806011402.769C1380908C@drugs.dv.isc.org> Subject: Re: draft-andrews-6man-fragopt updated In-reply-to: Your message of "Mon, 26 Aug 2013 16:08:00 -0700." Date: Tue, 27 Aug 2013 09:42:23 +1000 Message-Id: <20130826234223.CDC3E38E3CF7@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 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, 26 Aug 2013 23:42:46 -0000 In message , "C. M. Heard " writes: > On Mon, 19 Aug 2013, C. M. Heard wrote: > > On Tue, 6 Aug 2013, Mark Andrews wrote: > > > http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt > ... > > In answer to to the open questions, I would suggest using a single > > option code and making the protocol explicit. The strategy of > > leaving the protcol implicit leads to ambigiuities (e.g., between > > TCP, UDP, and UDP-lite). I would also suggest judicious use of > > padding to align 4 and 8 bytes quantities on natural boundaries. > > It occurs to me that instead of having a different option format for > every single upper-layer protocol, one could instead just package > the portion of the header chain (extension headers, if any, and > upper-layer header) that appears after the fragmentation header in > the initial fragment. That would require only a single option code, > would apply to all present and future upper-layer protocols, and > would provide the requisite upper-layer information in a form that > those who want it must already know how to parse. The option would > look like this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|1| (TBD) | Opt Data Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Portion of header chain following offset=0 fragment header + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The type would be chosen to indicate that the option is mutable and > is to be skipped if it is not recognized. The alignment requirement > would be 8n+6, since the upper-layer header and any preceding > extension headers always are aligned on 8-octet boundaries. > > Here are some other suggestions: > > - Make this a destination option that appears before the > fragmentation header, not a hop-by-hop option, as discussed in a > previous e-mail in this thread. It is quite possible to develop asics which understand this option the same way as there are asics which process tcp and udp headers. > - This option MUST NOT appear in an initial fragment (or in an > unfragmented fatagram). That avoids the possibiity that a > middlebox will interpret a datagram differently from an end system > (or another middlebox). This is a non starter. Whatever change we make needs to be visible in all fragment. Firewalls need to be able to identify if the packet is following old fragmentation rules or new fragmentation rules so it can decide if it is applying old policy or new policy. > - New end-system implementations MUST have the capability to insert > this option in non-initial fragments. That capability MUST be > configurable, and the default SHOULD be to insert the option. > > - If a forwarding node discards a packet containing this option, it > MUST be the result of a configurable policy, and not just the > result of a failure to recognize the option. By default, the > policy SHOULD be the same that the node would apply to an initial > fragment with the same header chain that is in the option, and > that in turn SHOULD be the same policy that the node would apply > to an unfragmented datagram with the same header chain (less the > fragmentation header). > > - A forwarding node that rewrites the flow label MAY use the > information available in this option for that purpose. > > - An end system is not required to process this option. However, if > it does, it SHOULD ensure that the copies the upper-layer in the > various fragments match what appears in the initial fragment, and > that the option does not appear in an initial fragment (or in an > unfragmented datagram). [Define codes and pointers for an ICMPv6 > Parameter Problem message that indicates these situations.] > > Acknowledgments to draft-ietf-6man-ext-transmit-03 for some stolen > text. > > Item for discussion: does it really matter whether or not this > option is marked as mutable? It would not be covered by an > Authetication Header in any case since "AH is applied only to whole > IP datagrams (not to IP fragments)" [RFC 2402] and this option is > inserted only after fragmentation. A NAT does not respect > immutability (as defined in RFC 2402), so the possibility of a NAT > being on the path does not seem like a good reason to mark it > mutable. On the other hand, what benefit could there be from > marking it as immutable? > > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From heard@pobox.com Mon Aug 26 19:09:35 2013 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 1929E11E811F for ; Mon, 26 Aug 2013 19:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97KzruOY11oY for ; Mon, 26 Aug 2013 19:09:30 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C9B11E8119 for ; Mon, 26 Aug 2013 19:09:28 -0700 (PDT) Received: (qmail 4258 invoked from network); 26 Aug 2013 19:09:23 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Aug 2013 19:09:23 -0700 Date: Mon, 26 Aug 2013 19:09:23 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: draft-andrews-6man-fragopt updated In-Reply-To: <20130826234223.CDC3E38E3CF7@drugs.dv.isc.org> Message-ID: References: <20130806011402.769C1380908C@drugs.dv.isc.org> <20130826234223.CDC3E38E3CF7@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 27 Aug 2013 02:09:35 -0000 On Tue, 27 Aug 2013, Mark Andrews wrote: > In message , > "C. M. Heard" writes: > > Here are some other suggestions: > > > > - Make this a destination option that appears before the > > fragmentation header, not a hop-by-hop option, as discussed in a > > previous e-mail in this thread. > > It is quite possible to develop asics which understand this option > the same way as there are asics which process tcp and udp headers. could be developed != exists in current core routers Existing core routers are likely to punt hop-by-hop options to a slow path. But they aren't the cause of the fragment dropping problems. So we should seek a solution that does not require updating them. I don't see why a destination option (apearing BEFORE the fragment header) would not work just as well as a hop-by-hop option while being immune from this particular problem. > > - This option MUST NOT appear in an initial fragment (or in an > > unfragmented fatagram). That avoids the possibiity that a > > middlebox will interpret a datagram differently from an end system > > (or another middlebox). > > This is a non starter. Whatever change we make needs to be visible in > all fragment. Firewalls need to be able to identify if the packet is > following old fragmentation rules or new fragmentation rules so it can > decide if it is applying old policy or new policy. I don't see that. The initial fragment, without the option, already has the upper-layer information that a firewall needs in order to apply a filtering policy (assuming of course that it complies with draft-ietf-6man-oversized-header-chain). Non-initial fragments get dropped because that information is missing. The option provides the missing information. Firewalls that discard non-initial fragments will need to be updated to use the option. Firewalls that unconditionally drop anything with a fragment header will need also to be updated not to drop initial fragments (as long as those fragments contain a complete upper-layer header, per draft-ietf-6man-oversized-header-chain). Either way, an update to the firewall is required. The downside of putting the option into initial fragments is what can happen if there is a mismatch between the contents of the option and the actual upper-layer header if both are present. If for ease of implementation the firewall uses the option but not the upper-layer header (so that all fragments are treated the same), what it lets through may be interpreted differently by an end system than the firewall expected (this is particularly true for old end system implemantations that have not been updated to recognize the option) -- in other words, there is a possibility of evading the firewall's policy. This possibility is completely elminated by eliminating the duplicate information, i.e., by leaving the option out of initial fragments (and unfragmented datagrams). It is true that an initial fragment generated by an old implementation and generated one by a new implementation cannot be distinguished under my proposal. The worst that happens is that the initial fragment generated by an old implementation gets through, but succeeding ones do not. In that case some resources are consumed on the destination host, but the datagram does not get through (as intended by the firewall). Indeed, in looking at http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf which was a primary reference for draft-taylor-v6ops-fragdrop, it seems that is generally (or often) what happens today. //cmh From marka@isc.org Mon Aug 26 19:24:57 2013 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 9265811E8123 for ; Mon, 26 Aug 2013 19:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHSYRDbsdGzr for ; Mon, 26 Aug 2013 19:24:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A4F2921F9C2C for ; Mon, 26 Aug 2013 19:24:52 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 58F28C947E; Tue, 27 Aug 2013 02:24:39 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377570292; bh=mJyWGdbka65SyF+oQHJ427IlsgG28INorJb8tfFUoPU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=NL+DxLXeAHY1YI7IvQREQMqCumHgoQb4Gb8g7HwNr54A8hsGKuw71emMVI5L0qpBB tHc++TUW1o4M5PJsB6+caClKllQRdNiOOxDsAVK6x/32dMO5yoOGjZl6k077z9UIZd 3QT8xZ5NbmTKOHCTbSiEjmlQjQo1JbmPrhNSPRu8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 27 Aug 2013 02:24:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D149016043C; Tue, 27 Aug 2013 02:25:13 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A20D21602D3; Tue, 27 Aug 2013 02:25:13 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id EEAB638E6258; Tue, 27 Aug 2013 12:24:33 +1000 (EST) To: "C. M. Heard" From: Mark Andrews References: <20130806011402.769C1380908C@drugs.dv.isc.org> <20130826234223.CDC3E38E3CF7@drugs.dv.isc.org> Subject: Re: draft-andrews-6man-fragopt updated In-reply-to: Your message of "Mon, 26 Aug 2013 19:09:23 -0700." Date: Tue, 27 Aug 2013 12:24:33 +1000 Message-Id: <20130827022433.EEAB638E6258@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 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, 27 Aug 2013 02:24:57 -0000 In message , "C. M. Heard " writes: > On Tue, 27 Aug 2013, Mark Andrews wrote: > > In message , > > "C. M. Heard" writes: > > > Here are some other suggestions: > > > > > > - Make this a destination option that appears before the > > > fragmentation header, not a hop-by-hop option, as discussed in a > > > previous e-mail in this thread. > > > > It is quite possible to develop asics which understand this option > > the same way as there are asics which process tcp and udp headers. > > could be developed != exists in current core routers > > Existing core routers are likely to punt hop-by-hop options to a > slow path. But they aren't the cause of the fragment dropping > problems. So we should seek a solution that does not require > updating them. Some punt them to the slow path but fragmented IP is also a small percentage of traffic. Others just don't process hop-by-hop. Others just drop. > I don't see why a destination option (apearing BEFORE the fragment > header) would not work just as well as a hop-by-hop option while > being immune from this particular problem. > > > > - This option MUST NOT appear in an initial fragment (or in an > > > unfragmented fatagram). That avoids the possibiity that a > > > middlebox will interpret a datagram differently from an end system > > > (or another middlebox). > > > > This is a non starter. Whatever change we make needs to be visible in > > all fragment. Firewalls need to be able to identify if the packet is > > following old fragmentation rules or new fragmentation rules so it can > > decide if it is applying old policy or new policy. > > I don't see that. Lots of firewalls discard all fragments as it is pointless sending the initial fragment if you are discarding non-initial fragments. As for mis-matches they are expected if you have NATs in the path. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From heard@pobox.com Mon Aug 26 21:38:00 2013 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 4DFEE21E80AD for ; Mon, 26 Aug 2013 21:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlc-QClbqkQk for ; Mon, 26 Aug 2013 21:37:55 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9BE11E814D for ; Mon, 26 Aug 2013 21:37:55 -0700 (PDT) Received: (qmail 20029 invoked from network); 26 Aug 2013 21:37:49 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Aug 2013 21:37:49 -0700 Date: Mon, 26 Aug 2013 21:37:49 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") In-Reply-To: Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 27 Aug 2013 04:38:00 -0000 Greetings, Upon reflection, I have come to the conclusion that the proposal in draft-andrews-6man-fragopt (or a variant thereof) is a much better solution to the problems with IPv6 fragmentation than the UDP segmentation scheme I proposed. The huge advantage of putting a skippable IPv6 option with higher-layer header information into IPv6 fragments is that it is much easier to deploy incrementally than the UDP segmentation scheme. New end systems could begin inserting the option as soon the format is standardized, and they would still be able to communicate with older end systems that comply with existing IPv6 specifictions, at least on paths where fragments are not discarded by firewalls. That's not true of the UDP segmentation scheme (or of more complex alternatives such as SEAL). A second advantage of the proposal in draft-andrews-6man-fragopt, or more specifically of a variant that I proposed in http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html, is that it can be made to work with any upper-layer protocol, present or future. The UDP segmentation scheme works for one protocol only. (SEAL would work with any upper-layer protocol, but since it hides the upper-layer headers, it could well be blocked by firewalls for that reason.) It is true that firewalls will need to be updated to make the option scheme achieve its objective of getting fragments through. It seems, however, that the same is true of the UDP segmentation scheme that I proposed; Google for "UDP packet length and the size on the wire do not match" for some examples. (SEAL, being a new upper-layer protocol, would also require firewall updates). The main lesson I draw from draft-taylor-v6ops-fragdrop is that IPv6 fragmentation, as currently specified, does not meet the requirements of certain operators because upper-layer header information is absent from non-initial fragments. The option scheme directly addresses that problem. Given that the 6man WG is not ready to deprecate IPv6 fragmentation, it seems to me that it should be rehabilitated to the extent possible, and I think the option scheme would do that. Thanks and regards, Mike Heard On Wed, 7 Aug 2013, Ronald Bonica wrote: > Fred, > > We should probably be clear about which problem we are trying to > solve. The following are possibilities: > > a) Remove network administrators' motivation for blocking IPv6 > fragments. To this end, we assume that the network administrators' > primary motivation is the tiny fragment problem. So, we solve the > tiny fragment problem by changing the way that IPv6 fragmentation > works. In the new fragmentation scheme, each fragment contains > parsable information regarding the payload protocol and port. > > b) Make UDP-based applications work in a world where network > administrators block IPv6 fragments. We do this by either > modifying UDP so that it supports fragmentation and reassembly of > long payloads or creating a new UDP-like protocol that supports > the fragmentation and reassembly of long payloads. > > Draft-andrews-6man-fragopt solves the problem posed in > draft-bonica-6man-frag-deprecate by solving problem a). Mike's > proposal solves the problem posed in > draft-bonica-6man-frag-deprecate by solving problem [b)]. > > IMHO, both proposals address the problem. We are currently trying > to figure out which will work best. > > Ron > > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, August 06, 2013 6:36 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > Ron, > > > > One other thing for now is that Mike's proposal doesn't even address > > the attack vector that 'draft-bonica-6man-frag-deprecate' > > is concerned about. To address the tiny fragment concern, the protocol > > must ensure that tiny fragments cannot ever be created. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > > Of Templin, Fred L > > > Sent: Tuesday, August 06, 2013 3:07 PM > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > Hi Ron, > > > > > > > -----Original Message----- > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > Sent: Tuesday, August 06, 2013 2:54 PM > > > > To: Templin, Fred L; C. M. Heard; IPv6 > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > Fred, > > > > > > > > If that's the case, we have a good argument for changing Mike's > > > > proposal ever so slightly, so that it uses a new protocol ID. But > > > > still, Mike's proposal is elegant because: > > > > > > > > a) It solves the problem at the right layer > > > > b) It reuses UDP transport machinery. (The only exception is the in > > > > LENGTH field) > > > > c) It reuses IP fragmentation machinery (moving it to the transport > > > > layer) > > > > d) Aside from b) and c), it introduces no new protocol machinery. So, > > > > it can be described in a few short pages. This is in stark contrast to > > > > SEAL (draft-templin-intarea-seal-61) whose protocol machinery requires > > > > 41 pages to describe > > > > > > There is a lot of boiler plate in the draft that is not required to > > > describe the protocol machinery. Plus, there are many things that > > > need to be described in a functional specification beyond just > > > posting a concept in an e-mail thread. > > > > > > > which required 61 draft versions to get right. > > > > > > The best things in life are worth investing the time and energy > > > to get right. Plus, SEAL is a universal format that handles both > > > tunnel- and transport-mode requirements for all manners of > > > existing protocols. > > > > > > If we are going to define a new protocol type, let's define one > > > that addresses everything we are currently struggling with and > > > has the extensibility to address additional requirements moving > > > forward into the future. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > Sent: Tuesday, August 06, 2013 2:58 PM > > > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > With a protocol as ossified as UDP, I have a hard time imagining all > > > > > middleboxes passing the packets with what they would see as a corrupted > > > > > length field. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > -----Original Message----- > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > > > > > Of Ronald Bonica > > > > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > > > > To: C. M. Heard; IPv6 > > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > Mike, > > > > > > > > > > > > The proposal sounds elegant. I will try to paraphrase it to make sure > > > > > > that I understand. > > > > > > > > > > > > When originating a UDP datagram, the host always queries it underlying > > > > > > IP stack to determine the PMTU for the destination. If the PMTU > > > > > > greater than or equal to the size of the payload plus the UDP header > > > > > > plus the IP header, plus all IP extension headers, the originating > > > > > > host emits a conventional UDP packet which is characterized as > > > > > > follows: > > > > > > > > > > > > - Protocol = 17 > > > > > > - Length <= L4 length from IP > > > > > > > > > > > > If the PMTU less than the size of the payload plus the UDP header plus > > > > > > the IP header, plus all IP extension headers, the originating host > > > > > > emits an unconventional UDP packet which is characterized as follows: > > > > > > > > > > > > - Protocol = 17 > > > > > > - Length > L4 length from IP > > > > > > - Segment Offset, M-bit and Identification fields added to UDP header > > > > > > before the payload > > > > > > > > > > > > If an unconventional UDP packet arrives a destination that supports > > > > > > unconventional packets, it is reassembled at the transport layer. If > > > > > > an unconventional UDP packet arrives a destination that does not > > > > > > support unconventional packets, it is discarded. > > > > > > > > > > > > Do I have this much right? > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > > > > > C. M. Heard > > > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > > > To: IPv6 > > > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > > > I agree that C.M. Heard's ideas should be explored in more detail by > > > > > > > > the IETF. > > > > > > > > > > > > The idea was essentially UDP with segmentation fields, which would > > > > > > require a new protocol number. > > > > > > > > > > > > In an offline discussion with Mark Smith and I kicked around an idea > > > > > > for an alternate version not requiring a new protocol number, but > > > > > > relying instead on the redundancy of the UDP Length field. The UDP > > > > > > Length field is not actually needed; TCP does not have one but rather > > > > > > relies on the length reported by the IP layer. Under current > > > > > > standards, the UDP Length field must be at least 8 and cannot exceed > > > > > > the IP payload length minus the combined length of any extension > > > > > > headers -- let's call this the L4 length from IP. Existing > > > > > > implementations are supposed to drop UDP datagrams that fail this > > > > > > check, and all the ones I know of do so. > > > > > > > > > > > > The question then arises whether it might reasonably be possible to re- > > > > > > purpose the case UDP Length > L4 length from IP to mean a segmented UDP > > > > > > datagram. > > > > > > > > > > > > In that case 8 <= UDP Length <= L4 length from IP would be intepreted > > > > > > as a standard unsegmented UDP datagram, as is it now. > > > > > > That's the case pictured below. Note that if the L4 length indicated > > > > > > by the IP layer exceeds the UDP Length, then the extra octets would be > > > > > > discarded and are not delivered to the application; that is the > > > > > > behavior of the implementations I know of. > > > > > > > > > > > > 0 15 16 31 > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | Source Port | Destination Port | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | Length <= L4 length from IP | Checksum | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | data octets ... > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > > > > > Now suppose that we have a long UDP datagram that we want to send in > > > > > > segments. We set the Length and Checksum fields as usual, and then cut > > > > > > the datagram into segments, each of which looks like this: > > > > > > > > > > > > 0 15 16 31 > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | Source Port | Destination Port | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | Length > L4 length from IP | Checksum | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | (reserved = 0) | Segment Offset |Res|M| > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | Identification | > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > > > > > | data octets ... > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > > > > > > > > > We put the same UDP header in each segment, so (if we take some care in > > > > > > how we choose the length of the segments) each one will have a UDP > > > > > > Length field that is greater than the IP payload length minus the > > > > > > combined length of any extension headers. Implementations that conform > > > > > > to the current specifications should discard these segments, and so > > > > > > should not mistakenly consider the segmentation fields as part of the > > > > > > application data. That should make it possible for segmented UDP > > > > > > datagrams to safely coexist with conventional unsegmented one, without > > > > > > getting a new protocol number. > > > > > > > > > > > > Possible downsides: some middleboxes may filter such "erroneous" > > > > > > datagrams, and some existing erroneous implementations may fail to do > > > > > > the checks they should and might mistake these segments for ordinary > > > > > > UDP datagrams. > > > > > > > > > > > > Note that this idea does not work with UDP-lite, which replaces the > > > > > > Length field with a Checksum Coverage field. That could easily be too > > > > > > short to exceed the L4 length from IP. > > > > > > > > > > > > Mike Heard > > > > > > -------------------------------------------------------------------- > > > > > > IETF IPv6 working group mailing list > > > > > > ipv6@ietf.org > > > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > From otroan@employees.org Tue Aug 27 03:40:10 2013 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 18C1E11E820A for ; Tue, 27 Aug 2013 03:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+n23d7MSIxL for ; Tue, 27 Aug 2013 03:40:05 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id CABEC11E81BA for ; Tue, 27 Aug 2013 03:40:04 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-46.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 488785FB3; Tue, 27 Aug 2013 03:40:03 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_CF3668A8-D943-4A27-9EA9-C3544A99DED9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: 6MAN minutes IETF 87 available Date: Tue, 27 Aug 2013 12:40:01 +0200 Message-Id: <556753D5-7D11-4FFE-AFC6-0DD9AFB4D2B4@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@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: Tue, 27 Aug 2013 10:40:10 -0000 --Apple-Mail=_CF3668A8-D943-4A27-9EA9-C3544A99DED9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii all, the minutes from the 6MAN working group session at IETF 87 are now available. http://www.ietf.org/proceedings/87/minutes/minutes-87-6man Best regards, Ole --Apple-Mail=_CF3668A8-D943-4A27-9EA9-C3544A99DED9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSHIIBAAoJEFuJXizso86gqiMH/0MN1QCVOUMeiUKXbkVqdYw2 0GYabj41TdLUnZ+en1U9boD35zq9ZX8iEl+WtP8kfLdP6UxIt7XnDq4qSHx0CukS y0QjhmZZywe1IiNzoy4EedaRlXNmLTuZNQoaqvQ8KhZopJ8YbPehi/18TqH+8wjM HFvXqtwY8HvCQChYpNhIUc2jLZP1rPqrGaiGHlT1PGlqArxk//gHKlf5CY5T/Lzd tfPqdKzVPBMvuQftCg7+Eq8erPy8fPq7XOiu1VhOMNebn7Dun0SSpezZKadDkS/R +kXjOjvnKivs76N8BAMbXSm4RVSzGa9/+jclLzr+VDfNCvWsQcwdeAlVGWzWkT8= =1iDS -----END PGP SIGNATURE----- --Apple-Mail=_CF3668A8-D943-4A27-9EA9-C3544A99DED9-- From Fred.L.Templin@boeing.com Tue Aug 27 08:15:15 2013 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 934D811E819A for ; Tue, 27 Aug 2013 08:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+XqlalOL1uQ for ; Tue, 27 Aug 2013 08:15:09 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB211E8194 for ; Tue, 27 Aug 2013 08:15:08 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r7RFF8SN004359 for ; Tue, 27 Aug 2013 10:15:08 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r7RFF0wO004154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 27 Aug 2013 10:15:07 -0500 Received: from XCH-BLV-404.nw.nos.boeing.com (130.247.25.157) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 27 Aug 2013 08:15:05 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.38]) with mapi id 14.02.0328.011; Tue, 27 Aug 2013 08:15:04 -0700 From: "Templin, Fred L" To: "C. M. Heard" , IPv6 Subject: RE: UDP+Fragmentation (was: "Deprecate") Thread-Topic: UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOot9MFgzqXTvDTEmLe4pCtit+a5mpJ+iw Date: Tue, 27 Aug 2013 15:15:03 +0000 Message-ID: <2134F8430051B64F815C691A62D983180F8054@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 27 Aug 2013 15:15:15 -0000 Hi Mike, I said a while back that Mark's proposal is fine for transport mode applica= tions, but for tunnels we still need something like SEAL. I will replay my message= from an off-list discussion below: Fred fred.l.templin@boeing.com "Hi, I am not exactly sure where tunnels fit with this discussion but here = is my thinking on tunnels: 1) Tunnels absolutely require some form of fragmentation/reassembly of the encapsulated packet, as established in 'draft-generic-6man-tunfrag'. This a= pplies to all tunnels over both IPv4 and IPv6. 2) Since in-the-network fragmentation/reassembly is painful, the tunnel ing= ress needs some way of knowing when it is OK to turn it off. For that purpose, w= e need RFC4821 for tunnels. 3) RFC4821 probing needs to occur in-band within the ordinay tunneling prot= ocol messages; otherwise, the probes might take a different path than the ordina= ry messages. (The same is true of RFC4821 applied to TCP.) 4) In order to probe the path in-band, the tunneling protocol encapsulation= needs (at a minimum) a "probe" bit and a probe acknowledgement message. That mean= s that the tunneling protocol needs either a new encapsulation format or a ne= w version number. 5) Since the same probing process applies to all forms of tunnels (IP/IP, G= RE, IPsec, etc) it would be best to have a generic encapsulation format that ap= plies equally to all. 6) This new encapsulation format can reuse the bulk of the IPv6 fragment he= ader format as well as the vast majority of the IPv6 fragmentation and reassembl= y code. 7) While defining a new fragmentation header format for tunnels, change the fragment offset field to 8 bits (down from 13) which encodes an integer mul= tiple of 256 byte segments, i.e., the minimum fragment size is 256 bytes. We were discussing tunnels several weeks ago before the discussion vectored off into transport mode considerations. Do we want to start discussing tunn= els again under this thread, or should it be a separate thread?" > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Monday, August 26, 2013 9:38 PM > To: IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") >=20 > Greetings, >=20 > Upon reflection, I have come to the conclusion that the proposal in > draft-andrews-6man-fragopt (or a variant thereof) is a much better > solution to the problems with IPv6 fragmentation than the UDP > segmentation scheme I proposed. >=20 > The huge advantage of putting a skippable IPv6 option with > higher-layer header information into IPv6 fragments is that it is > much easier to deploy incrementally than the UDP segmentation > scheme. New end systems could begin inserting the option as soon > the format is standardized, and they would still be able to > communicate with older end systems that comply with existing IPv6 > specifictions, at least on paths where fragments are not discarded > by firewalls. That's not true of the UDP segmentation scheme (or of > more complex alternatives such as SEAL). >=20 > A second advantage of the proposal in draft-andrews-6man-fragopt, > or more specifically of a variant that I proposed in > http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html, > is that it can be made to work with any upper-layer protocol, > present or future. The UDP segmentation scheme works for one > protocol only. (SEAL would work with any upper-layer protocol, but > since it hides the upper-layer headers, it could well be blocked by > firewalls for that reason.) >=20 > It is true that firewalls will need to be updated to make the option > scheme achieve its objective of getting fragments through. It > seems, however, that the same is true of the UDP segmentation scheme > that I proposed; Google for "UDP packet length and the size on the > wire do not match" for some examples. (SEAL, being a new > upper-layer protocol, would also require firewall updates). >=20 > The main lesson I draw from draft-taylor-v6ops-fragdrop is that IPv6 > fragmentation, as currently specified, does not meet the > requirements of certain operators because upper-layer header > information is absent from non-initial fragments. The option scheme > directly addresses that problem. Given that the 6man WG is not > ready to deprecate IPv6 fragmentation, it seems to me that it should > be rehabilitated to the extent possible, and I think the option > scheme would do that. >=20 > Thanks and regards, >=20 > Mike Heard >=20 > On Wed, 7 Aug 2013, Ronald Bonica wrote: > > Fred, > > > > We should probably be clear about which problem we are trying to > > solve. The following are possibilities: > > > > a) Remove network administrators' motivation for blocking IPv6 > > fragments. To this end, we assume that the network administrators' > > primary motivation is the tiny fragment problem. So, we solve the > > tiny fragment problem by changing the way that IPv6 fragmentation > > works. In the new fragmentation scheme, each fragment contains > > parsable information regarding the payload protocol and port. > > > > b) Make UDP-based applications work in a world where network > > administrators block IPv6 fragments. We do this by either > > modifying UDP so that it supports fragmentation and reassembly of > > long payloads or creating a new UDP-like protocol that supports > > the fragmentation and reassembly of long payloads. > > > > Draft-andrews-6man-fragopt solves the problem posed in > > draft-bonica-6man-frag-deprecate by solving problem a). Mike's > > proposal solves the problem posed in > > draft-bonica-6man-frag-deprecate by solving problem [b)]. > > > > IMHO, both proposals address the problem. We are currently trying > > to figure out which will work best. > > > > Ron > > > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Tuesday, August 06, 2013 6:36 PM > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > Ron, > > > > > > One other thing for now is that Mike's proposal doesn't even > address > > > the attack vector that 'draft-bonica-6man-frag-deprecate' > > > is concerned about. To address the tiny fragment concern, the > protocol > > > must ensure that tiny fragments cannot ever be created. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > > > > Of Templin, Fred L > > > > Sent: Tuesday, August 06, 2013 3:07 PM > > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > Hi Ron, > > > > > > > > > -----Original Message----- > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > Sent: Tuesday, August 06, 2013 2:54 PM > > > > > To: Templin, Fred L; C. M. Heard; IPv6 > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > Fred, > > > > > > > > > > If that's the case, we have a good argument for changing Mike's > > > > > proposal ever so slightly, so that it uses a new protocol ID. > But > > > > > still, Mike's proposal is elegant because: > > > > > > > > > > a) It solves the problem at the right layer > > > > > b) It reuses UDP transport machinery. (The only exception is > the in > > > > > LENGTH field) > > > > > c) It reuses IP fragmentation machinery (moving it to the > transport > > > > > layer) > > > > > d) Aside from b) and c), it introduces no new protocol > machinery. So, > > > > > it can be described in a few short pages. This is in stark > contrast to > > > > > SEAL (draft-templin-intarea-seal-61) whose protocol machinery > requires > > > > > 41 pages to describe > > > > > > > > There is a lot of boiler plate in the draft that is not required > to > > > > describe the protocol machinery. Plus, there are many things that > > > > need to be described in a functional specification beyond just > > > > posting a concept in an e-mail thread. > > > > > > > > > which required 61 draft versions to get right. > > > > > > > > The best things in life are worth investing the time and energy > > > > to get right. Plus, SEAL is a universal format that handles both > > > > tunnel- and transport-mode requirements for all manners of > > > > existing protocols. > > > > > > > > If we are going to define a new protocol type, let's define one > > > > that addresses everything we are currently struggling with and > > > > has the extensibility to address additional requirements moving > > > > forward into the future. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > Ron > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > Sent: Tuesday, August 06, 2013 2:58 PM > > > > > > To: Ronald Bonica; C. M. Heard; IPv6 > > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > With a protocol as ossified as UDP, I have a hard time > imagining all > > > > > > middleboxes passing the packets with what they would see as a > corrupted > > > > > > length field. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf > > > > > > > Of Ronald Bonica > > > > > > > Sent: Tuesday, August 06, 2013 11:49 AM > > > > > > > To: C. M. Heard; IPv6 > > > > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > > > Mike, > > > > > > > > > > > > > > The proposal sounds elegant. I will try to paraphrase it to > make sure > > > > > > > that I understand. > > > > > > > > > > > > > > When originating a UDP datagram, the host always queries it > underlying > > > > > > > IP stack to determine the PMTU for the destination. If the > PMTU > > > > > > > greater than or equal to the size of the payload plus the > UDP header > > > > > > > plus the IP header, plus all IP extension headers, the > originating > > > > > > > host emits a conventional UDP packet which is characterized > as > > > > > > > follows: > > > > > > > > > > > > > > - Protocol =3D 17 > > > > > > > - Length <=3D L4 length from IP > > > > > > > > > > > > > > If the PMTU less than the size of the payload plus the UDP > header plus > > > > > > > the IP header, plus all IP extension headers, the > originating host > > > > > > > emits an unconventional UDP packet which is characterized > as follows: > > > > > > > > > > > > > > - Protocol =3D 17 > > > > > > > - Length > L4 length from IP > > > > > > > - Segment Offset, M-bit and Identification fields added to > UDP header > > > > > > > before the payload > > > > > > > > > > > > > > If an unconventional UDP packet arrives a destination that > supports > > > > > > > unconventional packets, it is reassembled at the transport > layer. If > > > > > > > an unconventional UDP packet arrives a destination that > does not > > > > > > > support unconventional packets, it is discarded. > > > > > > > > > > > > > > Do I have this much right? > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > On Behalf Of > > > > > > > C. M. Heard > > > > > > > Sent: Monday, August 05, 2013 11:53 PM > > > > > > > To: IPv6 > > > > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > > > > > > > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > > > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > > > > > > > > I agree that C.M. Heard's ideas should be explored in > more detail by > > > > > > > > > the IETF. > > > > > > > > > > > > > > The idea was essentially UDP with segmentation fields, > which would > > > > > > > require a new protocol number. > > > > > > > > > > > > > > In an offline discussion with Mark Smith and I kicked > around an idea > > > > > > > for an alternate version not requiring a new protocol > number, but > > > > > > > relying instead on the redundancy of the UDP Length field. > The UDP > > > > > > > Length field is not actually needed; TCP does not have one > but rather > > > > > > > relies on the length reported by the IP layer. Under > current > > > > > > > standards, the UDP Length field must be at least 8 and > cannot exceed > > > > > > > the IP payload length minus the combined length of any > extension > > > > > > > headers -- let's call this the L4 length from IP. Existing > > > > > > > implementations are supposed to drop UDP datagrams that > fail this > > > > > > > check, and all the ones I know of do so. > > > > > > > > > > > > > > The question then arises whether it might reasonably be > possible to re- > > > > > > > purpose the case UDP Length > L4 length from IP to mean a > segmented UDP > > > > > > > datagram. > > > > > > > > > > > > > > In that case 8 <=3D UDP Length <=3D L4 length from IP would b= e > intepreted > > > > > > > as a standard unsegmented UDP datagram, as is it now. > > > > > > > That's the case pictured below. Note that if the L4 length > indicated > > > > > > > by the IP layer exceeds the UDP Length, then the extra > octets would be > > > > > > > discarded and are not delivered to the application; that is > the > > > > > > > behavior of the implementations I know of. > > > > > > > > > > > > > > 0 15 16 > 31 > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | Source Port | Destination Port > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | Length <=3D L4 length from IP | Checksum > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | data octets > ... > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| > ... > > > > > > > > > > > > > > Now suppose that we have a long UDP datagram that we want > to send in > > > > > > > segments. We set the Length and Checksum fields as usual, > and then cut > > > > > > > the datagram into segments, each of which looks like this: > > > > > > > > > > > > > > 0 15 16 > 31 > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | Source Port | Destination Port > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | Length > L4 length from IP | Checksum > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | (reserved =3D 0) | Segment Offset > |Res|M| > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | Identification > | > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+- > +-+-+-+-+-+ > > > > > > > | data octets > ... > > > > > > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| > ... > > > > > > > > > > > > > > We put the same UDP header in each segment, so (if we take > some care in > > > > > > > how we choose the length of the segments) each one will > have a UDP > > > > > > > Length field that is greater than the IP payload length > minus the > > > > > > > combined length of any extension headers. Implementations > that conform > > > > > > > to the current specifications should discard these > segments, and so > > > > > > > should not mistakenly consider the segmentation fields as > part of the > > > > > > > application data. That should make it possible for > segmented UDP > > > > > > > datagrams to safely coexist with conventional unsegmented > one, without > > > > > > > getting a new protocol number. > > > > > > > > > > > > > > Possible downsides: some middleboxes may filter such > "erroneous" > > > > > > > datagrams, and some existing erroneous implementations may > fail to do > > > > > > > the checks they should and might mistake these segments for > ordinary > > > > > > > UDP datagrams. > > > > > > > > > > > > > > Note that this idea does not work with UDP-lite, which > replaces the > > > > > > > Length field with a Checksum Coverage field. That could > easily be too > > > > > > > short to exceed the L4 length from IP. > > > > > > > > > > > > > > Mike Heard > > > > > > > ----------------------------------------------------------- > --------- > > > > > > > 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 msweet@apple.com Tue Aug 27 08:59:35 2013 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 042C911E8383 for ; Tue, 27 Aug 2013 08:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[AWL=2.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkZvHQVe4fFr for ; Tue, 27 Aug 2013 08:59:29 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0F21E80EC for ; Tue, 27 Aug 2013 08:59:29 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7RUPJy3LJhaCOFSYDKgVuw)" Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MS7003X75QL7X00@mail-out.apple.com> for ipv6@ietf.org; Tue, 27 Aug 2013 08:59:26 -0700 (PDT) X-AuditID: 11807166-b7fd66d000006a64-f7-521cccddb806 Received: from [17.153.97.211] (Unknown_Domain [17.153.97.211]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id DC.78.27236.DDCCC125; Tue, 27 Aug 2013 08:59:26 -0700 (PDT) From: Michael Sweet Message-id: <10DA696F-91F6-4005-A9A8-7185BADC43D8@apple.com> Date: Tue, 27 Aug 2013 11:59:26 -0400 Subject: Fwd: New Version Notification for draft-sweet-uri-zoneid-00.txt References: <20130827155538.31994.64908.idtracker@ietfa.amsl.com> To: "ipv6@ietf.org" X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUiODPxsu69MzJBBqs3CVi8PPueyeLIt1gH Jo+tJ3+weSxZ8pMpgCmKyyYlNSezLLVI3y6BK+PB0ryCNR4V+69+Z2lgXGXfxcjJISFgIvG+ cx0LhC0mceHeerYuRi4OIYFeJokpV/eAJdgE1CR+T+pjBbGZBRIkbqz7DlTEwcErYCNx+kAe hKknsf2XHEgFi4CqxIE395hAbGEBD4nJq26zgdhCAo4Sxx/tYwexRQSUJWZ0n2ODWCsrcfrc c5YJjDyzkCyYhTAVIqwtsWzha2aQMLOAjsTkhYyowhD2x/NHmBYwsq1iFChKzUmstNBLLCjI SdVLzs/dxAgKtIbCtB2MTcutDjEKcDAq8fBabJYJEmJNLCuuzD3EKMHBrCTCe+A0UIg3JbGy KrUoP76oNCe1+BCjNAeLkjgvn4dUkJBAemJJanZqakFqEUyWiYNTqoHRbtHlO38sRSwPCAn8 +JZU01xx6dUen2SBf1PWH7sq7dTxeW2r2BpWC6M9TWv6e5z+FelNsQlZFnX8/tuVKn2ZV5rj 1DcudvUV2m7Fc86ZRWnT2+I5XIq/g6rbXDXyo6QUgt0uNX4+pbsoNaq7cVItX+lmLf4+7aSo 55uvG953TbMOPL435LgSS3FGoqEWc1FxIgBS2oVuMAIAAA== 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, 27 Aug 2013 15:59:35 -0000 --Boundary_(ID_7RUPJy3LJhaCOFSYDKgVuw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, This is my promised ID that updates RFC 6874 to add the IPvFuture syntax that was adopted from the previous, abandoned draft on this subject (back in 2005) and is implemented widely in clients and printers, and also updates the HTTP conformance requirements and guidance to include the client's zone ID in requests sent to the server (so that the server can generate link-local URIs the client can actually use...) Comments welcome... Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-sweet-uri-zoneid-00.txt > Date: 27 August, 2013 11:55:38 AM EDT > To: Stuart Cheshire , Michael Sweet , "Robert M. Hinden" , Brian Carpenter > > > A new version of I-D, draft-sweet-uri-zoneid-00.txt > has been successfully submitted by Michael Sweet and posted to the > IETF repository. > > Filename: draft-sweet-uri-zoneid > Revision: 00 > Title: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers > Creation date: 2013-08-27 > Group: Individual Submission > Number of pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-00.txt > Status: http://datatracker.ietf.org/doc/draft-sweet-uri-zoneid > Htmlized: http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 > > > Abstract: > This document describes how the zone identifier of an IPv6 scoped > address, defined as in the IPv6 Scoped Address Architecture > (RFC 4007), can be represented in a literal IPv6 address and in a > Uniform Resource Identifier that includes such a literal address. It > updates the URI Generic Syntax specification (RFC 3986) accordingly. > > [ Editor's note: This draft adds the IPvFuture format used by CUPS > since 2005, addresses some misconceptions of how zoneid's are not > useful to HTTP servers, and is intended to replace RFC 6874. ] > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_7RUPJy3LJhaCOFSYDKgVuw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Subject: New Version Notification for = draft-sweet-uri-zoneid-00.txt
Date: 27 August, 2013 = 11:55:38 AM EDT
To: Stuart Cheshire <cheshire@apple.com>, Michael = Sweet <msweet@apple.com>, = "Robert M. Hinden" <bob.hinden@gmail.com>, Brian = Carpenter <brian.e.carpenter@gmail.com>


A new version of I-D, = draft-sweet-uri-zoneid-00.txt
has been successfully submitted by = Michael Sweet and posted to the
IETF = repository.

Filename: = draft-sweet-uri-zoneid
Revision: 00
Title: = Representing IPv6 Zone Identifiers in Address Literals and Uniform = Resource Identifiers
Creation date: 2013-08-27
Group: = Individual Submission
Number of pages: 11
URL: =             http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-00.txt
= Status:          http://dat= atracker.ietf.org/doc/draft-sweet-uri-zoneid
Htmlized: =        http://tools= .ietf.org/html/draft-sweet-uri-zoneid-00


Abstract:
=   This document describes how the zone identifier of an IPv6 = scoped
  address, defined as <zone_id> in the IPv6 = Scoped Address Architecture
  (RFC 4007), can be = represented in a literal IPv6 address and in a
  Uniform = Resource Identifier that includes such a literal address.  It
=   updates the URI Generic Syntax specification (RFC 3986) = accordingly.

  [ Editor's note: This draft adds the = IPvFuture format used by CUPS
  since 2005, addresses some = misconceptions of how zoneid's are not
  useful to HTTP = servers, and is intended to replace RFC 6874. = ]




Please note that it may take a couple of minutes = from the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_7RUPJy3LJhaCOFSYDKgVuw)-- From brian.e.carpenter@gmail.com Tue Aug 27 13:33:17 2013 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 E0BDF11E81BC for ; Tue, 27 Aug 2013 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHuBO5dMh37M for ; Tue, 27 Aug 2013 13:33:17 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2861411E81C8 for ; Tue, 27 Aug 2013 13:33:17 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so5273248pab.40 for ; Tue, 27 Aug 2013 13:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YyvfXqFCy21K6De8dz42r9IBAynBuWgFd09m+YkNaCU=; b=Z1zHShNQfiRvqU6R5rrKtVYepfDw0UwE8SGlNfngCL5zeOTfZ7EPQ+qQ/VAf6k8MfC CiQi6VdY0qId1VYTO8CnodTv78J8IAm9MXVIF53+7Pq5xoyd4ABTp8v7T46g8/L3RuJg Hgp0AwUz0u87fGIgjBjOalCThz714lEOQv5fNIIxjgzIXZH0tkwffhMsnwQOl8LGiTgx H9jRrGN/AJI2ASRPKvOxHO9LkZdu8yNxREXZ4csrjMe7H8tU3MUapmTsj/aJWzxtB7mS XaRZb+INtmm+YhTtDkzaw+PxKNZD89ucEQUgSuaPzhutI7ELNOY57KBmaDtHJlqnn/xQ 9I3g== X-Received: by 10.67.22.67 with SMTP id hq3mr16410463pad.132.1377635596879; Tue, 27 Aug 2013 13:33:16 -0700 (PDT) Received: from [192.168.178.20] (69.195.69.111.dynamic.snap.net.nz. [111.69.195.69]) by mx.google.com with ESMTPSA id yo2sm28908391pab.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 13:33:16 -0700 (PDT) Message-ID: <521D0D0E.7060400@gmail.com> Date: Wed, 28 Aug 2013 08:33:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Sweet Subject: Re: Fwd: New Version Notification for draft-sweet-uri-zoneid-00.txt References: <20130827155538.31994.64908.idtracker@ietfa.amsl.com> <10DA696F-91F6-4005-A9A8-7185BADC43D8@apple.com> In-Reply-To: <10DA696F-91F6-4005-A9A8-7185BADC43D8@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man 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, 27 Aug 2013 20:33:18 -0000 Michael, I don't know where the decision to use this syntax in CUPS (IPv6addrz = IPv6address "%25" ZoneID / "v1." IPv6address "+" ZoneID) was debated - I don't think it was here, and I don't generally follow the URI discussions. My opinion, fwiw, is that the "IPvFuture" branch invented by the URI people (again without any discussion here, iirc) is exactly the sort of vague extensibility that we should avoid (RFC 6709). The other thing you should realise is that the URI people were already quite annoyed by the RFC 6874 update, which took a lot of persuasion. Going back to them with another formal syntax change would be a very hard slog. That said, documenting something that is actually used, even if it's a formal syntax violation, is always a good thing. I think your path of least resistance is a short informational RFC describing the practice adopted in CUPS. However, I don't think we should change the formal statement that a ZoneID must not be sent out on the wire; again, documenting the practice may be advisable, but encouraging it certainly isn't, for the reasons given in the Security Considerations of RFC 6874. Regards Brian On 28/08/2013 03:59, Michael Sweet wrote: > All, > > This is my promised ID that updates RFC 6874 to add the IPvFuture syntax that was adopted from the previous, abandoned draft on this subject (back in 2005) and is implemented widely in clients and printers, and also updates the HTTP conformance requirements and guidance to include the client's zone ID in requests sent to the server (so that the server can generate link-local URIs the client can actually use...) > > Comments welcome... > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-sweet-uri-zoneid-00.txt >> Date: 27 August, 2013 11:55:38 AM EDT >> To: Stuart Cheshire , Michael Sweet , "Robert M. Hinden" , Brian Carpenter >> >> >> A new version of I-D, draft-sweet-uri-zoneid-00.txt >> has been successfully submitted by Michael Sweet and posted to the >> IETF repository. >> >> Filename: draft-sweet-uri-zoneid >> Revision: 00 >> Title: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers >> Creation date: 2013-08-27 >> Group: Individual Submission >> Number of pages: 11 >> URL: http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-00.txt >> Status: http://datatracker.ietf.org/doc/draft-sweet-uri-zoneid >> Htmlized: http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 >> >> >> Abstract: >> This document describes how the zone identifier of an IPv6 scoped >> address, defined as in the IPv6 Scoped Address Architecture >> (RFC 4007), can be represented in a literal IPv6 address and in a >> Uniform Resource Identifier that includes such a literal address. It >> updates the URI Generic Syntax specification (RFC 3986) accordingly. >> >> [ Editor's note: This draft adds the IPvFuture format used by CUPS >> since 2005, addresses some misconceptions of how zoneid's are not >> useful to HTTP servers, and is intended to replace RFC 6874. ] >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From warren@kumari.net Tue Aug 27 14:19:01 2013 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 5AA8A11E8218 for ; Tue, 27 Aug 2013 14:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cppXL51Kg2it for ; Tue, 27 Aug 2013 14:18:56 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C9011E8211 for ; Tue, 27 Aug 2013 14:18:53 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id E24C31B40357; Tue, 27 Aug 2013 17:18:51 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [6MAN] UDP+Fragmentation (was: "Deprecate") From: Warren Kumari In-Reply-To: Date: Tue, 27 Aug 2013 17:18:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> To: C. M. Heard X-Mailer: Apple Mail (2.1508) Cc: IPv6 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, 27 Aug 2013 21:19:01 -0000 On Aug 27, 2013, at 12:37 AM, C. M. Heard wrote: > Greetings, >=20 > Upon reflection, I have come to the conclusion that the proposal in=20 > draft-andrews-6man-fragopt (or a variant thereof) is a much better=20 > solution to the problems with IPv6 fragmentation than the UDP=20 > segmentation scheme I proposed. >=20 > The huge advantage of putting a skippable IPv6 option with=20 > higher-layer header information into IPv6 fragments is that it is=20 > much easier to deploy incrementally than the UDP segmentation=20 > scheme. New end systems could begin inserting the option as soon=20 > the format is standardized, and they would still be able to=20 > communicate with older end systems that comply with existing IPv6=20 > specifictions, at least on paths where fragments are not discarded=20 > by firewalls. That's not true of the UDP segmentation scheme (or of=20= > more complex alternatives such as SEAL). >=20 > A second advantage of the proposal in draft-andrews-6man-fragopt,=20 > or more specifically of a variant that I proposed in > http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html,=20 > is that it can be made to work with any upper-layer protocol,=20 > present or future. The UDP segmentation scheme works for one=20 > protocol only. (SEAL would work with any upper-layer protocol, but=20 > since it hides the upper-layer headers, it could well be blocked by=20 > firewalls for that reason.) >=20 > It is true that firewalls will need to be updated to make the option=20= > scheme achieve its objective of getting fragments through. It=20 > seems, however, that the same is true of the UDP segmentation scheme=20= > that I proposed; Google for "UDP packet length and the size on the=20 > wire do not match" for some examples. (SEAL, being a new=20 > upper-layer protocol, would also require firewall updates). >=20 > The main lesson I draw from draft-taylor-v6ops-fragdrop is that IPv6=20= > fragmentation, as currently specified, does not meet the=20 > requirements of certain operators because upper-layer header=20 > information is absent from non-initial fragments. The option scheme=20= > directly addresses that problem. Given that the 6man WG is not=20 > ready to deprecate IPv6 fragmentation, it seems to me that it should=20= > be rehabilitated to the extent possible, and I think the option=20 > scheme would do that. >=20 Apologies if I missed it and this was already discussed -- for some = reason my MUA is refusing to thread this conversation correctly and so = I'm reading thing all out of order=85 I have some issue / concerns with draft-andrews-6man-fragopt=20 The whole problem is that I cannot look at the fragment and know what = protocol and port it is actually destined to (I also have concerns about = past issues with reassembly / overlapping frags, but we'll skip those = for now). I am unclear how I am supposed to be able to trust the port information = in the new header? Lets say that I only allow traffic to 192.0.2.1 port 80. What is to stop a malicious party from: 1: Generating a packet to 192.0.2.1 port 22. 2: Fragmenting it into two parts. 3: Adding a few junk headers for padding (I think that this is optional) 4: Putting in this new header and listing the destination port as 80? I *guess* if *all* of the devices on the inside of my network know to = check that the new header attributes match the reassembled pack then I = have *some* protection, but this isn't (that I could see) specified in = the draft.=20 There are some comments about NATs changing things "both the source and = destination ports may have been changed so the ports may appear to be = completely unrelated. The source port is changed by a client NAT and the destination port is changed by a NAT acting a load balancer." It is conceivable that all of the devices behind a load balancer could = be configured to ignore this check, but that removes basically all of = the protection (same thing if the LB simply strips this option). W > Thanks and regards, >=20 > Mike Heard >=20 > On Wed, 7 Aug 2013, Ronald Bonica wrote: >> Fred, >>=20 >> We should probably be clear about which problem we are trying to=20 >> solve. The following are possibilities: >>=20 >> a) Remove network administrators' motivation for blocking IPv6=20 >> fragments. To this end, we assume that the network administrators'=20 >> primary motivation is the tiny fragment problem. So, we solve the=20 >> tiny fragment problem by changing the way that IPv6 fragmentation=20 >> works. In the new fragmentation scheme, each fragment contains=20 >> parsable information regarding the payload protocol and port. >>=20 >> b) Make UDP-based applications work in a world where network=20 >> administrators block IPv6 fragments. We do this by either=20 >> modifying UDP so that it supports fragmentation and reassembly of=20 >> long payloads or creating a new UDP-like protocol that supports=20 >> the fragmentation and reassembly of long payloads. >>=20 >> Draft-andrews-6man-fragopt solves the problem posed in=20 >> draft-bonica-6man-frag-deprecate by solving problem a). Mike's=20 >> proposal solves the problem posed in=20 >> draft-bonica-6man-frag-deprecate by solving problem [b)]. >>=20 >> IMHO, both proposals address the problem. We are currently trying=20 >> to figure out which will work best. >>=20 >> Ron >>=20 >>=20 >>> -----Original Message----- >>> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >>> Sent: Tuesday, August 06, 2013 6:36 PM >>> To: Ronald Bonica; C. M. Heard; IPv6 >>> Subject: RE: UDP+Fragmentation (was: "Deprecate") >>>=20 >>> Ron, >>>=20 >>> One other thing for now is that Mike's proposal doesn't even address >>> the attack vector that 'draft-bonica-6man-frag-deprecate' >>> is concerned about. To address the tiny fragment concern, the = protocol >>> must ensure that tiny fragments cannot ever be created. >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf >>>> Of Templin, Fred L >>>> Sent: Tuesday, August 06, 2013 3:07 PM >>>> To: Ronald Bonica; C. M. Heard; IPv6 >>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") >>>>=20 >>>> Hi Ron, >>>>=20 >>>>> -----Original Message----- >>>>> From: Ronald Bonica [mailto:rbonica@juniper.net] >>>>> Sent: Tuesday, August 06, 2013 2:54 PM >>>>> To: Templin, Fred L; C. M. Heard; IPv6 >>>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") >>>>>=20 >>>>> Fred, >>>>>=20 >>>>> If that's the case, we have a good argument for changing Mike's >>>>> proposal ever so slightly, so that it uses a new protocol ID. But >>>>> still, Mike's proposal is elegant because: >>>>>=20 >>>>> a) It solves the problem at the right layer >>>>> b) It reuses UDP transport machinery. (The only exception is the = in >>>>> LENGTH field) >>>>> c) It reuses IP fragmentation machinery (moving it to the = transport >>>>> layer) >>>>> d) Aside from b) and c), it introduces no new protocol machinery. = So, >>>>> it can be described in a few short pages. This is in stark = contrast to >>>>> SEAL (draft-templin-intarea-seal-61) whose protocol machinery = requires >>>>> 41 pages to describe >>>>=20 >>>> There is a lot of boiler plate in the draft that is not required to >>>> describe the protocol machinery. Plus, there are many things that >>>> need to be described in a functional specification beyond just >>>> posting a concept in an e-mail thread. >>>>=20 >>>>> which required 61 draft versions to get right. >>>>=20 >>>> The best things in life are worth investing the time and energy >>>> to get right. Plus, SEAL is a universal format that handles both >>>> tunnel- and transport-mode requirements for all manners of >>>> existing protocols. >>>>=20 >>>> If we are going to define a new protocol type, let's define one >>>> that addresses everything we are currently struggling with and >>>> has the extensibility to address additional requirements moving >>>> forward into the future. >>>>=20 >>>> Thanks - Fred >>>> fred.l.templin@boeing.com=20 >>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >>>>>> Sent: Tuesday, August 06, 2013 2:58 PM >>>>>> To: Ronald Bonica; C. M. Heard; IPv6 >>>>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") >>>>>>=20 >>>>>> With a protocol as ossified as UDP, I have a hard time imagining = all >>>>>> middleboxes passing the packets with what they would see as a = corrupted >>>>>> length field. >>>>>>=20 >>>>>> Thanks - Fred >>>>>> fred.l.templin@boeing.com >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf >>>>>>> Of Ronald Bonica >>>>>>> Sent: Tuesday, August 06, 2013 11:49 AM >>>>>>> To: C. M. Heard; IPv6 >>>>>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") >>>>>>>=20 >>>>>>> Mike, >>>>>>>=20 >>>>>>> The proposal sounds elegant. I will try to paraphrase it to make = sure >>>>>>> that I understand. >>>>>>>=20 >>>>>>> When originating a UDP datagram, the host always queries it = underlying >>>>>>> IP stack to determine the PMTU for the destination. If the PMTU >>>>>>> greater than or equal to the size of the payload plus the UDP = header >>>>>>> plus the IP header, plus all IP extension headers, the = originating >>>>>>> host emits a conventional UDP packet which is characterized as >>>>>>> follows: >>>>>>>=20 >>>>>>> - Protocol =3D 17 >>>>>>> - Length <=3D L4 length from IP >>>>>>>=20 >>>>>>> If the PMTU less than the size of the payload plus the UDP = header plus >>>>>>> the IP header, plus all IP extension headers, the originating = host >>>>>>> emits an unconventional UDP packet which is characterized as = follows: >>>>>>>=20 >>>>>>> - Protocol =3D 17 >>>>>>> - Length > L4 length from IP >>>>>>> - Segment Offset, M-bit and Identification fields added to UDP = header >>>>>>> before the payload >>>>>>>=20 >>>>>>> If an unconventional UDP packet arrives a destination that = supports >>>>>>> unconventional packets, it is reassembled at the transport = layer. If >>>>>>> an unconventional UDP packet arrives a destination that does not >>>>>>> support unconventional packets, it is discarded. >>>>>>>=20 >>>>>>> Do I have this much right? >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf Of >>>>>>> C. M. Heard >>>>>>> Sent: Monday, August 05, 2013 11:53 PM >>>>>>> To: IPv6 >>>>>>> Subject: Re: UDP+Fragmentation (was: "Deprecate") >>>>>>>=20 >>>>>>> On Thu, 1 Aug 2013, C. M. Heard wrote: >>>>>>>> On Thu, 1 Aug 2013, RJ Atkinson wrote: >>>>>>>>> I agree that C.M. Heard's ideas should be explored in more = detail by >>>>>>>>> the IETF. >>>>>>>=20 >>>>>>> The idea was essentially UDP with segmentation fields, which = would >>>>>>> require a new protocol number. >>>>>>>=20 >>>>>>> In an offline discussion with Mark Smith and I kicked around an = idea >>>>>>> for an alternate version not requiring a new protocol number, = but >>>>>>> relying instead on the redundancy of the UDP Length field. The = UDP >>>>>>> Length field is not actually needed; TCP does not have one but = rather >>>>>>> relies on the length reported by the IP layer. Under current >>>>>>> standards, the UDP Length field must be at least 8 and cannot = exceed >>>>>>> the IP payload length minus the combined length of any extension >>>>>>> headers -- let's call this the L4 length from IP. Existing >>>>>>> implementations are supposed to drop UDP datagrams that fail = this >>>>>>> check, and all the ones I know of do so. >>>>>>>=20 >>>>>>> The question then arises whether it might reasonably be possible = to re- >>>>>>> purpose the case UDP Length > L4 length from IP to mean a = segmented UDP >>>>>>> datagram. >>>>>>>=20 >>>>>>> In that case 8 <=3D UDP Length <=3D L4 length from IP would be = intepreted >>>>>>> as a standard unsegmented UDP datagram, as is it now. >>>>>>> That's the case pictured below. Note that if the L4 length = indicated >>>>>>> by the IP layer exceeds the UDP Length, then the extra octets = would be >>>>>>> discarded and are not delivered to the application; that is the >>>>>>> behavior of the implementations I know of. >>>>>>>=20 >>>>>>> 0 15 16 = 31 >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | Source Port | Destination Port = | >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | Length <=3D L4 length from IP | Checksum = | >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | data octets ... >>>>>>> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... >>>>>>>=20 >>>>>>> Now suppose that we have a long UDP datagram that we want to = send in >>>>>>> segments. We set the Length and Checksum fields as usual, and = then cut >>>>>>> the datagram into segments, each of which looks like this: >>>>>>>=20 >>>>>>> 0 15 16 = 31 >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | Source Port | Destination Port = | >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | Length > L4 length from IP | Checksum = | >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | (reserved =3D 0) | Segment Offset = |Res|M| >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | Identification = | >>>>>>> = +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ >>>>>>> | data octets ... >>>>>>> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... >>>>>>>=20 >>>>>>> We put the same UDP header in each segment, so (if we take some = care in >>>>>>> how we choose the length of the segments) each one will have a = UDP >>>>>>> Length field that is greater than the IP payload length minus = the >>>>>>> combined length of any extension headers. Implementations that = conform >>>>>>> to the current specifications should discard these segments, and = so >>>>>>> should not mistakenly consider the segmentation fields as part = of the >>>>>>> application data. That should make it possible for segmented = UDP >>>>>>> datagrams to safely coexist with conventional unsegmented one, = without >>>>>>> getting a new protocol number. >>>>>>>=20 >>>>>>> Possible downsides: some middleboxes may filter such "erroneous" >>>>>>> datagrams, and some existing erroneous implementations may fail = to do >>>>>>> the checks they should and might mistake these segments for = ordinary >>>>>>> UDP datagrams. >>>>>>>=20 >>>>>>> Note that this idea does not work with UDP-lite, which replaces = the >>>>>>> Length field with a Checksum Coverage field. That could easily = be too >>>>>>> short to exceed the L4 length from IP. >>>>>>>=20 >>>>>>> Mike Heard >>>>>>> = -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> = -------------------------------------------------------------------- >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --=20 Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 -- J.R.R. Tolkien From marka@isc.org Tue Aug 27 14:46:54 2013 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 2CD7B21E805D for ; Tue, 27 Aug 2013 14:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FP4LDmBfjvQ for ; Tue, 27 Aug 2013 14:46:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A166421E80A3 for ; Tue, 27 Aug 2013 14:46:49 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id ED733C94AD; Tue, 27 Aug 2013 21:46:35 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377640009; bh=3VFa3wBmObMPcDOfyzLAmMZzRkQbdrc7xU7ev+oSH/w=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=U72cM8zLE8IZAXy8FLxNOkI4DRUs0WVTGhI2h/nNd6K2xtQYtsoz1dple269r4crb G2I5Vj0e1+wrfKquByuDqXhIudOlu1YAA9wG/hkSzIbKBqQWFCTrZt24NxeJe6DfXy azeQoDkaJnxZF5wV5poxcKbKL+9fDOCc3M/cUlFw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 27 Aug 2013 21:46:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F0204160446; Tue, 27 Aug 2013 21:47:13 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5FAA516043C; Tue, 27 Aug 2013 21:47:13 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id ADEBC38EC6E6; Wed, 28 Aug 2013 07:46:24 +1000 (EST) To: Warren Kumari From: Mark Andrews References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net> Subject: Re: [6MAN] UDP+Fragmentation (was: "Deprecate") In-reply-to: Your message of "Tue, 27 Aug 2013 17:18:51 -0400." <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net> Date: Wed, 28 Aug 2013 07:46:24 +1000 Message-Id: <20130827214624.ADEBC38EC6E6@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "C. M. Heard" , IPv6 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, 27 Aug 2013 21:46:54 -0000 Warren can you please fix your MUA to generate legal To: lines. "To: C. M. Heard " is not legal a legal To: line. repl: bad addresses: C. M. Heard -- no at-sign after local-part (<) In message <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net>, Warren Kumari wri tes: > > On Aug 27, 2013, at 12:37 AM, C. M. Heard wrote: > > > Greetings, > > > > Upon reflection, I have come to the conclusion that the proposal in > > draft-andrews-6man-fragopt (or a variant thereof) is a much better > > solution to the problems with IPv6 fragmentation than the UDP > > segmentation scheme I proposed. > > > > The huge advantage of putting a skippable IPv6 option with > > higher-layer header information into IPv6 fragments is that it is > > much easier to deploy incrementally than the UDP segmentation > > scheme. New end systems could begin inserting the option as soon > > the format is standardized, and they would still be able to > > communicate with older end systems that comply with existing IPv6 > > specifictions, at least on paths where fragments are not discarded > > by firewalls. That's not true of the UDP segmentation scheme (or of > > more complex alternatives such as SEAL). > > > > A second advantage of the proposal in draft-andrews-6man-fragopt, > > or more specifically of a variant that I proposed in > > http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html, > > is that it can be made to work with any upper-layer protocol, > > present or future. The UDP segmentation scheme works for one > > protocol only. (SEAL would work with any upper-layer protocol, but > > since it hides the upper-layer headers, it could well be blocked by > > firewalls for that reason.) > > > > It is true that firewalls will need to be updated to make the option > > scheme achieve its objective of getting fragments through. It > > seems, however, that the same is true of the UDP segmentation scheme > > that I proposed; Google for "UDP packet length and the size on the > > wire do not match" for some examples. (SEAL, being a new > > upper-layer protocol, would also require firewall updates). > > > > The main lesson I draw from draft-taylor-v6ops-fragdrop is that IPv6 > > fragmentation, as currently specified, does not meet the > > requirements of certain operators because upper-layer header > > information is absent from non-initial fragments. The option scheme > > directly addresses that problem. Given that the 6man WG is not > > ready to deprecate IPv6 fragmentation, it seems to me that it should > > be rehabilitated to the extent possible, and I think the option > > scheme would do that. > > > > Apologies if I missed it and this was already discussed -- for some > reason my MUA is refusing to thread this conversation correctly and so > I'm reading thing all out of order. > > I have some issue / concerns with draft-andrews-6man-fragopt > The whole problem is that I cannot look at the fragment and know what > protocol and port it is actually destined to (I also have concerns about > past issues with reassembly / overlapping frags, but we'll skip those for > now). > I am unclear how I am supposed to be able to trust the port information > in the new header? > > Lets say that I only allow traffic to 192.0.2.1 port 80. > What is to stop a malicious party from: > 1: Generating a packet to 192.0.2.1 port 22. > 2: Fragmenting it into two parts. > 3: Adding a few junk headers for padding (I think that this is optional) > 4: Putting in this new header and listing the destination port as 80? > > I *guess* if *all* of the devices on the inside of my network know to > check that the new header attributes match the reassembled pack then I > have *some* protection, but this isn't (that I could see) specified in > the draft. > There are some comments about NATs changing things "both the source and > destination ports may have been changed so the ports may appear to be > completely unrelated. The > source port is changed by a client NAT and the destination port is > changed by a NAT acting a load balancer." > > It is conceivable that all of the devices behind a load balancer could be > configured to ignore this check, but that removes basically all of the > protection (same thing if the LB simply strips this option). > > W Assuming you don't have a load balancer that is changing the destination port the destination port will still be port 80 on all fragments in both the hop-by-hop option and the original TCP header. You still need to drop initial fragments where you can't see the entire header chain. Passing a fragment is no worse than passing a out of order segment. Reply traffic will still be from port 80 but after it has passed through a NAT the destination port in the option will not match the original source port. Again you still need to drop initial fragments where you can't see the entire header chain. You have looser rules on the non-initial fragments than for the initial fragments. But it is not wide open like it currently has to be. Mark > > Thanks and regards, > > > > Mike Heard > > > > On Wed, 7 Aug 2013, Ronald Bonica wrote: > >> Fred, > >> > >> We should probably be clear about which problem we are trying to > >> solve. The following are possibilities: > >> > >> a) Remove network administrators' motivation for blocking IPv6 > >> fragments. To this end, we assume that the network administrators' > >> primary motivation is the tiny fragment problem. So, we solve the > >> tiny fragment problem by changing the way that IPv6 fragmentation > >> works. In the new fragmentation scheme, each fragment contains > >> parsable information regarding the payload protocol and port. > >> > >> b) Make UDP-based applications work in a world where network > >> administrators block IPv6 fragments. We do this by either > >> modifying UDP so that it supports fragmentation and reassembly of > >> long payloads or creating a new UDP-like protocol that supports > >> the fragmentation and reassembly of long payloads. > >> > >> Draft-andrews-6man-fragopt solves the problem posed in > >> draft-bonica-6man-frag-deprecate by solving problem a). Mike's > >> proposal solves the problem posed in > >> draft-bonica-6man-frag-deprecate by solving problem [b)]. > >> > >> IMHO, both proposals address the problem. We are currently trying > >> to figure out which will work best. > >> > >> Ron > >> > >> > >>> -----Original Message----- > >>> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > >>> Sent: Tuesday, August 06, 2013 6:36 PM > >>> To: Ronald Bonica; C. M. Heard; IPv6 > >>> Subject: RE: UDP+Fragmentation (was: "Deprecate") > >>> > >>> Ron, > >>> > >>> One other thing for now is that Mike's proposal doesn't even address > >>> the attack vector that 'draft-bonica-6man-frag-deprecate' > >>> is concerned about. To address the tiny fragment concern, the protocol > >>> must ensure that tiny fragments cannot ever be created. > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- > >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > >>>> Of Templin, Fred L > >>>> Sent: Tuesday, August 06, 2013 3:07 PM > >>>> To: Ronald Bonica; C. M. Heard; IPv6 > >>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") > >>>> > >>>> Hi Ron, > >>>> > >>>>> -----Original Message----- > >>>>> From: Ronald Bonica [mailto:rbonica@juniper.net] > >>>>> Sent: Tuesday, August 06, 2013 2:54 PM > >>>>> To: Templin, Fred L; C. M. Heard; IPv6 > >>>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") > >>>>> > >>>>> Fred, > >>>>> > >>>>> If that's the case, we have a good argument for changing Mike's > >>>>> proposal ever so slightly, so that it uses a new protocol ID. But > >>>>> still, Mike's proposal is elegant because: > >>>>> > >>>>> a) It solves the problem at the right layer > >>>>> b) It reuses UDP transport machinery. (The only exception is the in > >>>>> LENGTH field) > >>>>> c) It reuses IP fragmentation machinery (moving it to the transport > >>>>> layer) > >>>>> d) Aside from b) and c), it introduces no new protocol machinery. > So, > >>>>> it can be described in a few short pages. This is in stark contrast > to > >>>>> SEAL (draft-templin-intarea-seal-61) whose protocol machinery > requires > >>>>> 41 pages to describe > >>>> > >>>> There is a lot of boiler plate in the draft that is not required to > >>>> describe the protocol machinery. Plus, there are many things that > >>>> need to be described in a functional specification beyond just > >>>> posting a concept in an e-mail thread. > >>>> > >>>>> which required 61 draft versions to get right. > >>>> > >>>> The best things in life are worth investing the time and energy > >>>> to get right. Plus, SEAL is a universal format that handles both > >>>> tunnel- and transport-mode requirements for all manners of > >>>> existing protocols. > >>>> > >>>> If we are going to define a new protocol type, let's define one > >>>> that addresses everything we are currently struggling with and > >>>> has the extensibility to address additional requirements moving > >>>> forward into the future. > >>>> > >>>> Thanks - Fred > >>>> fred.l.templin@boeing.com > >>>> > >>>>> Ron > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > >>>>>> Sent: Tuesday, August 06, 2013 2:58 PM > >>>>>> To: Ronald Bonica; C. M. Heard; IPv6 > >>>>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") > >>>>>> > >>>>>> With a protocol as ossified as UDP, I have a hard time imagining > all > >>>>>> middleboxes passing the packets with what they would see as a > corrupted > >>>>>> length field. > >>>>>> > >>>>>> Thanks - Fred > >>>>>> fred.l.templin@boeing.com > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > >>>>>>> Of Ronald Bonica > >>>>>>> Sent: Tuesday, August 06, 2013 11:49 AM > >>>>>>> To: C. M. Heard; IPv6 > >>>>>>> Subject: RE: UDP+Fragmentation (was: "Deprecate") > >>>>>>> > >>>>>>> Mike, > >>>>>>> > >>>>>>> The proposal sounds elegant. I will try to paraphrase it to make > sure > >>>>>>> that I understand. > >>>>>>> > >>>>>>> When originating a UDP datagram, the host always queries it > underlying > >>>>>>> IP stack to determine the PMTU for the destination. If the PMTU > >>>>>>> greater than or equal to the size of the payload plus the UDP > header > >>>>>>> plus the IP header, plus all IP extension headers, the originating > >>>>>>> host emits a conventional UDP packet which is characterized as > >>>>>>> follows: > >>>>>>> > >>>>>>> - Protocol = 17 > >>>>>>> - Length <= L4 length from IP > >>>>>>> > >>>>>>> If the PMTU less than the size of the payload plus the UDP header > plus > >>>>>>> the IP header, plus all IP extension headers, the originating host > >>>>>>> emits an unconventional UDP packet which is characterized as > follows: > >>>>>>> > >>>>>>> - Protocol = 17 > >>>>>>> - Length > L4 length from IP > >>>>>>> - Segment Offset, M-bit and Identification fields added to UDP > header > >>>>>>> before the payload > >>>>>>> > >>>>>>> If an unconventional UDP packet arrives a destination that > supports > >>>>>>> unconventional packets, it is reassembled at the transport layer. > If > >>>>>>> an unconventional UDP packet arrives a destination that does not > >>>>>>> support unconventional packets, it is discarded. > >>>>>>> > >>>>>>> Do I have this much right? > >>>>>>> > >>>>>>> Ron > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > >>>>>>> C. M. Heard > >>>>>>> Sent: Monday, August 05, 2013 11:53 PM > >>>>>>> To: IPv6 > >>>>>>> Subject: Re: UDP+Fragmentation (was: "Deprecate") > >>>>>>> > >>>>>>> On Thu, 1 Aug 2013, C. M. Heard wrote: > >>>>>>>> On Thu, 1 Aug 2013, RJ Atkinson wrote: > >>>>>>>>> I agree that C.M. Heard's ideas should be explored in more > detail by > >>>>>>>>> the IETF. > >>>>>>> > >>>>>>> The idea was essentially UDP with segmentation fields, which would > >>>>>>> require a new protocol number. > >>>>>>> > >>>>>>> In an offline discussion with Mark Smith and I kicked around an > idea > >>>>>>> for an alternate version not requiring a new protocol number, but > >>>>>>> relying instead on the redundancy of the UDP Length field. The > UDP > >>>>>>> Length field is not actually needed; TCP does not have one but > rather > >>>>>>> relies on the length reported by the IP layer. Under current > >>>>>>> standards, the UDP Length field must be at least 8 and cannot > exceed > >>>>>>> the IP payload length minus the combined length of any extension > >>>>>>> headers -- let's call this the L4 length from IP. Existing > >>>>>>> implementations are supposed to drop UDP datagrams that fail this > >>>>>>> check, and all the ones I know of do so. > >>>>>>> > >>>>>>> The question then arises whether it might reasonably be possible > to re- > >>>>>>> purpose the case UDP Length > L4 length from IP to mean a > segmented UDP > >>>>>>> datagram. > >>>>>>> > >>>>>>> In that case 8 <= UDP Length <= L4 length from IP would be > intepreted > >>>>>>> as a standard unsegmented UDP datagram, as is it now. > >>>>>>> That's the case pictured below. Note that if the L4 length > indicated > >>>>>>> by the IP layer exceeds the UDP Length, then the extra octets > would be > >>>>>>> discarded and are not delivered to the application; that is the > >>>>>>> behavior of the implementations I know of. > >>>>>>> > >>>>>>> 0 15 16 > 31 > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | Source Port | Destination Port > | > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | Length <= L4 length from IP | Checksum > | > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | data octets ... > >>>>>>> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > >>>>>>> > >>>>>>> Now suppose that we have a long UDP datagram that we want to send > in > >>>>>>> segments. We set the Length and Checksum fields as usual, and > then cut > >>>>>>> the datagram into segments, each of which looks like this: > >>>>>>> > >>>>>>> 0 15 16 > 31 > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | Source Port | Destination Port > | > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | Length > L4 length from IP | Checksum > | > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | (reserved = 0) | Segment Offset > |Res|M| > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | Identification > | > >>>>>>> > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > >>>>>>> | data octets ... > >>>>>>> +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > >>>>>>> > >>>>>>> We put the same UDP header in each segment, so (if we take some > care in > >>>>>>> how we choose the length of the segments) each one will have a UDP > >>>>>>> Length field that is greater than the IP payload length minus the > >>>>>>> combined length of any extension headers. Implementations that > conform > >>>>>>> to the current specifications should discard these segments, and > so > >>>>>>> should not mistakenly consider the segmentation fields as part of > the > >>>>>>> application data. That should make it possible for segmented UDP > >>>>>>> datagrams to safely coexist with conventional unsegmented one, > without > >>>>>>> getting a new protocol number. > >>>>>>> > >>>>>>> Possible downsides: some middleboxes may filter such "erroneous" > >>>>>>> datagrams, and some existing erroneous implementations may fail > to do > >>>>>>> the checks they should and might mistake these segments for > ordinary > >>>>>>> UDP datagrams. > >>>>>>> > >>>>>>> Note that this idea does not work with UDP-lite, which replaces > the > >>>>>>> Length field with a Checksum Coverage field. That could easily > be too > >>>>>>> short to exceed the L4 length from IP. > >>>>>>> > >>>>>>> Mike Heard > >>>>>>> > -------------------------------------------------------------------- > >>>>>>> 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 > > -------------------------------------------------------------------- > > > > -- > Do not meddle in the affairs of wizards, for they are subtle and quick to > anger. > -- J.R.R. Tolkien > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Tue Aug 27 12:48:39 2013 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 53BD011E81E6; Tue, 27 Aug 2013 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCOe2eewRQTa; Tue, 27 Aug 2013 12:48:38 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C291F11E81E3; Tue, 27 Aug 2013 12:48:38 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so5270174pbb.41 for ; Tue, 27 Aug 2013 12:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Tt2BJ4asv/tNbPEYeJqogfkelhNcZRqJbpisEBMu1E4=; b=ldZ2Ysaklay8YD6IPYT5ea0CaGCjw1h5KdMQDkAw3rCZzbunc5C/t5vIpAFbYgtx6e Gj6HjLZnat8/Xgk4CSvoMyQ1kB15oZag2qRMpYPWXTWQGebwxqcK/+Phx6xHSBUQxBQx RDgWzqkY3UE0GVpxurOD9+mNl2yYUd+Q7RHK0rfodkXGkDSUuY888SVkdOUpcEGVjNtq Pjq0zDJMB5QgjA233BJ2ZSI8MtiMEPQYsJyRGnzB5fa4MRpCsXKmS2EOFY+e9xI5MxIR G9EIR+iUYToHCvwxROnkIJfN4O23Kw5kBOzSxAVoio3zVa/tMVBRVfk6LrnsKZ7yazsX i3IA== X-Received: by 10.66.150.41 with SMTP id uf9mr22557898pab.108.1377632918543; Tue, 27 Aug 2013 12:48:38 -0700 (PDT) Received: from [192.168.178.20] (69.195.69.111.dynamic.snap.net.nz. [111.69.195.69]) by mx.google.com with ESMTPSA id ht5sm26374887pbb.29.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 12:48:37 -0700 (PDT) Message-ID: <521D0298.7020801@gmail.com> Date: Wed, 28 Aug 2013 07:48:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF discussion list Subject: Re: I-D Action: draft-sweet-uri-zoneid-00.txt References: <20130827155532.31994.88167.idtracker@ietfa.amsl.com> In-Reply-To: <20130827155532.31994.88167.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Aug 2013 15:21:30 -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, 27 Aug 2013 19:48:39 -0000 I am *not* an author of this draft, which Michael Sweet produced on his own. I have not read the draft and have no idea whether I agree with it. (I believe this was an honest mistake on his part but I don't want there to be any misunderstanding.) Regards Brian Carpenter On 28/08/2013 03:55, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers > Author(s) : Michael Sweet > Brian Carpenter > Stuart Cheshire > Robert M. Hinden > Filename : draft-sweet-uri-zoneid-00.txt > Pages : 11 > Date : 2013-08-27 > > Abstract: > This document describes how the zone identifier of an IPv6 scoped > address, defined as in the IPv6 Scoped Address Architecture > (RFC 4007), can be represented in a literal IPv6 address and in a > Uniform Resource Identifier that includes such a literal address. It > updates the URI Generic Syntax specification (RFC 3986) accordingly. > > [ Editor's note: This draft adds the IPvFuture format used by CUPS > since 2005, addresses some misconceptions of how zoneid's are not > useful to HTTP servers, and is intended to replace RFC 6874. ] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-sweet-uri-zoneid > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From msweet@apple.com Tue Aug 27 18:24:41 2013 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 65ED821E80F5 for ; Tue, 27 Aug 2013 18:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.785 X-Spam-Level: X-Spam-Status: No, score=-7.785 tagged_above=-999 required=5 tests=[AWL=2.214, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEiI1MpbUHdl for ; Tue, 27 Aug 2013 18:24:36 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4B921E80F4 for ; Tue, 27 Aug 2013 18:24:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MS700BOZVWQU8K1@mail-out.apple.com> for ipv6@ietf.org; Tue, 27 Aug 2013 18:24:35 -0700 (PDT) X-AuditID: 11807158-b7fea6d000001e19-32-521d51523c0e Received: from [17.153.39.112] (Unknown_Domain [17.153.39.112]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id BE.3D.07705.3515D125; Tue, 27 Aug 2013 18:24:35 -0700 (PDT) Subject: Re: New Version Notification for draft-sweet-uri-zoneid-00.txt From: Michael Sweet In-reply-to: <521D0D0E.7060400@gmail.com> Date: Tue, 27 Aug 2013 21:24:38 -0400 Message-id: <26E2CBB7-5F25-4D9B-9787-82B96E04B38D@apple.com> References: <20130827155538.31994.64908.idtracker@ietfa.amsl.com> <10DA696F-91F6-4005-A9A8-7185BADC43D8@apple.com> <521D0D0E.7060400@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiOFO9QDc4UDbI4G+TskXbxX1MFi/Pvmey OPIt1oHZY+vJH2weO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfG03XPWAvmKFbcfjOftYHx i1QXIyeHhICJxLOzV9kgbDGJC/fWA9lcHEICvUwS0x5OYwVJCAu4SxyZuoCpi5GDg1dAT2L7 LzmQMLOAlsSNfy+ZQGw2ATWJ35P6wMo5BTQl1p2axw5iswioSvw628cCUS8h8XDfNjYIW1ti 2cLXzCA2r4CNxPuNp6H29jNKXPv2D6xZRMBYorHrNCvEcbISp889Z5nAyD8L4YxZSM6YhWTs AkbmVYwCRak5iZWmeokFBTmpesn5uZsYQUHYUBixg/H/MqtDjAIcjEo8vBabZYKEWBPLiitz DzFKcDArifCW/AcK8aYkVlalFuXHF5XmpBYfYpTmYFES533NIRskJJCeWJKanZpakFoEk2Xi 4JRqYLzObhe7Z2u8rKGV8xX3J0e9snTeOV//wc/C2lN1n1VCxvi5Q1Ll0eVpUnMz6rySlY3d GoX1/qxZbfX9/6KzOUXbk8v25AnqnzeaOTGi7veS5Fydw3xXBfZ6dp9i/PXYcX38C4PdWoe+ XWoWfbNibb/tSbl7HSt/X+hiceRJDVnv0jo1zuvWFCWW4oxEQy3mouJEAENPt9Q+AgAA Cc: 6man 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, 28 Aug 2013 01:24:41 -0000 Brian, On 2013-08-27, at 4:33 PM, Brian E Carpenter wrote: > Michael, > > I don't know where the decision to use this syntax in CUPS > (IPv6addrz = IPv6address "%25" ZoneID / "v1." IPv6address "+" ZoneID) > was debated - I don't think it was here, and I don't generally > follow the URI discussions. My opinion, fwiw, is that the "IPvFuture" > branch invented by the URI people (again without any discussion here, > iirc) is exactly the sort of vague extensibility that we should avoid > (RFC 6709). I contacted the authors of RFC 3986 back in 2005 and got the following response from Bill Fenner: > From: Bill Fenner > Message-Id: <200510211805.j9LI56tA025825@bright.research.att.com> > Subject: RE: RFC 3986 and IPv6 Link-Local Addresses > Date: Fri, 21 Oct 2005 11:05:05 -0700 > > > >See http://lists.w3.org/Archives/Public/uri/2004Nov/0056.html > >and following discussion. > > Also http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt . > Mike's examples were the first ones we thought of, but even using > [v1...], %-escaping is still not permitted, thus requiring a different > character. The current I-D says "_", but we realized that was no good > when we saw it on a web page and the underlining of the URL obscured > the underscore. I've tentatively picked "+", e.g., > ipp://[v1.fe80::200:1234:5678:9abc+eth0]/ipp > > The document was adopted as an IPv6 WG work item but I missed the -00 > deadline for submitting it, so I'll be submitting a revised version > as draft-fenner-literal-zone-02.txt this weekend. > > Bill The code to support this was added to CUPS about a day later and has been the recommended method of supporting IPv6 link-local addresses for IPP printers since then (although we naturally prefer DNS/mDNS names over numeric addresses...) However, this draft did not advance any further, and since I wasn't monitoring the 6man WG I completely missed the subsequent work that became RFC 6874... > The other thing you should realise is that the URI people were already > quite annoyed by the RFC 6874 update, which took a lot of persuasion. > Going back to them with another formal syntax change would be a very > hard slog. Understood. > That said, documenting something that is actually used, even if it's > a formal syntax violation, is always a good thing. I think your path > of least resistance is a short informational RFC describing the > practice adopted in CUPS. Well, *technically* the syntax is already allowed by RFC 3986 (the IPvFuture rule in the ABNF) even if the content of a "v1" address string was never formally defined. Thus, a parser will be able to extract the address string even if the application using it doesn't understand the format. (I know I'm mincing bits here...) But I have no objection to making this an Informational RFC and rewriting the draft to simply reference RFC 6874 if you think it will be an easier "sell". > However, I don't think we should change the formal statement that > a ZoneID must not be sent out on the wire; again, documenting the > practice may be advisable, but encouraging it certainly isn't, > for the reasons given in the Security Considerations of RFC 6874. So WRT the security considerations in RFC 6784, I agree with everything up to the last paragraph. Regardless of whether clients strip the zone ID, HTTP servers that validate the Host header already need to special-case link-local addresses when comparing the incoming address to any of its own, and that code can easily be written to avoid the security issues identified in RFC 4007. However, RFC 6874 puts the burden entirely on the client, both to strip IPv6 link-local addresses *and* retain such information as long as is needed to rewrite URIs in the response from the server. Allowing the client to include the zone ID (and explaining why a client might do so) simplifies client code with no added burden to the server. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From heard@pobox.com Tue Aug 27 19:08:25 2013 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 27DF911E834B for ; Tue, 27 Aug 2013 19:08: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqDT4Ynju04k for ; Tue, 27 Aug 2013 19:08:21 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB82811E8268 for ; Tue, 27 Aug 2013 19:08:17 -0700 (PDT) Received: (qmail 2799 invoked from network); 27 Aug 2013 19:08:09 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Aug 2013 19:08:09 -0700 Date: Tue, 27 Aug 2013 19:08:09 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: [6MAN] UDP+Fragmentation (was: "Deprecate") In-Reply-To: <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net> Message-ID: References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 28 Aug 2013 02:08:25 -0000 On Tue, 27 Aug 2013, Warren Kumari wrote: > Apologies if I missed it and this was already discussed -- for > some reason my MUA is refusing to thread this conversation > correctly and so I'm reading thing all out of order? Ah, an operations person joining the discussion! Thank you! > I have some issue / concerns with draft-andrews-6man-fragopt > > The whole problem is that I cannot look at the fragment and know > what protocol and port it is actually destined to (I also have > concerns about past issues with reassembly / overlapping frags, > but we'll skip those for now). > > I am unclear how I am supposed to be able to trust the port > information in the new header? It is indeed possible to forge the option with upper-layer header information that is proposed to be passed in the option. > Lets say that I only allow traffic to 192.0.2.1 port 80. > What is to stop a malicious party from: > 1: Generating a packet to 192.0.2.1 port 22. > 2: Fragmenting it into two parts. > 3: Adding a few junk headers for padding (I think that this is optional) > 4: Putting in this new header and listing the destination port as 80? In http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html (which you may not have seen yet) I suggested that the upper-layer header option should not be allowed in the initial fragment, which contains the real upper-layer header. If it's there, your firewall (if it's been updated as proposed) should drop the datagram. If it's not, the datagram should be dropped because it has port 22 in the upper-layer header, in violation of the configured policy. Mark Andrews emphatically disagreed with my suggestion; but in that case, the initial fragment would have both the option and the upper-layer header, and they would not match (the option has port 80 and actual upper-layer header has port 22). That should make your firewall recognize that the initial fragment is bogus and drop it. In any case, the initial fragment should get dropped. Now, your firewall (if it's updated per either variation of the proposal) would allow the non-initial fragments to pass on (since the option says they are destined to port 80). But those won't reassemble to a complete datagram on the destination host. I imagine that your next question (and one that I _should_ have asked myself) is: how is this different from what we get from the combination of draft-ietf-6man-oversized-header-chain and draft-ietf-6man-ext-transmit, _without_ the upper-layer header option? The answer is that it's not different, at least not in a significant way. This is what would happen today if one applied stateless ACLs at layer 4 to initial fragments that contain a complete header chain but allowed non-initial fragments to go through unimpeded. Your firewall could do some checks like looking at the length of the upper-layer PDU claimed in the copy of the upper-layer header in the option (for protocols like UDP that have a length field, and if the option is formatted as I proposed) and then discard any non-initial fragments that have offsets past the end of the upper-layer data. However, it would still be possible for someone to send a bunch of non-initial fragments whose reassembly would never complete on the destination end host. > I *guess* if *all* of the devices on the inside of my network know > to check that the new header attributes match the reassembled pack > then I have *some* protection, but this isn't (that I could see) > specified in the draft. Actually, no. I suggested that end systems (where reassembly is done) should do this check if they can process the upper-layer header option. But that would not prevent them from getting a series fragments whose reassembly would never complete: all that an attacker needs to do is send an incomplete series of fragments. The gap can occur anywhere, and the upper-layer header option need not be forged (i.e., it could match the contents of the header in the initial fragment and pass all ACL checks). FWIW, the UDP segmentation proposal that I floated earlier in this thread suffers from the exact same problem. One of the other the issues mentioned in draft-taylor-v6ops-fragdrop is the problem of stateless load balancers that use the 5-tuple in initial fragments and (say) the 2-tuple in non-initial fragments. To the extent that it is considered trustworthy, the proposed upper-layer header option (with appropriate middlebox modifications) would fix this problem (as would the UDP segmentation proposal, at least for UDP), but then again, so would the use of the flow label as described in RFC 6437. OK, it seems that the ideas floated in this thread don't go really beyond what's already been standardized or (apparently) agreed upon here in 6man, and as far as I can see, the problem of an attacker being able to send a series of fragments whose reassembly will never complete is basically unsolvable. So let me ask a question: is this a sufficiently serious problem to be worth breaking fundamental connectivity for those protocols that don't have a good alternative to fragmentation? > There are some comments about NATs changing things "both the > source and destination ports may have been changed so the ports > may appear to be completely unrelated. The source port is changed > by a client NAT and the destination port is changed by a NAT > acting a load balancer." Just out of curiousity -- is this actually an issue in operational IPv6 networks? Thanks, Mike Heard From simon.perreault@viagenie.ca Wed Aug 28 02:46:40 2013 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 6544621F9A4C for ; Wed, 28 Aug 2013 02:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTd77+42Hej8 for ; Wed, 28 Aug 2013 02:46:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A220A21E8064 for ; Wed, 28 Aug 2013 02:46:37 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:804a:3155:d42a:4a6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 75D8B4041A for ; Wed, 28 Aug 2013 05:46:36 -0400 (EDT) Message-ID: <521DC6FD.6060008@viagenie.ca> Date: Wed, 28 Aug 2013 11:46:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: 6MAN Adoption call on References: <2FC4000A-0AC1-455B-8FD5-D54D51883D99@employees.org> In-Reply-To: <2FC4000A-0AC1-455B-8FD5-D54D51883D99@employees.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 28 Aug 2013 09:46:40 -0000 Le 2013-08-23 09:55, Ole Troan a écrit : > This message starts a one week 6MAN Working Group call on adopting: > > Title : Security Implications of IPv6 Options of Type 10xxxxxx > Author(s) : F. Gont, W. Liu > Filename : draft-gont-6man-ipv6-smurf-amplifier-03 > Pages : 12 > Date : 2013-03-21 > > http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-03 > > The call ends on August 30th, 2013. For adoption. I had commented on this draft earlier. I just read it again and still find it useful. I think we should simplify the recommendations and just never send Parameter Problem errors to multicast addresses. That's how it's going to be implemented in practice anyway. By the way, there seems to be an editing mistake on page 6, item (e.3) is repeated. Simon From pthubert@cisco.com Wed Aug 28 06:25:23 2013 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 9339C11E8195; Wed, 28 Aug 2013 06:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpQajtKSypfM; Wed, 28 Aug 2013 06:25:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F0D3311E818A; Wed, 28 Aug 2013 06:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2823; q=dns/txt; s=iport; t=1377696318; x=1378905918; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6ooRRyGCeMKNQrxsQ8+MGX+8nnfRi3X7R3Q5hFWrJCs=; b=gqLqIFUeAitul5wcDyzn2yZ1FR/40w2hie/ETTT6oz39+2rmAIL2j5WU QnngzZ/Ra5iX9YSlWVpjy97OINzgQ7wbZOWlhb9wgjco36ih3coaxWb9V myIGnzM6Ce2e28u/U6Sfa1eHrpdB7SscYyVUvYBpWAgz7hDw7Fa5cnEZQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAID5HVKtJXG//2dsb2JhbABbgweBBsAqgSAWdIIkAQEBAwF+BwQCAQgRBAEBAQodBzIUCQgCBAESCIdzBrknjzM4BoMWfQOIe4sclTuDIIIq X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="252733204" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2013 13:25:17 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7SDPHpL031402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 13:25:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 28 Aug 2013 08:25:17 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: RE: [6lo] 6lowpan-backbone-router-03 Thread-Topic: [6lo] 6lowpan-backbone-router-03 Thread-Index: AQHOomK36ThzJ87QvUC9dJXmgVbPLJmqnCtg Date: Wed, 28 Aug 2013 13:25:16 +0000 Deferred-Delivery: Wed, 28 Aug 2013 13:25:00 +0000 Message-ID: References: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> <4756.1377477429@sandelman.ca> In-Reply-To: <4756.1377477429@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.24] Content-Type: text/plain; charset="iso-8859-1" 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: Wed, 28 Aug 2013 13:25:23 -0000 Hello Michael: The BBR draft will be repositioned as a number of functions are migrated to= other drafts, including efficient ND. What will be left in the BBr draft is probably the function by a RPL root (= LBR) to proxy ND over the backbone so as to attract traffic for IPv6 addres= ses that are located on the LLN. So it is not just a root. The key piece is the mapping (redistribution?) of= RPL routes learnt from DAO into a Binding Table state in order to enable N= D proxy operation. > Are the wired part of the 6LBRs always located on the same link? Yes. This is why we call this link the backbone. It is expected to be a tra= nsit link where traditional NDP operates. Backbone Router is the term used = by ISA100.11a to refer to the routing entity that federates multiple LLNs a= s a single subnet over a high speed backbone. I'm using that same term to e= ase communication between ISA and IETF. > It seems to me that you are inventing a protocol to solve the MESH-under = problem, but that we already have such a protocol. The backbone router does not operate mesh routing at all. It is really focu= sed on ND proxy operation over a transit link we use as federating backbone= for a multilink subnet. Cheers,=20 Pascal -----Original Message----- From: 6lo-bounces@ietf.org [mailto:6lo-bounces@ietf.org] On Behalf Of Micha= el Richardson Sent: lundi 26 ao=FBt 2013 02:37 To: 6man@ietf.org; 6lo@ietf.org Subject: [6lo] 6lowpan-backbone-router-03 Pascal Thubert (pthubert) wrote: > There is a need for a protocol between the 6LBRs/NEAR routers to > exchange their state. This could be achieved by an extension on ND f= or > proxy operations as described in dratf-thubert-6lowpan-backbone-route= r, > a similar extension to a routing protocol running on the backbone or = a > richer extension to IPv6 NDP allowing some degree of pub/sub as well. Are the wired part of the 6LBRs always located on the same link? I'm asking because it seems like this is an important assumption. I read 6lowpan-backbone-router-03. Please number the figure in section 3. I'll call it "Figure Plan Network" I don't like the term backbone, and backbone router. What I see are three areas of a DAG connected by a heterogeneous layer-2. The "BBR" are just RPL routers. I don't know why a new protocol is necessa= ry for the mesh-over case.=20 Perhaps the MESH-under case has some requirements, but I'd rather just pret= end that it's four links (an ethernet link, and three mesh-under links) con= nected together to form a single mesh-over network. It seems to me that you are inventing a protocol to solve the MESH-under pr= oblem, but that we already have such a protocol. -- Michael Richardson -at the cottage- From Fred.L.Templin@boeing.com Wed Aug 28 10:11:18 2013 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 E09AF21F9D31 for ; Wed, 28 Aug 2013 10:11:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+fuhHh5Pkwy for ; Wed, 28 Aug 2013 10:11:14 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 31B7A11E81E1 for ; Wed, 28 Aug 2013 10:11:12 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r7SHBBtm014788 for ; Wed, 28 Aug 2013 10:11:11 -0700 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r7SHBAOd014779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 Aug 2013 10:11:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-PHX-513.sw.nos.boeing.com ([169.254.13.195]) with mapi id 14.02.0328.011; Wed, 28 Aug 2013 10:11:10 -0700 From: "Templin, Fred L" To: "C. M. Heard" , IPv6 Subject: RE: [6MAN] UDP+Fragmentation (was: "Deprecate") Thread-Topic: [6MAN] UDP+Fragmentation (was: "Deprecate") Thread-Index: AQHOo5OE6zP2qGnciEGFpvezoLzwlZmq2nvg Date: Wed, 28 Aug 2013 17:11:10 +0000 Message-ID: <2134F8430051B64F815C691A62D983180F973D@XCH-BLV-504.nw.nos.boeing.com> References: <782A011A-B28F-4BD9-B3F1-C194D6244DFA@gmail.com> <2134F8430051B64F815C691A62D983180E0A69@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0D96@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180E0E0D@XCH-BLV-504.nw.nos.boeing.com> <58A2CCE5-4EAB-4D80-8A97-88885F0E268C@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 28 Aug 2013 17:11:19 -0000 Hi Mike, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > C. M. Heard > Sent: Tuesday, August 27, 2013 7:08 PM > To: IPv6 > Subject: Re: [6MAN] UDP+Fragmentation (was: "Deprecate") >=20 > On Tue, 27 Aug 2013, Warren Kumari wrote: > > Apologies if I missed it and this was already discussed -- for > > some reason my MUA is refusing to thread this conversation > > correctly and so I'm reading thing all out of order? >=20 > Ah, an operations person joining the discussion! Thank you! >=20 > > I have some issue / concerns with draft-andrews-6man-fragopt > > > > The whole problem is that I cannot look at the fragment and know > > what protocol and port it is actually destined to (I also have > > concerns about past issues with reassembly / overlapping frags, > > but we'll skip those for now). > > > > I am unclear how I am supposed to be able to trust the port > > information in the new header? >=20 > It is indeed possible to forge the option with upper-layer header > information that is proposed to be passed in the option. >=20 > > Lets say that I only allow traffic to 192.0.2.1 port 80. > > What is to stop a malicious party from: > > 1: Generating a packet to 192.0.2.1 port 22. > > 2: Fragmenting it into two parts. > > 3: Adding a few junk headers for padding (I think that this is > optional) > > 4: Putting in this new header and listing the destination port as 80? >=20 > In http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html > (which you may not have seen yet) I suggested that the upper-layer > header option should not be allowed in the initial fragment, which > contains the real upper-layer header. If it's there, your firewall > (if it's been updated as proposed) should drop the datagram. If > it's not, the datagram should be dropped because it has port 22 in > the upper-layer header, in violation of the configured policy. >=20 > Mark Andrews emphatically disagreed with my suggestion; but in that > case, the initial fragment would have both the option and the > upper-layer header, and they would not match (the option has port 80 > and actual upper-layer header has port 22). That should make your > firewall recognize that the initial fragment is bogus and drop it. >=20 > In any case, the initial fragment should get dropped. >=20 > Now, your firewall (if it's updated per either variation of the > proposal) would allow the non-initial fragments to pass on (since > the option says they are destined to port 80). But those won't > reassemble to a complete datagram on the destination host. >=20 > I imagine that your next question (and one that I _should_ have > asked myself) is: how is this different from what we get from the > combination of draft-ietf-6man-oversized-header-chain and > draft-ietf-6man-ext-transmit, _without_ the upper-layer header > option? The answer is that it's not different, at least not in a > significant way. This is what would happen today if one applied > stateless ACLs at layer 4 to initial fragments that contain a > complete header chain but allowed non-initial fragments to go > through unimpeded. >=20 > Your firewall could do some checks like looking at the length of the > upper-layer PDU claimed in the copy of the upper-layer header in the > option (for protocols like UDP that have a length field, and if the > option is formatted as I proposed) and then discard any non-initial > fragments that have offsets past the end of the upper-layer data. > However, it would still be possible for someone to send a bunch of > non-initial fragments whose reassembly would never complete on the > destination end host. >=20 > > I *guess* if *all* of the devices on the inside of my network know > > to check that the new header attributes match the reassembled pack > > then I have *some* protection, but this isn't (that I could see) > > specified in the draft. >=20 > Actually, no. I suggested that end systems (where reassembly is > done) should do this check if they can process the upper-layer > header option. But that would not prevent them from getting a > series fragments whose reassembly would never complete: all that an > attacker needs to do is send an incomplete series of fragments. > The gap can occur anywhere, and the upper-layer header option need > not be forged (i.e., it could match the contents of the header in > the initial fragment and pass all ACL checks). >=20 > FWIW, the UDP segmentation proposal that I floated earlier in this > thread suffers from the exact same problem. >=20 > One of the other the issues mentioned in draft-taylor-v6ops-fragdrop > is the problem of stateless load balancers that use the 5-tuple in > initial fragments and (say) the 2-tuple in non-initial fragments. > To the extent that it is considered trustworthy, the proposed > upper-layer header option (with appropriate middlebox modifications) > would fix this problem (as would the UDP segmentation proposal, at > least for UDP), but then again, so would the use of the flow label > as described in RFC 6437. >=20 > OK, it seems that the ideas floated in this thread don't go really > beyond what's already been standardized or (apparently) agreed upon > here in 6man, and as far as I can see, the problem of an attacker > being able to send a series of fragments whose reassembly will never > complete is basically unsolvable. If each fragment contains a Message Authentication Code (MAC), the destination can discard fragments that are either missing or contain an incorrect MAC value. (Yes, this opens up other issues such as attacks on performance for running the MAC algorithm.)=20 > So let me ask a question: is this > a sufficiently serious problem to be worth breaking fundamental > connectivity for those protocols that don't have a good alternative > to fragmentation? Tunnels need fragmentation to meet the 1280 IPv6 minimum MTU, and preferably also to meet the 1500 legacy Internet cell size. Thanks - Fred fred.l.templin@boeing.com > > There are some comments about NATs changing things "both the > > source and destination ports may have been changed so the ports > > may appear to be completely unrelated. The source port is changed > > by a client NAT and the destination port is changed by a NAT > > acting a load balancer." >=20 > Just out of curiousity -- is this actually an issue in operational > IPv6 networks? >=20 > Thanks, >=20 > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Tina.Tsou.Zouting@huawei.com Wed Aug 28 10:20:21 2013 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 C4A8D21E804D for ; Wed, 28 Aug 2013 10:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSdkHusNu5WO for ; Wed, 28 Aug 2013 10:20:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E798D11E81A9 for ; Wed, 28 Aug 2013 10:20:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUV36691; Wed, 28 Aug 2013 17:20:14 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 28 Aug 2013 18:16:06 +0100 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 28 Aug 2013 18:16:53 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.175]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Wed, 28 Aug 2013 10:16:48 -0700 From: Tina TSOU To: Simon Perreault Subject: Re: 6MAN Adoption call on Thread-Topic: 6MAN Adoption call on Thread-Index: AQHOn9ZBmbAJ18Fwr0m6Mev7+jnViJmq3KaAgAAIb6I= Date: Wed, 28 Aug 2013 17:16:48 +0000 Message-ID: <0F36F4C8-A2CA-426F-B5D9-277ABED34DA0@huawei.com> References: <2FC4000A-0AC1-455B-8FD5-D54D51883D99@employees.org>, <521DC6FD.6060008@viagenie.ca> In-Reply-To: <521DC6FD.6060008@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 28 Aug 2013 17:20:21 -0000 RGVhciBhbGwsDQpJIGhhdmUgcmVhZCBkcmFmdC1nb250LTZtYW4taXB2Ni1zbXVyZi1hbXBsaWZp ZXItMDMgYW5kIGJlbGlldmUgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBkaXNjdXNzZWQgYW5k IHRoZSBzdWdnZXN0aW9ucyBmb3IgdXBkYXRpbmcgdGhlIHR3byBSRkNzIGFyZSBlc3NlbnRpYWwg Zm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbmQgdGhlIG9wZXJhdGlvbmFsIG1pdGlnYXRp b25zIHByb3Bvc2VkIGluIHRoZSBkb2N1bWVudCBwcm92aWRlIGdvb2QgY2hvaWNlcyBmb3IgZGVz aWduLiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBkb2N1 bWVudC4NCg0KVGhhbmsgeW91LA0KVGluYQ0KDQpPbiBBdWcgMjgsIDIwMTMsIGF0IDI6NDcgQU0s ICJTaW1vbiBQZXJyZWF1bHQiIDxzaW1vbi5wZXJyZWF1bHRAdmlhZ2VuaWUuY2E+IHdyb3RlOg0K DQo+IExlIDIwMTMtMDgtMjMgMDk6NTUsIE9sZSBUcm9hbiBhIKimY3JpdCA6DQo+PiBUaGlzIG1l c3NhZ2Ugc3RhcnRzIGEgb25lIHdlZWsgNk1BTiBXb3JraW5nIEdyb3VwIGNhbGwgb24gYWRvcHRp bmc6DQo+PiANCj4+ICAgIFRpdGxlICAgICAgICAgICA6IFNlY3VyaXR5IEltcGxpY2F0aW9ucyBv ZiBJUHY2IE9wdGlvbnMgb2YgVHlwZSAxMHh4eHh4eA0KPj4gICAgQXV0aG9yKHMpICAgIDogRi4g R29udCwgVy4gTGl1DQo+PiAgICBGaWxlbmFtZSAgICA6IGRyYWZ0LWdvbnQtNm1hbi1pcHY2LXNt dXJmLWFtcGxpZmllci0wMw0KPj4gICAgUGFnZXMgICAgICAgIDogMTINCj4+ICAgIERhdGUgICAg ICAgICAgOiAyMDEzLTAzLTIxDQo+PiANCj4+ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1nb250LTZtYW4taXB2Ni1zbXVyZi1hbXBsaWZpZXItMDMNCj4+IA0KPj4gVGhlIGNh bGwgZW5kcyBvbiBBdWd1c3QgMzB0aCwgMjAxMy4NCj4gDQo+IEZvciBhZG9wdGlvbi4NCj4gDQo+ IEkgaGFkIGNvbW1lbnRlZCBvbiB0aGlzIGRyYWZ0IGVhcmxpZXIuIEkganVzdCByZWFkIGl0IGFn YWluIGFuZCBzdGlsbA0KPiBmaW5kIGl0IHVzZWZ1bC4gSSB0aGluayB3ZSBzaG91bGQgc2ltcGxp ZnkgdGhlIHJlY29tbWVuZGF0aW9ucyBhbmQganVzdA0KPiBuZXZlciBzZW5kIFBhcmFtZXRlciBQ cm9ibGVtIGVycm9ycyB0byBtdWx0aWNhc3QgYWRkcmVzc2VzLiBUaGF0J3MgaG93DQo+IGl0J3Mg Z29pbmcgdG8gYmUgaW1wbGVtZW50ZWQgaW4gcHJhY3RpY2UgYW55d2F5Lg0KPiANCj4gQnkgdGhl IHdheSwgdGhlcmUgc2VlbXMgdG8gYmUgYW4gZWRpdGluZyBtaXN0YWtlIG9uIHBhZ2UgNiwgaXRl bSAoZS4zKQ0KPiBpcyByZXBlYXRlZC4NCj4gDQo+IFNpbW9uDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFk bWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From stig@venaas.com Wed Aug 28 10:38:21 2013 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 4DF9111E81CA for ; Wed, 28 Aug 2013 10:38:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9eYSZRLzaWT for ; Wed, 28 Aug 2013 10:38:19 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 948AE11E819D for ; Wed, 28 Aug 2013 10:38:19 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id EDEA17FF9; Wed, 28 Aug 2013 19:38:17 +0200 (CEST) Message-ID: <521E3584.8040900@venaas.com> Date: Wed, 28 Aug 2013 10:38:12 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tina TSOU Subject: Re: 6MAN Adoption call on References: <2FC4000A-0AC1-455B-8FD5-D54D51883D99@employees.org>, <521DC6FD.6060008@viagenie.ca> <0F36F4C8-A2CA-426F-B5D9-277ABED34DA0@huawei.com> In-Reply-To: <0F36F4C8-A2CA-426F-B5D9-277ABED34DA0@huawei.com> Content-Type: text/plain; charset=GB2312 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, 28 Aug 2013 17:38:21 -0000 Hi I'm not sure if this attack is all that serious since there is always an RPF check for multicast. As it says in the draft: It should be noted that if the multicast RPF check is used (e.g. to prevent routing loops), this would prevent an attacker from forging the Source Address of a packet to an arbitrary value, thus preventing an attacker from launching this attack against a remote network. Chapter 5 of [Juniper2010] discusses multicast RPF configuration for Juniper routers. If you read chapter 5 it starts out by explaining how RPF check is always done for multicast. Due to the RPF check, the possibility of spoofing is significantly reduced. Just like it is when using unicast RPF. Hence I don't think this attack vector is that serious. Unless I'm missing something, I don't think it is worth making the proposed change. Stig From bob.hinden@gmail.com Wed Aug 28 12:39:01 2013 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 5522411E81B8 for ; Wed, 28 Aug 2013 12:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVwynV2WzQ13 for ; Wed, 28 Aug 2013 12:39:01 -0700 (PDT) Received: from mail-gh0-x234.google.com (mail-gh0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id DB11C11E81AF for ; Wed, 28 Aug 2013 12:39:00 -0700 (PDT) Received: by mail-gh0-f180.google.com with SMTP id f18so1642834ghb.39 for ; Wed, 28 Aug 2013 12:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to; bh=vENJJlCL2VC85Pj+88PUMoqSyAeFVat5dwfqez7xY+I=; b=sfu0GvLHIOdpPQSh6qgGTfGXfTbqBafPrZAwKCGN40mHjrKOPKZ0PPO8cjiOx3XNH0 AdI1eaon+FACtVBLsduGm82ASS0pTEki+za2y1pdKnvMP6rQhinyRoAm3gsGviYOxMMY yjJhSUEHjQolkhgiSDpbtWcBxhouDb/Vf/rLsgJCilWeBu8m9ctvVbuRfNSK9bZQDjPQ koaDVPjQX++4bmvqySFeG7oxAnk1AREicTbZhkAAFJ97X/vpswCLjx9SA2NBbMDTTy19 8DtweN62PEhfEWoaV1Hz8Dvm+vp8QTDOEEFckoviSq+To0iPBAlAhyvcWeHHjqWDLCtX QjDA== X-Received: by 10.236.127.5 with SMTP id c5mr26633180yhi.42.1377718740374; Wed, 28 Aug 2013 12:39:00 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id r39sm33577191yhp.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:38:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Fwd: Publication has been requested for draft draft-ietf-6man-ext-transmit From: Bob Hinden Date: Wed, 28 Aug 2013 12:38:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B80CC31-D57A-4BE2-A9E1-B1D6AC921141@gmail.com> References: <20130828193745.12040.9535.idtracker@ietfa.amsl.com> To: IPv6 IPv6 List X-Mailer: Apple Mail (2.1508) 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, 28 Aug 2013 19:39:01 -0000 FYI Begin forwarded message: > From: IETF Secretariat > Subject: Publication has been requested for draft = draft-ietf-6man-ext-transmit > Date: August 28, 2013 12:37:45 PM PDT > To: "IESG Secretary" , "Brian Haberman" = > Cc: "Robert Hinden" , "Ole Troan" = >=20 >=20 > The state of document draft-ietf-6man-ext-transmit has been updated. = See more information below. >=20 > Previous state: WG Consensus: Waiting for Write-Up > Current state: Submitted to IESG for Publication > Transition date: 2013-08-28 12:37 > Author of the change: Robert Hinden >=20 > Comment: >=20 >=20 From samita.chakrabarti@ericsson.com Thu Aug 29 17:21:49 2013 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 76FEE11E8129 for ; Thu, 29 Aug 2013 17:21:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAprvq8GSdYT for ; Thu, 29 Aug 2013 17:21:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8FE11E8107 for ; Thu, 29 Aug 2013 17:21:43 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-1d-521fe596cc0b Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7A.2E.03458.695EF125; Fri, 30 Aug 2013 02:21:43 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 20:21:42 -0400 From: Samita Chakrabarti To: Jouni Korhonen , IPv6 IPv6 List Subject: RE: comments on draft-chakrabarti-nordmark-6man-efficient-nd-02 Thread-Topic: comments on draft-chakrabarti-nordmark-6man-efficient-nd-02 Thread-Index: AQHOjJFxKVq8BjxZtkW2gJrXh/gyiJmtExXA Date: Fri, 30 Aug 2013 00:21:42 +0000 Message-ID: References: <7A443800-AD78-4B9A-B566-F994CA29314B@gmail.com> In-Reply-To: <7A443800-AD78-4B9A-B566-F994CA29314B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXRPoO70p/JBBpsWCFi8PPueyWL/ugYm ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjy9GFzAWvhSqOTXzL3sC4nb+LkZNDQsBE ovP4InYIW0ziwr31bF2MXBxCAkcZJTZuX8MM4SxnlPjz9gATSBWbgJVER+8esA4RAW+J/zdn s4LYwgIeErfP9jFBxD0lNl7qY4SwjSQ+LlgBVsMioCrR/nI1mM0r4CvRPHcOWL2QgI3Eqbmv weKcArYSe7b0gc1nBLro+6k1YDXMAuISt57MZ4K4VEBiyZ7zzBC2qMTLx/9YIWxlie9zHrFA 1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dpcWpZbrqR 4SZGYDwck2Bz3MG44JPlIUZpDhYlcd4NemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBW 6DgwMwr86n1eJrHzZkgE092tdV8Vzq79UMn55EFL/bbNjnmOHVUbV8SFta/d0+Rxu7LwwTuj /7ccp0U15zt8vOSjn+0tX3DvgY5PBpvUJ/WLu1/v6N9SYcvvzyS+Kcw2je8vp+0Tm+ms+l72 nGa2BkvOGWlv61GPlLbPv9R7QP6+5znmcCWW4oxEQy3mouJEABvFX6ZVAgAA 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, 30 Aug 2013 00:21:50 -0000 Hi Jouni, Sorry for the much delayed response due to being out-of-office for some tim= e. Here are my response in line. Thanks again for the useful comments. We will address them in the next revision of the document. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: Monday, July 29, 2013 10:36 AM To: IPv6 IPv6 List Subject: comments on draft-chakrabarti-nordmark-6man-efficient-nd-02 Hi, Just to restate what I said on the microphone. Section 7.1. says: When the ARO is used by hosts an SLLA option MUST be included and the address that is to be registered MUST be the IPv6 source address of the Neighbor Solicitation message. What about link that do not have link-layer addresses? This specifically ca= ught my attention since the draft uses 3GPP as a motivational use case (see= Annex A.5.). Those links do not have link layer addresses. I think this pa= rt needs to be corrected/clarified.. =3D=3D=3D> Point taken. I agree that we should add wordings about the excep= tion cases. Also, in Annex A.5. it says: Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays silent about periodic RA. Though the informational drafts and It is correct that the referenced documents are silent (they do not require= or prohibit) about periodic RAs. However, 3GPP TS29.061, i.e. stage-3 that deals with the implementation level details, defines in sub-cl= ause 11.2.1.3.4 values for MaxRtrAdvInterval (recommendation is 21600s i.e.= 6h) and MinRtrAdvInterval. Also, stage-3 even uses language such as: "Afte= r the GGSN has sent a Create PDP Context Response message to the SGSN, it s= hall start sending Router Advertisements periodically on the new MS-GGSN li= nk established by the PDP Context". This needs to be corrected in the draft= . =3D=3D=3D=3D> Do you have a suggested text ? As I mentioned in-person conv= ersation that this appendix section will be taken into another draft for th= e use-cases of efficient-nd, so we can then elaborate on this section.=20 Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From samita.chakrabarti@ericsson.com Thu Aug 29 18:45:07 2013 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 B1EF711E815B for ; Thu, 29 Aug 2013 18:45:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvUd-Cn2gw0o for ; Thu, 29 Aug 2013 18:45:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E655921E808C for ; Thu, 29 Aug 2013 18:44:59 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-64-521ff91782d5 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7B.7F.03458.719FF125; Fri, 30 Aug 2013 03:44:56 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 21:44:55 -0400 From: Samita Chakrabarti To: ayourtch , "nordmark@cisco.com" , "pthubert@cisco.com" , "mrw@lilacglade.org" Subject: RE: draft-chakrabarti-nordmark-6man-efficient-nd review Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd review Thread-Index: AQHOkcnP4r4K+ymONk2WJnfIG/EPdJmtDULQ Date: Fri, 30 Aug 2013 01:44:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXSPn67ET/kgg4UvhSy+Ns9js3h59j2T xYLlS1ksPr3ez2YxY8o7RgdWjym/N7J6LFnyk8lj4/Z1LAHMUVw2Kak5mWWpRfp2CVwZfe2P GAtW5lf831bZwNgc1sXIwSEhYCLx525pFyMnkCkmceHeerYuRi4OIYGjjBLX1t9ihnCWM0qs 2j6XHaSKTcBKoqN3DztIQkRgGaPEkYV7GEESzAKhEj86W9hAbGEBB4lvmxrAbBEBR4lvq5ey Q9hGEvNvfQGLswioSsxs/McOcgWvgK/E0gl+IKaQgJ3E9d/mIBWcAvYSsyZ0soLYjEDHfT+1 hglik7jErSfzmSCOFpBYsuc8M4QtKvHy8T9WCFtZ4vucRywQ9ToSC3Z/YoOwtSWWLXwNVs8r IChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtzECIykYxJsjjsYF3yyPMQo zcGiJM67Qe9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGx/7zJy+2T6ooeaz+OPzKyg39 v6+2f1n7iqdqx859n0NTD7/SceuaonJCRvV7QyvDHpMl8w42P7miNVtq3t//v6LsnyiL+u1b tqrB6e26f1O3T9rpsvvGL1UxZ0eZ0y4VGxV7GA7eSp3Y9812Zi7fi4nzu28vm1V48vqVwNR1 /adLq+75vTNZx6bEUpyRaKjFXFScCADMYvIZcgIAAA== Cc: "ipv6@ietf.org" , Suresh Krishnan 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, 30 Aug 2013 01:45:07 -0000 Hi , Thanks for your detailed comments. Apology for the late reply . It'd be nice to know your name - so we could address you directly. Please see the responses in-line. -----Original Message----- From: ayourtch [mailto:ayourtch@cisco.com]=20 Sent: Monday, August 05, 2013 3:52 AM To: Samita Chakrabarti; nordmark@cisco.com; pthubert@cisco.com; mrw@lilacgl= ade.org Cc: ipv6@ietf.org Subject: draft-chakrabarti-nordmark-6man-efficient-nd review Hi, I've read through the document, and the problem that it touches is indeed *very* acute - I've experienced it every time in the large-scale wireless d= eployments. The below is a braindump written as I was reading the doc - I deliberately = left some of the pieces that might have been explained later in the documen= t, so if you want you might preempt these by adding explicit forward refere= nces. ---------- Overall, after reading the doc: 1) I think address registration introduces a new attack vector (registratio= n flood). More thoughts on this inline. 2) I think there are a few more "multicast chatter" cases that are missed -= inline. 3) Given that the FHS is a "must" in IPv6 network, if we assume its presenc= e, I think the protocol may be simplified, and be made more router-centric,= I think there may be a possible optimization which would not involve chang= ing the end hosts - as I'd guess it'll take a while for the end hosts to ad= apt. Now, I'm using the text from -02 from the below URL, will copypaste anchors= from it and comments interspersing. http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-n= d/?include_text=3D1 " joining the network the host does not wait for the Router Advertisements as the NEAR routers do not perform periodic multicast RA as per RFC 4861. Instead, the EAH sends a multicast RS to find out a NEAR router in the network. The RS message is the same as in RFC 4861. " The RS sending mechanism will be resilient, I assume, such that the node do= es get RA even in a high-loss environments, right ? Maybe useful to includ= e a paragraph or two on the unreliability of this mechanism. I think Suresh= said he had something on this, probably worth referencing. =3D=3D=3D> Sure. The target of this document is both high-loss networks and= regular IPv6 networks. In both cases less number of multicast signaling is= desirable. I think it make sense to add a few lines on configurable number of times th= e RS can be sent in a high-loss link. I'll check with Suresh on his proposa= l. Suresh, would you like to make the comment on the list again? " The TID field is used together with age of a registration for arbitration between two routers (default or backbone) to ensure freshness and ownership of the registration of a given target address. " freshness - yes.. ownership - not sure.. seems like I might spoof this valu= e easily.. ? =3D=3D=3D> Current IPv6 ND can be spoofed as well and it is no different t= han that. One can run L2-level security or run SEND. " Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only solicited RAs are RECOMMENDED. An RA MUST" This is sometime years in the future when there's no legacy IPv6 nodes ? Especially in context of mobile byod-type networks (e.g. ciscolive net), I = think the router might need to support both. OTOH, the *interval* of the mu= lticast RAs can be cranked up. This is what I am doing now, and it does hel= p... Okay, I see sometime later: "The efficiency-aware default router MUST not send periodic RA unless it is configured to support both legacy IPv6 and efficiency-aware hosts. If the Router is configured for efficiency-aware hosts support, it MUST send Router Advertisements with E-bit flag ON and MUST NOT set 'L' bit in the advertisements." Fair enough. But then if the router configured for interop, do we still sen= d RAs "relatively frequently" or do we say also to decrease their default f= requency ? Maybe a micro-optimization, not sure. I need to measure this som= ehow with existing gear. =3D=3D=3D> The document talks about both NEAR and legacy routers. The goal= is to transition to a network where all routers are NEAR and hosts are Eff= icient-hosts. But for interoperability and backward compatibility a router = can be configured in MIXED mode where it can serve both. RA frequency can b= e configured based on the type of network and applications. "containing Router's link-layer address (this is optional in [ND]. An RA MUST carry Prefix information option with L bit being unset, so that hosts do not multicast any NS messages" for the routable addresses, yes this solves the problem. But what I noticed= today is this use case: Bonjour advertising the services using all sorts of addresses, including li= nk-local addresses. So, then the devices will do ND on link-local addresses= , etc. - so this will solve the problem only partially, I think. =3D=3D=3D=3D> Not sure if I understand the problem here. Can you please exp= lain the sequence of ND messages in Bonjour and point to the partial proble= m you're envisoning? " Unlike RFC4861 which suggests multicast Router Advertisements, this specification optimizes the exchange by always unicasting RAs in response to RS." Yay! :-) (with my wireless hat on:) One thing (maybe) to mention is to say that in the final architecture this = may be configurable depending on the media type ? a broadcast medium with l= ow capacity could still make use of mcast RAs. =3D=3D=3D> Makes sense. Will discuss it with my co-authors about the sugges= tion. " The efficiency-aware host MUST NOT send or accept re-direct messages. It does not join solicited node multicast address. " Again, yay! Does this mean we can get rid of MLD queries as well ? =3D=3D=3D> I guess it can be spared for the solicited node MCAST addr. We= need to double check if NEAR uses solicited mcast for any reason. " one with ARO and another without ARO then the NS message with ARO gets the precedence and the NS without ARO is ignored. This behavior protects the router from Denial Of Service attacks. Similarly, if " What about two AROs that are different ? =3D=3D=3D> I suppose the text can be clarified here. We are talking about = the situation if the router receives two NS messages from the same host ( = one regular and the other containing ARO option), then it the router should= prefer the NS message with the ARO option. " Lifetime expires. If an ARO arrives for an NCE that is in UNCREACHABLE state, that NCE should be marked as STALE. " Can we then use this STALE state as an excuse to clean up the table if it g= ets=20 full(er) on the router, similar to what we do today with binding table with= FHS=20 ? I feel we should discuss - "what happens when the resources on the router= are=20 exhausted or close to exhaustion - how does it recover gracefully from this= =20 condition, if at all". =3D=3D=3D> Let's have the discussion off-line along with the co-authors and= see how we can address this comment to make the router more efficient. "However, it will create legacy NCE for NS messages for other routers in the network. This mode is able to prevent ND flooding on the link." I don't understand. Is this for more than one router running in a kind of=20 redundant mode ? I'd need to understand the exact topology in question, but= I=20 think I have a comment for this part :-) =3D=3D=3D> Good catch. It is trying to say that a NEAR creates legacy NCE f= or the other routers in the subnet since the routers are not registering w= ith each other. This part needs clarification. " An efficiency-aware Router(NEAR) SHOULD be able to have configuration knob to configure itself in Mixed-Mode where it will support both efficiency-aware hosts and legacy hosts. " Would this be an excuse for some vendors to not implement the mixed mode ? = I=20 have a vague feeling that this should be "MUST" to help enable transition, = but=20 probably "SHOULD" is for the routers made specifically for the energy-effic= ient=20 environments ? Is this something that justified by enough of a ballast of=20 having to support the legacy mode ? My hunch is that probably there is not = a=20 whole lot, but maybe I am wrong... =3D=3D> You are right -- 'SHOULD' is to help transition. There are some im= plementations who might not have to deal with legacy IPv6 nodes and they m= ay decide not to implement mixed mode. =20 " The new default router then first send an NS to its peers with a link scope multicast message to IPv6 address ff02::2 with the ARO option. " So, I think the movement scenario presents another attack vector, if I=20 understand it right - unless there is a signaling mechanism for asserting t= he=20 host's identity... I don't have a good solution now, just think this is a=20 problem. Maybe something like a binding table will take care of it - if it'= s=20 centralized at a L2 device that sees everything. I think it is a solved pro= blem=20 there... =3D=3D> Agree. It could be an attack vector in an open network. But it no n= ew threat. Do the routers today use any authentication mechanism when they= exchange multicast messages today? " value of TID wins. Note that the registration ownership and local movement detection behavior in NEAR router MUST be optionally configured. The NEAR routers MAY implement this feature. " So does this mean that by default we'll "protect" the existing entry ? =3D=3D=3D>This makes sure the newest valid registration wins when there are= multiple default routers in the subnet and the host policy is to always co= nnect to the router that provides itself with best performance or closest p= roximity. " The efficiency-aware behavior documented in this specification avoids the ND DOS attacks by: o Having the hosts register with the default router o Having the hosts send their packets via the default router o Not resolving addresses for the Routing Solicitor by mandating SLLA option along with RS o Checking for duplicates in NCE before the registration o Checking against the MAC-address and EUI-64 id is possible now for NCE matches " The way I see it, it does prevent the attack which destination guard preven= ts,=20 and that's it. On the other hand, it introduces a new attack where a malici= ous=20 host on local network can send a lot of registrations and exhaust resources= of=20 the router. =3D=3D=3D> Note that the registration actually creates the temporary NCE wi= th a short lifetime -- thus for unknown destinations when the attack happen= s, the NCE are cleared automatically after a very short while. Thus the DOS= attack cannot build up. For valid entries the temporary entries are replac= ed by registered entries. A node cannot randomly send registration NS as th= ey will fail with EUID checks -- of course the processing time of the CPU w= ill be spent or the implementation may put a limit to process failed regis= trations from a given host. I think this is where a mechanism from the network to signal "you're trying= too=20 much" could be useful. OTOH if implemented straightforwardly, this may beco= me a=20 way for the network to try to control the hosts... I don't know the answer = yet.=20 Maybe I am ratholing, sorry :-) =3D=3D> Your concerns are reasonable. Agree with you that the implementatio= ns can provide different solutions as a value-add. " router. At this point, the default routers use Neighbor Advertisements(NA) to arbitrate the latest ownership of the registration of host. The ownership of registration is useful for " I think I had some questions about this earlier - maybe would benefit from = a=20 reflow, and having the same "movement stuff" in the same place ? =3D=3D=3D> If you can clarify your comment with section numbers, it'd be qu= ite useful for us to address this comment. " if EAH node implements DNA host capability as well, then it SHOULD give preference to the NEAR routers in its candidate list of routers. " I think this is an over-spec. There is already "router preference" field, w= hich=20 can be happily used to enable more than one use case, including the ability= to=20 switch back and forth from legacy routers. =3D=3D=3D> I see. Can you please suggest a text here ? " multicast messages in the IPv6 ND procedure, it does not affect normal IPv6 multicast packets and ability of nodes to join and leave the multicast group or forwarding multicast traffic or responding to multicast queries. " ahha - so MLD queries are still sent by the querier routers ? I think that might be quite an impact as well (e.g. on WLC by default MLD=20 querier time is 90 seconds). =3D=3D=3D> It is trying to say the enhanced mode routers should work with = the existing protocols. Again, an implementation may choose to provide configuration kn= obs to customize. " These optimizations are not known to introduce any new threats against Neighbor Discovery beyond what is already documented for IPv6 [RFC 3756]. " As I noted above, I think this mechanism does introduce a new attack vector= ...=20 I am not sure if it does also introduce the attack vector of stealing the=20 address, seems like it might. =3D=3D=3D=3D> I don't think it provides a new kind of attack. Any ND packe= t information can be spoofed if it is run in the clear. How does it introduce stealing the IP address? Hope it helps. =3D=3D=3D> Thanks for your comments again. It is helpful indeed. Regards, -Samita From samita.chakrabarti@ericsson.com Thu Aug 29 18:55:29 2013 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 3DF4221F9344 for ; Thu, 29 Aug 2013 18:55: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpLQTWMskW7a for ; Thu, 29 Aug 2013 18:55:22 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 954ED21F999E for ; Thu, 29 Aug 2013 18:55:21 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-08-521ffb8855cf Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 33.AF.03458.88BFF125; Fri, 30 Aug 2013 03:55:20 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 21:55:20 -0400 From: Samita Chakrabarti To: Suresh Krishnan , ayourtch Subject: RE: draft-chakrabarti-nordmark-6man-efficient-nd review Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd review Thread-Index: AQHOkcnP4r4K+ymONk2WJnfIG/EPdJmfcESAgA2yVKA= Date: Fri, 30 Aug 2013 01:55:19 +0000 Message-ID: References: <52144475.9020101@ericsson.com> In-Reply-To: <52144475.9020101@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPgm7Hb/kgg4U/zCy+Ns9js3h59j2T xYLlS1ksPr3ez2YxY8o7RgdWjym/N7J6LFnyk8lj4/Z1LAHMUVw2Kak5mWWpRfp2CVwZu9tO sBbc4KzYuegnawPje/YuRk4OCQETicmb7rJC2GISF+6tZ+ti5OIQEjjKKLF2/m0mCGc5o8TJ y7fBqtgErCQ6eveAdYsIBEtcn9/CAlLELLCCUeLCp24WkISwgIPEt00NbBBFjhLfVi8FauAA sq0kpk4VAgmzCKhKnDt9AKyEV8BX4t7zyUwgtpBAgsTKlj3MIDangI7E5BeLwEYyAl33/dQa sBpmAXGJW0/mM0FcLSCxZM95ZghbVOLl439Q3yhLfJ/ziAWiXkdiwe5PbBC2tsSyha+ZIfYK Spyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzEC4+mYBJvjDsYFnywPMUpz sCiJ827QOxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFi8XWbTGWvmKiZLYefyOcIt/A8 2C7Vt3KKdP3JxPZkhc0JiS/5jS6di8qYm9t6pVh9490k833TS8ufrTrbzRldckp4s/deA50O VpGc8F23Dhrebr72Z5Hy2qmfvn7guj67r8Hy0KbWH8qnqmT9fL8J3IiJk1h7SGvy3sIdG1nm v/z7dNI5CQclluKMREMt5qLiRABp2N9odQIAAA== Cc: "nordmark@cisco.com" , "ipv6@ietf.org" , "pthubert@cisco.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: Fri, 30 Aug 2013 01:55:29 -0000 Hi Suresh, Thanks for the pointer to the draft. It sends continuous RS messages or uses exponential backoff algorithm until= it gets a RA. Sure, we can put a reference to this draft from our document for line-power= ed networks. In restricted node networks, continuous RS from multiple node= s are not desirable, in those cases the MAX_RS_SOLICITATIONS can be increa= sed to a higher number than 3. Regards, -Samita -----Original Message----- From: Suresh Krishnan=20 Sent: Tuesday, August 20, 2013 9:39 PM To: ayourtch Cc: Samita Chakrabarti; nordmark@cisco.com; pthubert@cisco.com; mrw@lilacgl= ade.org; ipv6@ietf.org Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd review Hi Andrew, On 08/05/2013 06:51 AM, ayourtch wrote: > The RS sending mechanism will be resilient, I assume, such that the=20 > node does get RA even in a high-loss environments, right ? Maybe=20 > useful to include a paragraph or two on the unreliability of this=20 > mechanism. I think Suresh said he had something on this, probably worth r= eferencing. Here is the draft I was talking about. The draft will go to WGLC soon. http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-01 Thanks Suresh From samita.chakrabarti@ericsson.com Thu Aug 29 19:10:02 2013 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 D004811E8149; Thu, 29 Aug 2013 19:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoKymPgbsSX8; Thu, 29 Aug 2013 19:09:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C08E711E815C; Thu, 29 Aug 2013 19:09:52 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-cf-521ffeef33b8 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E2.E3.09414.FEEFF125; Fri, 30 Aug 2013 04:09:51 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 22:09:51 -0400 From: Samita Chakrabarti To: Mark ZZZ Smith , "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: RE: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Thread-Index: Ac6BxnHoPpTQzrivR8KlRMSgd1HBBwdC+GAAAZSQ6YA= Date: Fri, 30 Aug 2013 02:09:50 +0000 Message-ID: References: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1377118542.8019.YahooMailNeo@web142504.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPlO77f/JBBp03rC2apwhYrFxxl8ni 9ISrbBb9U3cyWcyY8o7RgdXj8hVvjym/N7J6LFnyk8nj+4ErTAEsUVw2Kak5mWWpRfp2CVwZ 15rusBUsFKvYtHslYwNjr1AXIyeHhICJxJnPu9ghbDGJC/fWs3UxcnEICRxllOhtuMQC4Sxn lDh8qokZpIpNwEqio3cPUAcHh4hAgcTmlaYgYWaBNIneC61MILawgJtE+8I1bCC2iIC7xIL3 M6FsK4kzM08wgtgsAqoSDStfgNm8Ar4Snw93MkPs6gbaNXcT2C5OAQ+JwzO3gQ1lBLru+6k1 TBDLxCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGo15O4MXUKG4StLbFs4WtmiMWC EidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzAqDomwaa7g3HPS8tDjNIc LErivKv0zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFzUm/Sl7JCIf8UTidLIm3u6VSsm H3xyVsL307GMxR+E5dyM246s0ulgjT21YNK94CVLywQDX0nu/Mzim6Gb+7r+7Y1N6xgmvF60 +tzkO2wXSrs+uFxb+kl90sbDKwNYWOdM3OCm+3FL6df5P5YpWuw5dUTr4wn7iEXyi28eOv9q 7ul7q98psmvsUGIpzkg01GIuKk4EAFUC+/x4AgAA Cc: "Erik Nordmark \(nordmark@acm.org\)" , "pthubert@cisco.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: Fri, 30 Aug 2013 02:10:03 -0000 Hi Mark, Thanks for the interesting usecase example. Please see in-line.=20 -----Original Message----- From: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au]=20 Sent: Wednesday, August 21, 2013 1:56 PM To: Samita Chakrabarti; 6man@ietf.org; 6lo@ietf.org Cc: Erik Nordmark (nordmark@acm.org); pthubert@cisco.com Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted Hi, I haven't had a chance to do a thorough read though, however I haven't been= able to find where the following scenarios is dealt with.=A0 In a pure energy efficient scenario, say there are two NEAR routers on the = link (NEAR1, NEAR2). An EAH host (EAH1) at bootstrap chooses NEAR1, registe= rs its addresses and uses NEAR1 as its egress router for off-link traffic. = For the return traffic (i.e, off-link traffic coming onto the energy effici= ent segment), what occurs if the upstream network chooses to use NEAR2 to t= ry to forward traffic to EAH1, as the upstream network considers NEAR2 rath= er than NEAR1 to be closer to EAH1 e.g, because of a smaller IGP metric, or= the traffic source link is directly attached to NEAR2? =3D=3D=3D> You are right. The document does not clearly handles this case. = However implicitly, an EAH can register with multiple routers in the netwo= rk. But in order to add router policies ( in this case NEAR1 forwards north= bound-only, NEAR2 forwards southbound only) and synchronize that with EAH,= it needs some more work [ perhaps some additional option with the registra= tion]. Pascal has indicated the backbone router draft function. This document tries to be generic and provides hooks for further enhancemen= t for constrained nodes running IPv6. In my understanding, NEAR2 wouldn't have knowledge of EAH1, because EAH1 ha= s only been registered with NEAR1. So it would seem that currently the only= choice is for NEAR2 to drop those packets. =3D=3D=3D> Please see above. Further to this two or more NEAR scenario, even if the upstream network alw= ays considers NEAR1 to be the closer to the EAHs, if the NEARs are protecte= d by a redundancy protocol such as VRRP, when VRRP switches from using NEAR= 1 to NEAR2, how does NEAR2 acquire address registration information? Would = it be considered a EAH bootstrap event, so that all of the EAHs have to go = through selection and then registration of a NEAR? While I think that would= work, it would seem to be defeating the purpose of having a redundancy pro= tocol like VRRP which tries to make switching over between routers nearly i= f not ideally transparent to downstream hosts. =3D=3D=3D> We have not thought about interaction with VRRP. Good point. We= should discuss that off-line to understand the scenario and its applicabi= lity in this document. Best regards, -Samita From fgont@si6networks.com Fri Aug 30 18:57:54 2013 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 ADC6F21F9E70 for ; Fri, 30 Aug 2013 18:57:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nknwhIpqrVL for ; Fri, 30 Aug 2013 18:57:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E61C221F9E6B for ; Fri, 30 Aug 2013 18:57:53 -0700 (PDT) Received: from [186.134.59.188] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VFaRc-00072u-4R; Sat, 31 Aug 2013 03:57:44 +0200 Message-ID: <52214D8D.9070207@si6networks.com> Date: Fri, 30 Aug 2013 22:57:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stig Venaas Subject: Re: 6MAN Adoption call on References: <2FC4000A-0AC1-455B-8FD5-D54D51883D99@employees.org>, <521DC6FD.6060008@viagenie.ca> <0F36F4C8-A2CA-426F-B5D9-277ABED34DA0@huawei.com> <521E3584.8040900@venaas.com> In-Reply-To: <521E3584.8040900@venaas.com> X-Enigmail-Version: 1.4.6 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: Sat, 31 Aug 2013 01:57:54 -0000 On 08/28/2013 02:38 PM, Stig Venaas wrote: > > I'm not sure if this attack is all that serious since there is > always an RPF check for multicast. > > As it says in the draft: > > It should be noted that if the multicast RPF check is used (e.g. > to prevent routing loops), this would prevent an attacker from > forging the Source Address of a packet to an arbitrary value, thus > preventing an attacker from launching this attack against a remote > network. > > Chapter 5 of [Juniper2010] discusses multicast RPF configuration > for Juniper routers. > > If you read chapter 5 it starts out by explaining how RPF check is > always done for multicast. > > Due to the RPF check, the possibility of spoofing is significantly > reduced. Just like it is when using unicast RPF. Hence I don't think > this attack vector is that serious. That might help preventing an attacker to exploit this against an arbitrary system, but not against all nodes. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From randy@psg.com Sat Aug 31 04:13:22 2013 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 5D66611E8137; Sat, 31 Aug 2013 04:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhgfCXX6ZnBh; Sat, 31 Aug 2013 04:13:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id D2AD111E8136; Sat, 31 Aug 2013 04:13:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VFj73-0005Lk-6T; Sat, 31 Aug 2013 11:13:05 +0000 Date: Sat, 31 Aug 2013 20:13:03 +0900 Message-ID: From: Randy Bush To: joel jaeggli Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC In-Reply-To: <521E411F.9090203@bogus.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> <521E411F.9090203@bogus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: V6 Ops List , IPv6 Deployment Prevention 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, 31 Aug 2013 11:13:22 -0000 http://mailman.nanog.org/pipermail/nanog/2013-August/060709.html From internet-drafts@ietf.org Sat Aug 31 11:49:16 2013 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 E08C821E80D8; Sat, 31 Aug 2013 11:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFeeKuasbrnt; Sat, 31 Aug 2013 11:49:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE4D21E80E3; Sat, 31 Aug 2013 11:49:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-oversized-header-chain-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130831184916.11954.55055.idtracker@ietfa.amsl.com> Date: Sat, 31 Aug 2013 11:49:16 -0700 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, 31 Aug 2013 18:49:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Implications of Oversized IPv6 Header Chains Author(s) : Fernando Gont Vishwas Manral Ronald P. Bonica Filename : draft-ietf-6man-oversized-header-chain-05.txt Pages : 13 Date : 2013-08-31 Abstract: The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-oversized-header-chain-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Sat Aug 31 12:58:58 2013 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 EDF4511E8174 for ; Sat, 31 Aug 2013 12:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8z4O7FPQThm for ; Sat, 31 Aug 2013 12:58:58 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE8311E8173 for ; Sat, 31 Aug 2013 12:58:58 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md4so3188448pbc.2 for ; Sat, 31 Aug 2013 12:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=giTjQHSMgh5blzyA3d7P7VBfckUZAvUaN6k8ToaHPOg=; b=Qc7wfHmu7KBBtX8SFTehhIGDK89HaU5sW0aTw18KPrklgRvg+gu1gl9YuwxO8U5oEX YwC2tBJQOomSguRPe0H8NbmNj1kqWbnUdIwPVF42W0TgKzRxoYl8Xt92muw+n0ighMKb M6TwOjCB1oufRoXWBUbBWIf6KMDtnnro5TvEfDON7hFN2B9t4wV9M4rANcf7c6NcKAlX EaJS0AL1USgHSGyCAKXePM3LFrJ2wXRf+BD+7bY5urFPb7Nfwtdtyx+wDam9DUrCNGvB dZb0sRcCDoc5Bd1aTCULpVtqsTb1ZT62b8M3BQMh9vyu3T38NVM74f6IOWyXdnlMp2I7 1CHw== X-Received: by 10.68.244.2 with SMTP id xc2mr16951760pbc.58.1377979137274; Sat, 31 Aug 2013 12:58:57 -0700 (PDT) Received: from [192.168.178.20] (30.199.69.111.dynamic.snap.net.nz. [111.69.199.30]) by mx.google.com with ESMTPSA id oj6sm6345196pab.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 12:58:56 -0700 (PDT) Message-ID: <52224AF7.1090303@gmail.com> Date: Sun, 01 Sep 2013 07:58:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-05.txt References: <20130831184916.11954.55055.idtracker@ietfa.amsl.com> In-Reply-To: <20130831184916.11954.55055.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 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: Sat, 31 Aug 2013 19:58:59 -0000 Hi, > 3. Terminology > > For the purposes of this document, the terms Extension Header, Header > Chain, First Fragment, and Upper-layer Header are used as follows: > > Extension Header: > > Extension Headers are defined in Section 4 of [RFC2460]. > [IANA-PROTO] provides a list of assigned Internet Protocol Numbers > and designates which of those protocol numbers also represent > extension headers. The final clause is totally incorrect - the IANA list does not (today) identify extension headers. draft-ietf-6man-ext-transmit has the details in its IANA Considerations. Assuming draft-ietf-6man-ext-transmit is approved, this will change, but for that purpose you'd need a blocking (normative) reference to draft-ietf-6man-ext-transmit to guarantee the correct sequence of publication. Brian From fgont@si6networks.com Sat Aug 31 13:50:27 2013 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 4050811E818D for ; Sat, 31 Aug 2013 13:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP3fQZXSGXc4 for ; Sat, 31 Aug 2013 13:50:26 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF4211E8189 for ; Sat, 31 Aug 2013 13:50:26 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.109]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VFs7j-0005BT-99; Sat, 31 Aug 2013 22:50:23 +0200 Message-ID: <522256FA.6030802@si6networks.com> Date: Sat, 31 Aug 2013 17:50:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian E Carpenter Subject: Definition of Extension Header in draft-ietf-6man-oversized-header-chain-05.txt (was Re: I-D Action: draft-ietf-6man-oversized-header-chain-05.txt) References: <20130831184916.11954.55055.idtracker@ietfa.amsl.com> <52224AF7.1090303@gmail.com> In-Reply-To: <52224AF7.1090303@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man 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, 31 Aug 2013 20:50:27 -0000 On 08/31/2013 04:58 PM, Brian E Carpenter wrote: > >> 3. Terminology >> >> For the purposes of this document, the terms Extension Header, Header >> Chain, First Fragment, and Upper-layer Header are used as follows: >> >> Extension Header: >> >> Extension Headers are defined in Section 4 of [RFC2460]. >> [IANA-PROTO] provides a list of assigned Internet Protocol Numbers >> and designates which of those protocol numbers also represent >> extension headers. > > The final clause is totally incorrect - the IANA list does not (today) > identify extension headers. draft-ietf-6man-ext-transmit has the details > in its IANA Considerations. > > Assuming draft-ietf-6man-ext-transmit is approved, this will change, > but for that purpose you'd need a blocking (normative) reference > to draft-ietf-6man-ext-transmit to guarantee the correct sequence of > publication. I thought that's what we were intending (assuming draft-ietf-6man-ext-transmit goes smoothly) -- but I realize we missed the procedural piece of making sure of the correct sequence of publication. So I guess possible paths are: 1) Changing the above paragraph to something along the lines of: Extension Headers are defined in Section 4 of [RFC2460]. As a result of [draft-ietf-6man-ext-transmit], [IANA-PROTO] provides a list of assigned Internet Protocol Numbers and designates which of those protocol numbers also represent extension headers. (or something along these lines... please suggest alternative phrasing if deemed appropriate) 2) Change the above paragraph to: Extension Headers are defined in Section 4 of [RFC2460], and various extension headers have been specified in [RFC2460] itself and in other later documents. (which IMO would still be fine, since we don't really need to provide the full list here) Thoughts? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Sat Aug 31 18:28:52 2013 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 30DB011E81A3 for ; Sat, 31 Aug 2013 18:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OksRkHWWQfjz for ; Sat, 31 Aug 2013 18:28:51 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id A9A0311E8113 for ; Sat, 31 Aug 2013 18:28:51 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so3358719pdj.12 for ; Sat, 31 Aug 2013 18:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wRL4380KDY8xxX+vabnJZHghZZvP3y1QiKukXNnzak4=; b=MjpQxtzbo4lFVrvHeWX92sSYY8QPwREnMKbDq1jj7/hgLMvmIpn9aM0eeL9wYaRmoC a8fX2aAS7lkvre0jjjan6waUhCYoLY3O+AWjA0ckooXR9RddYynyjui2c/O8LyrfnoEU LX0+XMuj3+vxFjUNlIxGmPom68hEYDhxA/NqqTy8S03bfXJ9wD96W+C42ikoWOtf9K2/ QFHuZ+bwm7y76yB/tQtI4D7lg02rZhwGNd8t7EszB0iIe6Y+v5KyqJjzM7bBvh7Ufou8 1VDLXMSoAQ6/hmq7r6cBLlzypr3xkN+vxRSK/eSHZapGFMGVO/bfqrXuZ4wtnCJp5kUj jmRA== X-Received: by 10.68.130.200 with SMTP id og8mr3421721pbb.111.1377998927866; Sat, 31 Aug 2013 18:28:47 -0700 (PDT) Received: from [192.168.178.20] (30.199.69.111.dynamic.snap.net.nz. [111.69.199.30]) by mx.google.com with ESMTPSA id bb1sm6782044pbc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 18:28:47 -0700 (PDT) Message-ID: <5222984C.3050700@gmail.com> Date: Sun, 01 Sep 2013 13:28:44 +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: Definition of Extension Header in draft-ietf-6man-oversized-header-chain-05.txt (was Re: I-D Action: draft-ietf-6man-oversized-header-chain-05.txt) References: <20130831184916.11954.55055.idtracker@ietfa.amsl.com> <52224AF7.1090303@gmail.com> <522256FA.6030802@si6networks.com> In-Reply-To: <522256FA.6030802@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man 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, 01 Sep 2013 01:28:52 -0000 Hi Fernando, I'm biased, but I'd prefer the reference (your first suggestion), unless the ext-transmit draft gets stuck in the process, in which case you could make an editorial change later, even up to AUTH48. BTW check the IANA URL too; I think you had a pointer to a .txt file, but these days IANA is .xml based. Regards Brian On 01/09/2013 08:50, Fernando Gont wrote: > On 08/31/2013 04:58 PM, Brian E Carpenter wrote: >>> 3. Terminology >>> >>> For the purposes of this document, the terms Extension Header, Header >>> Chain, First Fragment, and Upper-layer Header are used as follows: >>> >>> Extension Header: >>> >>> Extension Headers are defined in Section 4 of [RFC2460]. >>> [IANA-PROTO] provides a list of assigned Internet Protocol Numbers >>> and designates which of those protocol numbers also represent >>> extension headers. >> The final clause is totally incorrect - the IANA list does not (today) >> identify extension headers. draft-ietf-6man-ext-transmit has the details >> in its IANA Considerations. >> >> Assuming draft-ietf-6man-ext-transmit is approved, this will change, >> but for that purpose you'd need a blocking (normative) reference >> to draft-ietf-6man-ext-transmit to guarantee the correct sequence of >> publication. > > I thought that's what we were intending (assuming > draft-ietf-6man-ext-transmit goes smoothly) -- but I realize we missed > the procedural piece of making sure of the correct sequence of > publication. So I guess possible paths are: > > 1) Changing the above paragraph to something along the lines of: > > Extension Headers are defined in Section 4 of [RFC2460]. > As a result of [draft-ietf-6man-ext-transmit], [IANA-PROTO] provides > a list of assigned Internet Protocol Numbers and designates which of > those protocol numbers also represent extension headers. > > (or something along these lines... please suggest alternative phrasing > if deemed appropriate) > > 2) Change the above paragraph to: > > Extension Headers are defined in Section 4 of [RFC2460], and various > extension headers have been specified in [RFC2460] itself and in > other later documents. > > (which IMO would still be fine, since we don't really need to provide > the full list here) > > Thoughts? > > Thanks! > > Cheers,